在过去的几年里，集装箱，特别是码头工人，在整个行业已经相当普遍。容器化以一种简单和开发人员友好的形式提供了独立的、可复制的构建和运行时环境。它们使整个软件开发过程运行得更加顺畅，从最初的开发到在生产中部署服务。像Kubernetes和Mesos这样的编排框架提供了服务组件的健壮抽象，这简化了部署和管理。比如许多其他的科技公司，数字海洋在内部使用容器来运行生产服务。我们有相当多的服务运行在Kubernetes内部，其中很大一部分运行在一个内部平台上，我们构建这个平台是为了消除一些新接触Kubernetes的开发人员的痛处。我们还在构建系统中使用CI/CD容器，并在本地使用容器进行开发。在这篇文章中，我将描述如何重新设计Docker注册表体系结构以获得更好的性能。（您可以在Joonas Bergius的演讲中了解DigitalOcean是如何同时使用容器和Kubernetes的，在Mac Browning的这篇演讲中，您可以了解更多关于我们内部平台DOCC的信息。）简单的开始和成长过程中，为了托管我们的私有Docker映像，我们设置了一个运行官方Docker注册表的服务器，以对象存储为后盾。对于私有注册中心来说，这是一种常见的、简单的模式，并且在早期就很好地工作了。通过依赖一致的对象存储作为备份存储，注册表本身不必担心一致性。但是，对于单个注册表实例，仍然存在性能和可用性瓶颈，并且依赖于能否到达运行注册处。As我们对容器的使用越来越多，我们开始遇到一些普遍的性能问题，比如缓慢或失败的映像推送。一个简单的解决方案是增加运行的注册表实例的数量，但是我们仍然依赖于单个区域的可用性和可访问性服务器。另外，官方Docker注册表的默认行为是通过重定向到后台存储来提供实际的图像数据。这意味着来自客户端的请求到达注册表服务器，该服务器返回指向对象存储的HTTP重定向（或配置注册表使用的任何远程后端）。我们遇到的一个独特问题是大型Docker映像（约10GB）的大量部署，将带宽推送到我们的存储后端。成百上千的客户同时请求一个新的、大的映像，这使我们从数据中心到存储的连接饱和。运行多个注册表实例并不能解决这个问题所有的数据仍然来自后台商店设计目标我们决定是时候彻底检查我们的Docker注册表架构了，有几个主要目标注意：存在于每个区域的区域缓存可减少任何区域的总体带宽出口减少或消除单点故障架构选项我们在每个DigitalOcean区域运营相对较大的Kubernetes集群，因此，使用Kubernetes和我们的定制提供的基本构建块是一个合乎逻辑的选择。Kubernetes为我们提供了很好的原语，比如扩展部署和简单的滚动部署。此外，我们有许多内部工具来运行、监视和管理内部运行的服务库伯内特斯。为了缓存时，我们决定利用Docker注册表禁用重定向的功能。禁用重定向会导致注册表服务器检索图像数据，然后直接将其发送到客户端，而不是将请求重定向到后端存储。这给初始响应增加了一点延迟，但使我们能够在注册表前面放置一个类似Squid的缓存代理，并提供缓存数据，而无需在后续操作中转换到备份存储请求。在在这一点上，我们对如何在每个区域运行多个缓存注册表有了一个好主意，但是我们仍然需要一种方法来引导客户机从他们所在区域的注册表请求Docker映像，而不是单一的全局映像。为了实现这一点，我们创建了一个新的DNS区域，该区域不在区域之间共享，以便每个区域中的客户端可以将我们注册表的DNS地址解析为本地区域的注册表部署，而不是到位于不同区域。实施详细信息我们最终使用的注册表配置相当标准，使用的存储后端配置了访问密钥和密钥。如前所述，一个重要的方面是禁用"redirect"："`[php]{`storage:redirect:disable:true`}`"，为了在本地使用注册表缓存图像数据，我们选择使用Squid。注册中心的每个实例都将使用自己的Squid实例和自己的缓存存储进行部署。这种方法设置和配置很简单，但也有缺点：值得注意的是，注册表的每个实例都有自己独立的缓存。这意味着，在多个实例的部署中，指向不同备份实例的多个相同请求可能会导致多个缓存未命中，注册表和缓存的每个实例一个。这里还有未来改进的空间，建立一个更大的共享缓存，一个区域中的所有注册表实例都位于该缓存后面。任何本地缓存都比我们最初的设置有了很大的改进，所以在我们的初始设置中可以进行折衷工作。到配置Squid，我们编写了一个简单的配置来监听HTTPS连接并将所有缓存未命中发送到本地注册表：```[php]{`HTTPS_port 443 accel defaultsite=dockerregistry no vhost cert=证书pem钥匙=密钥.pem... cache_peer 127.0.0.1 parent 5000 0 0 no query originserver no digest forceddomain=dockerregistry name=upstream login=PASSTHRU ssl acl site dstdomain dockerregistry http_access allow site cache upstream allow site cache allow site`````一旦我们编写了注册表和Squid配置，我们就将这两部分组合起来在Kubernetes部署中一起运行的软件。每个pod将运行一个registry实例和一个Squid实例，并具有自己的临时磁盘存储。在我们的区域Kubernetes集群中部署它非常简单-name:squid-config-configMap:name:squid-config-name:cache-emptyDir:{}容器：-名称：注册表映像：注册表：2.6.2 volumeMounts：-名称：注册表配置装入路径：/etc/码头工人/登记处/配置yml子路径：配置yml-名称：squid图像：squid:3.5.12端口：-containerPort:443 volumeMounts:-名称：squid config mountPath:/etc/squid/squid.conf子路径：squid.conf-name:cache mountPath:/cache`}``剩下的最后一点工作是启用对新注册表的入口，这是我们使用现有的HAProxy入口控制器完成的。我们使用Squid终止TLS，因此HAProxy只负责将TCP流量转发到我们的部署。```[php]{`apiVersion:extensions/v1beta1 kind:Ingress metadata:name:docker spec:rules:-host:dockerregistry http:paths:-path:/backend:serviceName:docker servicePort:443 tls:-hosts:-dockerregistry secretName:不需要`}```结论总之，这个注册表体系结构运行良好，在我们所有的数据中心提供了更快的拉和推。通过这个设置，我们现在在所有区域都运行Docker注册表，并且没有任何区域依赖于到达另一个区域来提供数据。现在每个注册中心实例都有一个Squid缓存代理支持，允许我们将对同一数据的许多请求完全保存在缓存中，并且完全是本地的。这使得更大的部署和更高的拉力性能。未来将围绕度量工具和监控进行改进。虽然我们目前通过抓取注册表日志来计算指标，但我们期待着Docker注册表本机包含普罗米修斯指标。此外，为注册表部署创建一个共享的区域缓存应该可以提供很好的性能提升，并减少我们在操作中看到的缓存未命中的数量。Jeff Zellner是交付团队的高级软件工程师，他致力于为整个数字海洋工程组织提供Kubernetes周围的基础设施和自动化。他是一个长期从事远程工作的人，初创公司o-phile，滑雪技术非常出色。