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

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

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

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

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

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

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

最新評論