Configuration Management is the practice of defining performance, functional, and physical attributes of a product and then ensuring the consistency of a systems "configuration" throughout its life. Configuration management tools that have been traditionally used in the systems realm for server and application deployments are now being used as configuration management automation tools to improve network operations. These tools are not new. What is new and exciting is how their use in networking is revolutionizing how infrastructures are managed.
設定管理（Configuration Management）是指定義產品的效能、功能及實體屬性，並在整個生命週期中確保系統「設定」一致性的做法。傳統上用於伺服器與應用程式部署系統領域的設定管理工具，現在也被當作設定管理自動化工具，用來改善網路維運。這些工具本身並不新穎，真正令人振奮的是它們在網路領域的應用，正在徹底改變基礎架構的管理方式。
Configuration management tools offer the following benefits:
設定管理工具提供以下優點：
- Automate the provisioning and deployment of applications and infrastructure自動化應用程式與基礎架構的佈建與部署
- Require no knowledge of programming—they use the declarative model (intent), not scripting不需要程式設計知識，使用宣告式模型（意圖），而非撰寫指令碼
- Leverage software development practices for deployments, including version control and testing在部署時運用軟體開發實務，包含版本控制與測試
- Common tools are Puppet, Ansible, Terraform, and Chef常見工具有 Puppet、Ansible、Terraform 及 Chef
From a networking perspective, it is common to deploy changes manually. A change could be adding a VLAN across a data center or campus, or making daily changes to firewall policies for new applications being deployed. When there is a defined manual workflow to perform a set of tasks, proper tools should be used to automate it. It does not make sense to spend an hour performing a change. This change could take just a few minutes by using a properly engineered tool. This process is where tools such as Puppet, Chef, Ansible and Terraform can dramatically reduce the number of manual interactions with the network.
從網路的角度來看，以手動方式部署變更是很常見的做法。例如在資料中心或校園網路新增 VLAN，或每天為新部署的應用程式調整防火牆政策。當有一組明確的手動工作流程需要執行一系列任務時，就應該使用適當的工具將其自動化。花一個小時完成一項變更是不合理的，透過妥善設計的工具，同樣的變更可能只需幾分鐘。這正是 Puppet、Chef、Ansible 及 Terraform 等工具能大幅減少對網路手動操作的地方。
With configuration management tools, you can define and enforce configurations related to system level operations (for example, authentication, logging, image), interface level configuration (for example, VLAN, QoS, security), routing configurations (for example, OSPF or BGP specifications), and so on.
使用設定管理工具，你可以定義並強制執行與系統層級操作（例如驗證、記錄、映像檔）、介面層級設定（例如 VLAN、QoS、安全性）、路由設定（例如 OSPF 或 BGP 規格）等相關的設定。
These tools are often referred to as DevOps tools. They are more specifically configuration management and automation tools that happen to be used by those organizations that have implemented some form of DevOps practices, such as version control and testing.
這些工具經常被稱為 DevOps 工具。更精確地說，它們是設定管理與自動化工具，恰好被那些已經導入某種 DevOps 實務（例如版本控制與測試）的組織所使用。
These tools enable you to automate applications, infrastructure, and networks to a high degree without the need to do any manual programming. While they do reduce the time that it takes to perform certain tasks, they also offer greater predictability.
這些工具讓你能在幾乎不需要任何手動程式設計的情況下，高度自動化應用程式、基礎架構與網路。它們不僅能縮短完成某些任務所需的時間，也能提供更高的可預測性。
A common architecture of configuration management tool systems consists of a central server, where a required or intended state of the system is defined, and a number of devices, where this state is pushed to and needs to be enforced.
設定管理工具系統常見的架構，是由一台定義系統所需或預期狀態的中央伺服器，以及一批必須推送並強制執行此狀態的裝置所組成。
Agent vs. Agentless Approach
代理式與無代理式方法
The two models of automated configuration management illustrated in the figure reflect two different philosophies. The first model is the intent-based model, where a central server defines the required or intended state of the system. Agents on system elements enforce that state. Agent-based configuration management is pull-based, and requires installation of an agent on a network device.
圖中所示的兩種自動化設定管理模型，反映了兩種不同的理念。第一種模型是意圖式模型，由中央伺服器定義系統所需或預期的狀態，系統元件上的代理程式則負責強制執行該狀態。以代理程式為基礎的設定管理屬於拉取（pull-based）模式，需要在網路裝置上安裝代理程式。
The second model is an evolution of traditional CLI and SSH techniques with automation to create reusable command sets and frameworks for scalability. No agent or client is required on the target elements. Agentless management is accomplished through remote shell access. With remote shell access, a configuration management server or primary will utilize a push model to deliver a payload in the form of a script through the network
第二種模型是傳統 CLI 與 SSH 技術的演進，結合自動化來建立可重複使用的指令集與框架，以提升可擴充性。目標元件上不需要任何代理程式或用戶端。無代理式管理是透過遠端 Shell 存取來完成的，透過遠端 Shell 存取，設定管理伺服器（或主要伺服器）會使用推送（push）模式，經由網路以指令碼的形式傳遞承載內容。
In the agent-based concept, exemplified by Puppet and Chef, the control software—the Puppet Master or the Chef Server " defines the intent of the configuration state of the target elements. On a target element, a software agent, or client, is monitoring the actual configuration state of the element. The agent or client interacts with the master or server to report actual state and to receive the intended state. If the actual state of the element differs from the intended state, then the agent takes necessary steps to enforce the configuration. An example of such step would be configuring that element to bring it in line with the intended state as defined by the master or server. The architecture is uniform for all target elements that can support the agent or client. When agents are used for switch management, they can be installed in the native Linux user space, a Linux container (LXC).
在以 Puppet 與 Chef 為代表的代理式概念中，控制軟體（Puppet Master 或 Chef Server）會定義目標元件設定狀態的意圖。在目標元件上，會有一個軟體代理程式（或用戶端）監控該元件的實際設定狀態。代理程式或用戶端會與主控端或伺服器互動，回報實際狀態並接收預期狀態。如果元件的實際狀態與預期狀態不同，代理程式就會採取必要步驟強制執行設定。例如，將該元件設定成符合主控端或伺服器所定義的預期狀態。這種架構對所有能支援該代理程式或用戶端的目標元件而言都是一致的。當代理程式用於交換器管理時，可以安裝在原生 Linux 使用者空間或 Linux 容器（LXC）中。
In the agentless approach, exemplified by Ansible and Terraform, the desired configuration state is defined in Ansible Playbooks and Terraform Configurations, respectively. Ansible Playbooks are text-based configuration files that specify how Ansible modules should be deployed. The Ansible framework reads these playbooks and utilizes the modules to provision (issue commands to configure) the target elements. For instance, on Linux servers, these commands are executed via Python scripts that are deployed through SSH and run on the target element. For Cisco platforms, these commands are executed via CLI. Similarly, Terraform Configuration files are text-based documents that outline how Terraform Providers should be utilized. The Terraform framework reads these configurations and uses the providers to provision (issue commands to configure) the targeted elements.
在以 Ansible 與 Terraform 為代表的無代理式方法中，所需的設定狀態分別定義在 Ansible Playbook 與 Terraform 設定檔中。Ansible Playbook 是文字型的設定檔案，用來指定應如何部署 Ansible 模組。Ansible 框架會讀取這些 Playbook，並利用模組佈建（發出指令以設定）目標元件。例如在 Linux 伺服器上，這些指令是透過 SSH 部署並在目標元件上執行的 Python 指令碼來執行的；對 Cisco 平台而言，這些指令則是透過 CLI 執行的。同樣地，Terraform 設定檔是文字型文件，說明應如何使用 Terraform 提供者（Provider）。Terraform 框架會讀取這些設定，並使用提供者來佈建（發出指令以設定）目標元件。
A major advantage to the remote shell access method is that there is little to no configuration required on the device as there are no agents required for installation. A potential drawback is the need to ensure that the security configuration on the device is kept synchronized, as any change can have a significant impact on the configuration management tool's ability to access the switch.
遠端 Shell 存取方法的一大優點，是裝置上幾乎不需要任何設定，因為不需要安裝代理程式。潛在的缺點則是必須確保裝置上的安全性設定保持同步，因為任何變更都可能對設定管理工具存取交換器的能力造成重大影響。
The key point with both approaches is that a single toolset can be used to configure IT infrastructure devices—such as application servers and the software that runs on them—and the network connectivity required between them. This means that the overall deployment lifecycle for an application can be defined and managed from a single point, by a single team. This is generally not the case with traditional network infrastructure because it is generally managed and configured separately from IT infrastructure. That separation of concerns can inhibit efficient application services deployments. Unifying configuration of all layers in a single toolset increases efficiency and agility, and reduces costs.
這兩種方法的重點都在於，可以使用單一工具組來設定 IT 基礎架構裝置（例如應用程式伺服器及其上執行的軟體）以及它們之間所需的網路連線。這表示應用程式的整體部署生命週期，可以由單一團隊從單一角度定義與管理。傳統網路基礎架構通常並非如此，因為它一般是與 IT 基礎架構分開管理與設定的。這種職責分離可能會阻礙有效率的應用程式服務部署。在單一工具組中統一所有層級的設定，能提升效率與敏捷性，並降低成本。
Declarative vs. Procedural Approach
宣告式與程序式方法
In the world of configuration management tools, there are two general approaches: declarative and procedural, represented by Terraform and Ansible, respectively. In a declarative model, the user defines only the desired state of the system. It is up to the declarative framework to take appropriate actions in the correct order to bring the system from the current to the desired state. This is very similar to ordering a dish in a restaurant, where you simply declare what dish you would like and let the staff do the rest. In contrast, with a procedural model, used by Ansible, you specify the exact sequence of steps that need to be followed to reach a desired outcome. This approach is like following a recipe in cooking, where each action must be executed in a particular order and manner specified by the recipe.
在設定管理工具的世界裡，有兩種通用的方法：宣告式與程序式，分別以 Terraform 與 Ansible 為代表。在宣告式模型中，使用者只需定義系統所需的狀態，至於採取何種正確順序的適當動作，將系統從目前狀態帶往所需狀態，則交由宣告式框架負責。這非常類似在餐廳點餐，你只需說出想要哪道菜，其餘就交給服務人員處理。相對地，Ansible 所採用的程序式模型，則需要你指定達成所需結果所必須遵循的確切步驟順序。這種做法就像按照食譜烹飪，每個動作都必須依照食譜指定的順序與方式執行。
The declarative and imperative approaches each excel in specific scenarios and are not mutually exclusive. For instance, a declarative tool like Terraform is well-suited for managing immutable infrastructure, where changes are typically made by rebuilding from a baseline. An example of this would be changing the IP interface of a virtual machine in a public cloud. In such cases, the existing virtual machine is usually deleted, and a new instance is redeployed with the new IP address. Conversely, an imperative tool like Ansible excels in tasks that require granular control over each action, such as installing and updating software or frequently modifying configurations. Terraform and Ansible can be highly complementary, especially in public cloud environments. For example, while Terraform can be used to deploy and manage virtual routers and switches in a cloud setting, Ansible can be utilized to handle the ongoing configuration management of these devices. This combination allows for robust infrastructure setup with detailed, customizable management capabilities.
宣告式與命令式方法各自在特定情境中表現出色，兩者並非互斥。例如，像 Terraform 這樣的宣告式工具，很適合用於管理不可變基礎架構，因為此類基礎架構的變更通常是透過從基準重建來完成的。舉例來說，變更公有雲中虛擬機器的 IP 介面時，通常會刪除既有的虛擬機器，再以新的 IP 位址重新部署一個新的執行個體。相對地，像 Ansible 這樣的命令式工具，則擅長需要對每個動作進行細緻控制的任務，例如安裝與更新軟體，或經常修改設定。Terraform 與 Ansible 可以高度互補，尤其是在公有雲環境中。例如，Terraform 可用於在雲端環境中部署與管理虛擬路由器與交換器，而 Ansible 則可用於處理這些裝置後續的持續設定管理。這種組合能同時實現穩健的基礎架構建置，以及細緻、可自訂的管理能力。