【編者的話】本演講主要針對亞馬遜公司的AWS公有云服務的IT基礎構架，但是也適合搭建其他的虛擬環境，私有云，和公有云。

為什么需要自動化編排

那么首先要了解，為什么需要自動化編排 （orchestration）

• IT環境可再生化 （Re-productable)
• 基礎設施代碼化（Infrastructure as Code）
• 應用易于配置（provision）和部署（deployment）
• 可擴展性高
• 穩定運行狀態

說白點，作為DevOps 工程師，希望自己管理的系統，自動化程度越高越好。希望創建整個系統的時候，能有一鍵安裝的能力。減少構建類似的開發（dev）、測試（stage）和生產（prod）環境的時間，避免重復勞動。 通過代碼管理應用的配置。出問題的時候，也比較容易及時搭建類似環境（svt）做參考。

IT服務的應用構架

云服務的應用構架，分三層，分別是： 基礎構架層 、服務層、應用層。

應用層包括了應用程序的代碼和配置。服務層包括操作系統以及系統配置。

服務層和應用層這塊的自動化已經很普遍，通常會用Puppet、Ansible、Chef、SaltStack之類的自動化配置軟件管理。Docker 的流行，也使得應用的配置管理變得異常便捷。這個大家應該都很有經驗了。 我就不展開了。

那么三層構架里就剩下基礎設施層的管理了。

基礎設施里包括了操作系統鏡像、vpc、gateway、security gorup、subnets、自動擴展配置（scaling）、bastion(jumphost）、V*N等等。 如何創建一致的基礎設施環境是DevOps工程師的一個主要職責。

所以，我們需要： IT基礎構架的自動化。

IT基礎構架的自動化

經過對多種工具的測試后，我公司用下面兩個open source 工具來做自動化管理：

• Packer - 專注于自動化創建鏡像
• Terraform - Infrastructure as Code

他們有幾個共同點：

• 用模版文件管理，可以版本控制（version control）和自動化。
• 方便在不同的平臺部署。
• 都是同一家公司的產品 － HashiCorp。

HashiCorp這家公司也是Vagrant （個人開發環境搭建）和Docker常用的服務發現工具 Consul 的開發公司。

Packer - 專注于創建鏡像

先介紹 Packer：

• 支持多種平臺。
• 用于創建操作系統的機器鏡像 （machine image），比如亞馬遜的AMIs、Openstack images、Docker images、google computer engine、DigitalOcean、virtualbox、VMware，etc。
• 用模版文件管理 （JSON 格式），方便版本控制和自動化。
• 不但支持創建Linux的鏡像，還可以制作Windows 的鏡像。
• 暫時不支持國內的云服務，比如阿里云之類的，個人有興趣的話，可以參與開發和定制。

也就是說，配置好一個模版文件，用pakcer命令就可以按需構建機器鏡像。也可以根據需求及時更改配置。 加入軟件版本控制（主要用的是 Git）后，就可以很方便的追溯更改。

制作鏡像的目的是什么呢？ 制作更新的鏡像文件可以減少操作系統升級的時間 （比如yum update），統一基本鏡像的配置，定期打補丁，定制公司內部安全標準，以及安裝配置必備應用（比如我個人偏好用 htop 替代 top 命令）。

有了pakcer，只需要了解這一個工具，就可以為不同平臺創建系統鏡像。這樣的話，DevOps 工程師可以擴充自己的能力來隨時應對不同的IT基礎設施環境。

下面來看看一個簡單的packer 的模版格式。

{

"variables": {
"aws_access_key": "",
"aws_secret_key": ""
},
"builders": [{
"type": "amazon-ebs",
"access_key": "{{user aws_access_key}}",
"secret_key": "{{user aws_secret_key}}",
"region": "us-east-1",
"source_ami": "ami-de0d9eb7",
"instance_type": "t1.micro",
"ssh_username": "ubuntu",
"ami_name": "packer-example {{timestamp}}"
}]
} </pre> 
 
這里例子里，第一個部分“variables”定義了變量， 變量也可以采用環境變量。 第二部分“builders”定義了如何創建新的鏡像：環境是aws 的 EBS鏡像， 所需要的api key， 源鏡像，鏡像創建的區域，實例大小，名字，用戶名（不同的操作系統有不同的用戶名，比如：ec2-user、Ubuntu、CentOS) ，等等。

{

"variables": ["..."],
"builders": ["..."],
"provisioners": [
{
"type": "file",
"source": "packer.sh",
"destination": "/tmp/packer.sh"
},
{
"type": "shell",
"inline": [

 "sudo chmod +x /tmp/packer.sh",

 "sudo bash -x /tmp/packer.sh",

 "sudo rm /tmp/packer.sh"


]
}
$ cat packer.sh
!/usr/bin/env bash
apt-get -y update
apt-get -y install htop</pre> 
 
“provisioners” 部分主要是用于在創建鏡像時，需要在源鏡像里執行的命令。 通常都是最基本的配置需求。 我喜歡將所有需要運行的命令都事先寫進一個本地的shell腳本文件（packer.sh）里，隨后復制到鏡像里執行。

如果應用安裝有需求的話，也可以安排在制作鏡像的時候，重啟幾次。
如果你需要在鏡像里缺省安裝docker，將安裝步驟寫到packer.sh 里即可。
制作好 template 文件后，運行下面的命令就可以產生最新的鏡像。
$ packer build \

-var 'aws_access_key=YOUR ACCESS KEY' \
-var 'aws_secret_key=YOUR SECRET KEY' \
example.json
==> amazon-ebs: amazon-ebs output will be in this color.
==> amazon-ebs: Creating temporary keypair for this instance...
==> amazon-ebs: Creating temporary security group for this instance...
...
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-19601070</pre> 
 
新的AMI （ami-19601070）就創建成功了，你可以登錄到AWS管理界面里確認。

 packer 的具體使用，請參閱packer網站的文檔： https://www.packer.io/docs 。有些基本的技巧，比如跳轉服務器（jumphost）的設置，鏡像命名的方式，我專門在GitHub上做了個 軟件倉庫 ，你們可以用來參考。 
鏡像制作好了，我們就需要構建整個IT的基礎設施了。
Terraform - Infrastructure as Code
下面介紹第二個工具： Terraform。
Terraform 的發音類似于電話（telephone）的英文發音，只要把 r 和 l 區分好就可以了。
那么Terraform 可以用來干什么呢？
 
  
Infrastructure as Code。

  
高效安全的部署IT基礎構架。

  
可以持續更改/迭代基礎設施。

  
配置用模版文件管理，便于版本控制。

  
語法簡單，可讀性很高。

  
支持主流的虛擬環境或者云服務，國內的云服務產品暫時不在其支持的列表。

  
不同的虛擬環境或者云服務，一個工作流程。

  
AWS cloudformation 的絕佳替代品。

  
方便地模擬，創建，更改，銷毀部分或者整個IT基礎構架。

 
Terraform用于創建，管理基礎設施資源。 Terraform的最大優勢就是，基礎設施的代碼化。將項目涉及到的所有資源：vpc、網關（gateway）、 security gorup、subnets、自動擴展配置（auto-scaling）、bastion（jumphost）、V*N、 ec2、elastic load balancer、route 53、 rds、ses、sns等等，都寫在一個配置模版文件里。
可能很多人會提到AWS CloudFormation，也可以實現AWS基礎設施的代碼化。 但是CloudFormation 模版文件實在是太復雜了，更改時很容易出錯。 隨著服務資源的增加，CloudFormation文件會變的很長，越來越難讀。
相對于Terrraform的模版文件，行數就少很多，而且代碼通俗易懂。
Terrraform 還有另一個優勢， 在管理不同的平臺時，無需學習新知識。Terrraform支持多種基礎平臺。IaaS（例如AWS、DigitalOcean、GCE、OpenStack的），PaaS的（Heroku、CloudFoundry）或SaaS服務（Atlas、DNSimple、CloudFlare的）。
對DevOps 工作人員來說，這是個很給力的功能。 公司的需求一直會變，外部的環境也會變，云服務的價格和服務也在變。 如果想對市面上所有主流的云產品都能精通，個人可能沒有那么多時間去一一了解，如果一直被亞馬遜云牽著鼻子走，可能會比較被動。公司要找樣樣精通的大牛也會消耗太高的招人成本。開發人員也可以騰出更多的時間專注于產品的開發實現上。
至于有些公司會有混合云的需求，Terraform也能很好的提供支持。
下面介紹Terraform 的幾個基本命令使用：
plan 模擬
apply 構建和改變
destroy 銷毀
provider "aws" {

access_key = "ACCESS_KEY_HERE"
secret_key = "SECRET_KEY_HERE"
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
$ terraform plan
...

aws_instance.example

ami:               "" => "ami-408c7f28"
availability_zone: "" => "<computed>"
instance_type:     "" => "t1.micro"
key_name:          "" => "<computed>"
private_dns:       "" => "<computed>"
private_ip:        "" => "<computed>"
public_dns:        "" => "<computed>"
public_ip:         "" => "<computed>"
security_groups:   "" => "<computed>"
subnet_id:         "" => "<computed>"     </pre> 
 
”terraform plan“ 并不會改變系統，只是展示將要更改的資源。如果確認后，運行”terraform apply” 來實施改變。

上面的模版文件里定制了一個簡單ec2實例。
你也可以在創建ec2實例時，加入userdata，就是第一次啟動時需要運行的命令。 也可以加入其他的資源，比如vpc、subnet、security groups、s3、rds，etc。
該產品還處在開發階段，基本功能夠用了，但不能夠實現所有的aws 的功能。另一個原因是，AWS 發展太快，新服務層出不窮，開源社區的開發人員跟不上。
那么我們來看看具體實施的命令。
$ terraform apply

aws_instance.example: Creating...
ami:           "" => "ami-408c7f28"
instance_type: "" => "t1.micro"
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</pre> 
 
可以看到，一個新的資源創建了。這里是一臺新的ec2 實例。

也可以銷毀， 先試運行一下：
$ terraform plan -destroy

...

aws_instance.example</pre>
確認后，刪除。
$ terraform destroy



aws_instance.example: Destroying...
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
...</pre> 
 
刪除和模擬刪除時，可以添加參數來控制要刪除的部分資源還是全部資源。

 具體Terraform 的使用，請參考 https://www.terraform.io/docs/index.html 。 
 和前面packer一樣，我在同一個GitHub軟件倉庫里，做了個簡單可用的vpc構建模版給你們 參考 。 
總結與鏈接分享
引進了packer 和Terraform后，整個自動化編排就成了如下的流程：
Packer (machine images) -> Terraform (構建基礎構架）-> puppet/ansible/chef/Docker（操作系統和應用的配置管理）
整個流水線上，都可以自動化了。
分享些其他的相關鏈接：
 
  
 Windows系統也可以用packer制作鏡像 

 https://github.com/joefitzgerald/packer-windows 

  
 packer 擴展定制介紹。比如有人會有興趣參與為阿里云定制，可以看這個文檔。 

 https://www.packer.io/docs/extend/builder.html 

  
 支持 微軟云 azure 的packer 擴展 

 https://github.com/Azure/packer-azure 

  
 Terraform 的一些模版范例 

 https://github.com/hashicorp/t ... mples 

 
Q&A
 Q：Terraform 建立EC2時怎么用之前構建好的鏡像？ 
A：例子中， "source_ami": "ami-de0d9eb7" 就是引入源鏡像。 
 Q：packers感覺就是鏡像的封裝，不知道描述是否貼切，它與kickstart有什么不同？ 
A：可以理解為封裝。kickstart 更像userdata。 
 Q：這個Terraform構建基礎架構是否可以理解為基礎應用環境的搭建？ 
A：是基礎設施（Infrastructure) 的搭建。 
 Q：請問如果在AWS主要服務運行在ECS ElasticBeanstalk 甚至API Gateway、Lambda這些stack，是否這些工具就不適用了？ 
 A：ElasticBeanstalk 本身已經是高度自動化了。 但是 lambda支持。 具體可以查看： https://www.terraform.io/docs/ ... .html 。 
 Q：Windows系統也可以用packer制作鏡像，底層需不需要虛擬化? 
A：可以在源鏡像上擴展，也可以直接用操作系統的iso文件制作。 
 Q：請問這里面介紹的模板與heat的模板通用么？ 
 A：我沒有用過heat。 但是這里有個專門的比較： https://www.terraform.io/intro ... .html 。 
 Q：我現在用的技術棧也是基于 vagrant+packer+terraform，上面講到Terraform 不支持 AWS VPC Peering 這一點是不正確的，因為我現在已經在使用了，可能您使用的版本比較老。 
 A：Terraform里的原話： You still have to accept the peering with the AWS Console, aws-cli or aws-sdk-go.（ https://www.terraform.io/docs/ ... .html ）。 
 Q：這個Terraform是否可用于管理CPU、內存等資源？ 
A：可以定義和更新需要的資源類型 （instance type），不同的instance type 代表不同的CPU和內存。 
 Q：用packer制作一次鏡像能用于生產測試各環境運行嗎，不同環境配置參數可能不同，packer如何支持一次打包到處運行的問題？ 
A：你可以按需定制不同的模版文件和制作不同的鏡像。 
 Q：packer 和 vagrant 使用起來感覺很像呀，他們的主要區別是啥 ？ 
 A：你說的是vagrant box 吧， packer 是可以用來創建 vagrant box 的。具體參考 https://www.packer.io/intro/ge ... .html 。 
 Q：可以簡單介紹一下您認為最好用的服務層和應用層的自動化工具，以及原因。 
A：這個話題很大。 主流的話，就是Puppet、Ansbile、Chef、SaltStack。 我們公司用Puppet 來管理系統配置，用Ansible管理應用級別的配置。因為系統配置改變相對較少，我們是level 4 engineering team，用Puppet 統一管理不同的云服務（AWS和公司內部的私有云）的系統配置。 但是Puppet 相對來說，學習曲線要比ansbile困難很多。 對應用的管理，需要較多的修改，BAU（運維）團隊比較容易支持。所以選用ansible 做自動配置管理。 
 Q：自動化編程能實現0運維嗎？ 
A：還是需要DevOps（自動化運維） 
 Q：基礎設施可以理解為中間件？JVM對于Hadoop來說是基礎設施？這樣理解正確嗎？ 
A：對我來說，jvm 和hadoop都屬于應用層的。 
 Q：packer制作鏡像，使用本地shell腳本文件來執行命令感覺調試困難，因為命令有錯的話如何方便配合用戶修改？不會是讓用戶看日志然后改腳本從頭重試，再錯再試，如此反復吧？很低效哦。 
A：有很多方法。但是寫腳本是最直接的。 鏡像的制作確實需要不斷調試的過程。 這是DevOps工作的一部分。 通常你將制作好的鏡像告訴開發人員即可。 
 Q： 腳本里直接使用apt-get，會不會導致不同時間創建的基礎設施上軟件版本出現不一致？你們考慮過自建軟件源保證一致性嗎？ 
A：這就是用packer 的好處。 你可以階段性的產生不同的鏡像，不會覆蓋以前的。 然后新鏡像需要在dev／uat 環境下測試。過關后，才可以用于生產環境。 鏡像制作完后，里面的內容不會改變了。 
 Q：可以對創意的資源健康狀況進行監控么？一旦有異常，會有自愈策略么？ 
A：Terraform里有部分支持的。比如某個security group 的inbound 規則有改變，運行 terraform plan 是可以看到有資源被修改。 如果運行實施的話，會修復的。 
 Q：編排的時候有沒有把類似監控nagios sensu 之類agent的考慮在內？ 
A：這個屬于應用層的配置，歸自動化配置管理工具，比如puppet／ansible 來管理。 
 Q：按照您的回復，不同時間創建的鏡像還是存在某些包版本不一致，您有針對性的測試方法推薦嗎，還是在uat環境應用沒問題就直接上生產使用了？ 
A：我們暫時是這樣使用的。dev／uat 環境下運行正常就推到生產環境。 如果出了問題，也可以快速回滾。公司允許我們承擔這個風險的。 
 Q： Terraform在AWS使用play apply等創建實例時候，只支持單個AMI鏡像么？如果想要同時配置多個不同鏡像的實例，該怎么辦？ 
A：不是的，可以創建任意多個。在創建不同的ec2實例時，指定不同的源鏡像即可。 
 Q：你們有沒有類似cmdb將所有的資源包括虛擬機的信息放在一個統一的數據庫里。 另外，你們有用服務發現嗎？用的什么軟件做服務發現? 怎么做的集成？ 
A：Terraform 的模版文件做的就是做這個事情啊。 針對第二個問題，服務發現屬于應用層的。 當然你可以在定制terraform 實例資源里的userdata時，加一條 服務發現的命令即可，這樣該實例啟動后，發現服務自然就注冊了這個新的實例了。 
 Q：用模版文件管理是如何進行版本控制（version control）的？ 
A：就是用Git 。 將Template 文件存到Git 里， 可以是內部的Git服務器，比如我們公司用的atlassian stash， 也可以用GitHub之類的 。 
 Q：這個自動化部署的工具，嘉賓有實踐過通過PaaS調用，并且部署成功嗎？ 
A：沒有。 AWS屬于IaaS。 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 以上內容根據2016年1月26日晚微信群分享內容整理。分享人 王云祥，DevOps工程師，現任職于澳洲電信，專注IT自動化解決方案，持有Puppet和AWS認證。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesz，進群參與，您有想聽的話題可以給我們留言。 
 </div>