关于为关键环境创建Docker镜像的最佳实践的快速问题。正如我们在现实世界中所知道的那样，部署到内部测试的团队/公司通常与部署到客户端测试环境和生产的人员不同。出现问题是因为在创建Docker UAT /生产图像时可能无法使用所有应用配置信息，例如与詹金斯。然后是关于存储在应用配置中的密码的问题。
所以我的问题是，如何＆＃34;完全配置＆＃34; Docker图像应该是吗？我看到它的方式，实际上不可能完全配置Docker镜像，但必须省略一些应用程序密码等。但是，这再次略微违背了Docker图像的目的？
答案 0 :(得分：0)
Docker镜像应该如何“完全配置”？我看到它的方式，实际上不可能完全配置Docker镜像，但必须省略一些应用程序密码等。但是，这再次略微违背了Docker图像的目的？
在便利性，安全性和灵活性之间总会有权衡。 使用零运行时配置的图像运行起来非常方便，但不是非常灵活，并且会暴露敏感的密码配置。 在运行时进行所有配置的映像非常灵活，不会泄露敏感信息，但如果未提供默认值，则可能不方便使用。如果用户不知道某些值，他们可能根本无法使用该图像。
在决定烘焙图像的配置以及运行时需要什么时，密码等敏感信息通常落在运行时。但是，情况并非总是如此。例如，您可能希望构建测试图像，其运行时配置为零，仅指向测试环境。无论如何，每个人都可以访问测试环境凭证，零配置对测试人员来说更方便，没有人可以意外地针对错误的数据库运行构建。
对于除凭据之外的配置（例如应用程序属性，日志级别，日志文件位置），组织结构和团队动态可能会决定您烘焙的配置数量。在devops环境中，进行更改和构建新映像可能会毫不费力。在这种情况下，可以根据需要烘焙尽可能多的配置。如果操作和开发是分开的，则可能需要数天才能对图像进行微小更改。在这种情况下，允许更多运行时配置是有意义的。
回到最初的问题，我个人赞成为除除凭据之外的所有内容选择合理的默认值，并仅在需要时允许运行时覆盖（具有不情愿配置的约定）。运行时配置对操作很方便，但它可以使开发团队难以追踪问题。