前言

初看《基礎設施即程式碼》這本書（亞馬遜有英文影印版）的時候，覺得基礎設施即程式碼可能和IaaS、PaaS這些概念類似，應該和雲端計算有關；而自己做過虛擬化的專案，感覺應該不會吃力。不過真正看起這本書的時候，還是覺得有些吃力，主要原因是裡面的一些版本管理及其他工具之前沒有接觸過或者接觸不多。
吃力歸吃力，讀書的過程自己觀念還是得到了一些更新。個人覺得這本書最大的意義在於讓我們瞭解，基礎設施也可以按照程式碼管理的思路去管理，從而去實現基礎設施的自動化部署，並且保證可靠性，持續交付。所有的目的就是讓我們的基礎設施健壯，並讓我們擁有持續交付的能力，而且不需要把時間總是花在一些重複的勞動上。因為我只讀了第一遍，所以有些地方可能沒有覆蓋到，你可以自己去發現。
這次的分享我將按照自己的知識體系更新，按三大塊來分享，主要分為觀念的更新，工具集的更新，以及自己可以採取的行動。

一、觀念的更新

從整體架構上，本書第一部分主要介紹了“基礎設施即程式碼”的一些基本知識。例如什麼是動態基礎設施平臺，我們都需要從哪些方面去定義它們。結合伺服器的建立、置備、更新等生命週期，我們該如何利用CFEngine、Puppet、Chef、Ansible等自動化工具實現伺服器全生命週期的自動化。
第二部分使用了單獨的章節介紹伺服器置備、伺服器模板映象管理和伺服器變更管理。第二部分的最後一章提升到了更高的層次，基於伺服器管理的模式描述了管理多種基礎設施元素和環境的方式。
第三部分則主要從工程實踐角度出發，講解了如何開展測試、如何管理變更、如何確保持續性等內容。
以下是我閱讀過程覺得需要記錄的一些點，供大家參考：

1.1 要自動化部署伺服器

自動化伺服器管理的目標：
能夠完全按需置備一臺新伺服器，等待時間不超過數分鐘。
置備新伺服器時完全不用人工參與，比如不需要人工響應事件。
當定義了伺服器配置變更之後，向伺服器應用該變更的過程不需要人工參與。
每個變更都應該被應用到所有相關的伺服器，而且在該變更之後置備的新伺服器都應該包含該變更。
置備以及變更伺服器的過程具有可重複性、一致性、自文件和透明化等特性。
修改置備伺服器以及變更配置的流程既容易又安全。
每次修改伺服器配置定義以及修改置備伺服器和更改伺服器的流程都會觸發執行自動化測試。
配置的變更和處理基礎設施任務的流程變更都應版本化，並且要應用到不同的環境中，以便支援對照性測試和階段性發布策略。

1.2 容器和虛擬機器概念上並非一樣

從使用硬體資源角度看，容器不是虛擬機器。容器沒有模擬硬體，與主機伺服器使用同一個作業系統，而且實際執行在同一個核心上。容器系統使用作業系統特性來隔離程式、檔案系統和網路，執行在容器中的程式就像執行在獨立的系統中。這靠的是嚴格限定該程式的訪問權，而不是模擬硬體資源。 使用容器的最佳方式是將它作為一種打包服務、應用程式或者任務的方法。它是一種快速建造的方式，將應用程式加入它的依賴當中，並提供一種標準方式讓其主機系統管理自身的執行時環境。

1.3 容器的好處之一是程式環境與主機環境解耦

容器化系統的價值在於，它為容器映象和工具提供了一種標準格式來構建、分發和執行這些映象。在 Docker 出現之前，團隊可以使用相同的作業系統特性來隔離執行的程式，但 Docker 以及類似工具大大簡化了這一過程。 容器化的好處如下：
將具體應用程式的執行時需求與容器執行的主機伺服器解耦； 通過容器映象可以重複建立一致的執行時環境，而該容器映象可以被分發和執行在任何支援該執行時的主機伺服器上； 將容器定義為可以被 VCS 管理的程式碼（比如在 Dockerfile 中），從而用來觸發自動化測試，並通常擁有基礎設施即程式碼的所有特性。

1.4 容器安全關注點之一在於映象包安全

討論容器時一個不可避免的話題就是安全性。容器提供的隔離性會引導人們認為容器提供的內在安全性比實際上要多。如果沒有小心對待社群提供的映象，Docker 基於其來構建定製化容器的模式會導致嚴重的漏洞

1.5 鳳凰伺服器應該是指經受了磨難可以自動重建的伺服器（8.2.3的補充內容）

作者用鳳凰伺服器的意思，應該是鳳凰涅槃、浴火重生，就是歷經劫難、義無反顧，置之死地之後重獲新生。有些章節也提到netflix定期自己破壞掉他們的部分伺服器，看到底多久可以重建起來。 這樣經過劫難的伺服器，才是足夠強健的。 https://martinfowler.com/bliki/PhoenixServer.html

1.6 對於大規模伺服器，要自動化並將人員價值體現在更有意義的事情上

第二部分側重於介紹伺服器的置備和配置。第9章將探討怎樣置備和配置更大的基礎設施元素組。隨著基礎設施的規模、複雜度和使用者數不斷增長，基礎設施即程式碼的收益越來越難實現： 特定變更的影響範圍越來越大，從而很難實現頻繁、快速和安全的變更；
人們在例行維護和救火上花費更多時間，在為服務帶來有價值的提升上花的時間越來越少；
允許使用者置備和管理自己的資源可能會對其他使用者和服務造成破壞。
典型的應對方式就是對基礎設施實施集中式的控制。這會導致在會議、文件和變更流程上花費更多時間，在給組織增值的活動上花費的時間越來越少。

除了集中控制，另一個選項是設計基礎設施以最小化特定變更的影響範圍。即使基礎設施的規模變得更大，一種定義、置備和管理基礎設施的有效方式也將支援頻繁和充滿信心的變更。這就允許將應用和服務基礎設施安全地委託出去。

1.7 基礎設施即程式碼的涵義就是使用軟體管理的思想來管理系統和裝置

基礎設施即程式碼的涵義是，執行軟體的系統和裝置本身就可以當作軟體來對待。這樣才能夠在基礎設施領域採用那些在軟體開發領域中被證明有效的實踐和工具。

1.8 軟體和基礎設施開發中保障質量的一些原則

及早開始交付可工作、有用的程式碼；
持續進行小而有用的增量交付；
只做當下必要的構建；
每一次增量構建都儘可能簡單；
確保每一個變更都是精心設計和實現的；
儘早收集每一個變更的反饋；
隨著你和使用者對系統的學習，改變需求是意料之中的事情；
假設交付的一切都將隨著系統的演化而變更。

1.9 持續交付不是持續部署（10.4.3）

持續交付（Continuous Delivery）的概念使得釋出決策變為了商業決策而不是技術決策。 關於 CD 的一個誤解是，它意味著每一個變更在提交併通過自動化測試後，需要立即應用到生產環境。雖然有些組織實際上是按照持續部署的做法來應用持續交付，但大多陣列織並不是這樣。CD 的要點不是將每一個變更立即應用到生產環境，而是確保每個變更都可以部署到生產環境。

這仍然需要決定什麼時候真正地將特定的變更或者釋出版本推送到生產環境。這可以由人來決定，但是由工具自動執行。實現決策流程的授權和稽核甚至也會成為可能。

CD 的偉大之處在於將釋出的決策變成商業決策，而非技術決策。其實技術驗證早已在每一次提交時完成。

1.10 始終關注質量

10章回顧了一些核心的軟體開發實踐，以及它們如何與基礎設施即程式碼一起工作。這些實踐的核心問題是質量。為了保證系統和定義系統的程式碼的質量，必須把對質量的關注放在首位。

將系統的質量置為高優先順序，持續接受反饋並立即採取行動，這樣的團隊才能讓流程良性迴圈。他們有信心定期做一些小的修復和調整，從而保障系統的順利執行。這也讓他們可以把更多的時間花費在更令客戶滿意的、更高優先順序的工作上，而不是天天忙於救火。

1.11 要管理技術債務，讓它可控

我們不要養成“認為現在已經足夠好”的壞習慣。
技術債務的四象限（10.5.2） https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

1.12 災難恢復：Netflix 和“猿猴軍團”（14.4.1）

Netflix 使用了名聲在外的自動化工具“混亂猴子”（Chaos Monkey）來證明基礎設施的彈性可以承受單個伺服器的故障。“混亂猴子”自動地半隨機銷燬一些伺服器例項。員工不會注意到這件事的發生，所以可以快速地識別任何被引入基礎設施中的弱點。 這是常規性的。 “混亂猴子”只是 Netflix“猿猴軍團”中的一個組成部分（參見 Netflix 技術部落格上的文章“The Netflix Simian Army”）。另一個是“混亂大猩猩”（Chaos Gorilla），它將整個資料中心（AWS 的可用區域）在執行過程中移除，以證明基礎設施的其他部分可以不間斷地繼續執行。“延遲猴子”（Latency Monkey）在客戶和伺服器之間的通訊中加入人為的延時，以發現上游伺服器能夠正確地應對服務降級。 正因為激進、持續地對災備過程進行了驗證，Netflix 每次都能不受亞馬遜雲基礎設施的故障影響，沒有中斷的情況。 這樣做的價值就在於主動摧毀，主動驗證。

二、工具和網站集

為了理解伺服器管理工具，最好參考伺服器的生命週期擁有的多個階段（如圖 4-1 所示）。

圖 4-1：伺服器的生命週期

2.1、chef（原書1.4.2）

https://www.ibm.com/developerworks/cn/cloud/library/1407_caomd_chef/index.html

2.2、作者獲得思路的一個網站

http://www.infrastructures.org/

2.3、Martin Fowler的網站（雪花伺服器）

https://martinfowler.com/bliki/SnowflakeServer.html

2.4、Puppet

https://puppet.com/
https://www.cnblogs.com/waiwofei/p/3678173.html
puppet有可以練習的虛擬機器

2.5、aminator

https://github.com/Netflix/aminator

2.6、MCollective

https://puppet.com/docs/mcollective/current/index.html

2.7、cron指令碼

https://blog.csdn.net/ithomer/article/details/6817019

三、自己可以採取的行動

3.1 要重新理解私有云和公有云

第二章 2.2節，2.23節

3.2 要開始瞭解公有云，並嘗試選擇公有云

3.3 要嘗試使用VCS去管理變更

VCS 是真相的唯一來源。如果兩個團隊都要檢出檔案並進行基礎設施的變更，他們可能做出不相容的修改。舉例來說，我可能要給一個應用伺服器增加配置，但與此同時 Jim 需要變更防火牆規則，正好會阻止對我的伺服器的訪問。如果我們都直接將變更應用到基礎設施上，就不知道彼此正在做什麼。我們可能重複應用變更，期望能強行應用自己的配置，但這樣會一直擾亂對方的工作。

不過，如果我們都需要提交變更才能讓它生效，就會很快知道變更衝突了。在VCS中，當前檔案的狀態正確地代表了已經把什麼應用到了基礎設施中。

3.4 要理解模板的厚和薄，在實際工作中學習如何處理

一個關鍵的權衡點是，如果越來越多的元素被打包到了伺服器模板中，那麼需要經常更新模板。這要求更加複雜的流程和工具來構建和管理模板。（4.2.3）

囫圇吞棗的讀了一遍，希望今後有機會再來一遍。學習軟體程式設計後再來體會。

2018年12月13日晨，南京，第一遍閱讀