推送go-demo镜像前，需要一个镜像库。Docker提供多种镜像库。有Docker Hub（https：//hub.docker．com/）、Docker Registry（https：//docs.docker．com/registry/）和Docker Trusted Registry（https：//doc s.docker．com/docker-trusted-registry/）。除此之外，还有很多来自第三方厂商的解决方案。
我们应该使用哪个镜像库？Docker Hub需要用户名和密码，笔者不太愿意提供自己的账号给你们。笔者在开始编写本书之前定义的一个目标是仅使用开源工具，因此Docker Trusted Registry在其他情况下是一个很好的选择，但这里并不适合。唯一的选择就是Docker Registry（https：//docs.docker．com/registry/）。
镜像库被定义为docker-compose-local.yml（http：//github．com/vfarcic/go-demo/ blob/master/docker-compose-local.yml）Compose文件中的服务之一。定义如下：
我们将registry设置为明确的容器名称，指定了镜像，并打开了端口5000（在主机和容器内）。
镜像库将镜像存储在/var/lib/registry目录中，因此我们将它作为卷挂载在主机上。这样，如果容器发生故障，数据就不会丢失。由于这是一个可以被许多人使用的生产服务，所以定义它应该始终在失败时重新启动。
运行以下命令：
现在我们有了镜像库，就可以做一个预运行。让我们确认可以在上面拉取和推送镜像：
Docker使用命名约定来决定从哪里拉取和推送镜像。如果名称带有地址前缀，则引擎将使用它来确定镜像库的位置。否则，它会假定我们想要使用Docker Hub。因此，第一个命令从Docker Hub中拉取alpine镜像。
第二个命令创建了alpine镜像的标签。该标签是镜像库localhost：5000的地址和镜像名称的组合。最后，我们将alpine镜像推送到在同一台服务器上运行的注册表中。
在开始正式使用镜像库之前，让我们确认镜像确实存在于主机上：
笔者不会详细介绍每个子目录包含的内容。重要需要注意的一点是，镜像库会在主机上保留镜像，以免失败时丢失数据，这种情况下，即使销毁虚拟机，Machine目录也会在我们的笔记本电脑上有备份。(www.xing528.com)
此时声称可以在生产中使用这个镜像库是有些仓促。即使持久化了数据，如果整个虚拟机崩溃，也会有停机时间，直到有人再次启动或创建新的虚拟机。因为其中一个目标是尽可能地避免停机时间，所以稍后我们应该寻找更可靠的解决方案，目前的设置就是这样。
现在准备将go-demo镜像推送到镜像库中：
与Alpine的例子一样，我们使用镜像库前缀标记镜像并将其推送到镜像库。我们还添加了一个版本号1.0。
推送是CI流程的最后一步，我们运行了单元测试、构建了二进制文件、构建了Docker镜像、运行了预备测试并将镜像推送到了镜像库。尽管我们做了所有这些事情，但还不确定该服务是否可以投入生产。我们从未测试过将其部署到生产（或类生产）集群时的行为。虽然我们做了很多，但还不够。
如果持续集成是我们的最终目标，那么现在就是动手验证的时刻。虽然那些需要创造力和批判性思维的手工劳动有很大的价值，但对于重复性的工作，我们不能这样说。将此持续集成流程转换为持续交付以及稍后的部署所需的任务实际上是重复的。我们已经完成了CI流程，现在是时候做更多的工作并将其转化为持续交付。
在进入持续集成流程成为持续交付所需的步骤之前，我们需要退后一步并探索集群管理。毕竟，大多数情况下生产环境都是一个集群。
我们将在每章结尾处销毁虚拟机。这样，你可以回到本书的任何一部分做这些练习，而不用担心你可能需要从前面的章节中执行一些步骤。此外，这样的过程将迫使我们重复一些事情，熟能生巧。为了减少你的等待时间，笔者尽了最大努力让镜像保持很小，并将下载时间降到最低。执行以下命令：
第2章介绍关于Swarm集群的搭建和运维。
【注释】
[1]http//technologyconver sations．com/category/test-driven-development
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
