许鞍华之前说自己做导演，不是一个比摄影师更好的摄影师，也没本事做灯光比灯光师好，因为行业发展使每一个部门都越来越复杂，要求高，只要懂得皮毛同其他人沟通，能知道你的要求就行。 

    这段话也算是给我找了个借口。有些概念虽然反复见，最多就是明白些皮毛，但与专业人员沟通效率能提高，有助于做好传达和解释工作。况且，有些工作并没有前路可寻，需要不断理解前进的方向，持续明确细化要求，要想找到路，坐对车，必须得多看多学多问多思考了。

------------分隔线--------------

《DevOps和自动化运维实践》   --------------   余洪春

云计算平台上（包括Kubernets）的各种资源，从服务器到网络，再到负载均衡都是由API创建和操作的，这就意味着所有的资源都可以由“软件定义”，这给各种自动化运维工具提供了一个非常好的基础环境。

由于机器数量众多、网络环境错综复杂，也需要由DevOps人员来设计工具，提供后端的自动化运维API，结合公司的CMDB资产管理系统，提供自动化运维功能，简化运维的操作流程及步骤，提高工作效率。

自动化运维把周期性、重复性、规律性的工作交给自动化平台（或产品）去处理，通过标准化、自动化、架构化、过程优化来降低运维成本、提高运维效率。

消除无效率：运维工作的手动工作，如果可以实现自动化，将显著提升效率水平。 减少错误：即使最谨慎的人也会犯错，尤其是面对着重复性的工作时。通过运维自动化工具来完成这样的工作，其结果是显而易见的，错误率将大大降低。 最大化员工使用：通过运维自动化，运维专家们的精力可以集中在更复杂、更有战略意义的业务问题上。同时也避免了雇用更多的员工来应对工作量增加的需求。同样一批人，有自动化运维，就有更大的能量来创造价值。 提高满意度水平：自动化运维工具帮助IT运维，可以为内部员工和外部客户提供高水平支持。无论是通过提供自助服务选项，还是大幅缩短时间（最多达90%）来减少联系和等待服务台的需求，自动化运维使得我们可以更好地拥抱SLA。 降低成本：系统中断、人为错误、重复工作，会导致不菲的费用和代价，而自动化运维几乎可以将这些成本完全消除。

YAML是一个可读性高的用于表达资料序列的格式。它的主要特点是可读性好、语法简单明了、表达能力强、扩展性和通用性强等。

YAML的可读性好。YAML和脚本语言的交互性好。YAML使用实现语言的数据类型。YAML有一个一致的信息模型。YAML易于实现。YAML可以基于流来处理。YAML表达能力强，扩展性好。

建议所有的YAML文件都以“---”作为开始行，这是YAML文件格式的一部分，表明是一个文件的开始。

Docker是现阶段最流行的容器技术，主要用于隔离，因为Docker镜像、容器运行简单便捷，适合于将应用快速部署上线、快速弹性扩充，所以Docker是非常适合DevOps的

虚拟机在性能上有较大损耗的原因如下： 虚拟机是在硬件层面实现虚拟化，需要有额外的虚拟机管理应用和虚拟机操作系统层，而Docker容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，所以性能上更接近于原生，基本上是没有任何损耗的。

Docker容器除了运行其中的应用之外，基本上不消耗额外的系统资源，在保证应用性能的同时，尽量减小系统开销。以传统虚拟机方式运行N个不同的应用就要启动N个虚拟机（每个虚拟机需要单独分配独占的内存、磁盘等资源），而Docker只需要启动N个隔离的容器，并将应用放到容器内即可。这也是为什么单机上只能运行十几个虚拟机，却能运行上千个容器的原因。

我们可以在DevOps的持续集成/持续（CI/CD）部署阶段就引入Docker，用Docker来实现操作系统、测试环境及生产环境的镜像封装，从而实现快速开发和部署，其流程如图

利用Docker来生成镜像，正好解决这些问题。另外，关于各个环境的配置文件的问题，可以结合实际情况来选择合适的方案。

Docker的三大核心概念列举如下：镜像（Image） 容器（Container） 仓库（Repository）

Docker镜像类似于虚拟机镜像，可以将其理解为一个面向Docker引擎的只读模板，包含了文件系统。镜像是创建Docker容器的基础，可以通过公有仓库或私有仓库下载已经做好的应用镜像，并且通过简单的命令就可以直接使用。镜像本身是只读的。

容器类似于一个轻量级的沙箱，Docker利用容器来运行和隔离应用。容器是从镜像创建的应用运行实例，可以对其进行启动、开始、停止、删除操作，而这些容器都是相互隔离、互不可见的。注意　容器=镜像+读写层，并且容器的定义并没有提及是否要运行容器。

Docker仓库是Docker集中存放镜像文件的场所。我们经常接触到的注册服务器就是存放仓库的地方，其中往往存放着多个仓库。每个仓库集中存放某一类镜像，往往包含多个镜像文件，通过不同的标签（TAG）来进行区分。

镜像就是一些只读层（read-only layer）的统一视角，它其实由数个只读层重叠在一起，除了最下面一层，其他层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在宿主机的文件系统上访问到。统一文件系统（Advanced Union File System，AUFS）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，从用户的角度看来，只存在一个文件系统。 而容器的定义和镜像几乎一样，也是一些层的统一视角，唯一区别在于容器最上面的那一层是可读可写的。

容器是一种便携式、轻量级的操作系统级虚拟化技术。它使用namespace隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而可以很方便地在任何地方运行。

由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定，因为每一个应用程序都不需要外部依赖，更不需要依赖外部的基础架构环境，这完美地解决了从开发到生产环境的一致性问题。

可以使用Docker集群管理三剑客之一的Docker-Compose（有时也简称之为Compose）来编排容器。Compose是用Python语言开发的Docker集群管理的工具和轻量级编排工具，我们通过编写YAML文件可以对一组容器进行编排，

自动化运维是指将IT运维中日常的、大量的重复性工作自动化，把过去的手动执行转为自动化操作。自动化是IT运维工作的升华，自动化运维不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的较高层次。

CMDB管理系统。 持续集成系统。 运维调度管理系统。

运维调度管理系统，有的公司也称之为“运营系统”，该系统是对复杂运维事务的封装，个人觉得运维调度管理系统是上述所有子平台中最有技术含量的，我们在运维过程中会接触到很多复杂的运维场景，比如容灾切换、服务迁移、熔断机制、扩容或缩容等，这些都不是简单地通过单一运维动作就能够完成的，需要综合考虑很多因素（最直接有效的监控指标就是业务参数和大数据日志分析），这也是我们需要花精力思考和总结的地方。

自动化运维的第一阶段是运维的标准化

标准化是自动化运维必须完成的第一步，只有操作系统、软件包的版本、安装路径及程序路径全部标准化了，后期我们才能使用自动化运维工具或脚本来进行批量处理，不然不仅会加大自动化的实施难度，而且会大大增加自动化运维故障的出现概率。而且如果不进行标准化，那么出现定位故障也将是一件很麻烦的事情。

自动化运维的第二阶段是Web化，相信每个公司都会根据自己的实际情况设有自己的管理平台，通过这个平台我们可以控制登录人员的权限，规范运维流程、运维的标准化流程，还有case的收集及整理等，通过这些我们能解决运

自动化运维的第三阶段，即服务化（API化），这个阶段的很多操作都会被记录或写入日志，这时可以让运维平台与公司其他平台进行交互，所以需要我们提供对外的API来进行数据交互，而且此时是不需要开放平台的登录权限的，只需要公开一些API以便公司其他平台调用这些数据即可，所以这个阶段还是有许多细节工作可以做的。 自动化运维的第四阶段，即智能化运维，这是最高级别的运维自动化。一般来说，此时的平台或系统都已经有了机器学习的能力，能根据当前的业务级别来自动扩容或缩容、进行故障的自动修复等，但这些工作也是非常复杂的，需要大量收集业务运营指标，然后通过机器学习的手段来自动地进行智能调整，这也需要技术团队做大量的工作，这也是目前自动化运维努力的目标。

现在我们的APP项目的架构方案主要是容器微服务化，Docker发布和k8s都在项目中使用，尤其是Docker，前端和后端程序均采用Docker化的方式来进行部署和发布。这对于运维人员的运维方式来说也是一个巨大的改变，而且Docker容器的自动化部署较依赖于k8s，随着k8s的深入使用，我们发现k8s在很多方面占据了巨大的优势，例如容器编排、水平自动扩展、滚动升级、负载均衡还有资源监控，

打造自动化运维平台，最难的不是如何开发，而是积累场景，长期积累各种业务场景才能打造出最合适的自动化运维平台。自动化运维不是终点，积累场景和大数据才是关键，所以自动化运维的每一步中都应该做好对数据和场景的积累。等到将来场景模型完全建立起来，我们才能实现最终的自动化运维目标。