什麼是devops呢？按照維基百科的定義，devops（development和operations的組合詞）是一種重視“軟體開發人員（dev）”和“it運維技術人員（ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體傳遞”和“架構變更”的流程，來使得建構、測試、釋出軟體能夠更加地快捷、頻繁和可靠。
在缺乏devops能力的組織中，開發與營運之間存在着資訊“鴻溝”──例如營運人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務使用者的需求則是更快地将更多的特性釋出給最終使用者使用。這種資訊鴻溝就是最常出問題的地方。而devops的引入能對産品傳遞、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──“熱更新檔”）起到意義深遠的影響。
devops包含四個核心的部分，文化、自動化、度量和分享，而本文的重點是自動化。自動化的目标是就是将整個傳遞流程盡其所能的自動化，當然也包含基礎設施管理的自動化，這也就意味着你的基礎設施的管理不是通過手工的方式或者執行腳本來完成，而在傳統的it環境下，基礎的硬體環境和軟體環境的設定作為基礎設施的關鍵部分是很難自動化的，但是随着雲計算的興起，通過可以機器處理的定義檔案而不是實體硬體配置或使用互動式配置來管理和派生計算基礎設施（程序，裸機伺服器，虛拟伺服器等）及其配置的過程變得越來越流行，也就是通過代碼來管理基礎設施，而這就是所謂的基礎設施即代碼（infrastracture as code）簡寫為iac。
iac相比傳統的方式，具有以下優點：
自服務性－如果基礎設施是通過代碼定義的時候，那麼整個流程都可以做到自動了，開發人員在需要的時候就就可以自己釋出，而不必等待運維人員來釋出。 快捷而安全－由于整個部署過種都是自動化的，計算機執行的速度比人更快而且更完全。 文檔化－在傳統的方式下，基礎設施的狀态隻存在于單個系統管理人員頭腦中，而iac以任何人都可以閱讀的源代碼的方式來儲存基礎設施的狀态，也就說是源代碼具有了文檔的功能。 版本管理－你還可以将你的iac代碼使用版本控制工具管理起來，也就意味着你的基礎設施變更曆史是可以追蹤的，這樣當出現問題的時候，就可以通過查找曆史來快速的定位和診斷問題。 可檢驗－因為基礎設施的狀态是以代碼的形式管理的，這樣任何變更都可以通過代碼審查或者提前運作測試來檢驗。 可重用－你還可以将你的代碼封裝成子產品，這樣當有不同需求的時候，你就可以組裝不同的子產品來完成你的工作，而不是所有的情況都需要重頭開始。
随着越來越多的人認識到iac的優勢，各式各樣的iac工具被開發出來，它們分為以下四類：
ad hoc script 配置管理工具 服務模闆工具 編排工具
作為一種最直接的方式，人們使用通用語言編寫各種ad hoc的腳本語言來完成基礎設施的自動化工作，這種方式對于簡單，一次性的工作很友善，但是對于複雜和長期的項目，你會發現維護這些腳本是一場惡夢。于是象chef,puppet和ansible等配置管理工具出現，它們在通用語言的基礎上定義相應的文法規則來安裝和管理伺服器上的軟體，這些工具定義的代碼和ad hoc腳本語言非常相似，但是它們強制要求代碼具有結構化，一緻性，可預測性，文檔化和清晰的參數命名，而且它們能夠遠端管理大量的伺服器。随着虛拟化和雲計算的興起，packer,docker等服務模闆工具出現，模闆工具的背後是鏡像，相比于啟動大量的伺服器，然後在使用配置管理工具運作同樣代碼來重複安裝軟體和設定系統，鏡像技術隻需要捕獲一個完整伺服器包含作業系統，軟體，檔案和配置等經檢驗過的狀态快照，然後通過terraform等編排工具基于鏡像來快速的建立伺服器，資料庫等等，這極大的提高了基礎設施建立和管理的效率，是以鏡像技術構成了主流雲平台不可缺少的組成部分，而作為基礎設施建立的第一步，鏡像制作自然而然的構成了iac的基石。
所謂的鏡像，就是一個包含預先配置好作業系統和預裝軟體的靜态單元，通過它可以快速的建立新的虛拟機運作執行個體，不同的平台支援不同的鏡像格式，例如aws的ec2支援amis，vmware支援vmdk/vmx,alicloud的ecs支援raw和vhd格式等等。各雲平台都提供了大量的基礎鏡像供使用者使用，但是随着雲平台使用者成熟度的增加，使用者對鏡像個性化的需要越來越強烈，同時出于商業的考慮，使用者也希望自己的系統具有在不同雲平台之間遷移的能力，當然也包含個性化的鏡像遷移的能力。盡管各大雲平台都提供了web界面工具使得使用者可以手工建立自定義鏡像，也開放了相應的api使得通過自動化的腳本來建立個性化的自定義鏡像成為可能。但是都存在一定的局限性而難以滿足使用者的最終需求，packer就在這種背景下誕生了。
packer是一個從單一的模闆檔案來建立多平台一緻性鏡像的輕量級開源工具，它能夠運作在常用的主流作業系統如windows、linux和mac os上，能夠高效的并行建立多平台例如aws、azure和alicloud的鏡像，它的目的并不是取代puppet/chef等配置管理工具，實際上，當制作鏡像的時候，packer可以使用chef或者puppet等工具來安裝鏡像所需要的軟體。通過packer自動化的建立各種平台的鏡像是非常容易的。
使用packer來建立鏡像有如下優點：
基礎設施部署訊捷：packer鏡像允許您在幾秒鐘内啟動完成配置和已配置的機器，而不是幾分鐘或幾小時。 這不僅有利于生産，也有利于開發，因為開發虛拟機也可以在幾秒鐘内啟動，而無需等待通常更長的配置時間。 可移植性：因為packer為多個平台建立相同的映像，您可以在alicloud中運作生産，在像openstack的私有雲中分階段測試，以及在桌面虛拟化解決方案（如vmware或virtualbox）中開發。 每個環境運作相同的機器映像，提供最終的可移植性。 穩定性的改進：packer在建構映像時安裝和配置機器的所有軟體。 如果這些腳本中有錯誤，它們将被早期捕獲，而不是在啟動機器後幾分鐘。 更好的可測試性： 在建構機器映像之後，可以快速啟動該機器映像，并且通過冒煙測試以驗證鏡像是可以正常工作的。 良好的可擴充性： packer使用插件機制，可以很友善的根據需要來擴充功能，并與許多流行的技術和工具內建。 是hashicorp公司生态系統的一部分
packer包含建構器(builder),（派生器）provisioner,(後處理器)post-processor三個元件，通過json格式的模闆檔案，可以靈活的組合這三種元件并行的、自動化的建立多平台一緻的鏡像檔案。為單個平台生成鏡像的單個任務稱為建構，而單個建構的結果也稱為工件(artifact)，多個建構可以并行運作。
builder又稱建構器，能夠為單個平台建立鏡像。建構器讀取一些配置并使用它來運作和生成鏡像。作為建構的一部分調用建構器以建立實際生成的鏡像。常見的建構器包括virtualbox，alicloud ecs和amazon ec2。建構器可以以插件的形式建立并添加到packer中。 provisioner(派生器），這一元件在buider建立的運作的機器中安裝和配置軟體。他們執行使鏡像包含有用軟體的主要工作。常見的派生器包括shell腳本，chef，puppet等。 post-processors(後處理器），它使用建構器或另一個後處理器的結果來建立新工件的過程。例如壓縮後處理器壓縮工件，上傳後處理器上傳工件等。
packer建立鏡像的原理其實并不複雜，以阿裡雲的鏡像建立過程為例：
1.阿裡雲建構器讀取配置檔案，根據配置檔案定義，通過阿裡雲提供的api送出建立相應的ecs執行個體，配置網絡和安全規則的請求。
2.阿裡雲控制系統根據api請求建立ecs執行個體，配置好網絡和安全規則等等。
3.派生器讀取配置檔案，通過ssh或者winrm等遠端協定連接配接上ecs執行個體，按照模闆檔案的要求安裝和配置軟體。
4.當ecs執行個體安裝和配置好所需要的軟體之後，建構器發出捕獲執行個體狀态建立鏡像的請求。
5.阿裡雲控制系統根據請求建立鏡像，建立過程完成後或者建立的過程中有任何錯誤發生，建構器會根據配置模闆的要求來保留或者清除相應的臨時資源。
6.如果配置有後處理器，可以對前面步驟産生的鏡像作進一步的處理，例如通過packer-post-processor-alicloud-import後處理器，可以将本地的鏡像導入到ecs鏡像系統中
在了解了packer的原理和優勢之後，我們就可以通過實踐來學習如何使用它來建立自己的鏡像。
然後打開終端，導航到下載下傳目錄下，執行如下指令，如果得到如下圖的輸出，packer就安裝好了：
下面通過建立一個包含redis資料庫的鏡像的簡單執行個體來學習如何使用packer。
首先打開常用的檔案編輯器，輸入如下内容，将其中<<...>>部分替換成你自己的實際值，并且存儲為alicloud.json模闆檔案：
打開指令行終端，輸入如下指令：
十幾分鐘後，你就可以在自定義鏡像清單裡看到剛剛建立好的鏡像packer_basic
阿裡雲的插件開發起步較晚，雖然已經向官方送出了pr，但是還沒有合并的主流中去，是以目前隻能以外挂的插件方式運作，目前已經支援從基礎鏡像建立新的自定義鏡像和上傳本地基于kvm建立的鏡像到ecs鏡像清單，現在國内對于packer插件的文檔也比較少，如果讀者需要更詳細的實戰資料，可以參考如下兩篇部落格，也歡迎讀者能夠在阿裡雲packer官方插件資源庫提出需求或者貢獻力量。
應用場景1：
官方提供的基礎鏡像隻能提供有限的作業系統版本組合，而有些專有雲使用者需要特定版本的作業系統鏡像，通過工單的形式周期過長，使用者難以接受，而由使用者自己制作基礎鏡像的不但技術要求高，從本地上傳到鏡像清單的操作也很複雜，使用者很難制作出能夠正常運作的基礎鏡像，而使用packer,其post-processor能夠自動的将本地鏡像上傳到鏡像清單中，通過提供一些基礎模闆，使用者隻需要修改模闆檔案的源iso，就可以建立出指定版本的基礎鏡像，極大的降低了鏡像制作的門檻。
應用場景2：
在鏡像市場中有許多第三方鏡像，isv制作鏡像中包含的内容是什麼，對阿裡雲及使用者都是不透明的，我們無法清晰的看到鏡像中是否有隐患或不安全的内容，為了確定安全，隻能進行大量的安全掃描，一方面，使得isv釋出鏡像的周期較長，另一方面，通過掃描二進制檔案，很難完全避免安全風險。而通過packer模闆檔案制作的鏡像，我們可以清晰的看到腳本中執行的指令，相比二進制檔案，安全掃描也容易得多，而且也友善isv做鏡像的版本管理，以及多平台的鏡像制作，提高鏡像制作的效率，不需要isv一遍一遍的手工制作。
應用場景3：
在彈性伸縮(ess)中，鏡像的生成是否友善高效起着重要的作用，當檢測到工作負載達到閥值的時候，需要使用鏡像來生成新的執行個體，當彈性伸縮的應用數量達到一定規模的時候，通過手工來建立鏡像是難以接受的。特别是當需要更新應用時，如果使用傳統的方式，直接在運作時執行個體上線上更新應用，一方面，線上更新的速度較慢，而且會影響線上使用者的檢驗，另一方面，當出現錯誤的時候，復原也比較困難，很容易形成較長時間的當機，而采用packer,結合jenkins和terraform等工具，能夠将應用的從代碼到鏡像更新，産生更新後執行個體的過程完全自動化。當jenkins檢測到有代碼送出時，可以觸發packer根據模闆使用更新後代碼建立新的鏡像，然後jenkins觸發terraform來建立新ecs執行個體，将新執行個體加入伸縮組，并将舊執行個體移出伸縮組，這樣就完成了應用的更新，當檢測到新代碼出現問題的時候，又可以将舊執行個體重新加入伸縮組而移除新執行個體來完成復原。
oreilly terraform up & running
<a href="https://www.packer.io/docs/">https://www.packer.io/docs/</a>