前回
Dockerfileを記述し、imageをbuildする方法を学んだ
Using the build chache
For each instrucion, Docker checks whether it cna reuse the instruction from a previos build
以前に似たようなinstruction(コマンド?)を実行していたら、dockerはcacheされた結果を利用して高速に処理を完了する
ただし以下の場合は無効
- RUNコマンドに変更があった場合
- COPYやADDによりimageにfileがコピーされた場合
- cacheがinvalidatedされたlayer以降のinstrucion
RUN, COPY, ADDには注意しろってこと?まあまだ使うことすらままんらないのに高速化とか気にしてもしゃーない気もするが
try it out
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
EXPOSE 3000
CMD ["node", "./src/index.js"]
FROM node:20-alpine
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --production
COPY . .
EXPOSE 3000
CMD ["node", "src/index.js"]
上よりも下のほうがcacheの観点からみるといいらしい。共通項としてpackage.jsonを定義したほうが質のいいcacheになるから?
まだnodeもyarnも触ったことないからよくわからん。anacondaみたいな感じでbaseとなるpackege一覧を最初にぶっこんどく的な?
Multi-stage build
By separating the build environment from the final runtime environment,, you can significantly reduce the image size and attack surface.
buildを分割することで小さくする?現状意味がわからない
try it out
FROM eclipse-temurin:21.0.2_13-jdk-jammy
WORKDIR /app
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline
COPY src ./src
CMD ["./mvnw", "spring-boot:run"]
- 解凍したdirにcd.
docker image build -t spring-helloworld .
- imageがbuildされた
- 動作確認 'docker run -d -p 8080:8080 spring-helloworld'
- ふぁっ!??
- 本当はこの後Dockerfileを
FROM eclipse-temurin:21.0.2_13-jdk-jammy AS builder
WORKDIR /opt/app
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline
COPY ./src ./src
RUN ./mvnw clean install
FROM eclipse-temurin:21.0.2_13-jre-jammy AS final
WORKDIR /opt/app
EXPOSE 8080
COPY --from=builder /opt/app/target/*.jar /opt/app/*.jar
ENTRYPOINT ["java", "-jar", "/opt/app/*.jar"]
のように分割して、ほらあなたのfinalimageは428MBになったよ。オリジナルは880MBなのにね!みたいなストーリー。
いや、今ところは400MB削減することよりも別のところに学習コストかけたほうがいい気がするんだが。。
ってことで今日はここまで。確かに有意義そうな内容ではあるけど、まだdockerよわよわな自分にとってはハードル高すぎるんでいったんスキップ。何の成果も得られなかったけど許してクレメンス