SOE的定義和益處

節選自《基于Linux的企業自動化》第一章。

本章詳細探討了Linux中的標準操作環境（Standard Operating Environment以下簡稱SOE）概念。盡管我們稍后將更詳細地討論，但簡而言之，SOE是一個以標準方式來創建和修改所有內容的環境。例如，這意味著所有Linux服務器都以相同的方式，使用相同版本的軟件構建。這是一個重要的概念，因為它使管理環境變得更加容易，并減少了那些看管環境的人的工作量。

1. 2什么是SOE？

既然我們已經探討了SOE對企業如此重要的原因，并且從較高的層次上理解了解決這些問題的方法，那么讓我們來詳細了解一下SOE。

我們將從定義SOE本身開始。

1.2.1定義SOE

讓我們從一個更實際的角度來快速看一下。我們已經說過，SOE是一個概念，而不是絕對的。在最簡單的層次上，它是一個通用的服務器映像或構建標準，部署在整個公司的大量服務器上。在這里，所有必需的任務都是以已知的、文檔化的方式完成的。

首先是基本操作系統，正如我們所討論的，有數百種Linux發行版可供選擇。從系統管理的角度來看，有些非常相似（例如，Debian和Ubuntu），而有些則明顯不同（例如，Fedora和Manjaro）。舉個簡單的例子，假設你想在Ubuntu 18.04 LTS上安裝Apache Web服務器，你可以輸入以下命令：

# sudo apt-get update

# sudo apt-get install apache2

現在，如果你想在CentOS 7上執行相同的操作，你可以輸入以下命令：

# sudo yum install httpd

如你所見，這些命令之間沒有任何共同之處，甚至連軟件包的名稱都不同，盡管這兩種情況的最終結果都是安裝了Apache。在小規模時，這不是一個問題，但是當服務器數量眾多并且隨著服務器數量的增加，管理這樣一個環境的復雜性也會增加。

基本操作系統只是一個開始。我們上面的例子是安裝Apache，但是我們也可以安裝nginx甚至lighttpd。畢竟，它們也是web服務器。

然后是配置。你希望用戶能夠通過SSH以root身份登錄嗎？為了審計或調試的目的，你需要一定級別的日志記錄嗎？你需要本機身份驗證還是集中式身份驗證？這份清單是無窮無盡的，如你所見，如果任其發展，可能會成為一個巨大的頭痛問題。

這就是SOE的用武之地。它實際上是一個規范，在較宏觀的層次上，它可能會規定：

·我們的標準基本操作系統是Ubuntu 18.04 LTS。

·我們的標準web服務器將是Apache 2.4。

·SSH登錄已啟用，但僅適用于具有SSH密鑰的用戶而不是root用戶。

·所有用戶登錄都必須記錄并存檔，以便進行審核。

·除少數本機應急（break glass）賬戶外，所有賬戶都必須集中管理（例如，通過LDAP或Active Directory）。

·我們的公司監控解決方案必須集成（例如，必須安裝并配置Nagios NCPA代理，以便與Nagios服務器通信）。

·所有系統日志必須發送到公司中央日志管理系統。

·必須對系統應用安全加固。

以上只是一個例子，絕不是完整的；但是，它應該開始讓你了解SOE在宏觀層次上的樣子。隨著本章的繼續，我們將深入探討這個問題，并給出更多的例子來建立一個明確的定義。

1.2.2了解一下要包含哪些內容

在繼續之前，我們先稍微更詳細地了解一下環境中要包含哪些內容。在上一節中，我們概述了一個非常簡單的SOE定義。任何一個好的SOE操作過程的一部分就是擁有一個預定義的操作系統構建，它可以隨時被部署。有多種方法可以實現這一點，我們將在本書后面討論這些，但是，目前，讓我們假設已經建立了Ubuntu 18.04 LTS的基本映像，正如前面所建議的那樣。

我們在這個標準構建中集成了什么？例如，我們知道我們的登錄策略將應用于整個組織，因此，在創建構建時，/etc/ssh/sshd_config必須定制為包含PermitRootLogin no和PasswordAuthentication no。在部署后，再在配置中執行此步驟沒有意義，因為這必須在每個部署上執行。很簡單，這將是低效的。

對于我們的操作系統映像，還有一些重要的自動化考慮因素。我們知道Ansible本身是通過SSH進行通信的，因此我們知道需要某種憑據（很可能是基于SSH密鑰的），以便Ansible在所有部署的服務器上運行。在實際執行任何自動化操作之前，必須手動將Ansible憑據推送到每臺計算機是沒有什么意義的，因此重要的是要考慮Ansible要使用的身份驗證類型（例如，基于密碼或SSH密鑰的身份驗證），并在構建映像此時創建賬戶和相應的憑據。具體方法取決于你的公司安全標準，但我建議將以下內容作為一種潛在的解決方案：

·在標準映像上創建一個本機賬戶，以便Ansible進行身份驗證。

·授予此賬戶適當的sudo權限，以確保可以執行所有所需的自動化任務。

·設置此賬戶的本機口令，或者將從Ansible密鑰對中取出的SSH公鑰添加到你創建的本機Ansible賬戶的authorized_keys文件中。

提示

這樣做當然會帶來一些安全風險。Ansible很可能需要完全訪問你服務器上的root，以便它有效地執行你可能要求它執行的所有自動化任務，因此如果憑據被泄露，此Ansible賬戶可能會成為后門。建議盡可能少的人可以訪問你的憑據，并建議你使用諸如AWX或Ansible Tower（我們將在第3章“使用AWX優化基礎設施管理”中探討）之類的工具來管理你的憑據，從而防止人們不適當地獲取憑據。你幾乎肯定還希望啟用對Ansible賬戶執行的所有活動的審計，并將這些活動記錄到某個中央服務器上，以便你可以檢查它們是否存在任何可疑活動，并根據需要對它們進行審計。

從用戶賬戶和身份驗證開始，還可以考慮Nagios跨平臺代理（NCPA）。在我們的示例中，我們知道需要監視所有部署的服務器，因此必須安裝NCPA代理，并定義令牌以便它可以與Nagios服務器通信。同樣，在部署標準映像之后，再在每臺服務器上執行此操作是沒有意義的。

但是web服務器呢？制定一個標準是明智的，因為這意味著所有對環境負責的人都能對這項技術感到滿意。這使得管理更容易，并且對于自動化特別有利，我們將在下一節中看到。但是，除非你只需要部署運行在Linux上的web服務器，否則這可能不應該作為標準構建的一部分包含在內。

作為一個合理的原則，標準構建應該盡可能簡單和輕量級。當額外的服務都是多余的時，在服務器上面運行它們，占用內存和CPU周期是沒有意義的。同樣，擁有未配置的服務會增加任何潛在攻擊者的攻擊面，因此出于安全原因，建議將其排除在外。

簡言之，標準構建應該只包含將對部署的每個服務器都通用的配置和/或服務。這種方法有時被稱為剛剛夠用操作系統（Just enough Operating System）或簡稱為JeOS，它是SOE的最佳起點。

在了解了SOE的基本原理之后，我們將在下一節中更詳細地了解SOE給你的企業帶來的好處。

1.3探索SOE的好處

到目前為止，你應該對什么是SOE以及它如何為Linux環境帶來規模經濟和更高的效率有所了解。現在，讓我們在此基礎上更詳細地看一個標準化重要性的例子。

1.3.1在Linux環境中SOE的好處示例

說Linux環境中有共同點，也就是說組成SOE的服務器都共享一些屬性和特性。例如，它們可能都是基于Ubuntu Linux構建的，或者它們都用Apache作為其web服務器。

我們可以用一個例子來探討這個概念。假設在負載均衡器后面有10臺Linux web服務器，它們都提供簡單的靜態內容。一切正常，但隨后必須進行配置更改。也許這是為了更改每個web服務器的文檔根目錄，使其指向另一個團隊已部署完成的新代碼版本。

作為負責人，你知道，由于整個解決方案是負載均衡的，所以所有服務器都應該提供相同的內容。因此，每臺服務器都需要進行配置更改。這意味著，如果你手工來做的話，你需要改變10個配置。

當然，你可以手工完成這項工作，但這將是一項乏味的工作，對于熟練的Linux管理員來說，這肯定不是最佳的時間利用方式。它也很容易出錯——在10臺服務器中的一臺上可能會出現打字錯誤，但不會被發現。或者管理員可能會被其他地方的事情中斷，最后只有服務器配置的一部分發生了更改。

更好的解決方案是編寫一個腳本來進行更改。這正是自動化的基礎，幾乎可以肯定的是，在10臺服務器上運行一次單個腳本要比在10臺服務器上手動進行相同的更改更好地利用時間。它不僅效率更高，而且如果在一個月內需要進行相同的更改，那么只需稍加調整就可以重用腳本。

現在，讓我們把計劃打亂。如果由于未知的原因，有人在CentOS 7上使用Apache構建了五個web服務器，而在Ubuntu 18.04 LTS上使用nginx構建了另外五個服務器，會怎么樣？最終的結果是相同的，畢竟，在一個基本的水平，它們都是網絡服務器。但是，如果要在CentOS 7上的Apache中更改文檔根目錄，則需要執行以下操作：

1.在/etc/httpd/conf.d中找到相應的配置文件。

2.對DocumentRoot參數進行所需的更改。

3.使用systemctl reload httpd.service重新加載web服務器。

如果必須在ubuntu18.04 LTS上對nginx執行相同的操作，你可以執行以下操作：

1.在/etc/nginx/sites-available中找到正確的配置文件。

2.對root參數進行所需的更改。

3.確保已使用a2ensite命令啟用站點配置文件。否則，Apache將看不到配置文件。

4.使用systemctl reload apache2.service重新加載web服務器。

從這個相當簡單（盡管是人為的）的例子中可以看出，缺乏通用性是自動化的敵人。為了應對這種情況，你需要執行以下操作：

1.檢測每臺服務器上的操作系統。這本身就是不簡單的。沒有一種方法可以檢測Linux操作系統，因此你的腳本必須經過一系列檢查，包括以下內容：

1./etc/os版本的內容（如果存在）。

2. lsb_release的輸出（如果已安裝）。

3. /etc/redhat-release的內容（如果存在）。

4. /etc/debian_version的內容（如果存在）。

5.其他操作系統所需的特定文件，如果上述步驟沒有產生有意義的結果。

2.在不同的目錄中運行不同的修改命令以影響更改，如前所述。

3.運行不同的命令來重新加載web服務器，同樣如前所述。

因此，腳本變得復雜，更難編寫和維護，當然也更難使其可靠。

盡管這個特殊的例子在現實生活中不太可能出現，但它確實有助于說明一個重要的問題：當環境按照給定的標準構建時，自動化更容易實現。如果決定所有web服務器都基于CentOS 7，都運行Apache 2，并以服務名稱命名站點配置，那么我們的自動化就變得簡單多了。實際上，你甚至可以運行一個簡單的sed命令來完成更改；例如，假設新的web應用程序部署到/var/www/newapp:

# sed -i 's!DocumentRoot.*!DocumentRoot /var/www/newapp!g'

/etc/httpd/conf.d/webservice.conf

# systemctl reload httpd.service

根本不需要環境檢測，只需兩個簡單的shell命令。這可能是一個非常簡單的自動化腳本的基礎，可以依次在10臺服務器上運行，也可以通過SSH遠程運行。不管是哪種方式，我們的自動化任務現在都非常簡單，并且顯示了通用性的重要性。重要的是，SOE在本質上提供了這種通用性。缺乏通用性不僅使自動化變得困難，而且還會妨礙測試，常常會扭曲測試結果，因為如果環境不同，測試結果可能不具有代表性。

在本章的下一節中，我們將在這些知識的基礎上演示SOE如何為軟件測試過程帶來好處。

1.3.2SOE對軟件測試的好處

我在許多環境中看到的一個常見問題是，一個新的軟件部署在一個隔離的預生產環境中成功地進行了測試，但在發布到生產環境中時卻不能正常工作。通常，這個問題可以歸結到生產環境和預生產環境之間的根本區別，因此很明顯，要使測試有效，兩個環境必須盡可能相似。

事實上，像Docker這樣的容器化平臺要解決的問題之一就是這個問題，因此可移植性是容器環境的一個核心特性。部署在Docker上的代碼構建在容器映像之上，簡單地說，就是一個精簡的操作系統映像（還記得JeOS嗎？）。實際上，這是一個非常小的SOE，只是在容器中運行，而不是在裸機服務器或虛擬機上運行。然而，值得考慮的是，如果通過環境標準化實現的可移植性是容器技術的一個關鍵特性，那么我們不應該嘗試在不考慮基礎設施的情況下全面實現這一點。

畢竟，如果生產服務器的配置與預生產服務器不同，那么測試的有效性如何？如果預生產環境是在CentOS 7.6上構建的，但是生產環境是落后于它的CentOS 7.4，那么你真的能確保在一個環境中成功的測試結果將保證在另一個環境中成功嗎？從理論上講，它應該可以工作，但由于環境之間的軟件和庫版本存在根本性差異，這永遠無法得到保證。這甚至是在我們考慮配置文件和安裝的軟件之間可能存在的差異之前需要考慮的。

因此，如果所有的環境都按照相同的標準構建，那么從理論上講，它們都應該是相同的，那么SOE在這方面可以提供幫助。你們中那些目光敏銳的人會注意到“應該”（should）這個詞在前一句中的用法，這是有充分理由的。SOE在定義解決測試失敗的方案方面向前邁出了一大步，但它們并不是全部。

一個環境只有在沒有人修改它的情況下才是標準的，如果所有用戶都有管理員級別的權限，那么很容易有人（善意的或其他的）登錄并進行更改，這意味著環境偏離了標準。

這個問題的答案是，自動化，SOE不僅僅是促進和實現自動化，它們還依賴于自動化來保持最初要求的標準化水平。兩者直接相互支持，理想情況下應該是不可分割的伙伴：SOE是環境本身的定義，自動化提供標準的實現、執行和審計。實際上，這正是本書的前提，即環境應該盡可能地標準化，并且應該讓盡可能多的更改自動化。

本書的重點將放在這個等式的自動化方面，因為除了堅持本章概述的原則之外，所采用的標準對于每個環境都是獨特的，本書的目標不是在微觀級別上確定它們。以我們前面的示例為例，Apache和nginx都有它們的優點，適合一個用例的可能不適合另一個用例。

操作系統也是如此，一些機構可能依賴Red Hat Enterprise Linux提供的支持軟件包，而其他機構則不需要支持軟件包，但需要Fedora提供的前沿技術。定義一個標準沒有對錯之分，只要它滿足它所支持的服務的需求。到目前為止，我們非常關注通用性和標準；然而，在需要替代解決方案的情況下，總會有一些邊緣案例。在下一節中，我們將確定如何知道何時應該偏離標準。

審核編輯 ：李倩