【DevOps 实践之路】（一）关于 《DevOps 实践之路》

关于 《DevOps 实践之路》

---

从去年来，对 DevOps 及相关技术充满兴趣，于是打算写一个系列文章，分享我 DevOps 实践之路的种种经历与想法。

刚实习的时候，我的脑海中还没有 DevOps 这个概念，代码只在本地保存，用U盘备份，在本地运行的，最初的一切是稳定有序的；

但是随着业务量增大，业务种类增多，在代码的管理、部署 上出现了很多令人头疼的事情；

由于办公环境电脑与网络不稳定，一些长期运行脚本需要放在服务器上运行，由于服务器一般是无桌面的linux环境，想查看多个脚本的运行状态就比较麻烦，得挨个去检查日志；

对于需要分布式部署的代码，比如爬虫，每次修改都登录每台服务器去做 停止旧程序，更新代码，启动新程序 的操作，如果更新频繁则非常麻烦；

对于分布式部署的程序，还需要不停的在每台机器去查看是否有因为网络或者数据库连接不稳定等因素造成程序崩溃的情况，并重启之；亦或在代码里加入健全的重试机制；

每台服务器都是多人在用，非常容易出现我的程序必须使用python3.9 ，而你的程序只能用python3.5，我的二进制lib和你的存在冲突等情况，解决起来很麻烦；

每次部署程序时，还需要看看哪台机器CPU、内存、硬盘的剩余情况，再根据自己的程序占用资源情况判断部署到哪台机器；

于是，我决定写一个系列文章，《DevOps 实践之路》，记录一下我通过 学习 DevOps 一步步解决遇到的问题的过程、方法和思想、感悟；

理解 DevOps

---

起源

参考：https://www.zhihu.com/question/58702398

软件开发的流程一般是 规划、编码、构建、测试、发布、部署和维护；

当程序不很复杂时，开发者可以完成所有工作，随着开发规模和复杂度提升，一个人完成所有工作量太大，于是把部分环节交给 测试工程师、开发工程师 等 去做；

但是现在的开发，面对着多变的需求，往往需要频繁的迭代版本，更新代码，也就是敏捷开发，即快速发布版本，快速得到反馈，快速迭代；

但是在运维人员眼中，稳定是最重要的，不喜欢频繁的变更，于是 DevOps 应运而生；

倡导思想

自动化和监视

理解

几个概念：

1、DevOps 从名字上看，就是 Dev + Ops ，即 开发 + 运维，目的是 通过自动化流程来使得软件整体过程更加快捷和可靠。

2、DevOps 集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

如果安全团队加入，则可以合并称作 DevSecOps；

3、既然把 Dev和Ops拼到一起，目的也是希望 开发和运维一体化，我理解的实现方式就是，软件流程中的开发和运维一体化，都由开发者实现，都用代码实现；

我个人觉得， DevOps 不应该局限在 软件流程中，而应该扩展到一个团队的方方面面，包括但不限于：

计划、目标、文档；

开发、测试、部署；

监控、自我修复、弹性计算；

关键词

组织架构；企业文化与理念；自动化；方便快捷的迭代（开发与部署）；优化组织架构和流程

DevOps 与 微服务、容器

---

微服务：将整个项目拆分成多个 服务（模块），每个开发者负责自己模块的整个流程，包括开发、测试、部署、迭代；

容器：将一个物理机划分成多个隔离的环境，不同开发者可以在相同的资源上部署各自的模块，部署快捷迅速，无需重复安装环境，且部署环境隔离，互不影响；

DevOps 相关技术

Docker、Rancher、GitLab、GitLab CI、Harbor、Kubernetes、etcd、prometheus

Helm 和 Operators & GitOps（Argo/Flux）

云原生

---

参考：http://www.dockone.io/article/2434138

背景

当前越来越多的企业将应用部署到容器上，但是大部分容器化的应用仍然基于传统软件架构搭建后，再打包成镜像并在容器中运行，也就是说只完成了基础设施与平台的云化，想要真正云化，应用也需要做出改变，这就需要摈弃传统的方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，也就是云原生的应用。

价值所在

发挥技术部门价值的点：

1、业务创新；
2、系统稳定；
3、成本优化：在尽量少的资源的情况下，保证业务的创新和稳定，是价值的体现；
4、技术创新；

定义

1、pivotal

特性：模块化（Modularity）、可观测性（Observability）、可部署性（Deployability）、可测试性（Testability）、可处理性（Disposability）以及可替换性（Replaceability）；

要点：DevOps、持续交付、微服务以及容器化；

2、CNCF（云原生计算基金会（Cloud Native Computing Foundation）

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括

• 容器
• 服务网格
• 微服务
• 不可变基础设施
• 声明式API

云原生的四要素

微服务

容器化

DevOps

持续交付

云原生的特性

弹性伸缩性

容错性

可观测性

发布稳定性

云原生相关技术

容器：包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包，实现 build once， run anywhere；

微服务：服务之间松耦合，应用程序模块化，每个服务可独立开发、测试、验证和部署；

容器编排：Kubernetes

服务网格：用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠地请求传递；通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身；

微服务优势：每个模块较小且易维护，可独立部署、独立扩展，更容易上新技术，容错更好；

不可变基础设施：一个工作负载（比如容器、虚拟机等）一旦部署以后就不会被修改。当需要更新，修复或修改某些内容的时候，只需要将新的、经过验证的工作负载替换旧的即可；

基础设施即代码（IaC）：云环境DevOps的核心原则。基础设施代码版本化，可 Review，可测试，可追溯，可回滚，一致性、防止配置漂移，方便共享、模板化和规模化，提升了运维整体效率和质量，通过代码也可以轻松了解基础设施的全貌。

声明式API

云原生的生态

1、Kubernetes服务提供商

最底层

2、Provisioning 层

为容器准备标准化的基础环境；

• Automation & Configuration：自动化部署和配置容器运行平台和环境（Ansible、Chef、Puppet、VMware以及OpenStack），或者手动安装 docker、k8s 、Prometheus 等开源软件；

• 容器镜像库：公有的 docker官方的registry，私有的Harbor；

• Security & Compliance

• Key Management：密钥管理；

3、Runtime

容器的整个运行环境，是云原生中最核心的部分，它包括了计算、存储、网络三大块：

• Container Runtime：Docker；

• Cloud-Native Storage：持久化存储；

• Cloud-Native Network：网络虚拟化，比如Calico、Flannel、Open vSwitch等方案；

4、Orchestration Management

主要负责容器平台的编排和调度，包括服务的发现和治理，远程调用，服务代理，微服务治理等组件;

代表作：Kubernetes、Docker Swarm；

5、App Definition and Development

应用平台层，容器平台上运行的具体应用和工具，一般分为 数据库、流处理和消息队列、应用和镜像制作、CI/CD;

6、Observability and Analysis（监控分析）

Prometheus、ELK 等；

云原生的一般实现路径

1、应用容器化

2、开发 CI/CD 环境和流程(gitlab-ci、argocd)

3、应用编排（Docker swarm、Kubernetes、Helm Charts）

4、监控和分析（Prometheus、Loki/ELK等）

5、服务代理、发现和治理

6、网络（Calico、Flannel等）

7、分布式数据库和存储（可提供弹性，需要专业的容器存储支持）

8、流和消息处理（RPC、API、消息队列）

9、镜像仓库（Harbor）

实现云原生应用需要注意

1、从微服务架构开始，考虑 资源需求、内在特征、依赖关系 等特性；

2、理解一切即代码；

k8s 与 云原生

云原生主要解决的问题：

1、运行标准的问题，例如一份代码，多份部署，优雅启动和关闭，而且环境等价

2、编排标准的问题，例如依赖关系，明确端口，以服务的形式关联

3、弹性的前提，例如无状态，水平伸缩

4、集中管理的问题，例如配置中心，日志中心

k8s相关组件：

配置中心：ConfigMap 和 Secrets

服务发现：Service 和 Ingress

负载均衡：Service

API网关：Service 和 Ingress

服务治理（熔断、限流、路由）

服务安全：NetworkPolicy

日志中心：Loki/集成 ELK

监控中心：集成 Prometheus

分布式链路追踪：集成OpenTracing

健康检查：Readliness 和 Liveness

弹性伸缩、容错恢复：HPA 和 VPA

部署、运行、调度：Scheduler、Deployment、Pods、Docker

任务：Jo

业务划分

---

我把我的业务分为三种，分别是脚本程序、需要分布式部署的程序、接口服务；

脚本程序一般只需要部署在一台机器就可以，需要经常变动，重启，需要实时查看运行情况；

分布式部署的程序一般是爬虫、下载、分析等数据流应用，需要部署在多个机器上；

接口服务则是对外提供访问，根据业务情况，有的需要单机，有的需要多机；

我的路线

---

三大上云架构：应用架构、数据架构、IT架构

1、本机开发、本机运行

2、本机开发 、手动拖到服务器上运行

3、引入Tmux，本机开发，手动拖到服务器上，通过 tmux + tmuxp 快速部署

4、引入Git + Gitlab，本机开发，通过 git 上传到 Gitlab，并通过webhook 自动执行在服务器上拉取新的代码

5、引入Docker + Harbor，应用容器化，把每个应用配置成可以打包的镜像，本机开发后，上传到服务器，在服务器执行构建新镜像，上传到镜像仓库 ，并在需要部署的机器上 拉取镜像，启动容器

6、引入 Gitlab-ci，应用容器化，把每个应用配置成可以打包的镜像，并编写 CI/CD 流程（gitlab-ci.yaml）， 本机开发后，通过 git 上传到 Gitlab，通过 gitlab-ci.yaml 自动执行 构建新镜像，上传到镜像仓库，以及其他机器拉取镜像，启动容器

7、引入 Docker swarm

8、引入 kubernetes

组成：

参考：https://www.jianshu.com/p/2ffb0e2c16e8

操作系统CentOS7
容器运行环境Docker
远端版本控制代码仓库Gitlab
持续集成工具Gitlab-runner
私有镜像仓库Harbor
镜像管理Rancher
微服务注册中心与配置中心jhipster-registry
微服务网关jhipster-gateway

技术栈

---

Docker、Rancher、GitLab、GitLab CI、Harbor、Kubernetes、etcd、prometheus

Helm 和 Operators & GitOps（Argo/Flux）

新名词

---

DataOps（MLOps/AIOps）：开发自动化学会自己从数据改善预算规划和预测能力；

GitOps：you build it, you own it，一种用于构建统一部署、监视和管理的云本地应用程序的操作模型。它的工作原理是使用Git作为声明性基础设施和应用程序的真实来源；

基础设施即代码（IaC）：基础设施，即服务器、网络和存储设备，代码化，是云环境DevOps的核心原则；

相关文章

---

https://mp.weixin.qq.com/s/pS5n74nGY96r2-ykGHkBwQ