Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Compose Spec の変遷と Cloud Run のイマ / The History ...
Search
Kento Kimura
PRO
April 14, 2026
Resources
Technology
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Compose Spec の変遷と Cloud Run のイマ / The History of Compose Spec and Cloud Run Support
Kento Kimura
PRO
April 14, 2026
Resources
0ベースから学ぶ、クラウドネイティブの春!
https://jaguer-cloud-native.connpass.com/event/387350/
More Decks by Kento Kimura
See All by Kento Kimura
頼れる Agentic AI を支える Datadog のオブザーバビリティ / Powering Reliable Agentic AI with Datadog Observability
aoto
PRO
0
430
作りっぱなしで終わらせない! 価値を出し続ける AI エージェントのための「信頼性」設計 / Designing Reliability for AI Agents that Deliver Continuous Value
aoto
PRO
2
420
Google に学ぶ、安全性を高める信頼性設計 / Reliability Design for Enhanced Safety: Lessons from Google SRE
aoto
PRO
0
92
AI エージェントで AI エージェントを作る!Google Cloudが実現するフルスタックな AI 開発エコシステム / Building AI Agents with AI Agents! Full-Stack AI Development Ecosystem on Google Cloud
aoto
PRO
0
390
Jagu'e'r Advent Calendar でコミュニティを盛り上げよう / Join us the community with Jagu'e'r Advent Calendar
aoto
PRO
0
81
現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability
aoto
PRO
1
1.6k
「最速」で Gemini CLI を使いこなそう! 〜Cloud Shell/Cloud Run の活用〜 / The Fastest Way to Master the Gemini CLI — with Cloud Shell and Cloud Run
aoto
PRO
1
450
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
1.2k
予測から調査へ、AI エージェントで叶える AIOps の未来 / From Prediction to Investigation: The Future of AIOps with AI Agents
aoto
PRO
0
220
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructure:2026年6月度サービス・アップデート
oracle4engineer
PRO
1
370
IaC コードを資産へ:AWS CDK 社内ライブラリと横断展開 / aws-summit-japan-2026
gotok365
10
1.6k
Zenoh on Zephyr on LiteX
takasehideki
2
130
AWS Security Hub CSPMの成功・失敗体験
cmusudakeisuke
0
590
MySQL & MySQL HeatWave Report - June 2026
freshdaz
0
200
Hatena Engineer Seminar 37 jj1uzh
jj1uzh
0
150
AIは、人間らしい仕事の夢を見るか?─ AI時代のtoB/toEプロダクトを再設計する
techtekt
PRO
0
160
AWS Summit 2026で見えたSIerにとっての Amazon Quickの位置づけ
maf_0521
0
110
秘密度ラベル初心者が第1歩でつまづかないための「設計・運用」ポイント
seafay
PRO
1
510
AI Agentをシステムに組み込む前にゆるく向き合ってみる
hayama17
0
170
From Prompt Engineering to Loop Engineering
shibuiwilliam
1
280
「勝手に広まる」人気 AI エージェントを爆速で作ろう!(AWS Summit Japan 2026講演資料)
minorun365
PRO
10
2.6k
Featured
See All Featured
Balancing Empowerment & Direction
lara
6
1.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The Spectacular Lies of Maps
axbom
PRO
1
820
Accessibility Awareness
sabderemane
1
140
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
310
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
New Earth Scene 8
popppiees
3
2.4k
We Are The Robots
honzajavorek
0
260
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
66
55k
BBQ
matthewcrist
89
10k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Transcript
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