Dive Deep in Cloud Run: Automatic Base Image Update 30th Aug, Kento Kimura Jagu'e'r CloudNative #15『大人の夏休み自由研究ビアバッシュLT』

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

4 What’s this

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 \ --source \ --base-image= gcloud run deploy \ --image= \ --base-image=

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 \ --source \ --base-image= gcloud run deploy \ --image= \ --base-image=

7 Dive Deep

8 Multi Stage Build マルチステージビルドのポイント マルチステージビルドで Dockerfile の可読性・ 保守性を向上し、軽量な実行イメージを作成できる ● Dockerfile の中で複数の FROM 命令文を利用 ● 各 FROM 命令文で異なるベースを用いる ● 実行ステージでは必要な成果物のみをコピー ● 一般的にはビルドと実行でステージを分ける ● AS[名前] で各ステージを命名できる ● ビルド時に --target で特定ステージのみ指定 ● BuildKit を利用すると依存ステージのみビルド ● 外部イメージもステージとして利用可能 # syntax=docker/dockerfile:1 FROM golang:1.21 AS builder WORKDIR /src COPY <

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

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 実際にコンテナイメージをビルドす るプロセス

11 CloudNative Buildpacks(CNB) Rebase pack rebase のはなし ● アプリのイメージを検査することで、pack rebase はアプリのベースイメージの 新しいバージョンが存在するかどうかを判断する ● 存在すれば、rebase はアプリのレイヤメタデータを更新し、 新しいバージョンのベースイメージを参照する ● めっちゃ便利 exec exec artifact artifact base-image new-base-image rebase

12 CloudNative Buildpacks(CNB) イメージ拡張(image extension) のはなし ● ビルドイメージ・実行イメージのベースイメージを独立して拡張・入替できる ● Dockerfile で定義した内容を参照して、ベースイメージだけを入替する ○ FROM scratch で作成した実行イメージはベースイメージなし ○ アプリケーション実行に必要なランタイムなどが含まれたベースイメージを加える layer3 layer2 exec exec layer1 artifact artifact build image scratch base-image COPY rebase

13 Key takeaways

14 Matome ● Cloud Run のベースイメージ自動更新機能は ソースコード・コンテナデプロイのどちらでもできる ● Cloud Run のコンテナイメージ作成は CloudNative Buildpack(CNB) が使われている ● リビルドなしのイメージ更新は マルチステージビルドと CNB のおかげ(推測) ● 続きはブログで…(鋭意執筆中)

Thank you