从 docker-compose 构建和使用 docker 镜像

Vas*_*asu 5 docker docker-compose

我有一个 Dockerfile,它创建了一个包含我的图像需要运行的所有依赖项的图像。然后,我将文件挂载为只读数据卷,并将各种文件设置为入口点。虽然这意味着我不需要有多个 Dockerfile,但出于某种原因,每次我向 docker-compose 文件添加新服务时,我都会创建一个新图像(尽管它看起来只是从缓存中提取)。有没有办法让 docker-compose 文件构建一次镜像,然后让所有服务都依赖于这个新构建的镜像?

我知道可以单独构建映像,为其命名,然后让 docker-compose 文件引用该映像,但这需要 2 个命令,而不是docker-compose up我现在使用的单个命令。

这是我的docker images输出的样子。您可以看到每个服务都在创建自己的映像,我不喜欢这种情况。我不完全确定这是否意味着每个图像在磁盘上占用了额外的 1.3GB,或者它们是否都只是引用相同的基本图像(我猜是后者,但很想知道),但它仍然会污染 docker 图像列表。

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
Run Code Online (Sandbox Code Playgroud)

当前的 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)"
Run Code Online (Sandbox Code Playgroud)

另外,如果有关于如何改进 docker-compose 文件的任何建议,我很想听听他们的意见,但我相信这是另一个问题。

ste*_*epf 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
        [...]
Run Code Online (Sandbox Code Playgroud)

请注意,这种方法非常脆弱。重命名父文件夹或服务本身都会导致问题。如果docker-compose以错误的顺序启动服务,启动某些服务将失败或依赖可能过时的映像。

我知道可以单独构建映像,为其命名,然后让 docker-compose 文件引用该映像,但这需要 2 个命令,而不是我现在使用的单个 docker-compose up。

我仍然鼓励你这样做。它使事情更加一致(而且更快!)。开发镜像和测试多容器应用程序是两件不同的事情,应该分别对待。