只是一个关于在关键环境下创建Docker映像的最佳实践的快速问题。我们在现实世界中知道，通常部署到内部测试的团队/公司与部署到客户端测试环境和生产的人员通常是不同的。出现问题是因为在创建Docker UAT /生产映像时（例如，使用Jenkins）可能无法使用所有应用程序配置信息。然后是关于存储在应用程序配置中的密码的问题。
所以我的问题是，Docker映像应如何“完全配置”？以我的看法，实际上不可能完全配置Docker映像，但是必须省略一些应用程序密码等。但这又有点违反了Docker镜像的目的吗？
Docker映像应如何“完全配置”？以我的看法，实际上不可能完全配置Docker映像，但是必须省略一些应用程序密码等。但这又有点违反了Docker镜像的目的吗？
在便利性，安全性和灵活性之间总会有取舍。使用零运行时配置运行的映像非常便于运行，但不会非常灵活且敏感，例如密码设置会暴露出来。在运行时进行所有配置的映像非常灵活，并且不会公开敏感信息，但是如果未提供默认值，使用起来可能会很不方便。如果用户不知道某些值，他们可能根本无法使用该图像。
诸如密码之类的敏感信息通常在确定要烘焙到图像中的配置以及在运行时需要什么时确定在运行时侧。但是，情况并非总是如此。例如，您可能希望使用零运行时配置（仅指向测试环境）来构建测试映像。无论如何，每个人都可以访问测试环境凭据，零配置对于测试人员来说更加方便，而且没有人可以意外地针对错误的数据库运行构建。
对于凭据以外的配置（例如，应用程序属性，日志级别，日志文件位置），组织结构和团队动态可能会决定您需要接受多少配置。在devops环境中，进行更改和构建新映像可能很轻松。在这种情况下，可以根据需要烘焙尽可能多的配置。如果操作和开发是分开的，则可能需要几天的时间对图像进行较小的更改。在这种情况下，允许进行更多的运行时配置是有意义的。
回到最初的问题，我个人赞成为除凭据之外的所有内容选择合理的默认值，并仅在需要时才允许运行时覆盖（使用勉强的配置）。运行时配置对于操作人员来说很方便，但是它会使开发团队难以跟踪问题。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句