Compose Spec の変遷と Cloud Run のイマ 〜なぜ gcloud は docker-compose.yaml に対応した？〜 14th Apr, Jagu'e'r Cloud Native #22 『0ベースから学ぶ、クラウドネイティブの春！』 Speaker: Kento Kimura 

> who am i? self_intro: name: “Kento Kimura” age: 28 company: “Datadog” role: sales_engineer communities: - name: “Jagu‘e’r” description: “Japan Google Cloud Usergroup for Enterprise” - name: “JDDUG” description: “Japan Datadog User Group” - name: “JAWS-UG” description: “Japan AWS User Group” conferences: - name: “GCTS” description: “Google Cloud Community Tech Surge” - name: “o11yconjp” description: “Observability Conference Tokyo” 

話すひと ● 所属： Technical Solutions / Sales Engineering ● コミュニティ： Jagu'e'r 歴4年 昨年 Jagu'e'r Leader になりました🐯 ● 本を書きました： SRE Magazine Vol.01 木村 健人 (Kento Kimura) Datadog Japan GK 

Cloud Run が docker-compose.yaml に対応🎉🎉 ローカルと本番、同じファイルで。 ※Cloud Run services は2023年に複数コンテナのデプロイに対応したが、ローカルと本番のファイルを分ける必要があった 

Hello!! Compose Specification 

コンテナ① コンテナ② Compose Specification って？ 「Docker Compose のフォーマットをオープンにした仕様」 複数のコンテナを依存関係や リソース制限と共に定義できる 宣言的なファイルの仕様(.yaml) services: web: build: . ports: - "${APP_PORT}:5000" environment: - REDIS_HOST=${REDIS_HOST} - REDIS_PORT=${REDIS_PORT} depends_on: redis: condition: service_healthy redis: image: redis:alpine healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s timeout: 3s retries: 5 start_period: 10s 

Compose Specification って？ 「Docker Compose format v2/v3 の分裂を解消するオープン仕様」 2016~17年、コンテナオーケストレーションに力を入れていた Docker 社は Docker Swarm への統合で v3 を発表しリソース制限を deploy.resouces に移動した v2(ローカル向け) v3(本番・Swarm 向け) cpus: “0.5” cpus: mem_limit: 512m mem_limit: depends_on: depends_on: deploy: 

Compose Specification って？ 「Docker Compose format v2/v3 の分裂を解消するオープン仕様」 2016~17年、コンテナオーケストレーションに力を入れていた Docker 社は Docker Swarm への統合で v3 を発表しリソース制限を deploy.resouces に移動した v2(ローカル向け) v3(本番・Swarm 向け) cpus: “0.5” cpus: mem_limit: 512m mem_limit: depends_on: depends_on: deploy: Docker Swarm 使わない ＝ v2 の方が便利 

Compose Specification の仕様 Docker Compose format v2/v3 のいいとこ取りをして、バージョンを廃止 x-{name} フィールドは特定のツールが利用・利用しない場合は無視する →拡張機能によって、ローカル/AWS/ Azure/ Google Cloud で共通利用できる v2 Services, networks, volumes v3 configs, secrets new x-{name} 廃止 version 

Compose Specification の仕様 Docker Compose format v2/v3 のいいとこ取りをして、バージョンを廃止 x-{name} フィールドは特定のツールが利用・利用しない場合は無視する →拡張機能によって、ローカル/AWS/ Azure/ Google Cloud で共通利用できる v2 Services, networks, volumes v3 configs, secrets new x-{name} 廃止 version どうしてこうなった？？ 

Docker と Compose 年表 2014 Docker が Fig を買収 Docker-compose に リネームされる(v1) 2016 services/networks/ volumes の分離(v2) 2017 オーケストレーション の Swarm 対応(v3) ローカルは v2 が併存 2020 Compose Spec として 単一仕様の OSS 化 v2/v3 の分裂を解消 →AWS / Azure 対応 2020 Docker 社の縮小で、 compose-cli 廃止 →ツールはクラウド側 次第 2025-26 Cloud Run の Compose 対応の 発表・GA 

Docker と Compose 年表 2014 Docker が Fig を買収 Docker-compose に リネームされる(v1) 2016 services/networks/ volumes の分離(v2) 2017 オーケストレーション の Swarm 対応(v3) ローカルは v2 が併存 2020 Compose Spec として 単一仕様の OSS 化 v2/v3 の分裂を解消 →AWS / Azure 対応 2020 Docker 社の縮小で、 compose-cli 廃止 →ツールはクラウド側 次第 2025-26 Cloud Run の Compose 対応の 発表・GA コンテナ オーケスト レーション 戦争 Swarm の実質的な 敗北 Docker 分裂 による 専用 CLI 廃止 ベンダー対応 による復活 

Compose Spec/tool 年表 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 Docker 分裂 Native CLI ツール 分裂 買収 廃止 Fig Specification Implementation OSS 化 Docker tools docker-compose v1 Docker Compose v2 v1 Python(v1~3) v2 AWS Swarm Google v3 Go(v5) compose-cli ECS ACI Cloud Run ACA Compose Specification Azure ECS Compose-x(OSS) 

Cloud Run ❤ Compose Specification 

Compose Specification for Cloud Run の仕様① Compose フィールド Cloud Run のマッピングと説明 services サービスは、デプロイされた Cloud Run サービスの個々のコンテナにマッピング volumes bind, volume, tmpfs マウントを Cloud Run の同等のマウントに変換 secrets Secret Manager を使用 configs Cloud Storage の使用 build コンテナビルドの指定・再ビルドの強制 image Docker Hub と Artifact Registry のイメージをサポート ports 8080:8080 などのポート マッピングのリスト。上り（内向き）コンテナを決定 expose 依存サービスが通信に使用できるポートを確保 depends_on コンテナの起動順序を定義 

Compose Specification for Cloud Run の仕様② Compose フィールド Cloud Run のマッピングと説明 cpus Cloud Run の CPU とメモリの上限を設定 (~2 CPU→1Gi Mem/~4 CPU→2Gi Mem/4~ CPU→4Gi Mem) container_name コンテナの名前。デフォルトでサービス名と同じ environment 環境変数を対応するコンテナに渡す command Cloud Run の args 属性にマッピングしてオーバーライド entrypoint サポート対象 env_file サポート対象 x-google-cloudrun: ingress-container （拡張機能）すべての外部トラフィックを受信する Ingress コンテナとしてマーク x-google-cloudrun: volume-type: in-memory （拡張機能）n-memory ボリュームを設定 

gcloud run compose up をしよう！ gcloud コマンドで docker-compose.yaml から Cloud Run services をデプロイする 1. ‘run-compose’ コンポーネント(compose.yaml の変換ツール)をインストールする $ sudo apt-get install google-cloud-cli-run-compose 2. Cloud Run 対応フィールドを確認する a. 無効なフィールドの削除 b. 拡張機能(x-google-cloudrun:)の追加 3. しばらく待つ…(yaml 変換・コンテナビルド・サービス名決定) リージョンの選択後、‘Setting up resources…’ が表示(‘run-compose’で変換) 4. ディレクトリ名をサービス名として Cloud Run services が起動 ※ディレクトリ名に無効な文字(_ など)が含まれている場合起動に失敗 

Cloud Run docker-compose.yaml cloud-run.yaml run-compose OR Artifact Registry Cloud Deploy Cloud Shell Google Cloud Cloud Deploy gcloud run compose up Google Cloud CLI Build Deploy gcloud run compose up のアーキテクチャ 

Thank you