docker 最适合生产环境吗？
Is docker best just for prod environments?
我刚刚决定开始使用 docker 来测试使用 AWS fargate 构建微服务应用程序。
我的问题确实与听说许多开发团队使用 Docker 来避免人们在提交代码时说“在我的机器上工作”这句话有关。尽管我看到该问题的解决方案已得到解决，但我仍然看不出 Docker 图像实际上如何在开发环境中使用。
任何高于生产的工作流程都让我感到困惑。我的想法的例子是...
10 名开发人员的团队都使用 docker，每个人都将图像从 repo 拉到那里的容器，如果他们都有自己的版本，则带有源代码图像，这意味着他们对该图像所做的任何编辑都是他们自己的，并且当他们推回可以合并 none 编辑的回购时（以及编辑图像源代码并不容易完成）以及）。
我用 git -GitHub 的方式来考虑它，其中代码被推送到一个分支，然后合并到 master 以创建成品。
我想如果你从 GitHub master 那里提取代码并创建 Docker 图像就是使用它的方式，但这又回到了我最初的假设 Docker 用于生产环境而不是开发。
是否在开发中使用了 docker，以便开发人员可以只测试团队中其他开发人员正在使用的容器上的功能，以便所有环境在整个团队中匹配？
我真的不明白 docker 的开发环境的工作流程。
在生产部署之前，我会强调三个我发现 Docker 特别有用的案例：
Docker对于安装本地依赖真的很有用。如果您的应用程序需要数据库，docker run postgresql 带有适当的选项。需要一个干净的开始？删除容器。 运行宁两个微服务需要单独的数据库？启动两个容器。第二个微服务由另一个团队维护？ 运行 它也在一个容器中。
Docker 对于 在 CI 系统 中捕获构建环境很有用。例如，Jenkins 可以 运行 在容器内构建步骤，bind-mounting 当前工作树在其中，因此构建仅包含 build-time 依赖项（可以独立更新）的图像很有用CI 系统本身）。
如果您正在 运行 宁 Docker 在生产中，您可以 测试您即将 运行。你保证安装环境在 QA 和 prod 环境中是相同的，因为它封装在相同的 Docker 图像中。开发人员可以根据 production-installed 代码调试问题，而无需实际投入生产。
在您描述的基本场景中，需要注意的一个重要细节是您从不“编辑图像”；您总是 docker build 从其 Docker 文件和其他源代码中获取新图像。在编译语言（C++、Go、Java、Rust、Haskell）中，源代码不会出现在图像中。即使您“在开发中使用 Docker”，实际的源代码也会在其他系统中（通常是 Git），并且通常您会有一个构建“官方”的 CI 系统" 来自该源代码的图像。
我看到 Docker 提议进行 day-to-day 开发，要么是因为使用的语言生态系统很难同时安装多个版本，要么是为了避免在主机系统上安装软件。您需要特定的工具支持才能“在容器内开发”，如果开发人员选择他们自己的 IDE，则此支持不是通用的。相反，在 OS 包管理器（APT、Homebrew）和解释器版本管理器（rbenv、nvm）之间，通常可以直接在主机上安装一些东西。如果您的应用程序对特定版本的 Node 不那么敏感，则使用主机上已安装的任何版本可能比尝试将 Docker 插入到进程中更容易。
我刚刚决定开始使用 docker 来测试使用 AWS fargate 构建微服务应用程序。
我的问题确实与听说许多开发团队使用 Docker 来避免人们在提交代码时说“在我的机器上工作”这句话有关。尽管我看到该问题的解决方案已得到解决，但我仍然看不出 Docker 图像实际上如何在开发环境中使用。
任何高于生产的工作流程都让我感到困惑。我的想法的例子是...
10 名开发人员的团队都使用 docker，每个人都将图像从 repo 拉到那里的容器，如果他们都有自己的版本，则带有源代码图像，这意味着他们对该图像所做的任何编辑都是他们自己的，并且当他们推回可以合并 none 编辑的回购时（以及编辑图像源代码并不容易完成）以及）。
我用 git -GitHub 的方式来考虑它，其中代码被推送到一个分支，然后合并到 master 以创建成品。
我想如果你从 GitHub master 那里提取代码并创建 Docker 图像就是使用它的方式，但这又回到了我最初的假设 Docker 用于生产环境而不是开发。
是否在开发中使用了 docker，以便开发人员可以只测试团队中其他开发人员正在使用的容器上的功能，以便所有环境在整个团队中匹配？
我真的不明白 docker 的开发环境的工作流程。
在生产部署之前，我会强调三个我发现 Docker 特别有用的案例：
Docker对于安装本地依赖真的很有用。如果您的应用程序需要数据库，
docker run postgresql带有适当的选项。需要一个干净的开始？删除容器。 运行宁两个微服务需要单独的数据库？启动两个容器。第二个微服务由另一个团队维护？ 运行 它也在一个容器中。Docker 对于 在 CI 系统 中捕获构建环境很有用。例如，Jenkins 可以 运行 在容器内构建步骤，bind-mounting 当前工作树在其中，因此构建仅包含 build-time 依赖项（可以独立更新）的图像很有用CI 系统本身）。
如果您正在 运行 宁 Docker 在生产中，您可以 测试您即将 运行。你保证安装环境在 QA 和 prod 环境中是相同的，因为它封装在相同的 Docker 图像中。开发人员可以根据 production-installed 代码调试问题，而无需实际投入生产。
在您描述的基本场景中，需要注意的一个重要细节是您从不“编辑图像”；您总是 docker build 从其 Docker 文件和其他源代码中获取新图像。在编译语言（C++、Go、Java、Rust、Haskell）中，源代码不会出现在图像中。即使您“在开发中使用 Docker”，实际的源代码也会在其他系统中（通常是 Git），并且通常您会有一个构建“官方”的 CI 系统" 来自该源代码的图像。
我看到 Docker 提议进行 day-to-day 开发，要么是因为使用的语言生态系统很难同时安装多个版本，要么是为了避免在主机系统上安装软件。您需要特定的工具支持才能“在容器内开发”，如果开发人员选择他们自己的 IDE，则此支持不是通用的。相反，在 OS 包管理器（APT、Homebrew）和解释器版本管理器（rbenv、nvm）之间，通常可以直接在主机上安装一些东西。如果您的应用程序对特定版本的 Node 不那么敏感，则使用主机上已安装的任何版本可能比尝试将 Docker 插入到进程中更容易。