這篇文章討論了如何在我們的環(huán)境中安裝和配置軟件，這個(gè)任務(wù)通常被稱為服務(wù)器配置（Server Provisioning）。

服務(wù)器配置

在開始介紹現(xiàn)代化的工具之前，我們來看看最基本且經(jīng)過實(shí)戰(zhàn)考驗(yàn)的服務(wù)器配置工具：shell腳本。在Chef、Ansible或Puppet出現(xiàn)之前，很多運(yùn)營團(tuán)隊(duì)使用Bash來配置服務(wù)器（在Windows上則使用PowerShell腳本）。

例如，如果想在運(yùn)行Ubuntu的Amazon EC2實(shí)例上安裝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腳本來配置服務(wù)器上的所有東西。據(jù)我所知，所有主流的配置工具都使用了基于安全傳輸層（如SSH）的shell命令或PowerShell（Chef可能是個(gè)例外）。即使你使用了配置工具，在某些時(shí)候也需要用到腳本。因此，當(dāng)你開始使用配置工具（如Chef或Ansible）時(shí)，學(xué)習(xí)如何使用基本的shell腳本也會(huì)為你帶來很多好處。

你可能會(huì)問自己，為什么在shell腳本已經(jīng)可以完成所有工作的同時(shí)還要學(xué)習(xí)配置工具？很多環(huán)境已經(jīng)使用shell腳本進(jìn)行服務(wù)器配置，那么為什么要使用配置工具代替它們？

首先，shell腳本通常使用的是聲明性語法。shell腳本通過運(yùn)行命令序列來安裝軟件，而配置工具只需要指定服務(wù)器應(yīng)該安裝哪些軟件，這樣就可以使用相同的代碼在不同的操作系統(tǒng)上、使用不同的包管理器以及指定不同的版本來安裝和配置相同的軟件。

其次，配置工具通常會(huì)提供用于組織基礎(chǔ)設(shè)施的方式。雖然使用shell腳本也可以做到這一點(diǎn)，但配置工具通常會(huì)提供更簡潔明了的方案。因?yàn)槭切袠I(yè)標(biāo)準(zhǔn)，開發(fā)人員可以更輕松地找出QA環(huán)境中哪些服務(wù)器運(yùn)行RabbitMQ。

第三，每個(gè)主要的配置工具都有一個(gè)蓬勃發(fā)展的社區(qū)，他們構(gòu)建可復(fù)用的模塊來安裝大多數(shù)開源軟件。你可以直接在模塊配置中指定內(nèi)存限制，而不需要記住Postgres配置文件在哪里，這樣可以節(jié)省很多時(shí)間。

當(dāng)然，原因還有很多，這里就不一一例舉了。盡管學(xué)習(xí)曲線有點(diǎn)陡峭，但學(xué)習(xí)配置工具仍然是值得的。與shell腳本相比，配置工具更容易使用，便于思考，也更容易維護(hù)。

關(guān)于命名

學(xué)習(xí)使用Chef（服務(wù)器配置工具）的前幾周給我留下了深刻的印象。入門指南展示了如何創(chuàng)建一個(gè)“recipe”，其中包含安裝或配置軟件的說明，我能夠理解這種比喻背后的含義。recipe必須存在于“cookbook”中，這是有道理的。然后你在“kitchen”里測試cookbook，但我開始有點(diǎn)懷疑了。

這種比喻有點(diǎn)令人感到困惑，于是我決定去看一下其他工具，如Ansible。Ansible文檔的第一頁介紹了“playbook”的概念，而playbook包含一系列“play”。

那么，這些問題很重要嗎？當(dāng)然很重要了，因?yàn)?strong>在學(xué)習(xí)配置工具之前，你應(yīng)該知道，它們很有可能會(huì)引入大量令人費(fèi)解的術(shù)語。即使是為了完成基本的任務(wù)，你也必須重新學(xué)習(xí)很多術(shù)語。如果你是剛開始學(xué)習(xí)配置工具，我強(qiáng)烈建議你隨時(shí)寫下這些術(shù)語定義，你還有很多東西要學(xué)。

每個(gè)軟件開發(fā)人員都會(huì)為現(xiàn)有的單詞創(chuàng)建不同的含義，他們甚至還會(huì)發(fā)明一些單詞，比如“uninitialize”和“unregister”。這已經(jīng)成為軟件開發(fā)的一部分。

我會(huì)盡量用大家熟悉的術(shù)語來解釋這些工具。

配置管理

你決定使用花哨的配置工具在遠(yuǎn)程服務(wù)器上安裝Nginx。在開始設(shè)置數(shù)據(jù)庫備份節(jié)點(diǎn)前，一切都很順利。你已經(jīng)編寫了MySQL主服務(wù)器的配置文件，但是你不太確定如何配置MySQL從服務(wù)器的內(nèi)部DNS地址。這個(gè)時(shí)候配置管理就派上用場了。

在設(shè)置服務(wù)器時(shí)，最好可以將應(yīng)用程序視為由兩部分組成：不可變部分（通常是代碼或編譯的二進(jìn)制文件）和可變部分（通常是配置文件或環(huán)境變量）。大部分由社區(qū)創(chuàng)建的模塊默認(rèn)情況下會(huì)安裝二進(jìn)制文件，并提供盡可能合理的配置，而且會(huì)為我們暴露出一些屬性，方便對其進(jìn)行覆蓋。

這些屬性通常包含特定于用戶環(huán)境的值。大多數(shù)配置工具都為用戶提供了一種機(jī)制，通過模板將特定于環(huán)境的值插入到配置文件中，或直接插入到環(huán)境變量中。

你可以使用配置工具提供的配置管理來配置MySQL主服務(wù)器的配置文件，然后在其中配置從服務(wù)器。

Secret管理

這樣就可以解決上述的問題，但后來發(fā)現(xiàn)，你必須上傳AWS憑證才能讓MySQL從服務(wù)器訪問S3。你知道不能直接將這些憑證提交到代碼庫中，因此這些憑證只能存在于你的機(jī)器和NSA服務(wù)器上。

這個(gè)時(shí)候你需要的是Secret管理。

與自動(dòng)化領(lǐng)域的所有東西一樣，你也有很多管理秘鑰的可選項(xiàng)。谷歌提供了一項(xiàng)名為KMS的服務(wù)，AWS也提供了一項(xiàng)名為Secret Manager的服務(wù)，Chef提供了加密數(shù)據(jù)包，Hashicorp提供了一款名為Vault的產(chǎn)品，Ansible也有一款名為Vault的產(chǎn)品。除了KMS會(huì)對字符串進(jìn)行加密之外，所有這些工具都提供了相同的功能：保護(hù)對加密秘鑰的訪問（這些秘鑰被用在配置管理中）。

有好幾次，我不小心將秘鑰提交到了代碼庫。這類事情一直在發(fā)生，而且非常危險(xiǎn)。

切勿以明文形式存儲(chǔ)API密鑰或憑證。

可以使用Secret管理解決方案來存儲(chǔ)這些數(shù)據(jù)，然后將其綁定到配置工具中。

一個(gè)簡單的例子：Chef

首先需要安裝Chef Development Kit（ChefDK）。

如前所述，我們需要一個(gè)recipe來安裝Nginx。出于教學(xué)的目的，我們將從頭開始創(chuàng)建它，而不是從社區(qū)的cookbook中撈一個(gè)出來。

我們需要?jiǎng)?chuàng)建一個(gè)cookbook。cookbook通常存在于`cookbooks`目錄中，在項(xiàng)目的根目錄運(yùn)行以下命令：

mkdir cookbooks

現(xiàn)在讓我們創(chuàng)建一個(gè)cookbook，用于放置我們的新recipe：

chef generate cookbook cookbooks/application

這個(gè)命令在`cookbooks/application`目錄中創(chuàng)建了很多文件，我們關(guān)心的是`cookbooks/application/recipes/default.rb`這個(gè)文件。這個(gè)文件包含了默認(rèn)的recipe，我們將安裝Nginx的命令放到這個(gè)文件中。

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

這個(gè)文件中的前兩個(gè)命令將執(zhí)行你期望的操作：

• `apt_update`更新你的aptitude包。
• `package ‘nginx’`使用操作系統(tǒng)默認(rèn)包管理器安裝`nginx`包（在這個(gè)示例中，它使用的是aptitude）。

最后一個(gè)命令將`cookbooks/application/files/index.html`拷貝成遠(yuǎn)程服務(wù)器上的`/var/www/html/index.html`，并設(shè)置文件的權(quán)限，讓Nginx服務(wù)器可以訪問它。

這個(gè)文件還不存在，所以需要?jiǎng)?chuàng)建它。首先要?jiǎng)?chuàng)建`文件`目錄：

mkdir cookbooks/application/files

然后創(chuàng)建文件`cookbooks/application/files/index.html`，其中包含以下內(nèi)容：

<html lang="en-us"> <head> <title>Hello, World!</title> </head> <body>      Chef has landed.    </body> </html>

更新`packer.json`，加入Chef相關(guān)配置：

{ "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`進(jìn)行了兩處更改。

首先，我們?yōu)锳MI添加了一個(gè)`Image`標(biāo)簽。我們之前從Packer的輸出中復(fù)制AMI ID，并粘貼到Terraform代碼中。這不是一個(gè)可維護(hù)的解決方案，因?yàn)锳MI ID會(huì)經(jīng)常發(fā)生變化，而且我們不應(yīng)該在每次發(fā)生變化時(shí)都要將更改推送到存儲(chǔ)庫中。相反，我們使用Terraform的`data`資源來動(dòng)態(tài)讀取AMI ID（使用`Image=application`查詢最新的AMI）。

其次，我們使用`chef-solo`替換了`shell`。我們告訴它在哪里可以找到cookbooks目錄，以及要運(yùn)行哪個(gè)recipe。默認(rèn)情況下，`run_list`中的`recipe[COOKBOOK]`條目將執(zhí)行`recipes/default.rb`。我們也可以顯式指定explicity:`recipe [COOKBOOK::RECIPE]`來覆蓋默認(rèn)行為。由于我們的recipe保存在`recipes/default.rb`中，所以將使用默認(rèn)行為。

現(xiàn)在開始構(gòu)建我們的AMI：

packer build packer.json

我們的新AMI有一個(gè)`Image`標(biāo)簽，現(xiàn)在修改`terraform.tf`中硬編碼的AMI，讓它通過標(biāo)簽來查找AMI。

將以下內(nèi)容添加到`terraform.tf`中：

data "aws_ami" "web" {    most_recent = true   owners = ["self"]    filter {                             name = "tag:Image"          values = ["application"]    }                                }

現(xiàn)在使用`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}"  }

運(yùn)行下面的命令創(chuàng)建Chef配置的服務(wù)器，然后啟動(dòng)瀏覽器，打開地址為負(fù)載均衡器的域名：

terraform plan -out terraform.plan  terraform apply "terraform.plan"  open "http://$(terraform output dns)"

你應(yīng)該能夠在打開的瀏覽器頁面上看到：Chef has landed!

一個(gè)簡單的例子：Ansible

讓我們使用Ansible來構(gòu)建這個(gè)相同的示例。首先需要安裝Ansible。

Ansible將安裝和配置說明組織到`tasks`中，然后將`tasks`組織到`playbook`中。讓我們?yōu)閜laybook創(chuàng)建一個(gè)目錄結(jié)構(gòu)。

mkdir playbook  mkdir playbook/files

這并不是組織Ansible playbook的最佳實(shí)踐。因?yàn)槲覀兊挠美芎唵?，所以使用了簡化版本。如果你對Ansible感興趣，應(yīng)該根據(jù)官方提供的建議來構(gòu)建playbook。

在`playbook/application.yml`中創(chuàng)建playbook，內(nèi)容如下：

---  - 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

這個(gè)playbook文件包含配置我們的服務(wù)器所需的所有信息。現(xiàn)在讓我們來討論一下它的結(jié)構(gòu)。

每個(gè)playbook包含一個(gè)“play”列表，每個(gè)play包含一個(gè)“tasks”列表，task用于安裝和配置軟件。我們的playbook包含兩個(gè)play。第一個(gè)play在Ubuntu上安裝Python 2.7（用于運(yùn)行Ansible）。第二個(gè)play安裝和配置Nginx。

我們在每個(gè)play的根節(jié)點(diǎn)配置了兩個(gè)參數(shù)：`hosts`和`become`。`hosts`參數(shù)告訴Ansible應(yīng)該在哪臺(tái)機(jī)器上運(yùn)行playbook（“all”表示在所有機(jī)器上運(yùn)行）。`become:yes`表示Ansible將通過sudo運(yùn)行所有命令，否則將會(huì)出現(xiàn)很多權(quán)限錯(cuò)誤。

play的第一個(gè)task負(fù)責(zé)安裝和配置Nginx，它將更新aptitude緩存，并確保`nginx`包存在。如果已經(jīng)安裝了`nginx`包，這個(gè)命令將不執(zhí)行任何操作。

第二個(gè)task將`files/index.html`拷貝到遠(yuǎn)程服務(wù)器上，并為其分配正確的權(quán)限。

這個(gè)文件還不存在，所以讓我們創(chuàng)建它。將以下內(nèi)容加入到`playbook/files/index.html`中：

<html lang="en-us"> <head> <title>Hello, World!</title> </head> <body>      Ansible has landed.    </body> </html>

這就是我們配置Ansible所需的全部內(nèi)容?，F(xiàn)在讓Packer使用這個(gè)配置。使用以下內(nèi)容更新`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作為配置器，需要提供一個(gè)指向playbook文件的路徑，我們將其設(shè)置為`./playbook/application.yml`。我們可以看到用于安裝Nginx的play頂部有一行：`hosts: applications`。這是我們用來告訴Ansible需要安裝應(yīng)用程序的主機(jī)別名。我們需要告訴Packer我們正在為其中一個(gè)主機(jī)構(gòu)建映像，所以我們將`host_alias`屬性設(shè)置為`applications`。

運(yùn)行下面的命令來創(chuàng)建Ansible配置的服務(wù)器，然后啟動(dòng)瀏覽器，打開地址為負(fù)載均衡器的域名：

packer build packer.json  terraform plan -out terraform.plan  terraform apply "terraform.plan" open "http://$(terraform output dns)"

你應(yīng)該可以在打開的瀏覽器頁面上看到：Ansible has landed!

英文原文：http://stephenmann.io/post/a-brief-introduction-to-provisioning/