【编者的话】本演讲主要针对亚马逊公司的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}}"    }]    } 

这里例子里，第一个部分“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）、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>"     

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

可以看到，一个新的资源创建了。这里是一台新的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时怎么用之前构建好的镜像？

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，进群参与，您有想听的话题可以给我们留言。