前言：
这是一篇总结文章，总结最近 几个月学习关于 Cloud DevOps 的基本体系和经验。几个月前，想尝试一些自己没接触过的领域，是的，就是这么爱学习。在众多的热点领域里，云计算一眼就被我选中了，于是报了网课 Cloud DevOps。报课的时候我反正只看懂了 Cloud，至于 DevOps 嘛， 不重要啦，内容很多内容也是我感兴趣的，什么云计算的基础啦，亚马逊云的相关操作啦，通过代码来部署整个云端架构啊，持续集成和持续部署啦，虽然还有一些看不懂的学习点，不过我想学习的点都有了，其他的当作额外学习嘛，于是，就是这么自然的，开始了学习，几个月下来，收获颇多，所以分享下，也是自己的一个记录。通过这篇文章，
你能知道：
你什么时候需要 Cloud 的 DevOps；
每一个步骤有什么工具链来完成工作；
每个工具如何完成基本工作以及他们之间如何建立联系。
如果有错或者补充，请留言指明。以下是正文。
首先，你这样来理解 DevOps：就是一整套的工具链和一整套的体系方法把这套工具链串起来让开发工作和运行维护工作变得更加轻松，至于 Cloud 只是这一整套工具链里面的一个工具体系。
DevOps 的整个工具链体系是很巨大也很复杂甚至做好是需要一笔不小预算的，所以什么时候你需要一套完成的 DevOps 呢？应该说一个很大大大并且项目会一直持续很久需要不断维护更新的，比如你和一群人开始创业开发了一个软件进行商业化了，这时候你们需要一套这样的体系，以简化你们的工作流程。而当你就是做一些研究型工作，写一些代码，几个星期几个月之后你就再也不会理它了，那就没必要了。
下面来总结下一个基本的 Cloud DevOps 工具链体系如何建立。
某一天，你和你的小伙伴们突然灵光满面，想到一个超级好的点子，优秀的你们要把这个点子做成一个商业软件，部署在云端服务器，然后你们要靠它挣钱发财，所以呢，你们就开始构思一个工作流程或者体系，来简化你们的工作，当然你们可以不把这个称为 DevOps，尽管就是在做这个事。
作为纯软件工程师，你们自然而然的开始围绕软件本身开始做计划，由于对云端部署没什么经验，你们决定现在本地开发编译看看效果，你们设计好了软件架构图，定义好了你们的工作语言，比如 C++, Python, Java 等，由于经常在一起合作，你们也很轻松的定义好了你们使用的各种代码规范，代码提交规范，分工也很明确。在这里来说，就是最基本也是最日常的软件开发内容了，这里面涉及的主要的工具无非就是
写代码的 IDE：VS Code, Vim, Atom ...
版本管理工具: Git(GitHub, GitLab, BitBucket...)
编译工具: Make, CMake...
终端工具：Bash, PowerShell, CMD...
说到这里，估计鄙视链又要出来了... 打了几架之后，你们确定好了能想到的一切开发环境和开发工具。于是你们开始废寝忘食的工作，定架构写代码，憧憬软件卖钱后年薪千万的美好日子。
突然有一天，你们意识到，你们软件里很多模块在你们 debug 之后修改一些内容，需要你们手动去做重复性的事来进行模块集成，集成完又测试，出了问题又 debug，又集成... 如此反复你们终于决定思考下有没有什么办法让这个流程简化下，经过严密分析，发现集成这个步骤虽然需要完成很多动作，比如先调用某个依赖库，然后运行某个软件，动作多的恐怖，但是这些步骤都是能够流程化的。然后你们看到了持续集成这个专业名词，并且直到了这个领域最有名的工具之一：
这个工具通过一系列的插件，能够根据你定义好的触发规则来启动一系列的工具软件，比如在晚上 12 点这样一个大家都睡着的时间自动打开你电脑里的 matlab 软件，又或者每次你 commit 新内容到了 github ，帮你自动执行一系列的软件操作来自动化集成，这样的好处是，比如你们每天工作到晚上 8 点，你只需要提交代码到 github repository，然后 jenkins 就会帮你执行那个需要一两个小时的集成工作，在成功集成之后，根据你的设定，自动调用你的自动化测试脚本进行测试，整个过程一旦成功结束或者出现问题，会以邮件的形式发送给事先设定好的收件人邮箱，这样一觉醒来，你就知道结果了，还挺爽的呢。
关于 Jenkins 的使用，网上的资料越来越多，找本书系统的看一下，很多工具都有两种方式来工作，使用 GUI 一步步进行操作 和 使用一套定义好的语法规则编写 Pipeline 来操作，显然前者简单明了，对于大部分人来说，懂得如何通过 GUI 操作就完全足够了，但是对于 DevOps 来说，却往往偏向于后者，就是能用代码来运行的操作就不用鼠标了，因为我们要实现整套工具链的自动化，就是为了少动手，这应该算是一个做 DevOps 的工程师的基本素养。所以对于 Jenkins 来说，自动化 Pipeline 的实现是必不可少的，jenkins 里有很多好玩实用插件，2.0 版本的高亮插件 Blue Ocean 是一个全新的 Pipeline 实现方案，它使得 jenkins 跟 GitHub, GitLab, Bitbucket 等代码库的交互变得异常简单。
Jenkinsfile 的编写是你实现脚本 Pipeline 必不可少的。
又解决了一个大问题。
过了几个月，你们终于在本地完成了第一版软件。某天下午，你们邀请了几个朋友进行内测，让他们在本地安装你们的软件，然后运行看看效果。激动人心的时候马上要到了，你们准备好了香槟，等他们成功使用后，不论出现一些什么小 Bug，你们都要庆祝。那个下午，香槟没开，你们一直在做一件事，就是给内测的朋友配置各种依赖库环境...
晚上，等内侧朋友们走了，你们把香槟开了，说要借酒消愁，你们都陷入了沉思，有没有什么办法让不同的依赖库能够得到有效管理，操作变得可控呢？
天才如你们，立马找到了相关解决方案：容器化管理。自然，作为最火的容器化工具，
立马就被你们看重并采纳了，熟悉相关的操作后，你们决定将大部分的依赖库都容器化，由于容器太多，需要得到有效管理，你们必须选用一个有效的工具对容器进行管理和编排，
作为最火的容器化编排工具也被你们采用。在熟练掌握 docker image/container, kubeadm, kubectl, kubelet 等一系列操作之后，一顿操作下来，你们重构了你们的代码，重新召集朋友成功进行了内测，你们忘记买香槟，因为那晚你们开了香槟喝了一口就去找解决方案，还剩很多，你们这天把剩下的喝完了，嗯，酸的，但你们高兴的像群小孩子...
关于容器化这里，infrastructure as code（写代码来部署环境） 这块，你需要掌握以下：
YAML 格式文档：YAML 格式文档已经成为架构部署这方面的主流，你会发现在云架构部署也是使用它；
.sh 如果你是用 bash, .ps1 如果你是用 Powershell, .bat 如果你使用 CMD
Dockerfile: 构建容器 Pipeline
终于到了要上线的一步 -- 将应用部署到云端。云的选择很多，从众多选择中，你们选中了大名鼎鼎的 AWS，有些东西你也说不上来哪里好，但就是替代不了... 好吧，其实就是因为你们没经验，随便选了一个。
你们马上就掌握了大部分的云端基本操作，比如你们知道了：
IAM：AWS 的权限管理工具，不同的开发者有不同的职责，作为管理员，你得给不同的工程师建立不同的 IAM 权限，比如开发代码模块的就只能查看代码仓库，前端开发就只能查看他们的设计文件；
EC2 Instance: 相当于一台在云端的电脑，根据需要选择型号，开启基本上就收费；
S3 bucket: 存储文件
CloudFormation: AWS 的管理语言，infrastructure as code 的 AWS 实现方案；
Gateway: 建立外部网络和你的云端服务器的联系；
FireWall: 防火墙设置；
NAT: 内部 IP 与可联网使用 IP 真实 IP 对应关系；
...
AWS 部署操作的基本流程推荐：
计划好你的云端部署方案，这里推荐一个工具： LucidChart ，包含基本 AWS 所有组件的图标；
根据你设计好的部署方案编写部署用的 YAML 文件，一般包括 network.yaml 和 service.yaml 两个文件创建，不推荐从头开始手写所有内容，应该使用模板根据自己的需要修改内容；
连接好你写代码用的本机电脑和 AWS 云端；
部署云端架构。
以上几步确实需要一些学习积累，好在 AWS 提供了详细的文档帮助你学习
到这里，云端架构就基本布置好了。
现在你们捋了捋思路，本地容器化的应用已经实现了，你们得通过你们的本地写代码的电脑通过 SSH 进入云端主机(EC2 instance)，在云端主机里部署 kubernetes 集群，jenkins 服务器，把之前的 jenkins 操作流程部署到云端，在 jenkins 里面给 AWS 设定好 credential， 然后根据需要进行你的相关部署， 由于不同应用需求不同，接下来的步骤就根据自己实际需要进行。又是一系列的操作。
几个月后，你们的产品正式销售运营。你们这一次准备了很多香槟~
