我之前概述過加速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這種做法對任何團隊來說，都能在創建新實例的時候節省等待時間。