【编者的话】本演讲主要针对亚马逊公司的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 groups、subnets、自动扩展配置（scaling）、bastion（jumphost）、VPN等等。 如何创建一致的基础设施环境是DevOps工程师的一个主要职责。
所以，我们需要： IT基础构架的自动化。
IT基础构架的自动化
经过对多种工具的测试后，我公司用下面两个开源工具来做自动化管理：- Packer - 专注于自动化创建镜像
- Terraform - Infrastructure as Code
他们有几个共同点：
- 用模版文件管理，可以版本控制（version control）和自动化。
- 方便在不同的平台部署。
- 都是同一家公司的产品 － HashiCorp。
HashiCorp这家公司也是Vagrant （个人开发环境搭建）和Docker常用的服务发现工具 Consul 的开发公司。
Packer - 专注于创建镜像
先介绍 Packer。Packer是一个开源工具，用于从单一配置来源为多平台创建相同的机器映像。目前支持的平台包括Amazon EC2、DigitalOcean、OpenStack、VirtualBox和VMware。- 支持多种平台。
- 用于创建操作系统的机器镜像 （machine image），比如亚马逊的AMIs、Openstack images、Docker images、google computer engine、DigitalOcean、virtualbox、VMware等。
- 用模版文件管理 （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}}"
}]
}
这里例子里，第一个部分“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
“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
新的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）、vpn、 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>"
”terraform plan“ 并不会改变系统，只是展示将要更改的资源。如果确认后，运行”terraform apply” 来实施改变。
上面的模版文件里定制了一个简单ec2实例。
你也可以在创建ec2实例时，加入userdata，就是第一次启动时需要运行的命令。 也可以加入其他的资源，比如vpc、subnet、security groups、s3、rds等。
该产品还处在开发阶段，基本功能够用了，但不能够实现所有的aws 的功能。另一个原因是，AWS 发展太快，新服务层出不穷，开源社区的开发人员跟不上。
那么我们来看看具体实施的命令。
$ terraform apply
aws_instance.example: Creating...
ami: "" => "ami-408c7f28"
instance_type: "" => "t1.micro"
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
可以看到，一个新的资源创建了。这里是一台新的ec2 实例。
也可以销毁， 先试运行一下：
$ terraform plan -destroy
...
- aws_instance.example
确认后，删除。
$ terraform destroy
aws_instance.example: Destroying...
Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
...
删除和模拟删除时，可以添加参数来控制要删除的部分资源还是全部资源。
具体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时怎么用之前构建好的镜像？Q：packers感觉就是镜像的封装，不知道描述是否贴切，它与kickstart有什么不同？
A：例子中， "source_ami": "ami-de0d9eb7" 就是引入源镜像。
Q：这个Terraform构建基础架构是否可以理解为基础应用环境的搭建？
A：可以理解为封装。kickstart 更像userdata。
Q：請問如果在AWS主要服務運行在ECS ElasticBeanstalk 甚至API Gateway、Lambda這些stack，是否這些工具就不適用了？
A：是基础设施（Infrastructure) 的搭建。
Q：Windows系统也可以用packer制作镜像，底层需不需要虚拟化?
A：ElasticBeanstalk 本身已经是高度自动化了。 但是 lambda支持。 具体可以查看：https://www.terraform.io/docs/ ... .html。
Q：请问这里面介绍的模板与heat的模板通用么？
A：可以在源镜像上扩展，也可以直接用操作系统的iso文件制作。
Q：我现在用的技术栈也是基于 vagrant+packer+terraform，上面讲到Terraform 不支持 AWS VPC Peering 这一点是不正确的，因为我现在已经在使用了，可能您使用的版本比较老。
A：我没有用过heat。 但是这里有个专门的比较：https://www.terraform.io/intro ... .html。
Q：这个Terraform是否可用于管理CPU、内存等资源？
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：用packer制作一次镜像能用于生产测试各环境运行吗，不同环境配置参数可能不同，packer如何支持一次打包到处运行的问题？
A：可以定义和更新需要的资源类型 （instance type），不同的instance type 代表不同的CPU和内存。
Q：packer 和 vagrant 使用起来感觉很像呀，他们的主要区别是啥 ？
A：你可以按需定制不同的模版文件和制作不同的镜像。
Q：可以简单介绍一下您认为最好用的服务层和应用层的自动化工具，以及原因。
A：你说的是vagrant box 吧， packer 是可以用来创建 vagrant box 的。具体参考 https://www.packer.io/intro/ge ... .html 。
Q：自动化编程能实现0运维吗？
A：这个话题很大。 主流的话，就是Puppet、Ansbile、Chef、SaltStack。 我们公司用Puppet 来管理系统配置，用Ansible管理应用级别的配置。因为系统配置改变相对较少，我们是level 4 engineering team，用Puppet 统一管理不同的云服务（AWS和公司内部的私有云）的系统配置。 但是Puppet 相对来说，学习曲线要比ansbile困难很多。 对应用的管理，需要较多的修改，BAU（运维）团队比较容易支持。所以选用ansible 做自动配置管理。
Q：基础设施可以理解为中间件？JVM对于Hadoop来说是基础设施？这样理解正确吗？
A：还是需要DevOps（自动化运维）
Q：packer制作镜像，使用本地shell脚本文件来执行命令感觉调试困难，因为命令有错的话如何方便配合用户修改？不会是让用户看日志然后改脚本从头重试，再错再试，如此反复吧？很低效哦。
A：对我来说，jvm 和hadoop都属于应用层的。
Q： 脚本里直接使用apt-get，会不会导致不同时间创建的基础设施上软件版本出现不一致？你们考虑过自建软件源保证一致性吗？
A：有很多方法。但是写脚本是最直接的。 镜像的制作确实需要不断调试的过程。 这是DevOps工作的一部分。 通常你将制作好的镜像告诉开发人员即可。
Q：可以对创意的资源健康状况进行监控么？一旦有异常，会有自愈策略么？
A：这就是用packer 的好处。 你可以阶段性的产生不同的镜像，不会覆盖以前的。 然后新镜像需要在dev／uat 环境下测试。过关后，才可以用于生产环境。 镜像制作完后，里面的内容不会改变了。
Q：编排的时候有没有把类似监控nagios sensu 之类agent的考虑在内？
A：Terraform里有部分支持的。比如某个security group 的inbound 规则有改变，运行 terraform plan 是可以看到有资源被修改。 如果运行实施的话，会修复的。
Q：按照您的回复，不同时间创建的镜像还是存在某些包版本不一致，您有针对性的测试方法推荐吗，还是在uat环境应用没问题就直接上生产使用了？
A：这个属于应用层的配置，归自动化配置管理工具，比如puppet／ansible 来管理。
Q： Terraform在AWS使用play apply等创建实例时候，只支持单个AMI镜像么？如果想要同时配置多个不同镜像的实例，该怎么办？
A：我们暂时是这样使用的。dev/uat 环境下运行正常就推到生产环境。 如果出了问题，也可以快速回滚。公司允许我们承担这个风险的。
Q：你们有没有类似cmdb将所有的资源包括虚拟机的信息放在一个统一的数据库里。 另外，你们有用服务发现吗？用的什么软件做服务发现? 怎么做的集成？
A：不是的，可以创建任意多个。在创建不同的ec2实例时，指定不同的源镜像即可。
Q：用模版文件管理是如何进行版本控制（version control）的？
A：Terraform 的模版文件做的就是做这个事情啊。 针对第二个问题，服务发现属于应用层的。 当然你可以在定制terraform 实例资源里的userdata时，加一条 服务发现的命令即可，这样该实例启动后，发现服务自然就注册了这个新的实例了。
Q：这个自动化部署的工具，嘉宾有实践过通过PaaS调用，并且部署成功吗？
A：就是用Git 。 将Template 文件存到Git 里， 可以是内部的Git服务器，比如我们公司用的atlassian stash， 也可以用GitHub之类的 。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
A：没有。 AWS属于IaaS。
以上内容根据2016年1月26日晚微信群分享内容整理。分享人王云祥，DevOps工程师，现任职于澳洲电信，专注IT自动化解决方案，持有Puppet和AWS认证。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题可以给我们留言。
有疑问加站长微信联系（非本文作者）
