《DevOPS》-项目初始化

1. DevOPS 三大方法论：IaC、CaaS、人类不可靠论

2. 线上灾难现场两大定律：墨菲定律、奥卡姆剃刀定律

Part.1 本章目标

初始化一个项目，作为本书的实战代码仓库。

本章将以阿里云和Ucloud做为公有云演示平台进行演示，进行必要的初始化工作。

难度系数：

风险提示与免责声明

由于本书是从零开始搭建，而运维工作本身是严谨 & 容易造成损失的。为了简化教学难度，有些章节牺牲了安全性降低了操作难度。所以：

请读者不要在生产环境中操作演示代码！请读者不要在生产环境中操作演示代码！请读者不要在生产环境中操作演示代码！

重要的事情说三遍，由于使用本书demo产生的任何线上漏洞和损失，本人不承担任何责任。

如果不同意，请放弃阅读。继续阅读本书将表示读者已经同意作者的风险提示，产生的任何风险由读者自理。

Part.2 前置依赖

无

Part.3 依赖知识储备

编程基本知识

Part.4 本章收获

理论部分

理解云计算运维工作的本质

理解Terraform的工作原理

实战部分

获取并配置云平台API-Key，可以进行后续的实验

初始化一个devops项目，用于本书后续的代码实现及版本跟踪

Part.5-1 理解云平台

回溯历史

想象一下你正在使用的个人电脑，一台个人电脑中，装载了很多个App。比如你正在使用的浏览器，他们要想如期运行，需要用到 「CPU」、「内存」、「磁盘」 这些基础资源。

而你访问的网页，通常都是从其他服务器获取的，你还需要依赖网络资源。每一个完整的请求其实由很多个数据包组成，都需要从自身的「网卡」经过局域网的「交换机」再通过「路由器」，发送到外网。

其实这也是最早期服务器端应用运行的方式，和个人使用的应用程序没有任何区别。都是直接运行在物理机上的，只是地位位置在机房，运行时间7 * 24 * 365不间断运行。而且这些物理机价格都不菲，至少比我们日常办公的电脑贵多了。

由于早期服务器资源价格昂贵，大部分应用又很难完全用尽独立物理机的资源， 渐渐的出现了虚拟化技术。将一台性能良好的服务器，虚拟出多台「计算机」，然后分给App来使用， 每一个App就像是使用一台独立的计算机一样。对于开发者和用户而言，是无感知的。

再后来，随着虚拟化的不断进化， 从原来的全虚拟化技术如「VMvare workstation」，到半虚拟化技术 「XEN」以及内核级虚拟化 「KVM」。再往后出现了基于namespace思路方式实现的「LXC」隔离技术，这也是时下火到没朋友的「Docker」容器化技术实现的原理。

而云计算就是伴随着虚拟化出现的，想象一下这样的场景：

一家公司，需要大约200台2核4G的机器，满足业务使用。如果没有虚拟化技术，我们只能傻呵呵的买200台2核4G的机器，如果硬件故障率是10%， 那么200台机器，有20台就可能出问题需要人工维护。

如果是采用虚拟化技术，我们可以采购12台32核64G的机器，这样只需要配置这12台机器即可。相同的硬件故障率，我们只会出错2台，大大降低了维护成本。

同时，如果我们能有一个软件能管理所有物理资源，在一个统一的「管理平台」中操作， 创建或者销毁一台虚拟的「计算机」，这样不就很省事了吗？

其实，在没有云计算这个概念之前，VMware 已经实现了。当年的 vSphere 拯救了不知道多少位IT人士的发际线。

看到这想必你也略有体会了，云计算运维工作，本身并没有什么神秘可言，本质上就是如何用软件来更好的分配物理计算资源的技术， 并不是无中生有的黑科技，是运维技术不断进化的产物，而且我认为是必然结果， 因为（大多数情况）维护一个大的数据中心，最后分摊的成本，要远比维护一个小的数据中心便宜的多。

虚拟化是一颗种子，从此打开了IT基础设施运维方式的脑洞，成就了今天的云时代。

Part.5-2 理解IaC

回溯历史，我们知道了云计算是如何顺应技术潮流产生的。

那么在今天这个云时代，扛机器的事情云厂商帮我们做了，网络配置云厂商也帮我们做了，很多和硬件直接打交道的事情云厂商都帮我们做了。

那么运维人员的未来在哪里？

答案是：要么进化，要么淘汰。

大自然的进化论，在人类世界的科技生态，依然有效，真相就是如此残酷又美丽。而现在进化的形态，就是 DevOPS。原来大量的运维工作都已经外包给云厂商了，我们可以更多专注于业务场景。

• 李小萌的故事 •

在这里我们根据真实事件改编，讲一个「李小萌」的故事，通过发生在李小萌身上的事，理解什么是「IaC」

李小萌同学在一家公司负责运维工作，

现在公司服务器资源紧张，最后经过层层流程各方撕逼，领导审批通过同意追加资源，共开通：

- 2台8核16G，普通磁盘200G的机器，每台机器网络使用按流量计费。

- 2台16核32G，SSD磁盘 300G的机器，每台机器网络使用按带宽计费。

因为使用了云计算平台，他的工作内容是，在云管理平台里，创建这些机器资源。

其实本质上，只是填写表单，确认表单没有问题，然后开通。

整件事情，其实大家不难发现，李小萌的工作量最大的地方，并不是怎么创建机器，

而是核对这些机器资源（表单）是否正确。比如：

- CPU 是不是8核

- 内存 是不是16G

- 网络带宽是多大的

- 操作系统是否与整个生产环境统一

这么枯燥的工作，李小萌觉得简直是在侮辱智商，浪费自己的青葱年华。虽然公司给发工资，但是拿钱卖青春的事，这和卖那啥有什么本质区别？

于是李小萌一万个不开心最后痛定思痛，觉得这个事，工资能不能我拿，但这活，我不干了！可是作为本职工作，他又不能把锅甩给别人，所以他只能去欺负机器，让机器帮他卖命。钱他赚着，活机器来干。

现在作案动机有了，就差怎么把事情干成了。这个时候李小萌就把目标锁定到了云厂商的API。

如果我通过封装接口的方式，去操纵机器，那这样不就解决了吗？

在查阅了一番云厂商手册之后， 他通过撰写sh脚本的方式：

完成了机器的初始化。

可是没多久，公司业务蒸蒸日上，机器资源又不够了。

这次领导们很高兴，大手笔的上次的型号每样要采购20台，但是多了额外的需求。

8核16G 10台普通300G硬盘，10台SSD 500G硬盘。

16核32G 5台300G硬盘，12台500G硬盘，3台1T硬盘。

这个时候，李小萌同学又不开心了，我堂堂年少有为青年，终日沉迷代码，怎么能做这么枯燥没前途的事情？

不行，这个事能不能钱我拿着，这活我不干了。

于是他想了想，我能不能去构造一个配置文件，然后写一个程序去读取配置文件呢？

类似这样的想法：

然后通过写一个程序，遍历配置，去请求云厂商接口，那么不就结束了吗？

其实李小萌同学，这个时候，不知不觉就已经走在了`IaC`的路上。

IaC 全称：

[Infrastructure as Code（基础设施即代码）](https://en.wikipedia.org/wiki/Infrastructure_as_code)

这个理论主张很简单，字面就能理解，将基础设施通过代码的方式来管理表达，这样做的好处有很多，最直观的就是：

易维护

可审计

可协作

Part.5-3 理解 Terraform

我们继续讲李小萌的故事，李小萌在的公司，由于之前公司管理层经营不善，资金紧张，同时受行情影响，用户数急速下滑。

最后领导们又双叒叕经过激烈的撕逼，决定要把服务器砍掉50台，另外还有20台，原来的16核32G降配到8核16G。

除去数据迁移的事情我们不在这里讨论，只说删机器、改配置的事情，这些工作又是鼠标点点，核对数据的工作，没有操作难度。

这个时候，李小萌同学又双叒叕不开心了，我堂堂年少有为青年，终日沉迷代码，怎么能做这么枯燥没前途的事情？

不行，这个事能不能钱我拿着，这活我不干了。

可是这次事情就棘手了，加机器很容易，要删除机器，我们就必须要知道，删除「哪」一台。

同样，给机器变更配置也是如此，我们也必须要知道，修改的是「哪」一台。

显然要满足这个需求，李小萌的程序还需要能支持把创建时机器的状态信息存储的能力。

故事讲到这，也可以告一段落了，因为李小萌去写他的程序了

其实，这些能通过封装云API接口操纵云厂商的程序，

Terraform 就是其中一种实现，也是目前最流行的开源实现我觉得没有之一。

使用Terraform你也可以像李小萌一样，不需要操作云平台就能操纵云平台资源。

总结

虚拟化是云计算出现的起点

云计算是运维技术栈进化的必然产物

IaC是实现运维产品的重要方法论

Terraform是一种与云厂商资源交互的客户端工具

Part.6 实战

经过理论讲解后，下面将带领读者学习如何初始化一个Terraform项目，为后续的开发工作做准备。

• Ucloud •

云平台界面操作

1.登录Ucloud控制台

2.点击右上角头像，选择 API密钥，如图所示：

3. 根据界面提示，完成API密钥的创建

本地配置

1. 编辑~/.bash_profile添加在云平台创建好的API-Key，用于Terraform等工具的身份认证。

2. 添加API-KEY环境变量

3. 生效配置

小技巧: 也可以通过开启新的Termial来生效新的环境变量。

4.验证配置已添加

• 阿里云 •

云平台界面操作

1.登录阿里云控制台

2.点击右上角头像，选择accesskeys，如图所示：

3.此时会出现安全警告，选择继续使用Access Key

注意事项：后续随着项目发展对安全要求等级的提高，建议使用子账户来管理各项权限， 本书为了便于学习，如无特殊声明，均使用超级管理员密钥。

4.点击创建Access Key，系统会自动帮你生成一个新的 key。

注意事项：要特别留意系统提示，此时不要关闭页面，点击保存将 key 下载至本地。出于安全考虑，现在各大公有云厂商对于 API-Key 都是只展示一次， 如果你忘记下载，只能重新创建一个新的 API-Key，或者需要使用手机等KYC信息找回。

本地配置

1.编辑~/.bash_profile添加在云平台创建好的API-Key，用于Terraform等工具的身份认证

2.添加API-KEY环境变量

3.生效配置

小技巧: 也可以通过开启新的Termial来生效新的环境变量。

4.验证配置已添加

• 初始化项目 •

执行以下代码初始化一个新的代码仓库

安全风险提示

在环境变量中保存 API-Key 虽然方便，但是存在一定的安全隐患。所以在真实世界中，我们要小心一些恶意的来源不明的脚本， 如果对方恶意搜集环境变量，并且发送到对方手中，等于交出了服务器权限。

这方面的改进措施，我们会在后续的高阶章节进行探讨和实现。

Ucloud配置

1. 新建一个目录：tf-zone/ucloud

2. 撰写 provider.tf

provider用于身份验证和初始化

3.撰写 variables.tf

撰写变量模板的用途是将逻辑与业务内容分量，

在这个实验中，我们可能这次需要在一个上海的机房创建，

下一次是在北京，如果我们能将这些业务信息变量化，可以大大提升复用程度。

4. 在tf-zone/ucloud目录（一定要在指定目录），执行terraform init

请确保你的网络环境可以正常访问 https://releases.hashicorp.com

5.在tf-zone/ucloud目录，执行terraform plan -var "api_public_key=$UCLOUD_PUB_KEY" -var "api_private_key=$UCLOUD_PRV_KEY"检查是否报错

关于完整的手册，请参考[terraform-ucloud]

阿里云配置

1. 新建一个目录：tf-zone/aliyun

2. 撰写 provider.tf

provider用于身份验证和初始化

‍

3.撰写 variables.tf

撰写变量模板的用途是将逻辑与业务内容分量，

在这个实验中，我们可能这次需要在一个上海的机房创建，

下一次是在北京，如果我们能将这些业务信息变量化，可以大大提升复用程度。

‍4. 在tf-zone/aliyun目录（一定要在指定目录），执行terraform init

请确保你的网络环境可以正常访问 https://releases.hashicorp.com

5.在tf-zone/aliyun目录，执行terraform plan检查是否报错

关于完整的手册，请参考[terraform-alicloud]

点击“阅读原文” 关注Github