在使用Docker分发应用程序时，将环境变量作为设定项目成为（某些领域中的）事实标准模式
我正在开发某种应用程序，并分发官方的Docker镜像。最近经常看到这种情况。
以用户的角度来看，如果能够在应用程序设置中使用环境变量会很方便。
为什么？
-
- ADD/COPYがいらない
変更のたびビルドしなくていい
Mountつかわなくていい
Mount用のファイルを管理しなくていい
docker-compose.ymlなどで完結
所以，对于应用程序的配置，一些Docker镜像在这个环境变量中使用了以下命名规则。
-
- {アプリケーション名}_{ディレクティブ}_{サブディレクティブ}
- {アプリケーション名}_{設定項目名}
如果将具有类似含义的环境变量以大写形式传递给应用程序，那么存在一种规则，即该环境变量可以指定或覆盖配置文件中的相同项目。
并不是要提出可以随意形成任何形象，而是讲述一种在为众多人使用时制作某种官方形象或图像的方法。
例如，这些都采取了这样的方法。
-
- kafka(Confluent)とその周りのモジュール confluentinc/cp-docker-images at v5.1.2
graylog Graylog2/graylog-docker at 3.0.0-1
追加说明：虽然稍后有提及，但这个规则的好处是可以将配置文件的参考内容直接替换为环境变量。
在 Docker 容器启动时通过环境变量向配置文件添加附加内容。
在上述例子中，kafka（Confluent）会在Docker容器启动时，通过环境变量将配置信息追加到配置文件中。
跟随五点一点二版本，将 confluentinc/cp-docker-images 进行重述。
如果您有想要添加到配置文件的设置项目，我们将通过以下方式为您设置环境变量。
default.replication.factor <= KAFKA_DEFAULT_REPLICATION_FACTOR
kafka.num.partitions <= KAFKA_NUM_PARTITIONS
通过这样做，可以通过环境变量来设置所有参数。
如果查看下面的入口文件组，您会大致了解它是如何实际运作的。
- https://github.com/confluentinc/cp-docker-images/tree/v5.1.2/debian/kafka/include/etc/confluent/docker
自称的说唱歌手正在进行追加说明。(考虑到可能会感到困难，建议在开头表明一下如果是应用程序的分发方会更好，只是提供一种表达的方式。)
如果存在环境变量，优先使用。
我认为这可能是由于Graylog的一种类型。即使粗略查看入口点，也不觉得有文件更改的情况。(我对Java也不熟悉，所以没有继续追踪。)
- Graylog2/graylog-docker at 3.0.0-1
与Kafka不同，Graylog的配置文件中的分隔符是下划线”_”，因此`GRAYLOG_*的环境变量后半部分应与小写和下划线的配置项相对应。
is_master <= GRAYLOG_IS_MASTER
password_secret <= GRAYLOG_PASSWORD_SECRET
在阅读配置文件的参考资料时，将其转化为环境变量更容易。
因此，对于类似以下问题的回答也会总结为“按照规则来吧”。
- Please document GRAYLOG_ELASTICSEARCH_HOSTS · Issue #8 · Graylog2/graylog-docker
附赠品，Rubygems例子
顺便说一句，类似于Rubygems的thekompanee/chamber，也可以使用这种模式，在配置用的 yaml 文件中，将键和环境变量配对使用，我偶尔会用到它。
- thekompanee/chamber: A surprisingly configurable convention-based approach to managing your application’s custom configuration settings.
如果有这种环境变量，不仅限于Docker容器，优先使用的类型也非常好。
最后
我觉得这种方法在中国已经比较普及了，但是我觉得没有明确说出来的讨论也不多，所以我想写一下。
在创建配置文件时，如果模板中的项目变多，分支会变得臃肿。管理对象最好保持尽量少，这样对使用者来说也更方便，当我自己分发一些东西时，我也希望能以这种方式来制作。
