我之前概述過加速AWS基礎(chǔ)設(shè)施啟動的方法。本文中談到的方法可以進一步減少大約50%的時間，即在應(yīng)用運行前，預(yù)先bake（pre-bake）所需服務(wù)。

我們的微服務(wù)應(yīng)用托管于Docker容器，可以從Docker倉庫或私有倉庫中拉取（pull）。不像在Ubuntu服務(wù)器上使用bash腳本進行安裝和配置，每個應(yīng)用所對應(yīng)的獨立Docker鏡像可以單獨復(fù)制到所需實例。這意味著在處理較大負載時可以快速添加實例，如果此方法可行，值得在組織中推廣應(yīng)用。

用戶體驗的頭一件事是演示流程，展示應(yīng)用如何為團隊的Github 分支（branches)創(chuàng)建環(huán)境。我們預(yù)先為應(yīng)用demo在EC2 AMI創(chuàng)建單獨鏡像。這樣，我們僅為需要運行應(yīng)用的用戶啟動Docker容器。

可擴展IT自動化工具Ansible可以完成大部分工作。我們用它運行各種簡單任務(wù)，如更新服務(wù)器host文件，生成證書，拉取需要的Docker鏡像。舉個例子，我們可以運行指定命令以及使用在Ansible YAML設(shè)置文件中的指定變量。在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鏡像的東西必須是唯一的，否則如果每個鏡像都有相同的標志文件，就沒有辦法加以區(qū)分。為了將Docker安裝到AMI以及將容器bake到AMI，我們需要刪除Docker key.json文件和Docker pid file。Docker在下次啟動時還會生成這些文件，所以刪掉也沒關(guān)系。

實例必須和用戶鏈接，這樣我們才能協(xié)助他們的應(yīng)用以及確定他們所使用的資源量。為了使實例在部署之后更加個性化，我們將亞馬遜SSM代理bake到鏡像中，這樣就可以實現(xiàn)在第一時間與實例進行交互。為用戶分配和配置實例的速度越快，內(nèi)部DNS和路由配置允許應(yīng)用訪問的速度也就越快。

對于預(yù)先bake Docker鏡像到亞馬遜AMI這種做法，盡管目前支持它的理由還比較有限，但還是值得推廣到幾乎所有的架構(gòu)。特別是Runnable這種一個實例可以對應(yīng)各種應(yīng)用、數(shù)據(jù)庫和服務(wù)的情況，只要你知道實例在部署時需要什么，就可以使用上述方法。可以使用多個AMI來填補所有角色需要，或者只用一個有多個Docker鏡像的實例，這些鏡像不被運行也沒有資源消耗。這種做法對高可用基礎(chǔ)設(shè)施的擴展速度非常有幫助，可以將其縮短到數(shù)秒鐘。

需要運行什么，就bake什么，這種做法理解起來很簡單。由于存在重復(fù)的問題，我們還不能做到先發(fā)制人的準備好證書和指定配置，不過這些都是不計算在等待時間內(nèi)的小進程。網(wǎng)絡(luò)傳輸，也可能有磁盤I/O通常在服務(wù)器創(chuàng)建和啟動新的Docker容器的過程中耗費較多時間，因此減少這類時間消耗能顯著的提高啟動速度。另外，這些考慮并非只針對特定產(chǎn)品。創(chuàng)建預(yù)先bake的AMI這種做法對任何團隊來說，都能在創(chuàng)建新實例的時候節(jié)省等待時間。