windows - 通过 docker-compose 将 build-args 传递给 Dockerfile 的奇怪行为

Question

我正面临一个奇怪的问题(或者更好:两个不同的奇怪问题)试图通过 build-arg s 给我的 Dockerfile通过 docker-compose up .
我的文件 - 初始设置Dockerfile :

ARG  NODE_VERSION
FROM node:${NODE_VERSION}

ARG NPM_REGISTRY_TOKEN
RUN echo "=====> token ${NPM_REGISTRY_TOKEN}"
... ... ...

docker-compose.yml :

version: '3'
services:
  myservice:
    build:
      context: ./myservice
      dockerfile: ../Dockerfile
      args:
        - NODE_VERSION=10.15.1-alpine
        - NPM_REGISTRY_TOKEN

有了这个初始设置，我有以下行为(在 Linux Mint 20 上，docker-compose 版本 1.26.2，构建 eefe0d31):

运行 docker build --build-arg NPM_REGISTRY_TOKEN=xyz123在输出中产生 =====> token xyz123 : NPM_REGISTRY_TOKEN arg 流向 Dockerfile

运行 docker-compose build --build-arg NPM_REGISTRY_TOKEN=xyz123 myservice在输出中产生 =====> token xyz123 : NPM_REGISTRY_TOKEN arg 流向 Dockerfile

运行 NPM_REGISTRY_TOKEN=xyz123 docker-compose up myservice在输出中产生 =====> token : NPM_REGISTRY_TOKEN env arg 应该流向 Dockerfile由于 - NPM_REGISTRY_TOKEN (根据 https://docs.docker.com/compose/compose-file/#args :您可以在指定构建参数时省略该值，在这种情况下，它在构建时的值是 Compose 运行环境中的值)但它似乎在构建期间不可用

我的文件 - 重新加载
只需更换我的 docker-compose.yml归档到

version: '3'
services:
  myservice:
    build:
      context: ./myservice
      args:
        - NODE_VERSION=10.15.1-alpine
        - NPM_REGISTRY_TOKEN
      dockerfile: ../Dockerfile

似乎解决了问题:切换 args和 dockerfile yml 文件中的条目解锁了将环境变量传递给 Dockerfile 的功能如 build-arg s 通过 docker-compose up ， 也。 问题解决了。或不？
更改操作系统，遇到新问题
因此，我团队中的开发人员也使用多种不同的操作系统:Linux、Mac Os 和 Windows。
在 docker-compose 的相同版本 (1.26.2) 上运行相同的命令在 Windows 10 Professional 1909 上，我们遇到了最初遇到的相同问题，两者都使用 docker-compose.yml 的初始版本。文件并使用适用于 Linux 的版本。
我们尝试从命令行传递 env var，在命令提示符中设置它们，通过 GUI 将它们设置为系统变量......我们尝试启动 docker-compose up为 git-bash ，但我们无法在 Dockerfile 中获取变量值.
我在谷歌上搜索了一下，但没有发现任何对已知错误或 Windows 版本限制的引用 docker-compose .
任何人都知道问题可能是什么？非常感谢您提前!

Answer 1

所以，最后，在不同的操作系统和不同的配置上进行了一些尝试和失败之后，我最终解释了我的问题 - 因此有了一个可行的解决方法，这使我能够为我的 docker-compose-yml 找到一个令人满意的配置。文件。
简答 :这不是操作系统的问题，也不是环境变量传递的问题，也不是 context 的顺序的问题/dockerfile部分 - 这是我的撰写文件中不同服务之间的冲突问题。
更详细 : 我的 docker-compose.yml文件也包含一个额外的服务，它的工作是初始化应用程序指向的数据库:

version: '3'
services:
  myservice:
    build:
      context: ./myservice
      dockerfile: ../Dockerfile
      args:
        - NODE_VERSION=10.15.1-alpine
        - NPM_REGISTRY_TOKEN
    depends_on:
      - persistence
      - db_initializer
    command: sh -c './wait-for localhost:5432 -- ./wait-for localhost:15672 -- npm run start:dev'
  persistence:
    # Setting up the DBMS here
  db_initializer:
    build:
      context: ./myservice
      dockerfile: ../Dockerfile
      args:
        - NODE_VERSION=10.15.1-alpine
    depends_on:
      - persistence
    command: sh -c './wait-for localhost:5432 -- ./wait-for localhost:15672 -- npm run db:migrate'

所以，问题是我正在配置 两个基于相同的自构建镜像的服务，使用不同的命令启动它( npm run db:migrate 用于 db_initializer 服务， npm run start:dev 用于应用程序服务)。显然 compose 采用了为第一个初始化服务提供的配置( db_initializer ，因为 myservice 依赖于它)并将该配置用于两个服务，忽略(不同的) args我为第二个容器提供的部分:所以我能够解决(这次是真的!)这个问题只是合并服务声明，包括所有 args我需要:

version: '3'
services:
  myservice:
    build:
      context: ./myservice
      dockerfile: ../Dockerfile
      args:
        - NODE_VERSION=10.15.1-alpine
        - NPM_REGISTRY_TOKEN
    depends_on:
      - persistence
      - db_initializer
    command: sh -c './wait-for localhost:5432 -- ./wait-for localhost:15672 -- run db:migrate && npm run start:dev'
  persistence:
    # Setting up the DBMS here

所以，在几个月没有收集答案之后，我认为是时候分享我的经验了，希望它可以帮助遇到这种奇怪行为的人。