在多個環境中建立基礎設施時，同時確保標準化和有效的監控，安全的这些东西就變得非常關鍵。為了實現這一目標，採取不可變的基础設施方法，將環境作為代碼來提供是至關重要的。
本文的目的是通過使用GitLab的結構來強制實施模板和標準，使用Terraform在服務器之間應用和維護標準，並使用Ansible進行軟件供应和配置，並在倉庫之間使用共享角色模型的方法來展示一種可能的方法。為了管理Terraform中机器的狀態，我們使用MinIO，因為它使這一代碼在本地實現變得可能。
架構設計
步驟1
過程總是從提交標準化問題開始，指明要使用的堆疊模型，是否需要防火牆权限，以及是新的設置還是僅僅是資源升級。
步驟2
操作員查看問題並開始過程。所有的對話和花費的時間都在問題中記錄。
步驟3
在 GitLab 裡開始一個新專案，基於將要創建的基礎設施模型。這個項目被放置在 GitLab 中的相對應組裡，它繼承了標準化基礎設施創建所需的必要環境變量。
步驟 4
當項目創建完成時，你只需要在問題中指定的環境（KVM、VMware）中為将要創建的基础設施指定 IP。經過與 Terraform 計劃後，會創建所需的資源，包括如有需要時新增標签，讓 Veeam 根據標签策略執行備份。完成後，創建基礎設施的狀態被存儲在一個桶裡。
步驟 5
接下來的步驟包括對所有服務器執行標準任務，如標識它們、更新套件、安裝必要的工具，以及讓 Zabbix 註冊主機以基礎監控操作系統和堆栈。取決於資源組，會將合適的訪問密钥分配給負責的團隊。例如，數據庫管理員（DBAs）會收到數據庫服務器的訪問密钥。
步驟 6
基於選擇的模型，執行整個堆栈的安裝和配置過程。 similarly, 用戶被創建，當必要時，凭证被註冊在 Vault 中。
步驟 7
應用現在在新的環境中運行，可以對每個堆疊進行特定的監控，並在Consul中註冊新服務器。Prometheus subsequently identifies where it needs to collect information from. 每個堆疊都已經配置了自己的監控控制盤，唯一的差別是創建的项目的名稱。
步驟 8
新的基礎設施已經交付給requester。在數據庫的情況下，凭據直接在Vault中提供。
項目結構
GitLab中的文件結構如下所示：
- /infrastructure/：主組，用於存放全局環境變量與預設值
- /infrastructure/gitlab-models：管道模型，我們有兩個主要項目
- ansible-pipelines：一個用於維護堆疊和角色 composition 的項目。
在上面的工作中，我們看到一個典型的任務示例。在結構中，它位於以下路徑：/infrastructure/gitlab-models/ansible-pipelines/common-task/provision.yml
- terraform-pipelines：可用基礎設施模型的管道，如vSphere、KVM、AWS等。
在上圖中，我們有一個位於 terraform-pipelines 群組內的管道範例，例如 kvm-terraform-pipeline.yml。如我們所見，這是一個 GitLab CI 模型，旨在在堆疊管道中擴展。
- /infrastructure/templates：在這個群組中，我們有啟動項目，這些項目將用於建立堆疊模型。
- /infrastructure/provision/ansible/roles：在這個項目中，我們只有 Ansible 角色，這使我們能夠集中和獨立更新角色。
- /infrastructure/dependencies-iac：此儲存庫包含平台的依賴項，例如 Terraform 和 Ansible 的 Dockerfiles，確保所需工具和庫的版本不會更改。
- /infrastructure/modules/：為 Terraform 創建的模組存儲在此儲存庫中，每個項目都有其各自的文件夾。
- /infrastructure/on-premise/：這個群組是用來維護已創建的基礎設施，並根據環境、數據中心、堆疊和項目進行細分。在圖中，我們可以看到從群組到子群組再到最終項目的層級結構。在每個層級，我們可以覆蓋與這些群組相關的變數值。
如何使用平台
為了簡化平台的使用，我們創建了一個名為 issues-ops 的儲存庫，在這裡我們提供了一個問題模板，可以根據具體需求進行選擇。這樣，基礎設施請求從一開始就被記錄下來。
問題創建後，DevSecOps團隊可以開始設定環境。為了做到这一点，他們只需要導航到適當的分組，在此情況下，為基礎設施/去皮/暂存/dc1/負載平衡器/Nginx，並根據模板創建新項目。然後他們應該提供要創建的項目的名稱並分配必要的變量。
在每個模板中，已經配置了用於環境創建的所需的.gitlab-ci.yml文件。在NGINX的情況下，它是用這種格式設置的。
在這個設定中，也包括基礎設施創建模板和Ansible模板，確保這些项目中已經整合了默認角色。另外，我們提供擴展模型的步驟。如果需要安裝額外的角色，您只需添加相應的區塊，使配置採取模塊化、建造塊的方法。
在下面的圖像中，我們看到運行要求的环境創建管線。您會發現authorized_keys和common被执行了，即使它們沒有在.gitlab-ci.yml中显式声明。這是因為我們從導入的Ansible模板中獲得了標準角色，確保在所有项目中應用默認角色。
結論
基礎設施平台對維持和執行標準有很大的貢獻，因為它需要一個預定義模型進行計劃、測試、實施，並作為模板在建立任何新基礎設施之前使其可用。此過程確保無論我們何時需要在環境中部署資源，我們都在建立一致的標準，对这些环境进行版本控制，并确保必要时它们可以被可靠地重建。
其中一个主要的挑戰是保持模型的最新性和验证，特别是随着应用的演进和操作系统版本的变更。使用基础设施即代码时，务必要记住，所有的变更都应该通过它来进行，确保正确的配置版本控制和环境不可变性。不这样做可能会导致平台将环境回退到其定义状态，可能会覆盖手动更改。
本文提出的模型具有多功能性，适用于本地环境及多云环境，使其成为混合基础设施的有效解决方案。
Source:
https://dzone.com/articles/implement-an-iac-platform-with-terraform-ansible-gitlab