以Chef和Ansible為例快速入門伺服器配置
這篇文章討論瞭如何在我們的環境中安裝和配置軟體，這個任務通常被稱為伺服器配置（Server Provisioning）。
伺服器配置
在開始介紹現代化的工具之前，我們來看看最基本且經過實戰考驗的伺服器配置工具：shell指令碼。在Chef、Ansible或Puppet出現之前，很多運營團隊使用Bash來配置伺服器（在Windows上則使用Shell/">PowerShell指令碼）。
例如，如果想在執行Ubuntu的Amazon EC2例項上安裝Nginx，可以使用以下指令碼（install-nginx.sh）：
#!/bin/sh ssh -t ubuntu@$1 sudo apt-get upgrade ssh -t ubuntu@$1 sudo apt-get -y install nginx
我們可以使用shell指令碼來配置伺服器上的所有東西。據我所知，所有主流的配置工具都使用了基於安全傳輸層（如SSH）的shell命令或PowerShell（Chef可能是個例外）。即使你使用了配置工具，在某些時候也需要用到指令碼。因此，當你開始使用配置工具（如Chef或Ansible）時，學習如何使用基本的shell指令碼也會為你帶來很多好處。
你可能會問自己，為什麼在shell指令碼已經可以完成所有工作的同時還要學習配置工具？很多環境已經使用shell指令碼進行伺服器配置，那麼為什麼要使用配置工具代替它們？
首先，shell指令碼通常使用的是宣告性語法 。shell指令碼通過執行命令序列來安裝軟體，而配置工具只需要指定伺服器應該安裝哪些軟體 ，這樣就可以使用相同的程式碼在不同的作業系統上、使用不同的包管理器以及指定不同的版本來安裝和配置相同的軟體。
其次，配置工具通常會提供用於組織基礎設施的方式 。雖然使用shell指令碼也可以做到這一點，但配置工具通常會提供更簡潔明瞭的方案。因為是行業標準，開發人員可以更輕鬆地找出QA環境中哪些伺服器執行RabbitMQ。
第三，每個主要的配置工具都有一個蓬勃發展的社群，他們構建可複用的模組來安裝大多數開源軟體。你可以直接在模組配置中指定記憶體限制，而不需要記住Postgres配置檔案在哪裡，這樣可以節省很多時間。
當然，原因還有很多，這裡就不一一例舉了。儘管學習曲線有點陡峭，但學習配置工具仍然是值得的。與shell指令碼相比，配置工具更容易使用，便於思考，也更容易維護 。
關於命名
學習使用Chef（伺服器配置工具）的前幾周給我留下了深刻的印象。入門指南展示瞭如何建立一個“recipe”，其中包含安裝或配置軟體的說明，我能夠理解這種比喻背後的含義。recipe必須存在於“cookbook”中，這是有道理的。然後你在“kitchen”裡測試cookbook，但我開始有點懷疑了。
這種比喻有點令人感到困惑，於是我決定去看一下其他工具，如Ansible。Ansible文件的第一頁介紹了“playbook”的概念，而playbook包含一系列“play”。
那麼，這些問題很重要嗎？當然很重要了，因為在學習配置工具之前，你應該知道，它們很有可能會引入大量令人費解的術語 。即使是為了完成基本的任務，你也必須重新學習很多術語。如果你是剛開始學習配置工具，我強烈建議你隨時寫下這些術語定義，你還有很多東西要學。
每個軟體開發人員都會為現有的單詞建立不同的含義，他們甚至還會發明一些單詞，比如“uninitialize”和“unregister”。這已經成為軟體開發的一部分。
我會盡量用大家熟悉的術語來解釋這些工具。
配置管理
你決定使用花哨的配置工具在遠端伺服器上安裝Nginx。在開始設定資料庫備份節點前，一切都很順利。你已經編寫了SQL/">MySQL主伺服器的配置檔案，但是你不太確定如何配置MySQL從伺服器的內部DNS地址。這個時候配置管理就派上用場了。
在設定伺服器時，最好可以將應用程式視為由兩部分組成：不可變部分（通常是程式碼或編譯的二進位制檔案）和可變部分（通常是配置檔案或環境變數）。大部分由社群建立的模組預設情況下會安裝二進位制檔案，並提供儘可能合理的配置，而且會為我們暴露出一些屬性，方便對其進行覆蓋。
這些屬性通常包含特定於使用者環境的值。大多數配置工具都為使用者提供了一種機制，通過模板將特定於環境的值插入到配置檔案中，或直接插入到環境變數中。
你可以使用配置工具提供的配置管理來配置MySQL主伺服器的配置檔案，然後在其中配置從伺服器。
Secret管理
這樣就可以解決上述的問題，但後來發現，你必須上傳AWS憑證才能讓MySQL從伺服器訪問S3。你知道不能直接將這些憑證提交到程式碼庫中，因此這些憑證只能存在於你的機器和NSA伺服器上。
這個時候你需要的是Secret管理。
與自動化領域的所有東西一樣，你也有很多管理祕鑰的可選項。谷歌提供了一項名為KMS的服務，AWS也提供了一項名為Secret Manager的服務，Chef提供了加密資料包，Hashicorp提供了一款名為Vault的產品，Ansible也有一款名為Vault的產品。除了KMS會對字串進行加密之外，所有這些工具都提供了相同的功能：保護對加密祕鑰的訪問（這些祕鑰被用在配置管理中）。
有好幾次，我不小心將祕鑰提交到了程式碼庫。這類事情一直在發生，而且非常危險。
切勿以明文形式儲存API金鑰或憑證。
可以使用Secret管理解決方案來儲存這些資料，然後將其繫結到配置工具中。
一個簡單的例子：Chef
首先需要安裝Chef Development Kit（ChefDK）。
如前所述，我們需要一個recipe來安裝Nginx。出於教學的目的，我們將從頭開始建立它，而不是從社群的cookbook中撈一個出來。
我們需要建立一個cookbook。cookbook通常存在於`cookbooks`目錄中，在專案的根目錄執行以下命令：
mkdir cookbooks
現在讓我們建立一個cookbook，用於放置我們的新recipe：
chef generate cookbook cookbooks/application
這個命令在`cookbooks/application`目錄中建立了很多檔案，我們關心的是`cookbooks/application/recipes/default.rb`這個檔案。這個檔案包含了預設的recipe，我們將安裝Nginx的命令放到這個檔案中。
apt_update package 'nginx' cookbook_file '/var/www/html/index.html' do source 'index.html' owner 'www-data' group 'www-data' mode '0755' action :create end
這個檔案中的前兩個命令將執行你期望的操作：
- `apt_update`更新你的aptitude包。
- `package ‘nginx’`使用作業系統預設包管理器安裝`nginx`包（在這個示例中，它使用的是aptitude）。
最後一個命令將`cookbooks/application/files/index.html`拷貝成遠端伺服器上的`/var/www/html/index.html`，並設定檔案的許可權，讓Nginx伺服器可以訪問它。
這個檔案還不存在，所以需要建立它。首先要建立`檔案`目錄：
mkdir cookbooks/application/files
然後建立檔案`cookbooks/application/files/index.html`，其中包含以下內容：
<html lang="en-us"> <head> <title>Hello, World!</title> </head> <body> Chef has landed. </body> </html>
更新`packer.json`，加入Chef相關配置：
{
"builders": [{
"type": "amazon-ebs",
"region": "us-east-1",
"source_ami": "ami-04169656fea786776",
"instance_type": "t2.small",
"ssh_username": "ubuntu",
"ami_name": "Ubuntu 16.04 Nginx - {{timestamp}}",
"tags": {
"Image": "application"
}
}],
"provisioners": [{
"type": "chef-solo",
"cookbook_paths": ["cookbooks"],
"run_list": ["recipe[application]"]
}]
}
我們對之前的`packer.json`進行了兩處更改。
首先，我們為AMI添加了一個`Image`標籤。我們之前從Packer的輸出中複製AMI ID，並貼上到Terraform程式碼中。這不是一個可維護的解決方案，因為AMI ID會經常發生變化，而且我們不應該在每次發生變化時都要將更改推送到儲存庫中。相反，我們使用Terraform的`data`資源來動態讀取AMI ID（使用`Image=application`查詢最新的AMI）。
其次，我們使用`chef-solo`替換了`shell`。我們告訴它在哪裡可以找到cookbooks目錄，以及要執行哪個recipe。預設情況下，`run_list`中的`recipe[COOKBOOK]`條目將執行`recipes/default.rb`。我們也可以顯式指定explicity:`recipe [COOKBOOK::RECIPE]`來覆蓋預設行為。由於我們的recipe儲存在`recipes/default.rb`中，所以將使用預設行為。
現在開始構建我們的AMI：
packer build packer.json
我們的新AMI有一個`Image`標籤，現在修改`terraform.tf`中硬編碼的AMI，讓它通過標籤來查詢AMI。
將以下內容新增到`terraform.tf`中：
data "aws_ami" "web" {
most_recent = true
owners = ["self"]
filter {
name = "tag:Image"
values = ["application"]
}
}
現在使用`aws_ami.web resource`輸出的ID替換`aws_instance.web1`和`aws_instance.web2 `resource中的AMI ID：
resource "aws_instance" "web1" {
ami= "${data.aws_ami.web.id}"
availability_zone= "us-east-1a"
instance_type= "t2.small"
vpc_security_group_ids = ["${aws_security_group.application.id}"]
subnet_id= "${aws_subnet.private1.id}"
}
resource "aws_instance" "web2" {
ami= "${data.aws_ami.web.id}"
availability_zone= "us-east-1b"
instance_type= "t2.small"
vpc_security_group_ids = ["${aws_security_group.application.id}"]
subnet_id= "${aws_subnet.private2.id}"
}
執行下面的命令建立Chef配置的伺服器，然後啟動瀏覽器，開啟地址為負載均衡器的域名：
terraform plan -out terraform.plan terraform apply "terraform.plan" open "http://$(terraform output dns)"
你應該能夠在開啟的瀏覽器頁面上看到：Chef has landed!
一個簡單的例子：Ansible
讓我們使用Ansible來構建這個相同的示例。首先需要ofollow,noindex" target="_blank">安裝Ansible 。
Ansible將安裝和配置說明組織到`tasks`中，然後將`tasks`組織到`playbook`中。讓我們為playbook建立一個目錄結構。
mkdir playbook mkdir playbook/files
這並不是組織Ansible playbook的最佳實踐。因為我們的用例很簡單，所以使用了簡化版本。如果你對Ansible感興趣，應該根據官方提供的建議來構建playbook 。
在`playbook/application.yml`中建立playbook，內容如下：
--- - hosts: all gather_facts: False become: yes pre_tasks: - name: Install Python 2.7 raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal) - hosts: applications become: yes tasks: - name: Install Nginx apt: name: nginx state: present update_cache: yes - name: Update contents of index.html copy: src: index.html dest: /var/www/html/index.html owner: www-data group: www-data mode: 0755
這個playbook檔案包含配置我們的伺服器所需的所有信息。現在讓我們來討論一下它的結構。
每個playbook包含一個“play”列表，每個play包含一個“tasks”列表，task用於安裝和配置軟體。我們的playbook包含兩個play。第一個play在Ubuntu上安裝Python 2.7（用於執行Ansible）。第二個play安裝和配置Nginx。
我們在每個play的根節點配置了兩個引數：`hosts`和`become`。`hosts`引數告訴Ansible應該在哪臺機器上執行playbook（“all”表示在所有機器上執行）。`become:yes`表示Ansible將通過sudo執行所有命令，否則將會出現很多許可權錯誤。
play的第一個task負責安裝和配置Nginx，它將更新aptitude快取，並確保`nginx`包存在。如果已經安裝了`nginx`包，這個命令將不執行任何操作。
第二個task將`files/index.html`拷貝到遠端伺服器上，併為其分配正確的許可權。
這個檔案還不存在，所以讓我們建立它。將以下內容加入到`playbook/files/index.html`中：
<html lang="en-us"> <head> <title>Hello, World!</title> </head> <body> Ansible has landed. </body> </html>
這就是我們配置Ansible所需的全部內容。現在讓Packer使用這個配置。使用以下內容更新`packer.json`：
{
"builders": [{
"type": "amazon-ebs",
"region": "us-east-1",
"source_ami": "ami-04169656fea786776",
"instance_type": "t2.small",
"ssh_username": "ubuntu",
"ami_name": "Ubuntu 16.04 Nginx - {{timestamp}}",
"tags": {
"Image": "application"
}
}],
"provisioners": [{
"type": "ansible",
"playbook_file": "./playbook/application.yml",
"host_alias": "applications"
}]
}
我們只修改了使用Ansible作為配置器，需要提供一個指向playbook檔案的路徑，我們將其設定為`./playbook/application.yml`。我們可以看到用於安裝Nginx的play頂部有一行：`hosts: applications`。這是我們用來告訴Ansible需要安裝應用程式的主機別名。我們需要告訴Packer我們正在為其中一個主機構建映像，所以我們將`host_alias`屬性設定為`applications`。
執行下面的命令來建立Ansible配置的伺服器，然後啟動瀏覽器，開啟地址為負載均衡器的域名：
packer build packer.json terraform plan -out terraform.plan terraform apply "terraform.plan" open "http://$(terraform output dns)"
你應該可以在開啟的瀏覽器頁面上看到：Ansible has landed!
英文原文：http://stephenmann.io/post/a-brief-introduction-to-provisioning/
感謝張嬋對本文的審校。