Dive Deep in Cloud Run: Automatic Base Image update

Transcript

1. Dive Deep in Cloud Run: Automatic Base Image Update 30th Aug, Kento Kimura Jagu'e'r CloudNative #15『大人の夏休み自由研究ビアバッシュLT』
2. Self-Introduction • 所属：Technical Solutions / Sales Engineer • 担当：パブリッククラウドのアーキテクト知識を活かした 　Datadog のプリセールス技術支援 • 資格：Google Cloud 全 11 資格、AWS 10 資格、Azure 12 資格 • 表彰：Google Cloud Partner Top Engineer 2023-24 Jagu'e'r Award 2023 優秀賞 木村 健人 (Kento Kimura) Datadog Japan GK Technical Solutions Sales Engineering History データセンター運用保守 → パブリッククラウド技術支援 → プリセールス技術支援 Community Jagu’e’r デジクラ人材育成分科会 運営リード O11y-SRE/CloudNative/TechWriters 分科会 運営メンバー Partner Top Engineer 2023 Partner Top Engineer 2024
3. 4 What’s this
4. Automatic Base Image Update • Google Cloud Next ’24 で Private Preview Cloud Run のソースコードデプロイ機能利用時に、ベースイメージを指定してのデプロイが可能 ベースイメージの更新時にデフォルトで自動更新、--clear-base-image で自動更新の無効化も可能 5 • 2024/8/21 に Public Preview コンテナデプロイでも実行イメージを FROM scratch とするマルチステージビルドの場合、 ビルドイメージのベースイメージを指定できるように！ gcloud run deploy <SERVICE_NAME> \ --source \ --base-image=<REGISTORY_PATH> gcloud run deploy <SERVICE_NAME> \ --image=<IMAGE_NAME> \ --base-image=<BASE_IMAGE>
5. Automatic Base Image Update • Google Cloud Next ’24 で Private Preview Cloud Run のソースコードデプロイ機能利用時に、ベースイメージを指定してのデプロイが可能 ベースイメージの更新時にデフォルトで自動更新、--clear-base-image で自動更新の無効化も可能 • 裏側では Buildpack, Cloud Build が使われている • 0 downtime, 0 rebuild • 48時間以内に脆弱性に対応するパッチを配布 6 • 2024/8/21 に Public Preview コンテナデプロイでも実行イメージを FROM scratch とするマルチステージビルドの場合、 ビルドイメージのベースイメージを指定できるように！ • マルチステージビルド理解する必要… gcloud run deploy <SERVICE_NAME> \ --source \ --base-image=<REGISTORY_PATH> gcloud run deploy <SERVICE_NAME> \ --image=<IMAGE_NAME> \ --base-image=<BASE_IMAGE>
6. 7 Dive Deep
7. 8 Multi Stage Build マルチステージビルドのポイント マルチステージビルドで Dockerfile の可読性・ 保守性を向上し、軽量な実行イメージを作成できる • Dockerfile の中で複数の FROM 命令文を利用 • 各 FROM 命令文で異なるベースを用いる • 実行ステージでは必要な成果物のみをコピー • 一般的にはビルドと実行でステージを分ける • AS[名前] で各ステージを命名できる • ビルド時に --target で特定ステージのみ指定 • BuildKit を利用すると依存ステージのみビルド • 外部イメージもステージとして利用可能 # syntax=docker/dockerfile:1 FROM golang:1.21 AS builder WORKDIR /src COPY <<EOF ./main.go package main import "fmt" func main() { fmt.Println("hello, world") } EOF RUN go build -o /bin/hello ./main.go FROM scratch COPY --from=builder /bin/hello /bin/hello CMD ["/bin/hello"] ◆ 引用 • docker.docs 『Multi-stage builds』 https://docs.docker.com/build/building/multi-stage/#use-a-previous-stage-as-a-new-stage
8. 9 Multi Stage Build マルチステージビルドを簡単に説明 ビルドステージで作成されたイメージから 必要な成果物だけをコピーして、実行ステージで 最小限の製品イメージを作成する FROM scratch では何も実行されず、Dockerfile に イメージに追加のレイヤーは作成されない 実行ステージで FROM scratch を利用してステージ を開始して FROM --from=ステージ名 で最初のレイ ヤーとして必要なものだけを持ってくる # おまじない FROM ビルドするためのイメージ AS 名前 WORKDIR /アプリを置く場所 COPY コードを持ってくる RUN コンパイルやビルドをする FROM 実行するためのイメージ AS 名前 COPY --from=ステージ名 成果物を持ってくる CMD ["エントリーポイント "] ビルドステージ 実行ステージ layer3 layer2 layer1 layer1 artifact build image scratch COPY
9. 10 CloudNative Buildpacks(CNB) CNB はマルチステージビルドを前提としている Google Cloud も gcr.io/buildpacks/builder いう Builder を提供していて、 Cloud Run, App Engine で利用されている！ Stack Buildpack が使用するマルチステー ジビルドのコンテナイメージ • Build image アプリのビルドに使用する コンテナイメージ • Run image アプリの実行に使用する コンテナイメージ Builder 前述の Stack と Buildpack の集合の 組み合わせ Buildpack 特定構成のアプリに対する 複数のビルドプロセス • Detect ビルド対象アプリが Buildpack の 対象構成か判定するプロセス • Build 実際にコンテナイメージをビルドす るプロセス
10. 11 CloudNative Buildpacks(CNB) Rebase pack rebase のはなし • アプリのイメージを検査することで、pack rebase はアプリのベースイメージの 新しいバージョンが存在するかどうかを判断する • 存在すれば、rebase はアプリのレイヤメタデータを更新し、 新しいバージョンのベースイメージを参照する • めっちゃ便利 exec exec artifact artifact base-image new-base-image rebase
11. 12 CloudNative Buildpacks(CNB) イメージ拡張(image extension) のはなし • ビルドイメージ・実行イメージのベースイメージを独立して拡張・入替できる • Dockerfile で定義した内容を参照して、ベースイメージだけを入替する ◦ FROM scratch で作成した実行イメージはベースイメージなし ◦ アプリケーション実行に必要なランタイムなどが含まれたベースイメージを加える layer3 layer2 exec exec layer1 artifact artifact build image scratch base-image COPY rebase
12. 13 Key takeaways
13. 14 Matome • Cloud Run のベースイメージ自動更新機能は ソースコード・コンテナデプロイのどちらでもできる • Cloud Run のコンテナイメージ作成は CloudNative Buildpack(CNB) が使われている • リビルドなしのイメージ更新は マルチステージビルドと CNB のおかげ(推測) • 続きはブログで…(鋭意執筆中)
14. Thank you