本文讲的是如何通过提前Bake Docker镜像加快基础设施的启动速度【编者的话】本文介绍了如何预热Docker镜像来减少基础设施的启动时间，比如通过Ansible工具、删除key.json文件和Docker PID文件等等。
我之前 概述过 加速AWS基础设施启动的方法。本文中谈到的方法可以进一步减少大约50%的时间，即在应用运行前，预先bake（pre-bake）所需服务。
我们的微服务应用托管于Docker容器，可以从Docker仓库或私有仓库中拉取（pull）。不像在Ubuntu服务器上使用bash脚本进行安装和配置，每个应用所对应的独立Docker镜像可以单独复制到所需实例。这意味着在处理较大负载时可以快速添加实例，如果此方法可行，值得在组织中推广应用。
用户体验的头一件事是演示流程，展示应用如何为团队的Github 分支（branches)创建环境。我们预先为应用demo在EC2 AMI创建单独镜像。这样，我们仅为需要运行应用的用户启动Docker容器。
可扩展IT自动化工具Ansible可以完成大部分工作。我们用它运行各种简单任务，如更新服务器host文件，生成证书，拉取需要的Docker镜像。举个例子，我们可以运行指定命令以及使用在Ansible YAML设置文件中的指定变量。在bake镜像时，Ansible拉取Docker镜像方法如下：
考虑到bake到EC2镜像的东西必须是唯一的，否则如果每个镜像都有相同的标志文件，就没有办法加以区分。为了将Docker安装到AMI以及将容器bake到AMI，我们需要删除Docker key.json文件和Docker pid file。Docker在下次启动时还会生成这些文件，所以删掉也没关系。
实例必须和用户链接，这样我们才能协助他们的应用以及确定他们所使用的资源量。为了使实例在部署之后更加个性化，我们将亚马逊SSM代理bake到镜像中，这样就可以实现在第一时间与实例进行交互。为用户分配和配置实例的速度越快，内部DNS和路由配置允许应用访问的速度也就越快。
对于预先bake Docker镜像到亚马逊AMI这种做法，尽管目前支持它的理由还比较有限，但还是值得推广到几乎所有的架构。特别是Runnable这种一个实例可以对应各种应用、数据库和服务的情况，只要你知道实例在部署时需要什么，就可以使用上述方法。可以使用多个AMI来填补所有角色需要，或者只用一个有多个Docker镜像的实例，这些镜像不被运行也没有资源消耗。这种做法对高可用基础设施的扩展速度非常有帮助，可以将其缩短到数秒钟。
需要运行什么，就bake什么，这种做法理解起来很简单。由于存在重复的问题，我们还不能做到先发制人的准备好证书和指定配置，不过这些都是不计算在等待时间内的小进程。网络传输，也可能有磁盘I/O通常在服务器创建和启动新的Docker容器的过程中耗费较多时间，因此减少这类时间消耗能显著的提高启动速度。另外，这些考虑并非只针对特定产品。创建预先bake的AMI这种做法对任何团队来说，都能在创建新实例的时候节省等待时间。
我之前 概述过 加速AWS基础设施启动的方法。本文中谈到的方法可以进一步减少大约50%的时间，即在应用运行前，预先bake（pre-bake）所需服务。
我们的微服务应用托管于Docker容器，可以从Docker仓库或私有仓库中拉取（pull）。不像在Ubuntu服务器上使用bash脚本进行安装和配置，每个应用所对应的独立Docker镜像可以单独复制到所需实例。这意味着在处理较大负载时可以快速添加实例，如果此方法可行，值得在组织中推广应用。
用户体验的头一件事是演示流程，展示应用如何为团队的Github 分支（branches)创建环境。我们预先为应用demo在EC2 AMI创建单独镜像。这样，我们仅为需要运行应用的用户启动Docker容器。
可扩展IT自动化工具Ansible可以完成大部分工作。我们用它运行各种简单任务，如更新服务器host文件，生成证书，拉取需要的Docker镜像。举个例子，我们可以运行指定命令以及使用在Ansible YAML设置文件中的指定变量。在bake镜像时，Ansible拉取Docker镜像方法如下：
- name: pulling docker images
become: true
command: docker pull {{ item }}
with_items:
- "registry.runnable.com/runnable/image-builder:{{ IMAGE_BUILDER_VERSION }}"
- "swarm:{{ SWARM_VERSION }}"
- "google/cadvisor:{{ CADVISOR_VERSION }}"
考虑到bake到EC2镜像的东西必须是唯一的，否则如果每个镜像都有相同的标志文件，就没有办法加以区分。为了将Docker安装到AMI以及将容器bake到AMI，我们需要删除Docker key.json文件和Docker pid file。Docker在下次启动时还会生成这些文件，所以删掉也没关系。
实例必须和用户链接，这样我们才能协助他们的应用以及确定他们所使用的资源量。为了使实例在部署之后更加个性化，我们将亚马逊SSM代理bake到镜像中，这样就可以实现在第一时间与实例进行交互。为用户分配和配置实例的速度越快，内部DNS和路由配置允许应用访问的速度也就越快。
对于预先bake Docker镜像到亚马逊AMI这种做法，尽管目前支持它的理由还比较有限，但还是值得推广到几乎所有的架构。特别是Runnable这种一个实例可以对应各种应用、数据库和服务的情况，只要你知道实例在部署时需要什么，就可以使用上述方法。可以使用多个AMI来填补所有角色需要，或者只用一个有多个Docker镜像的实例，这些镜像不被运行也没有资源消耗。这种做法对高可用基础设施的扩展速度非常有帮助，可以将其缩短到数秒钟。
需要运行什么，就bake什么，这种做法理解起来很简单。由于存在重复的问题，我们还不能做到先发制人的准备好证书和指定配置，不过这些都是不计算在等待时间内的小进程。网络传输，也可能有磁盘I/O通常在服务器创建和启动新的Docker容器的过程中耗费较多时间，因此减少这类时间消耗能显著的提高启动速度。另外，这些考虑并非只针对特定产品。创建预先bake的AMI这种做法对任何团队来说，都能在创建新实例的时候节省等待时间。
原文链接：How We Pre-Bake Docker Images to Reduce Infrastructure Spin-Up Time（翻译：马远征)
原文发布时间为：2017-01-19
本文作者：马远征
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：如何通过提前Bake Docker镜像加快基础设施的启动速度
