伺服器配置自動化：Windows Azure 上的 Ubuntu（+ WordPress、Nginx、Git）
我們想要一些關於如何自動將 Ubuntu 虛擬機配置為我們的應用程序的登台伺服器的想法，測試登台程式碼，然後將腳本部署到生產伺服器（而不是一個人通過 ssh 在登台伺服器上安裝所有東西，複製文件結束，手動編輯配置等）
如果需要，我們可以遷移到 AWS，但我們現在在 Azure 上還可以——我們基本上在 Azure 上獲得了一個具有 SSH 訪問權限的 Ubuntu VM，所以它與其他配置基於 linux 的伺服器的方式應該沒有什麼不同。想像
我們想要一個腳本做的基本上是：
- 通過 SSH “進入”新的虛擬機
- 安裝 nginx、MariaDB、php、其他 apt-get 安裝
- 從 Git 儲存庫部署我們的 wordpress 程式碼副本
- 使用 wordpress 配置資訊和其他資訊將範例暫存數據庫導入 MariaDB
- 使用 cloudflare API 為伺服器設置 DNS 主機名（可選，如果需要，可以手動執行此操作）
- 讓測試新程式碼的人四處看看
然後，如果它工作正常，我們希望自動將 Git 中的新程式碼推送到我們的生產伺服器，而無需手動編輯 wordpress 配置文件等。但這與通過腳本設置登台環境的問題有點不同
到目前為止我遇到的工具是這些（由於帳戶代表低而無法提供連結）
- 廚師
- 木偶
- 流浪漢
- 鹽棧
- Ansible
- 巨聚
在深入研究它們之前，我想知道是否有人對適用於我們需求的內容有 10,000 英尺的看法。
您真正需要的是解決兩個相互疊加的不同（但密切相關）問題的解決方案：
- 配置管理
- 部署自動化
兩者之間有一些重疊，當您開始時，可能會有點模糊哪些工具用於您的基礎設施的哪些部分。不過，這裡有一些通用指南可以幫助您入門：
配置管理工具通常遵循面向資源的冪等模型。也就是說，您將系統建模為一組具有狀態的資源，並不斷執行配置管理工具以查看是否有任何與您的規範不同的地方。如果資源未處於該狀態，則您有一些特定於類型的邏輯將資源帶入該狀態。包或使用者帳戶是一種簡單而明顯的資源，但您可能還擁有 ElasticSearch 模板、SELinux 數據庫中的條目或 Nagios 主機，這些主機也可以在您選擇的配置管理系統中聲明為資源。
舉個簡單的例子，一個包可能已安裝或未安裝，並且它可能附加了一個版本。配置管理工具將能夠採用說明包 X 應該安裝的配置規範，查看它目前未安裝，並採取正確的步驟將其從未安裝狀態變為已安裝狀態（顯然，通過安裝它）。
冪等性意味著您可以應用相同的配置十次、一百次或一千次並獲得完全相同的結果——只有需要更改的內容實際上被更改了。這與可能會在配置文件中附加一行一百次的腳本形成對比（這意味著您最終在該文件中使用同一行一百次）。
使用此模型的配置管理系統的缺點是資源之間的關聯相當鬆散，它們不能很好地映射到數據庫導入或模式遷移等長期執行的任務，而且它們通常不會給你大量的準確控制在堆棧中的多個系統中應用的順序。
Puppet 和 Chef 是配置管理系統的範例。
部署自動化工具用於執行臨時任務。換句話說，當你需要做某事時，你顯式地執行它們。（好吧，有時您會從觸發器隱式執行它們，例如從持續集成系統中。）這些通常以可預測的方式編排多個系統；例如，您可能只希望您的一個 Web 伺服器在升級期間執行數據庫遷移，並且您可能希望僅在數據庫遷移成功時才進行應用伺服器升級，並且您可能希望您的應用伺服器在一次重新啟動三個時間，這樣您就不會在更新期間關閉整個應用程序。最重要的是，您只希望這個過程在您告訴它時準確地開始。
Capistrano 和 Fabric 是部署自動化工具的流行範例。對於單個伺服器，您可以在整個應用程序中輕鬆使用 Makefiles 之類的東西。
在您的特定情況下，您可能需要一個配置管理系統來處理諸如數據庫系統和 PHP 的安裝以及 Web 伺服器的配置之類的事情。另一方面，您可能需要一個部署工具來處理數據庫的創建以及將測試數據填充到其中。從 Git 下載應用程式碼可以通過配置管理或部署自動化工具輕鬆建模，具體取決於哪種更適合您的需求。無論您選擇哪種方法，人們對於您的應用程序的配置文件應該如何進入伺服器都有不同的意見。
當您使用此類工具時，最重要的是，如果您沒有正確使用它們，它們將完全是一種浪費。換句話說，如果您正在使用一種花哨的自動化部署方法將您的應用程序置於暫存狀態，而您的生產伺服器實際上看起來並不像您的花哨的暫存伺服器，那麼您幾乎已經付出了很多努力沒有收穫。做正確的事，他們會很好地為你服務。