從docker-compose構建和使用docker鏡像

Question

我有一個Dockerfile，它創建一個包含我的圖像需要運行的所有依賴項的圖像。 然后，我將文件作為只讀數據卷掛載，並將各種文件設置為入口點。 雖然這意味着我不需要多個Dockerfiles，但由於某種原因，每次我向docker-compose文件添加新服務時，我都會創建一個新圖像（雖然看起來它只是從緩存中拉出來）。 有沒有辦法讓docker-compose文件構建一次圖像，然后讓所有服務依賴於新構建的圖像？

我知道可以單獨構建映像，給它起一個名字，然后讓docker-compose文件引用該映像，但這需要2個命令而不是我現在使用的單個docker-compose up 。

這是我的docker images輸出的樣子。 您可以看到每個服務都創建了自己的圖像，這是我不喜歡的。 我不完全確定這是否意味着每個圖像在磁盤上占用額外的1.3gb，或者它們是否只是引用相同的基本圖像（我猜是后者，但是很想知道肯定的），但它仍然污染碼頭圖像列表。

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
docker_http_server_1   latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_test_client     latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_test_client_3   latest              a6eac9198c44        5 weeks ago         1.315 GB
meh                    latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_data_server_1   latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_server1         latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_server2         latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_server          latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_test_client_2   latest              a6eac9198c44        5 weeks ago         1.315 GB
docker_http_server_2   latest              a6eac9198c44        5 weeks ago         1.315 GB
<none>                 <none>              9428e39bd080        5 weeks ago         431.7 MB
<none>                 <none>              08a27b512ded        5 weeks ago         430.3 MB
<none>                 <none>              acc3e230ecaa        5 weeks ago         411.1 MB
<none>                 <none>              96c74b6e7d9d        5 weeks ago         829.2 MB
<none>                 <none>              acf4a5ef1eeb        5 weeks ago         677 MB
<none>                 <none>              8f646f9a5352        5 weeks ago         2.759 GB
<none>                 <none>              ce8fa0a27cde        5 weeks ago         562.3 MB
<none>                 <none>              533cfe78e0d2        5 weeks ago         165.6 MB
redis                  latest              0d1cbfaa41da        7 weeks ago         185 MB
ubuntu                 16.04               bd3d4369aebc        7 weeks ago         126.6 MB
nginx                  latest              4efb2fcdb1ab        8 weeks ago         183.4 MB
hello-world            latest              c54a2cc56cbb        3 months ago        1.848 kB

當前的docker-compose文件：

version: '2'
services:
    data_server_1:
        build: .
        volumes:
            - "..:/buggy:ro"
        entrypoint: "/buggy/buggy_data_server.py"

    http_server_1:
        build: .
        volumes:
            - "..:/buggy:ro"
        entrypoint: "/buggy/buggy_http_server.py"
        links:
            - data_server_1 

    http_server_2:
        build: .
        volumes:
            - "..:/buggy:ro"
        entrypoint: "/buggy/buggy_http_server.py"
        links:
            - data_server_1 

    nginx:
        image: nginx
        ports:
            - "80:80"
            - "443:443"
            - "4242:4242"
        links:
            - data_server_1 
            - http_server_1 
            - http_server_2
        volumes:
            - "../nginx/nginx.conf:/etc/nginx/nginx.conf:ro"
            - "../static:/www/static"
            - "../protos:/www/protos"

    # This is effectively the same as running it on the host machine and host
    # network rather than within the docker network. This is so that we can test
    # to ensure that the tcp listening port works via the public interface
    # rather than through the docker channels.
    test_client:
        build: .
        network_mode: "host"
        volumes:
            - "..:/buggy:ro"
        entrypoint:
            - "/buggy/test_client.py"
            - "--key=/buggy/keys/robot1.key"
            - "--no-gui"
            - "--status"
            - "--buggy-name=Deep Mind (Status)"

    test_client_2:
        build: .
        network_mode: "host"
        volumes:
            - "..:/buggy:ro"
        entrypoint:
            - "/buggy/test_client.py"
            - "--key=/buggy/keys/robot2.key"
            - "--no-gui"
            - "--imu"
            - "--buggy-name=Bender (IMU)"

    test_client_3:
        build: .
        network_mode: "host"
        volumes:
            - "..:/buggy:ro"
        entrypoint:
            - "/buggy/test_client.py"
            - "--key=/buggy/keys/robot3.key"
            - "--no-gui"
            - "--camera"
            - "--buggy-name=Megatron (Camera)"

此外，如果有任何關於如何改進docker-compose文件的建議，我很樂意聽到它們，但我相信這是另一個問題。

Answer 1

如果您正在尋找更復雜的構建選項，您可能希望在Compose之外查看。 正如在其他答案中所說，這里有兩個問題（1.構建圖像，2。運行容器）。 Compose專注於運行容器。

您可以使用dobi （免責聲明：我是dobi的作者）來構建您的圖像，並啟動Compose。 你的dobi.yaml可能如下所示：

image=app:
  image: reponame/appname
  tags: [latest]

compose=dev:
  files: [docker-compose.yml]
  project: '{project}'
  depends: [app]

您可以使用dobi dev運行以構建映像（一次）並啟動Compose（相當於docker-compose up -d 。要獲取交互式日志，您可以運行dobi dev:attach 。

您還必須刪除build: . 從你docker-compose.yml取而代之的是image: reponame/appname:latest

Answer 2

我不完全確定這是否意味着每個圖像在磁盤上占用額外的1.3gb，或者它們是否只是引用相同的基本圖像

它們都引用相同的圖像ID反映的相同基本圖像。 容器名稱的行為類似於符號鏈接。

有沒有辦法讓docker-compose文件構建一次圖像，然后讓所有服務依賴於新構建的圖像？

您可以通過僅構建一次圖像並在您的撰寫文件中相應地引用它來解決此問題，例如

version: '2'
services:
    data_server_1:
        build: .
        [...]

    http_server_1:
        image: docker_data_server_1
        [...]

    http_server_2:
        image: docker_data_server_1
        [...]

請注意，方法非常脆弱。 重命名父文件夾或服務本身將導致問題。 如果docker-compose以錯誤的順序旋轉服務，則啟動某些服務將失敗或依賴於可能過時的圖像。

我知道可以單獨構建圖像，給它起一個名字，然后讓docker-compose文件引用該圖像，但這需要2個命令而不是我現在使用的單個docker-compose up。

我仍然鼓勵你這樣做。 它使事情更加一致（並且更快！）。 開發圖像和測試多容器應用程序是兩回事，應該相應地對待。