将环境变量中的 Django SECRET_KEY 传递给 Dockerized gunicorn
Pass Django SECRET_KEY in Environment Variable to Dockerized gunicorn
一些背景知识
最近我遇到了一个问题，我的 Django 应用程序正在使用基本设置文件，尽管 DJANGO_SETTINGS_MODULE 被设置为不同的设置文件。结果发现问题是 gunicorn 没有继承环境变量，解决方案是将 -e DJANGO_SETTINGS_MODULE=sasite.settings.production 添加到我称为 gunicorn 的 Dockerfile CMD 条目中。
问题
我在处理应用程序中的 SECRET_KEY 时遇到了问题。我将它设置在一个环境变量中，尽管我之前将它存储在 JSON 文件中，但这似乎不太安全（如果我错了请纠正我）。
问题的另一部分是，当使用 gunicorn 时，它不会继承通常在容器上设置的环境变量。如上所述，我 运行 使用 DJANGO_SETTINGS_MODULE 解决了这个问题。我想 gunicorn 也会遇到 SECRET_KEY 的问题。解决这个问题的方法是什么？
我目前的做法
我在环境变量中设置 SECRET_KEY 并将其加载到 django 设置文件中。我在包含 export SECRET_KEY=<secretkey> 的文件 "app-env" 中设置值，Dockerfile 包含 RUN source app-env 以便在容器中设置环境变量。
跟进问题
使用 Dockerfile 命令 ENV 设置环境变量 SECRET_KEY 而不是获取文件会更好吗？像这样在 Dockerfile 中硬编码密钥是否可以接受（似乎对我来说不是这样）？
是否有 "best practice" 用于处理 Dockerized 应用程序中的密钥？
如果事实证明它与环境变量一样安全，我总是可以回到 JSON。但是弄清楚人们如何处理 SECRET_KEY 和 gunicorn 的环境变量问题仍然很好。
代码
这是 Dockerfile：
FROM python:3.6
LABEL maintainer x@x.com
ARG requirements=requirements/production.txt
ENV DJANGO_SETTINGS_MODULE=sasite.settings.production_test
WORKDIR /app
COPY manage.py /app/
COPY requirements/ /app/requirements/
RUN pip install -r $requirements
COPY config config
COPY sasite sasite
COPY templates templates
COPY logs logs
COPY scripts scripts
RUN source app-env
EXPOSE 8001
CMD ["/usr/local/bin/gunicorn", "--config", "config/gunicorn.conf", "--log-config", "config/logging.conf", "-e", "DJANGO_SETTINGS_MODULE=sasite.settings.production_test", "-w", "4", "-b", "0.0.0.0:8001", "sasite.wsgi:application"]
我将从为什么它不能按原样工作开始，然后讨论您必须继续前进的选项：
在容器的构建过程中，单个 运行 指令是 运行 作为它自己的独立容器。后续层只会捕获对该容器写入层文件系统的更改。这意味着您的 source app-env 命令 运行s 并退出，并且可能不会对磁盘进行任何更改，从而使 运行 行成为空操作。
Docker 允许您在构建时使用 ENV 指令指定环境变量，您已使用 DJANGO_SETTINGS_MODULE 变量完成此操作。我不一定同意 SECRET_KEY 应该在这里指定，尽管在 Docker 文件中放置开发所需的值可能没问题。
由于 SECRET_KEY 变量对于不同的环境（暂存和生产）可能不同，因此在 运行 时设置该变量可能是有意义的。例如：
docker run -d -e SECRET_KEY=supersecretkey mydjangoproject
-e 选项是 --env 的缩写。此外，还有 --env-file，您可以传入一个包含变量和值的文件。如果您不直接使用 docker cli，那么您的 docker 客户端也应该能够在那里指定它们（例如 docker-compose 允许您在yaml)
在这种特定情况下，由于容器内部 知道需要哪些变量，因此您可以在运行时调用它。有两种方法可以做到这一点。首先是把CMD改成这样：
CMD source app-env && /usr/local/bin/gunicorn --config config/gunicorn.conf --log-config config/logging.conf -e DJANGO_SETTINGS_MODULE=sasite.settings.production_test -w 4 -b 0.0.0.0:8001 sasite.wsgi:application
这里使用了CMD的shell封装语法，而不是exec语法。这意味着 CMD 的整个参数将是 运行 inside /bin/sh -c ""
shell 将处理 运行ning source app-env 然后是你的 gunicorn 命令。
如果您需要在 运行 时更改命令，您需要记住在需要的地方指定 source app-env &&，这让我想到了另一种方法，即使用入口点脚本
Docker 中的 ENTRYPOINT 功能允许您在容器首次启动时处理任何必要的启动步骤。考虑以下入口点脚本：
#!/bin/bash
cd /app && source app-env && cd - && exec "$@"
这将明确地 cd 到 app-env 所在的位置，获取它，cd 回到 oldpwd 所在的位置，然后执行命令。现在，您可以在 运行 时间为此图像覆盖命令和工作目录，并使 app-env 文件中指定的任何变量处于活动状态。要使用此脚本，您需要将其添加到映像中的某处并确保其可执行，然后使用 ENTRYPOINT 指令在 Docker 文件中指定它：
ADD entrypoint.sh /entrypoint.sh
RUN chmod a+x /entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
使用入口点策略，您可以保持 CMD 不变，无需更改。
一些背景知识
最近我遇到了一个问题，我的 Django 应用程序正在使用基本设置文件，尽管 DJANGO_SETTINGS_MODULE 被设置为不同的设置文件。结果发现问题是 gunicorn 没有继承环境变量，解决方案是将 -e DJANGO_SETTINGS_MODULE=sasite.settings.production 添加到我称为 gunicorn 的 Dockerfile CMD 条目中。
问题
我在处理应用程序中的 SECRET_KEY 时遇到了问题。我将它设置在一个环境变量中，尽管我之前将它存储在 JSON 文件中，但这似乎不太安全（如果我错了请纠正我）。
问题的另一部分是，当使用 gunicorn 时，它不会继承通常在容器上设置的环境变量。如上所述，我 运行 使用 DJANGO_SETTINGS_MODULE 解决了这个问题。我想 gunicorn 也会遇到 SECRET_KEY 的问题。解决这个问题的方法是什么？
我目前的做法
我在环境变量中设置 SECRET_KEY 并将其加载到 django 设置文件中。我在包含 export SECRET_KEY=<secretkey> 的文件 "app-env" 中设置值，Dockerfile 包含 RUN source app-env 以便在容器中设置环境变量。
跟进问题
使用 Dockerfile 命令 ENV 设置环境变量 SECRET_KEY 而不是获取文件会更好吗？像这样在 Dockerfile 中硬编码密钥是否可以接受（似乎对我来说不是这样）？
是否有 "best practice" 用于处理 Dockerized 应用程序中的密钥？
如果事实证明它与环境变量一样安全，我总是可以回到 JSON。但是弄清楚人们如何处理 SECRET_KEY 和 gunicorn 的环境变量问题仍然很好。
代码
这是 Dockerfile：
FROM python:3.6
LABEL maintainer x@x.com
ARG requirements=requirements/production.txt
ENV DJANGO_SETTINGS_MODULE=sasite.settings.production_test
WORKDIR /app
COPY manage.py /app/
COPY requirements/ /app/requirements/
RUN pip install -r $requirements
COPY config config
COPY sasite sasite
COPY templates templates
COPY logs logs
COPY scripts scripts
RUN source app-env
EXPOSE 8001
CMD ["/usr/local/bin/gunicorn", "--config", "config/gunicorn.conf", "--log-config", "config/logging.conf", "-e", "DJANGO_SETTINGS_MODULE=sasite.settings.production_test", "-w", "4", "-b", "0.0.0.0:8001", "sasite.wsgi:application"]
我将从为什么它不能按原样工作开始，然后讨论您必须继续前进的选项：
在容器的构建过程中，单个 运行 指令是 运行 作为它自己的独立容器。后续层只会捕获对该容器写入层文件系统的更改。这意味着您的 source app-env 命令 运行s 并退出，并且可能不会对磁盘进行任何更改，从而使 运行 行成为空操作。
Docker 允许您在构建时使用 ENV 指令指定环境变量，您已使用 DJANGO_SETTINGS_MODULE 变量完成此操作。我不一定同意 SECRET_KEY 应该在这里指定，尽管在 Docker 文件中放置开发所需的值可能没问题。
由于 SECRET_KEY 变量对于不同的环境（暂存和生产）可能不同，因此在 运行 时设置该变量可能是有意义的。例如：
docker run -d -e SECRET_KEY=supersecretkey mydjangoproject
-e 选项是 --env 的缩写。此外，还有 --env-file，您可以传入一个包含变量和值的文件。如果您不直接使用 docker cli，那么您的 docker 客户端也应该能够在那里指定它们（例如 docker-compose 允许您在yaml)
在这种特定情况下，由于容器内部 知道需要哪些变量，因此您可以在运行时调用它。有两种方法可以做到这一点。首先是把CMD改成这样：
CMD source app-env && /usr/local/bin/gunicorn --config config/gunicorn.conf --log-config config/logging.conf -e DJANGO_SETTINGS_MODULE=sasite.settings.production_test -w 4 -b 0.0.0.0:8001 sasite.wsgi:application
这里使用了CMD的shell封装语法，而不是exec语法。这意味着 CMD 的整个参数将是 运行 inside /bin/sh -c ""
shell 将处理 运行ning source app-env 然后是你的 gunicorn 命令。
如果您需要在 运行 时更改命令，您需要记住在需要的地方指定 source app-env &&，这让我想到了另一种方法，即使用入口点脚本
Docker 中的 ENTRYPOINT 功能允许您在容器首次启动时处理任何必要的启动步骤。考虑以下入口点脚本：
#!/bin/bash
cd /app && source app-env && cd - && exec "$@"
这将明确地 cd 到 app-env 所在的位置，获取它，cd 回到 oldpwd 所在的位置，然后执行命令。现在，您可以在 运行 时间为此图像覆盖命令和工作目录，并使 app-env 文件中指定的任何变量处于活动状态。要使用此脚本，您需要将其添加到映像中的某处并确保其可执行，然后使用 ENTRYPOINT 指令在 Docker 文件中指定它：
ADD entrypoint.sh /entrypoint.sh
RUN chmod a+x /entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
使用入口点策略，您可以保持 CMD 不变，无需更改。