创建Docker UAT /生产图像 [英] Creating a Docker UAT/Production image

问题描述

关于在关键环境下创建Docker图像的最佳做法，只需一个简单的问题。正如我们在现实世界中所知道的那样，通常情况下，团队/公司部署到内部测试的时间与部署到客户端测试环境和生产中的人员不同。出现问题，因为在创建Docker UAT /生产图像时，所有应用配置信息可能不可用。与詹金斯然后有关于存储在应用程序配置中的密码的问题。

所以我的问题是，Docker图像应该如何完全配置？我看到的方式，实际上不可能完全配置Docker的图像，但是一些应用程序密码等必须被排除。但是再一次，这略逊于Docker图像的目的？

解决方案

如何完全配置 Docker的形象应该如何？我看到的方式，实际上不可能完全配置Docker的图像，但是一些应用程序密码等必须被排除。但是再一次，这略逊于Docker图像的目的？

在方便性，安全性和灵活性之间始终会有折衷。
使用零运行时配置的映像运行非常方便，但不是非常灵活，并且会暴露敏感的配置（如密码）。
在运行时完成所有配置的映像非常灵活，不会公开敏感信息，但如果未提供默认值，则可能会使用不方便。如果用户不知道某些值，他们可能根本无法使用该图像。

敏感信息（如密码）通常在运行时停留在决定什么配置在运行时烘烤图像和要求。但是并不总是如此。例如，您可能需要构建仅包含测试环境的零运行时配置的测试映像。每个人都可以访问测试环境凭据，零配置对于测试人员来说更方便，并且没有人可以意外地针对错误的数据库运行构建。

对于除凭证之外的配置（例如应用程序属性，日志级别，日志文件位置），组织结构和团队动态可能决定了您进行多少配置。在进行更改和构建新映像的环境中，可能无痛。在这种情况下，您可以随意烘烤尽可能多的配置。如果操作和开发是分开的，则可能需要几天才能对图像进行微小的更改。在这种情况下，允许更多的运行时配置是有意义的。

回到原来的问题，我个人赞成为除了凭据之外的所有内容选择合理的默认值，并允许运行时仅根据需要重写（与不情愿配置的约定）。运行时配置对于操作系统是方便的，但它可以使开发团队难以追踪问题。

Just a quick question about best practices on creating Docker images for critical environments. As we know in the real world, often times the team/company deploying to internal test is not the same as who is deploying to client test environments and production. There becomes a problem because all app configuration info may not be available when creating the Docker UAT/production image e.g. with Jenkins. And then there is the question about passwords that are stored in app configuration.

So my question is, how "fully configured" should the Docker image be? The way I see it, it is in practice not possible to fully configure the Docker image, but some app passwords etc. must be left out. But then again this slightly defies the purpose of a Docker image?

解决方案

how "fully configured" should the Docker image be? The way I see it, it is in practice not possible to fully configure the Docker image, but some app passwords etc. must be left out. But then again this slightly defies the purpose of a Docker image?

There will always be tradeoffs between convenience, security, and flexibility. An image that works with zero runtime configuration is very convenient to run but not very flexible and sensitive config like passwords will be exposed. An image that takes all configuration at runtime is very flexible and doesn't expose sensitive info, but can be inconvenient to use if default values aren't provided. If a user doesn't know some values they may not be able to use the image at all.

Sensitive info like passwords usually land on the runtime side when deciding what configuration to bake into images and what to require at runtime. However, this isn't always the case. As an example, you may want to build test images with zero runtime configuration that only point to test environments. Everyone has access to test environment credentials anyways, zero configuration is more convenient for testers, and no one can accidentally run a build against the wrong database.

For configuration other than credentials (e.g. app properties, loglevel, logfile location) the organizational structure and team dynamics may dictate how much configuration you bake in. In a devops environment making changes and building a new image may be painless. In this case it makes sense to bake in as much configuration as you want to. If ops and development are separate it may take days to make minor changes to the image. In this case it makes sense to allow more runtime configuration.

Back to the original question, I'm personally in favor of choosing reasonable defaults for everything except credentials and allowing runtime overrides only as needed (convention with reluctant configuration). Runtime configuration is convenient for ops, but it can make tracking down issues difficult for the development team.

这篇关于创建Docker UAT /生产图像的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！