目录
[2.1 镜像容器管理系统](#2.1 镜像容器管理系统)
[2.1.1 镜像分类](#2.1.1 镜像分类)
[2.1.1.1 磁盘镜像](#2.1.1.1 磁盘镜像)
[2.1.1.2 镜像容器](#2.1.1.2 镜像容器)
[2.1.1.2.1 镜像容器分层管理示意图](#2.1.1.2.1 镜像容器分层管理示意图)
[2.1.2 镜像容器管理系统软件](#2.1.2 镜像容器管理系统软件)
[2.2 配置管理系统](#2.2 配置管理系统)
[2.2.1 配置管理系统的功能](#2.2.1 配置管理系统的功能)
[2.2.1.1 管理操作系统层、中间件层相关软件的安装和配置](#2.2.1.1 管理操作系统层、中间件层相关软件的安装和配置)
[2.2.1.2 管理软件应用相关的安装和配置](#2.2.1.2 管理软件应用相关的安装和配置)
[2.2.1.3 管理网络的配置和调整](#2.2.1.3 管理网络的配置和调整)
[2.2.1.4 管理基础设施的资源、配置](#2.2.1.4 管理基础设施的资源、配置)
[2.2.2 配置管理系统架构](#2.2.2 配置管理系统架构)
[2.2.3 配置管理工具](#2.2.3 配置管理工具)
[2.3 运维发布管理系统](#2.3 运维发布管理系统)
[2.3.1 概述](#2.3.1 概述)
[2.3.2 运维发布管理系统周边关系](#2.3.2 运维发布管理系统周边关系)
[2.3.3 运维发布管理系统的作用](#2.3.3 运维发布管理系统的作用)
[2.3.4 运维发布管理系统的不足](#2.3.4 运维发布管理系统的不足)
[2.3.5 运维发布管理系统现状](#2.3.5 运维发布管理系统现状)
一、概述
熟悉CI/CD平台使用的读者想必知道，在业界，CI/CD流程的平台产品通常是在一起的。也就是说很多产品具备持续集成能力的同时，也具备持续交付、持续部署能力。用一句话总结就是，CI流程是生产出可用的软件制品包；CD流程是将软件制品包部署到测试、生产等环境以达到用户需求。从CI到CD的流程在平台实现上很多能力是可以公用的，典型的能力如任务管理、编排调度、系统监控等。除了这些公共能力外，想要实现上述CD流程的平台化，通常包含以下几个系统。
二、持续交付/持续部署主要构成
2.1 镜像容器管理系统
在介绍镜像管理的基本概念时曾提到，镜像可以看出静态的，无论是软件制品镜像还是操作系统镜像，最终都是通过持续交付、持续部署流程的调度生成可运行的生产环境实例，让服务或软件真正运行起来。为了完成这一流程的标准化和自动化，镜像容器管理系统在其中起着重要的作用。
2.1.1 镜像分类
针对这些镜像的管理通常是由镜像容器管理系统或容器注册表来完成的。由于不同的企业，其技术路线的选型不同，涉及的镜像类型存在较大的差异，常见的镜像类型有：
2.1.1.1 磁盘镜像
如iso光盘数据镜像、vhd虚拟机通用镜像、raw非结构化磁盘镜像等。
2.1.1.2 镜像容器
如ovf和ova格式虚拟化镜像、Docker容器镜像、阿里云主机镜像等。
2.1.1.2.1 镜像容器分层管理示意图
在DevSecOps中，涉及镜像的主要镜像容器类型是由云原生基础和虚拟化架构决定的。为了达到对操作系统、运行环境、应用软件包的"一次构建，多次部署"，通常对这些镜像及依赖镜像创建的运行实例过程实施分层管理，遵循开放容器计划(Open Container Initia，OCI)，使用包含不同运行环境的容器镜像来解决镜像部署过程中的标准化问题，如下图所示：
2.1.2 镜像容器管理系统软件
这些不同类型的镜像通过镜像容器管理系统与CI/CD的打通，在完成整个镜像生命周期管理的同时，也完成了通过容器化的持续部署功能。
在镜像管理系统中，除了管理容器从创建到销毁的生命周期外，拉取、推送容器镜像到不同的环境中去，还有镜像存储、容器运行、容器网络接口管理、CI/CD接口集成等功能，其本质是通过容器化技术的深度应用，构建黄金管道的自动化测试与部署能力。
目前，常用的镜像容器管理系统如下图所示：
2.2 配置管理系统
2.2.1 配置管理系统的功能
通过前文对配置管理基本概念的介绍，读者了解了配置管理在DevSecOps中起到的重要作用和使用模式，它的使用场景除了基本的版本控制管理之外，还体现在以下几个方面：
2.2.1.1 管理操作系统层、中间件层相关软件的安装和配置
这些功能可以通过前文的镜像管理来解决。如果无法镜像化，则仍需要通过定义自己的Configuration as Code（配置即代码）来解决。
2.2.1.2 管理软件应用相关的安装和配置
从前文的讨论可以知道，通过镜像容器方案来达到"一次构建，多次部署"的过程中，仍有很多配置需要根据部署环境的不同而做改变。这些配置需要通过配置管理，以保证这些线上操作的可重复性。
2.2.1.3 管理网络的配置和调整
即Networks as Code（网络即代码）。通过网络策略、路由策略、端口开放等，完成蓝绿发布、灰度发布、流量牵引等不同操作的配置。
2.2.1.4 管理基础设施的资源、配置
这些可以依托云管系统来完成，但云管系统与CI/CD的集成、调度等工作仍是配置管理的重点。
2.2.2 配置管理系统架构
以上这些场景下，通过配置管理系统或配置管理工具，从配置脚本到环境变量适配，以完成不同环境下的测试、部署需要，从而完成1台到多台机器的批量操作，满足单一部署到高并发、高可用环境下的多部署策略的支撑。常见的配置管理系统架构如图所示：
2.2.3 配置管理工具
目前，常用的配置管理工具如表所示：
2.3 运维发布管理系统
2.3.1 概述
在介绍持续交付、持续部署的流程时曾介绍，流程的关键改变是将研发产物从测试环境发布到UAT环境、准生产环境、生产环境上。在这一发布过程中，起着最大作用的就是运维发布管理系统或自动化部署系统。用户通过任务调度，借助运维发布管理系统，将不同阶段的制品或应用安装包推送到不同的运行环境中去。
2.3.2 运维发布管理系统周边关系
运维发布管理系统与配置管理系统，以及各个运行环境之间的关系，如下图所示：
2.3.3 运维发布管理系统的作用
运维发布管理系统以任务调度为主线，为用户提供一键发布、灰度发布、一键回滚等自动化发布操作 。开发人员或运维人员在使用时，跟踪任务的执行进度、过程日志、异常记录，判断发布操作的进展情况，以便及时地做出发布策略的调整。
例如，通过资源划分可以开展滚动发布，每次发布一定比例的服务器，如10%、30%、60%，通过三次覆盖所有的服务器。这样的情况下，如果没有运维发布系统，当服务器达到一定数量级时，运维的成本会很高，发布周期也会很长。甚至，发布的版本如果出现了问题，难以及时回退或回滚。而使用运维发布管理系统，这些问题都是在系统的功能范围之内。
2.3.4 运维发布管理系统的不足
当然，运维发布管理系统也有自身的不足，尤其是在云原生和微服务的架构逐步成为主流的背景下，运维发布管理系统与应用、应用架构的耦合是有一定侵入的，这种影响在推广落地过程中，既要看用户的容忍度，也很考验产品的成熟度与易用性。
2.3.5 运维发布管理系统现状
目前，运维发布管理系统在不少企业是单独存在的，很多还是与CI/CD融合在一起的。不论它是哪种形态，所提供的能力都需要相应的系统去承载。这些才是运维发布管理系统对整个CI/CD流程的真正价值。
好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！