我們遇到了一個有趣的爭論，並陷入了兩個陣營。我對我們可能缺少的想法或陷阱的任何特定問題感興趣。實際上，任何可以幫助我們做出決定或指出我們沒有考慮到的事情的東西。我知道這有點繞開了「無意見」規則，但我希望這仍然是一個可以接受的問題。也很抱歉篇幅較長，其中存在一些細微差別。
1）一方面（我的－我並非沒有偏見）發現不可變伺服器模型對於雲端系統來說非常有趣。為此，我們將基礎架構的所有元件遷移到 Docker 中進行了原型設計。我們的自訂應用程式透過 Jenkins 直接建置到部署到本機 Docker 註冊表的 Docker 映像中。然後，我們建立了大量 Ansible 角色和一個 playbook，能夠連接到空伺服器，安裝 Docker，然後告訴 Docker 根據需要安裝所有容器。幾分鐘後，整個應用程式及其所有支援基礎設施都已連接並開始工作 - 日誌記錄、監控、資料庫建立/填充等。我們的擴展計劃是製作新的 Playbook，從基礎可信 AMI（可能是非常簡單的映像）構建新的 AWS 伺服器，滾動部署生產應用程式以處理配置管理和發布，並且通常不再編輯伺服器 -只是重新製作它們。我並不關心我所描述的內容在實踐中是否有效——只要它是一個合理的模型。
2) 另一個陣營希望使用Puppet 來處理設定管理，Ansible 來部署我們的自訂應用程式（這些應用程式是從我們的建置流程產生的tarball），Foreman 來處理整個流程的觸發和管理，Katello 來做一些基礎工作影像管理。發布將涉及 Puppet 根據需要更改配置，以及 Ansible 在一定程度的 Foreman 協調下部署更新的元件。如果我們需要新伺服器，伺服器的建置速度會相當快，但目的並不是讓它們成為標準流程的一部分。這更接近 phoenix 伺服器模型，但壽命較長。
所以我的問題實際上可以歸結為：帶有我上面描述的工具的不可變伺服器模型實際上是否像它看起來的那樣現實？我喜歡這樣的想法：我們的暫存過程實際上可以即時建立應用程式的完整克隆，讓 QA 對其進行錘煉，然後只需翻轉資料庫儲存和一些 DNS 設定即可使其生效。
或者不可變伺服器模型在實踐中失敗了嗎？我們在 AWS 和雲端環境方面擁有豐富的經驗，因此這並不是真正的問題 - 更重要的是如何可靠地部署相當複雜的應用程式。這是特別令人感興趣的，因為我們發布得非常頻繁。
除了實際為我們創建 EC2 伺服器之外，我們讓 Ansible 做大部分需要做的事情，這並不難。我無法理解為什麼你在這個模型中實際上需要 Puppet/Foreman/Katello。據我所知，Docker 比任何工具中的自訂部署腳本都要乾淨、簡單得多。當您不再擔心必須在原位配置它們並只需使用新配置再次建置它們時，Ansible 似乎比 Puppet 使用起來簡單得多。我是 KISS 原則的粉絲——尤其是在墨菲定律盛行的自動化領域。在我看來，機械越少越好。
任何有關該方法的想法/意見或建議將不勝感激！
答案1
在我們公司，我們已在客戶的遺留基礎架構上成功實施了 Puppet。我們還使用 Docker 容器來運行專用服務（這實際上是一個經過修剪和扭曲以適應容器的舊應用程式）。
當我第一次開始使用容器時，我對容器並不滿意（是的...... 30kb 應用程式變成了200MB 的重圖像），但是當我在一場小災難後不得不重新創建整個環境時，我改變了主意。我認為 Docker 正是為此而發明的：快速且頻繁的部署，無需擔心伺服器配置。如果正確設計容器，您可以輕鬆地在雲端供應商、開發人員筆記型電腦和託管資料中心之間切換。因為您所需要的只是一個帶有 Docker 守護程式的普通 Linux 盒子。
- 在場景 1）中，您將所有內容集中在一個地方（我的意思是一個地方，因為使用 Docker，您將在同一個儲存庫中擁有程式碼和配置），易於管理、讀取和部署。
- 在場景 2) 中，您必須將 3 個不同（！）工具的配置部分儲存在一個儲存庫中，並將應用程式程式碼儲存在另一個儲存庫中，這使得事情變得更加複雜
我在之前的專案中也使用過 Puppet，到目前為止，我的經驗是，不可變伺服器是可以實現的，而不是使用 Docker，而不是 Puppet 或 Chef。我相信配置管理工具對雲端提供者而不是開發團隊更有用。
答案2
這是我的 2 歐分。
您提出的兩個選項是實現（某種）不變性的有效選項。
我認為你應該選擇一個你更舒服的。
然而，從你寫的內容來看，似乎還沒有共識。
也許需要第三種選擇？ ;)
然而，這種不變性不是目標，而是確保其他屬性的手段（無配置漂移、更好的穩定性…）。
我會清楚地陳述我的目標，設定一些指標來驗證它們，並使用這兩個選項進行一些測試。然後，您將獲得一些數據來選擇最適合您的業務的數據。
祝你好運！