企业私人Dockerregistry最佳实践
当我们正在准备与我们自己的私人登记处一起展开时，这个问题最近出现在我的脑海里。 什么是企业最佳实践，为什么？
Q1：
-
使用1个S3存储后端运行多个registry？ 每个registry都有设置，可以将它推送到同一个S3存储桶中的dev，qa或prod（顶级）文件夹。
-
运行1registry与1个S3存储后端为所有dev / qa / prod环境？ 由于Docker的整个目的是让图像在任何地方运行，所以我们只提供不同的docker运行参数，因为docker镜像本身在env中是完全相同的，只是你传递的运行参数是不同的。
-
每个环境运行1个registry和1个S3存储后端
Q2：
从开发者一路推广的形象，最好的做法是什么？ 涉及到哪些工具组合。 例如，我们有一个用于Dockerfiles的中心gitlab，当我们检查新的Dockerfile时，会有一个钩子触发Jenkins从Dockerfile构build镜像并在registry中检查它。 什么是轻松推广的好方法（除非你之前select了第二种选项），图像到了下一个级别 – qa，并最终产生？
Q3：
如果您更新了其中一个基本映像，那么确保将更改传播到registry中的其他映像上的方法是什么？ 例如，你用新的东西来更新你自定义的基础Ubuntu Dockerfile，并且你希望使用这个基础镜像的其他Docker文件被重build并推送到registry中，这样更改将被自动传播。
Q4：
如果您拥有不同的AWS账户，那么它是否在以上所有方面发挥作用：DEV为1，QA为1，PROD为1等。
我们select了第二个选项。 我会简单地描述一下我们正在使用的东西，尽pipe我们不是一个大的企业环境（在任何给定时间运行几百个容器），但也许会给你一些想法。 我们坚持使用单个S3后端/存储桶（在一个帐户上）来存储所有“types”图像，并适当地命名图像。 这里的诀窍是我们的“开发”环境基本上是“生产”环境。 这是我们整个devise的核心，也是我们使用Docker的理由：让我们的开发环境尽可能镜像生产环境。 我们在几个不同地理位置的数据中心上安装了几台商用专用硬件的生产机器，并在这些机器上运行我们的图像。 我们正在使用标准的Git工作stream来推送代码和更改。 我们目前使用Bitbucket（和我们自己托pipe的Gitlab镜像），并运行testing每个推动掌握Shippable（这里是可烧的大风扇！）。 我们用一个自定义的软件来协调所有的事情，在“头”服务器上监听webhooks，然后构build/标记/提交并将docker映像推送到我们的私有registry（一次它也被托pipe在同一个“头”服务器）。 然后，这个自定义软件webhooks到每个生产机器上的一个非常简单的自定义服务器，从私人registry中拉出新的图像和零停机时间 – 更新新的容器，而不是旧的。 我们使用Jason Wilder在我们的所有docker机器上的令人难以置信和令人敬畏的nginx代理反向代理，这使得这个过程比没有。 如果您对将这些dev / QA / prod映像进行隔离有一些特殊的要求，我build议尽可能less地分割这个后端，以防止出现更多可能的故障点。 docker工人的真正实力在于您可以创造的环境的一致性。 当我们将一个容器的任务从开发到QA切换到生产时，我们所做的只是将容器从“dev / QA”端口监听的端口号更改为“生产”端口号，并跟踪这些更改在我们的内部追踪器。 我们在DNS中使用多个Alogging来“负载均衡”，并且不需要扩展到使用实际负载均衡器（但是），但是可能我们会使用我们所喜爱的nginx-proxy映像的负载平衡function很多，因为这是一个已经内置的function。
如果由于某种原因需要更改基础映像，我们会在环境中进行更改（更新，不pipe），然后在新的Dockerfile中将其FROM中移除。 然后，这些更改被烘焙到新的图像中，然后推送到我们的私人registry中，然后传播到生产中，就像任何其他“常规”代码推送一样。 我应该注意到，我们将所有的数据反映在S3上（不只是我们的最终产品docker图像），万一发生了一些悲剧，我们需要启动一个新的“头”服务器（它本身使用docker工具的所有function）。 FWIW，这对我们来说是一个价格突破，能够转向商品专用硬件而不是EC2。 祝你好运！