【DevOps】DevOps 实践之路（一）：谈谈 DevOps、云原生、Docker、K8s

前言

---

最近决定写一个系列文章，名称就叫 DevOps 实践之路，一直想做 目前业务的 自动化运维工作，但是由于涉及到的知识点比较繁杂，理论倒是学习了一大堆，迟迟没有实质性的实践，于是决定写一个系列文章，一方面是想边思考边实践边记录，如何把 K8s、云原生 这些特别火的 DevOps 技术名词 和 我们的业务相结合，切实 解决我们项目 已存在的 或 可能存在的问题，把 DevOps 的体系逐渐渗透到项目里；

再说一下我对 DevOps 这个系列文章的思路构想吧，由于这个系列的名称 是 DevOps 实践之路 ，再加上我之前已经写过很多 DevOps 理论性的东西了，所以这个系列文章 尽可能少的展开去讲技术的应用， 主要去讲 : DevOps 思想 +方案分析 + 实践记录 ；

整个系列也会 围绕 DevOps 、 云原生 、 云计算 、 Docker 、 K8s 、架构搭建、项目部署与迁移 、项目监控管理 等展开。

谈谈我的项目发展史 与 项目中的DevOps

---

项目发展史

我目前工作3年零2个月，算上实习经历 已经工作有5年时间。在刚成为 coder 的时候，我的精力放在对语言的学习上，先java 后 python，后来慢慢接触开源软件，学习开源软件的使用，因为在初期只做一些类似管理系统的项目上，一般的语言技巧 加上 开源软件的使用，足以应付各种业务场景；

2018年初，我接触了数据监测分析业务，从此踏入了大数据领域，刚开始的业务量与数据量都很小，我们的业务流程是：

监测任务（mysql） => 数据抓取（Scrapy） => 数据入库（mysql）
=> 数据分析 => 数据入库（mysql） => 数据展示与分析报告导出（Java Web）

由于初期业务小数据量少，我们只需要一台服务器，装一个mysql 就可以满足 抓取数据 与 分析数据的 入库；

随着业务的顺利进行，业务逐渐在成长，主要发生了以下变化：

• 业务复杂性：各种监测业务的需求逐渐精细，对不同业务要有不同的监测方案；
• 业务量猛增：每日的监控量成倍增加；

对于业务复杂性，我们开发了 业务调度系统 来应对不同的业务需求；

购买服务器：而随着业务量猛增，我们不得不购买更多的服务器，从而将数据抓取与数据分析节点 分散到更多服务器，来应对大量的业务需求；

引入消息队列：然而，抓取数据量也跟着剧增后，mysql 撑不住了，于是我们 引入了 分布式消息系统 kafka，去做抓取数据的缓存，数据抓取入库的问题算是解决了；

引入内存数据库：为了减轻 mysql 的压力，把中间数据 （不用最终落地的数据） 尽量保存在 Redis 内存数据库里；

引入分库分表：业务需求增加 需要 多部署数据抓取节点 ，抓取量增加 分析结果也增加，随着分析结果的日增量逐渐上涨，mysql 的数据越来越多，导致表的性能逐渐降低，于是引入了 mycat 针对业务做了分库分表策略；（后来也设想过能否舍弃 mycat，做完善的归档策略）

所以目前的业务架构大致为：

监测任务（mysql） => 任务调度 => 数据抓取（Scrapy） => 数据入消息队列（kafka）
=> 数据分析 => 数据入库（mysql + mycat） => 数据展示与分析报告导出（Java Web）

目前项目中的 DevOps

以上讲的是 目前的业务架构情况，也是我将要进行的 DevOps 实践之路的 应用背景。

现在我先介绍一下我们目前用到 DevOps 的部分：

1、Tmux 与 Tmuxp：我把我的业务都放在了 服务器上，并通过 Tmux 开了多个会话去跑，通过会话名称管理、记录、查看对应的业务；Tmux 实现了 业务可以持续在后台运行，且可以看到控制台输出信息；后来 为了防止机器意外关机，忘记部署过哪些业务，我又使用了 Tmuxp，Tmuxp 说白了 就是将 Tmux 运行业务的 过程 脚本化，把每个业务的部署过程 记录在 yaml 文件里，并通过 tmuxp 命令 一键运行，自动创建 tmux 会话 并 启动我们的业务，方便启动、迁移、业务记录；

2、Scrapyd：数据采集部分，我们主要使用了 Scrapyd，我之所以把这个当作 DevOps ，是因为 我们的爬虫部署流程是将本地写好的爬虫上传到一台服务器，然后通过 Scrapyd 部署到多台服务器中去，这也是一种部署方式；

3、Paramiko：早期部署代码很傻瓜，代开xshell 和 xftp，然后把代码拖上去，再运行，后来发现了 paramiko ，一个 python 模块，可以通过代码 远程连接服务器，完成远程执行命令，上传文件等操作，为部署代码节省了不少力气；

4、Git + Gitee + Webhook：之前一直担心代码管理、代码保存 与 不同地方 代码统一的问题，经常把代码拖来拖去，上班把代码从服务器拖到本地，下班又把代码上传到服务器，回家加班再从服务器拖到家里的电脑上，说白了就是手动代码同步，非常麻烦；后来找到一套 代码管理 、代码 保存、代码同步的方案 ，就是 Git + Gitee + Webhook：

• 在公司本地机器改完代码，直接执行 git push 的 python 脚本（GitPython），就可以推到 Gitee；

• 在Gitee 配置了 webhook，并在服务器部署了 flask 接口，所有 push 到 gitee 的代码 都会 推送消息到服务器，服务器自动执行 git pull 脚本 同步代码；

• 家里的机器手动执行 git pull 脚本，就可以同步 gitee 上的 代码了；

聊聊 DevOps，Let‘s All in Codes，All in One！

---

DevOps 的精髓就是 运维即代码（All in Codes，All in One）

即 文档（用户故事、用户场景、功能特性等）、配置（应用配置、环境配置、脚本等）、环境（基础设施、中间件环境等）、发布包（二方库、三方库、部署包）需要统一看待成代码，纳入版本管理，同时建立5者间的关系，提供全视角的链路追踪。

我认识的DevOps

DevOps ： Development + Operations，字面上就是 开发 和 运维的 结合，用来加速 产品 启动 到上线，并使流程自动化；

基础设施即代码：这个词的 英文是 Iac（InfrastructureAsCode），我所理解的 DevOps 是真正的把开发 和 运维 完全 融为一体，运维的过程也可以通过 开发，也就是写代码的方式进行，而 lac 的含义正是 运行环境的创建、维护等运维的操作 用代码描述出来；

Operation as Code：所以有说 DevOps 的精髓就是 运维即代码（Operation as Code）；

All in Codes，All in One：我心中理想的 DevOps 效果就是 All in Codes；我们在开发时要考虑和准备的因素有很多，比如代码、代码涉及到的 数据库、分布式消息队列等的搭建，代码需要的网络环境、机器环境、系统环境的配置，如果我们可以把这些所有东西都通过代码的形式放到一起，也就是说，代码既可以完成应用的开发，也能完成 运行环境的配置与搭建，同时还能保证应用运行的平稳，即 所有这一切都在代码里，无需关心部署在哪里，随时随地迁移到任何环境；

打通应用全生命周期（需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等）的自动化流程；

DevOps的范围

1、基础设施：应用的运行环境的创建与维护；
2、持续部署：使修改与部署、运行 完成自动化；
3、服务健壮性：故障自动重启、发现问题自动迁移等；
4、监测预警：程序与运行环境的监测和预警；

DevOps的相关软件

代码管理（SCM）：Gitee、GitHub、GitLab、BitBucket、SubVersion

构建工具：Ant、Gradle、maven

自动部署：Capistrano、CodeDeploy

持续集成（CI）：Jenkins、GitLab CI、Bamboo、Hudson

配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

容器：Docker、LXC、第三方厂商如AWS

容器平台： Rancher

镜像仓库：VMware Harbor

编排：Kubernetes、Core、Apache Mesos、DC/OS

服务注册与发现：Zookeeper、etcd、Consul

脚本语言：python、ruby、shell

日志管理：ELK、Logentries

系统监控：prometheus、Datadog、Graphite、Icinga、Nagios

性能监控：AppDynamics、New Relic、Splunk

压力测试：JMeter、Blaze Meter、loader.io

预警：PagerDuty、pingdom、厂商自带如AWS SNS

HTTP加速器：Varnish

消息总线：ActiveMQ、SQS

应用服务器：Tomcat、JBoss

Web服务器：Apache、Nginx、IIS

数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库

项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

云原生

---

参考：https://zhuanlan.zhihu.com/p/97295179

定义：

云原生的英文名是 CloudNative ，云原生计算基金会（CNCF）给出的定义是 ：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”

从这个定义我们可以做以下拆分：

云原生的基石：K8s；

云原生的代表技术：容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）；

表层含义：

“Cloud Native” 就是一开始开发的时候就是为了最终部署到云环境上的，因此，在开发阶段，与我们部署服务器的思路便应该有所区别；

1、服务调用：K8s 的 IP 是动态的，因此调用服务只能通过服务名；

2、数据的持久存储：容器出现问题会自动销毁 与 重生 ，容器内部的数据也会随之消失，因此持久存储的地方应该和容器分离；

云技术的三大基石:

---

基础设施即代码 (Infrastructure As Code）

用编写代码的方式 创建应用需要的 基础设施，包括服务器、网络环境等，并对这些代码进行版本管理；最大的优势就是可重复性，即通过代码记录 创建环境的过程，方便再次使用部署；

之前都是通过博客去做这些记录，其实博客很难和项目打包到一起，很难去对应哪些项目用了哪些部署过程；从我理解的云原生的概念来看，本质是 DevOps，而 DevOps 的终极目标就是让应用的一切都打包成一个整体，不止是应用代码，还包括环境部署过程，运行方法等；就是我之前说的 All in codes，All in one，让我把打包的这一切 拿到一个新的环境时，可以很方便的完成 从部署到运行的整个流程，而且是自动化的进行这些步骤；此外，还非常方便交接项目~！

关键词：Dev 代码、Ops 代码、可复用、自动化；

不可变基础设施（immutable infrastructure）

有了 基础设施即代码 的概念，就可以 随时通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。因此当服务器出现问题时，不需要花时间修复，而是直接销毁服务器，再创建一个新的；所以说，基础设施 只有 创建 和 删除，而不可改变；

关键词：复现应用、秒级；

声明式API（declarative APIs）

只需要通过编写代码，来描述应用希望的最终状态，比如我在文件中描述了一种状态 “三个节点的 kafka 集群”，这样系统就能自动创建这样的状态，并定期检测差异，如果与描述不符时也可自动修复，保证容错性；

关键词：声明状态、容错性；

Docker 与 K8s

---

图片来自 https://www.kubernetes.org.cn/8351.html

K8s 相关的 DevOps 生态的基础功能：

源码到容器镜像仓库，Kubernetes 是容器平台事实标准：Github / DockerHub；

CI/CD 流水线、任务编排、发布策略：Argo / Teckton / Spinnaker / Jenkins-X / Flagger；

镜像打包、分发：Helm / CNAB；

丰富的应用运行负载支撑：Deployment(无状态) / StatefulSet(有状态) / OpenKruise(原生有状态增强)；

丰富的弹性和应用扩缩容能力：HPA / KEDA。

K8s YAML 配置文件 的组成

• 运维：实例数，策略和发布；
• 研发：镜像、端口号等；
• 基础设施：调度策略；

K8s 应用的5个配置

配置 Deployment ，一般需要填写5个信息即可；

镜像、启动参数、环境变量、端口、挂载卷；

我的实践之路

---

对于现有的 DevOps 与 K8s 的实践方案，我已经阅读了一些相关的实践案例，但是还没有亲自实践过任何一种，也尚不清楚对于我们的业务来说，哪种方案更适合，更能做出最大方面的优化；

目前我打算选择一种比较通用的方案：

** Ansible + Gitlab + Jenkins Pipeline + Docker+k8s + Helm 自动化部署**

启动 Gitlab 可以替换成 GitHub 或者 我现在正在用的 Gitee；

所以我会从 ansible 的使用讲起，然后用ansible 批量安装 docker 与 K8s ，并进行更多方案的探索，敬请期待！

参考：

https://www.zhihu.com/people/jfeng45/

https://www.zhihu.com/people/si-nei-er-91

https://www.kubernetes.org.cn/tags/kubernetes1-18