前言：
最近学到了用Docker、AWS(CloudFormation)、Bitbucket、Buildkite、Packer来创建EC2实例来跑代码的一套流程，在这里主要对Packer进行介绍，之后有机会再补上CloudFormation的内容。
文章内容如下
1.什么是CloudFormation？
2.什么是AMI？
3.什么是Packer？
4.了解了以上的一些信息之后，我们来看一下从代码提交开始是怎么一步步执行的。
5.为什么是Packer？别的技术不行吗？
6.我该怎么快速了解这个Packer并投入使用？
在介绍Packer之前，我们先来介绍一下前置知识。
1.什么是CloudFormation？
A CloudFormation template describes your desired resources and their dependencies so you can launch and configure them together as a stack. You can use a template to create, update, and delete an entire stack as a single unit, as often as you need to, instead of managing resources individually.
上文是摘自AWS官网的描述，CloudFormation stack 可以理解成要创建的AWS服务和一些参数的集合
2.什么是AMI？
AMI 全称是 Amazon Machine Image，AWS 官方提供了很多现成的 AMI, 就跟 Docker Registry 提供了很多 Base Image 一样, 为了一些定制的需求，就是启动 EC2 节点时指定的操作系统的镜像。截屏2020-11-29 上午1.46.15
3.什么是Packer？
自动化打包镜像的轻量级开源工具，可凭借单一配置文件，高效并行的为多云平台创建一致性的镜像
同样上文可能仍然会有一些疑惑，在这里我介绍一下我所了解到的AWS和Packer的整合方式：
1.Packer会从AWS提供的AMI中选择一个来deploy，使其成为一个EC2实例(这里以EC2来举例，它还可以包括其他实例的AMI，下同)
2.使用所有自定义配置来配置这个EC2实例，然后从这个EC2实例中创建一个AMI
3.一旦创建好了一个AMI，那么一开始部署的这个EC2就会被销毁。
一开始我并不是很能区分Packer和CloudFormation之间的区别，事实上，Packer专注于对EC2的配置，而CloudFormation则更高一级，他里面不仅有EC2、还包含着S3、LoadBalance、SNS、环境变量等一些配置。
4.了解了以上的一些信息之后，我们来看一下从代码提交开始是怎么一步步执行的。
以下是对上图的简单文字介绍：
1.首先本地push代码到Bitbucket之后，由于Pipeline的配置会触发Pileline的build流程，Fetch在Bitbucket中新的代码
2.在我们的Pipeline的配置文件中，第一步我们执行一些对Template的验证、跑一下测试方法(在图中并没有画出)
3.Create AMI
3.1验证Packer 和CloudFormation的Template没有问题后，就Packer出场，通过Packer Template，在AWS商店中找到相应的 AMI
3.2 将这个AMI部署成EC2后，在此EC2上根据Template配置SSH、添加一些文件(比如传一些脚本上去)，你可以在官网上找到这 配置的意义https://www.packer.io/docs/builders/amazon-ebs.html
3.3 将这个EC2变成我们自定义的AMI，会在下面的CloudFormation中用到4.Deploy(这里本来还应该有部署到测试环境，此处省略了)
4.1 通过CloudFormation配置的AWS服务之间的关系、参数来创建我们的AWS堆栈(这里举个例子：比如一个博客网站，他可能需要一个S3、ALB(一种LoadBalance)、EC2（当然这里还要配置一下，使用我们刚才Packer创建的AMI来部署这个EC2）、SNS)
读到此相信你对Packer和CloudFormation已经有简单的了解了，那么我们再来回头看这个Packer。
5.为什么是Packer？别的技术不行吗？
在回答此问题前，我们先来看看传统的可变基础架构:
在传统的可变服务器基础架构中，服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。
这样会造成一个问题: 配置漂移，即当构建好的服务被部署在服务器上后，由于有人登陆该服务器并修改了一个东西，导致该服务的配置被更改，从而使机器上的实际配置与源代码管理的配置不一致
不可变基础架构:
一个不变的基础设施是另一个基础设施范例，他们部署了服务器之后决不会被修改。如果需要以任何方式更新，修复或修改某些内容，则会根据具有相应更改的公共映像构建新服务器以替换旧服务器。经过验证后，它们就会投入使用，而旧的则会退役。
不可变基础架构的好处包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。
Packer正是一个不可变基础架构的解决方案(当然还需要借助其他工具一起完成不可变服务器的搭建)。
他可以将Develop->Deploy->Configure的步骤变成Develop->Configure->Deploy
6.我该怎么快速了解这个Packer并投入使用？
1.首先推荐一个我在学习过程中看的介绍视频：https://www.youtube.com/channel/UC2sYgV-NV6S5_-pqLGChoNQ
可以在下面的频道上看到Packer的介绍和简单入门使用。
2.Packer官网：https://www.packer.io/docs/builders/amazon/ebs
这个链接导向的是Packer与AWS整合部分。
