Skip to content
所有文章 ‹ Part 04 of 09 · 從筆電連上遠端資料庫
工程 · 1 min read

docker-compose 的 image vs build:差在來源,不是有沒有映像

docker-compose 的 image: 和 build: 最後都跑一個映像,分岔只在映像從哪來;而 build.context 是必填,因為 COPY 是相對 context 解析的。

image: 和 build: 最後跑的都是一個映像,Docker 從不直接跑原始碼。分岔在於映像從哪來:

image: 從 registry 拉現成的 build: 用本地 Dockerfile + 檔案編出來 run 一個映像 兩者最後都跑一個映像,分岔只在它從哪來
image: 拉現成、build: 本地編:兩者最後都跑映像,差別只在 provenance。
指令映像來源需要本地 build?
image:從 registry 拉現成的❌
build.context:用本地 Dockerfile + 檔案編出來✅(首次執行 / --build)

build.context 對 build 來說是必填。你沒辦法「只指一個 Dockerfile」。context 是交給 daemon 的那棵檔案樹。COPY x 是相對於 context 解析的,所以沒有 context 就沒東西可 copy。(dockerfile: 只是點名用哪份食譜,context: 還是要給。)兩個一起用,就是在命名一個本地編出來的映像。

這次的實例: ClickHouse 服務用 build: {context: ./clickhouse-portforward},因為沒有現成映像同時打包 gcloud + kubectl + auth-plugin + entrypoint。Cloud SQL 服務用 image:(公開的 gce-proxy),所以不需要 build。

image: 拉現成、build: 本地編:兩者最後都跑映像,差別只在 provenance。


參考來源

Related: 回到遠端資料庫連線總覽。接著看 COPY 烤進映像、volume 即時掛載。

↑↓ 移動 ↵ 開啟 esc 關閉