抽象的 DevOps
网络化：典型的传统软件代表 Office 系列，Photoshop 等大都不需要网络支持，单体安装在电脑上即可使用，这类软件不牵涉运维，所以更没有 DevOps 概念。新型的以互联网为基础的软件，例如微信，腾讯会议等都是建立在网络基础上的，这属于典型的 C/S 的架构，C/S 架构中服务器端软件地位极为重要，服务器端软件是隐藏在众多用户背后的不可见的，需要稳定性、安全性等运维诉求，就引出了开发和运维工作的协同化诉求。
Web 化：相对于 C/S 的软件，B/S 的软件在用户端的部分（C/S 是桌面或者手机应用，B/S 是网页）上有更高的更新发布频率，需支持更新过程不停止服务，无感更新等特性，对软件的交付速度和质量有了更高的要求，这也引出了开发和运维工作的协同化诉求。
云化：传统的 ERP，CRM，HRM，视频会议系统都是有软件供应商独立实施给客户方，而这些软件也都在逐步云化，产生了例如销售易，腾讯会议，钉钉，企业微信等 SaaS 应用软件，这类 SaaS 化的软件对 DevOps 诉求更为迫切。
敏捷化：传统的外包软件交付模式因其反馈周期长，实施成本高等弊病已经开始大规模的转向敏捷、小步快跑、高速迭代的模式，更高的交付速度要求开发和运维之间必须建设协作文化，流程，标准以及工具。
本文在探讨完毕两个视角、双向移动、四个层面后会把开发和运维的中间重叠部分（软件交付）为主题来详细阐述这一 DevOps 实践的最大难题。
开发视角
运维视角
视角的聚焦
业务运维的左移
为什么我们这边修好了 bug 今天不能给我发布？我需要查一下生产环境日志要等 3 个小时？运维同学能不能不要总是抄错配置项？
请用文档详细撰写清楚发布步骤和注意事项并仔细评估发布风险。运维团队已经排满了所有发布计划，你这个修复问题不严重，请等下周再排。
基础设施运维的右移
在没有云主机的年代，运维团队不得不扛着沉重的服务器去机房里，对照着官方指南，安装操作系统、配置网络策略；云主机时代，容器还未到来之时，运维团队摆脱了物理服务器，却不得不维护大量的服务器软件，安装、卸载、批量发布等，去维护业务运行的基础软件环境；在有了 Kubernetes，Docker 等容器技术之后，运维工程师从维护软件运行基础环境中解脱，转而做更上层的基础设施：监控体系、负载均衡等；不远的将来，当 Serverless 重构云计算体系的时候，运维人员连监控体系、负载均衡等都不需要关注了，全量交给云来解决。
DevOps 的四个重要层面
从人员管理层面看 DevOps
从信息流转层面看 DevOps
开发交付测试阶段：信息提供方是开发、主接收方是测试、抄送方是产品经理、项目经理、运维等，这个提测申请是否结构化？是否具备标准？有没有流程？是否有专用工具支撑？
测试回馈：信息提供方是测试，主接收方是开发、抄送方产品经理、项目经理等，这个信息最简单的方式是采用体系化的缺陷管理系统配合上下游来一起管理，细化流程和标准后即可实现顺畅，精准传达
交付发布：信息主提供方是开发，主接收方是运维，抄送方是产品经理、测试、项目经理等，这个阶段的自动化程度是相当重要的，要想实现自动化，前提是结构化、流程化、标准化先行。在本文的后续段落中会以 Kubernetes 体系的自动部署为实战来介绍如何结构化、流程化、标准化最终实现自动化
从工具系统层面看 DevOps
角色切面：好的 DevOps 工具系统应该像是一个为工厂量身定制的生产流水线，各个角色各司其职，关注精准的信息，执行标准的操作，输出标准的结果。在弱整合的工具系统里可能不同系统的用户、角色、权限设计都有很大差异，难以实现角色切面。例如一套基于 Jira + GitLab + Jenkins + Kubernetes 的体系，运维角色应该加入 Jira 的项目中么？产品经理是否需要关注 Jenkins 的 Job 执行状态？
自动流转：自动流转是为了解决重复性的机械劳动而设计的，要想具备自动流转的特性，整合性和角色切面也必须设计的非常好，开发完毕到提测自动部署，测试通过到自动发布，在设计好流程和标准后都是一些机械化的重复劳动。
从技术架构层面看 DevOps
单体 Tomcat：构建一般使用 IDE 配合 Maven/Gradle，少许团队会使用 Jenkins 之类的进行自动化构建 war 包，部署往往选择 scp/sftp 形式进行发布，停机部署，需要运维人员专门人工操作，容易出现错误
多实例 Tomcat + Nginx 负载均衡 + 动静分离：构建开始变的复杂，前端的 js css 等需要进行独立的压缩和上传，部署过程有很多运维团队开始选用 Ansible 之类的便于管理 Nginx 的复杂配置文件和多实例并行发布，Ansible 等工具为自动化的发布提供了诸多便利，但仍然要求运维人员去撰写难以维护的 playbook 和服务器的基础软件环境
前后端分离 + 容器化：当以 Docker 为代表的容器技术开始流行的时候，团队开始尝试构建的结果不再局限到 war 包层面，可以把前端和后端分别构建出 Docker 镜像，以 Docker 镜像作为标准交付，但服务的配置信息、扩缩容能力，健康检查等问题仍然困扰着运维团队
微服务化架构 + 容积集群部署：以 Kubernetes，Istio Service Mesh等为代表的容器集群编排和微服务技术开始逐步进入大家的视野，部分团队开始尝试让开发团队自主通过 Kubernetes 工作负载 Yaml 文件、ConfigMap 等形式管理配置信息，使用 Service 配合微服务的流量控制体系进行灰度控制、服务降级、熔断处理、标准化健康检查监控等。
Serverless 无服务器架构：以 Serverless Framework、AWS Lambda、Knative 等为代表的新一代无服务器架构的服务器端应用已经帮助一些技术领先的团队实现了进一步的去运维化，后端开发只需要按照云函数的定义要求进行少量的声明或者配置，即可实现全套的 CI/CD、负载均衡、弹性伸缩、生产级别高可用等能力。如果你还不知道什么是 Serverless，欢迎来这里了解：
https://cloud.tencent.com/product/sls
VM/虚拟机 实现了去硬件化 Hardwareless
Container/容器 实现了去操作系统化 OSless
云函数/Serverless 实现了去服务化 Serverless
DevOps 的粘合剂：持续部署
业务运维部分左移：常规发布、配置管理等基础业务运维左移到开发团队
基础设施运维部分右移：基础计算资源由云全托管，直接使用云的 Kubernetes 集群，负载均衡器，数据库等
开发团队和运维团队分离：运维团队更多的是制定业务运维规范标准和流程，在云的基础上层进行更高层次的基础设施运维，如制作业务监控体系，信息安全，日志系统等
整合式 DevOps 系统：直接使用 CODING 提供的集敏捷项目管理，测试管理，代码管理，持续集成，制品库，持续部署为一体的 SaaS 服务
简单的微服务技术架构：未引入如 Istio 等高级微服务架构（引入微服务架构的持续部署跟此示例类似，但细节过多，不适于在此文详述），使用 Docker 镜像 + Kubernetes
前提准备：
使用腾讯云 TKE 创建一个 Kubernetes 集群：
https://cloud.tencent.com/document/product/457/11741
准备好一套可以构建出 Docker 镜像的源代码，并提供对应的 Kubernetes Manifest 文件，示例代码库：https://wzw-test.coding.net/p/demo-for-cd/d/demo-for-cd/git
配置好自动构建过程：https://help.coding.net/docs/devops/ci/manual.html
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "<h1>欢迎使用 CODING CD!！</h1>"
if __name__ == __main__ :
app.run(debug=True,host= 0.0.0.0 )
FROM python:3.7
COPY . /app
COPY pip.conf /etc/
WORKDIR /app
RUN pip install -r requirements.txt
ENTRYPOINT ["python"]
CMD ["app.py"]
pipeline {
agent any
environment {
ENTERPRISE = "wzw-test"
PROJECT = "demo-for-cd"
ARTIFACT = "demo-for-cd"
CODE_DEPOT = "demo-for-cd"
ARTIFACT_BASE = "${ENTERPRISE}-docker.pkg.coding.net"
ARTIFACT_IMAGE="${ARTIFACT_BASE}/${PROJECT}/${ARTIFACT}/${CODE_DEPOT}"
}
stages {
stage( 检出 ) {
steps {
checkout([$class: GitSCM , branches: [[name: env.GIT_BUILD_REF]],
userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]])
}
}
stage( 打包镜像 ) {
steps {
sh "docker build -t ${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF} ."
sh "docker tag ${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF} ${ARTIFACT_IMAGE}:latest"
}
}
stage( 推送到制品库 ) {
steps {
script {
docker.withRegistry("https://${ARTIFACT_BASE}", "${env.DOCKER_REGISTRY_CREDENTIALS_ID}") {
docker.image("${ARTIFACT_IMAGE}:${env.GIT_BUILD_REF}").push()
}
}
}
}
}
}
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: demo-for-cd
name: demo-for-cd-deployment
spec:
replicas: 3
selector:
matchLabels:
app: demo-for-cd
template:
metadata:
labels:
app: demo-for-cd
spec:
containers:
- image: demo-for-cd-image
name: demo-for-cd
ports:
- containerPort: 5000
imagePullSecrets:
- name: coding-registryservice.yamlapiVersion: v1
kind: Service
metadata:
labels:
name: demo-for-cd-service
spec:
ports:
- name: http
port: 5000
protocol: TCP
selector:
app: demo-for-cd
type: LoadBalancer
在 CODING 平台实现简单的开发与运维的切面
运维角色进行预配置
运维在配置部署流程的时候需要制定流程启动所需制品标准（此处映射我们提的交付流程的信息要结构化），我们声明了启动流程需要三个制品分别是: 一个 Docker 镜像，一个 Deployment Manifest 文件，一个 Service Manifest 文件。
运维可选配置若干个自动触发器来自动启动这个流程（此处映射我们提的交付流程的信息在结构化的基础上实现自动化），我们设置了当 Docker 镜像库出现新镜像版本时自动触发此流程。
可以给部署流程添加额外的通知推送用以告知相关人员（此处映射我们提的信息流转要精准，区分主接收人和抄送订阅），这里可以把发布事件信息同步到产品经理、项目经理等
尽量做到版本化管理一切资源：版本化管理 Kubernetes 配置文件，管理容器镜像，管理部署流程配置等等，这样有助于快速的灾难恢复，问题追溯等，这些能力 CODING 都已提供，可以很方便的实现。
可在流程中插入 Kubernetes Job，使用 run job 来处理发布过程中的诸如数据库表结构更新，数据迁移，静态资源预编译等过程
使用 Kubernetes ConfigMap 来管理配置项和配置文件，这样所有的可交付制品类型就被限制为 Docker 镜像和 Kubernetes Manifest，便于管控
可选使用独立 Git 仓库来管理 Kubernetes 文件，主要由运维团队来管理，接受开发团队的合并请求（可自由决定配置管理是否左移至开发团队）
开发角色完成开发和发布
其他场景的持续部署
Ansible + 堡垒机场景：这类持续部署的核心在于 Ansible 的 Playbook 的撰写质量，可以选择直接接入 CI （如 CODING 持续集成、Jenkins）体系使用，实现快速部署。
云主机的弹性伸缩组：CODING 持续部署支持基于云主机镜像配合弹性伸缩组的模式进行发布，此模式较重，可以根据自己实际情况进行选择。
scp/sftp，Git/SVN：建议尽快升级至容器等形态的方式发布，在未升级前也可以考虑直接嵌入到 CI 中执行。
Serverless 场景：这种属于基础设施右移非常彻底的类型，大多数情况下不需要引入独立的持续部署工具体系，可以考虑直接在 CI 甚至于 IDE 开发阶段使用插件等机制添加部署能力，无需进行过度复杂的设置。CODING 持续部署不排除未来会针对 Serverless 部署场景添加更多的其他方面能力，如审批，通知等，以支持更安全稳定的发布行为管控。
最后的总结：该分还是该合？
作者简介
王振威，CODING DevOps 研发四部总监，主要负责 CI、制品库、CD 的产品设计及开发，在企业研发管理、代码管理流程、敏捷开发实战、容器云技术落地、运维监控方案等方面有极为深刻的认识。
本文分享自微信公众号 - DevOps持续交付（devopscd）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/2483000/blog/4362729