带有 docker/build-push-action 和 GitHub Actions 的生产环境文件答案

【问题标题】：Production ENV file with docker/build-push-action and GitHub Actions带有 docker/build-push-action 和 GitHub Actions 的生产环境文件
【发布时间】：2021-08-24 08:29:23
【问题描述】：

创建发布标签时，我有以下 docker/build-push-action 作业在我的 GitHub 操作中运行。

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      -
        name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      -
        name: Login to DockerHub
        uses: docker/login-action@v1 
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}
      -
        name: Build and push
        id: docker_build
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: user/repo:latest
      -
        name: Image digest
        run: echo ${{ steps.docker_build.outputs.digest }}

在我的Dockerfile 中，我有一个任务需要.env.production 并使其变为.env。

COPY .env.production .env

这显然失败了，因为 .env.production 不包含在 Git 中。

我的问题是，如何在我的 GitHub 操作中发生类似的事情？我曾考虑在 Build and push 之前创建 env 文件，但我认为该任务从 docker 容器中的 main 拉取，所以实际上看不到我创建的文件？或者如果有任何东西覆盖它。

实现这一目标的最佳方法是什么？

提前致谢

【问题讨论】：

标签： docker environment-variables github-actions dockerhub dotenv

【解决方案1】：

这是我想出来的。

Dockerfile

...
ARG ARG_ENV_SECRET
ARG ARG_ENV_SECRET_1
COPY ./env-script.sh ./
RUN ./env-script.sh
...

env-script.sh 此脚本创建 .env 文件

#!/bin/sh

touch .env
{
  printf "ENV_SECRET=%sENV_SECRET_1=%s" "$ARG_ENV_SECRET" "ARG_ENV_SECRET_1"
} >> .env

docker-action.yml

...

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Build, tag, and push the image to Amazon ECR
        id: build-image
        env:
          ENV_SECRET: ${{ secrets.ENV_SECRET }} #naming used below
          ENV_SECRET_1: ${{ secrets.ENV_SECRET_1 }}
        run: |
          docker \ 
           --build-arg ARG_ENV_SECRET=$ENV_SECRET #name declared above
           --build-arg ARG_ENV_SECRET_1=$ENV_SECRET_1
          build .
...

我很确定这不是最佳途径，但它对我们有用，因为我们使用第三方来运行我们的 AWS 服务。更好的方法是在启动实例时使用 AWS 机密。你可以阅读更多关于它的信息here。

【讨论】：