《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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190827A00WX700?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券