DevOps期末复习

DevOps导论 - 开场白

课程实践I 10%（暂定）

课程实践II 20%

课程实践III 20%

考试50% （暂定）

DevOps导论 - 第一讲 - 从凤凰项目谈起

DevOps渊源

定义：DevOps -> Development Operations

起源：是Patrick Debois在2009年提出的一种方法论——能否像敏捷开发一样来做运维？

作用：加强了开发，测试和运维之间的沟通协作, 打破了传统团队之间的壁垒，通过实现自动化和架构变更，从而提高研发效率，节省成本，最终更快捷地实现交付产品，并且提高产品质量。

软件工程发展趋势

演化发展史

改进措施

• 变更可视化

  • 工具导入和过程落实的问题（看板）

• 解放资源约束

  • Brent的问题——保护、共享和容忍

• 安全审计

  • 角色转变——共同目标

• 运维自动化/工具化

三步工作法

第一步

概念

• 充分理解工作流（开发-运维-客户）

• 流量最大化（小批量、缩小任务间隔、缺陷控制）

• 不断为了整体目标的实现而优化工作流

部分关键实践与方法

• 持续构建、集成以及交付；

• 按需创建环境；

• 限制半成品（WIP）；

• 构建支持顺利变更的安全系统；看板（任务可视化）

第二步

概念

• 价值流（开发-运维-客户）的快速持续反馈

• 避免问题再次发生（或者快速发现和修复）

• 从源头上保证质量

部分关键实践和方法

• 适时停止生产线

• 持续改进

• 构建自动化测试套件，确保代码随时可部署

• Dev和Ops共享目标和pain

• 远程监测手段（自动化）

第三步

概念

创建培育良好的文化（不断尝试、重复和练习）

部分关键实践和方法

• 营造勇于创新、敢于冒险以及高度信任的企业文化

• 确保至少20%资源投入在非功能需求上

• 不断鼓励和强化改进

四种典型IT工作类型

1. 业务项目

   • 大部分支持企业业务计划的开发项目
   • 典型的，由公司项目管理办公室来跟踪和管理

2. IT内部项目

   • 由业务项目衍生出来的基础架构或者IT运维项目和内部的一些改进项目
   • 典型的，不是集中跟踪和管理
   • 当IT运维瓶颈出现时，投入的生产能力不易于弄清

3. 变更

   • 由上述两类项目引起的
   • 往往通过问题跟踪系统（IT Remedy, JIRA、Git等等）来跟踪和管理
   • 多套系统的问题

4. 计划外工作

   • 操作事故和问题
   • 一旦发生，前述问题的解决会受到影响

IT 工作可视化和WIP控制图示

精益生产和DevOps

传统行业的精益生产和DevOps原理相同

精益理论:

• 降低批量规模

• 减少半成品

• 缩短并且增强反馈回路

DevOps是IT价值流中应用精益理论的结果

5 Levels Agile VS. DevOps

即：价值观，原则，方法，实践，工具

价值观

• 借助敏捷宣言

  

• CAMS/CALMS

  • Culture
  • Automation
  • Lean
  • Measurement
  • Sharing

原则

精益 Principles

• 消除浪费。

• 增强学习。

• 尽量延迟决策。

• 尽快交付。

• 赋予团队权力。

• 内建完整性。

• 全局优化。

方法

• Scrum

• XP

• Kanban

实践

• 敏捷实践

  • 管理实践：迭代式计划、站立会议、回顾、评审、短周期迭代、团队估算等
  • 技术实践包括单元测试、持续交付、持续集成、编码标准、重构等

• 运维实践

方法

• 源代码管理

• 构建服务器

• 基础设施/环境的配置管理

• 虚拟基础架构和容器

• 测试自动化

• 管道编排

关键术语

CI/CD

• 持续集成（ Continuous Integration, CI）

• 持续交付（ Continuous Delivery ,CD）

• 持续部署（Continuous Deployment, CD ）

不同级别的云服务

• Software as a Service (SaaS) - 软件即服务：是一种软件许可和交付模型，其中软件在订阅的基础上获得许可并集中托管

• Infrastructure as a Service (IaaS) - 基础设施即服务：云托管的虚拟机通常按"现收现付"收费。用户可以完全控制机器，但需要自己安装和配置任何所需的中间件和应用程序。

• Platform as a service (PaaS) - 平台即服务：PaaS供应商为应用程序开发人员提供开发环境。提供商通常会开发工具包和标准，以及用于分销和支付的渠道。

指标

• Deployment frequency - 部署频率：您的组织多久部署一次代码？

• Lead time for changes - 变更进入生产的时间：从代码提交到代码在生产中成功运行需要多长时间？

• Mean time to recover (MTTR) - 平均恢复时间(MTTR)：发生服务事件一般需要多长时间恢复服务

• Change failure rate - 改变失败率：有多少百分比的更改会导致服务降级或随后需要修复？

流水线与编排

• Pipeline - 流水线：为了让应用从概念到生产，工程师们都按照顺序和最终例行的步骤工作。

• Pipeline Orchestration - 流水线编排：使构成持续交付管道的各种自动化任务能够在正确的时间被调用的工具或产品。 它们通常还会记录每个任务的状态和输出，并可视化通过管道的特征流。

容器与Docker

• 容器：容器为虚拟机提供了一种轻量级的替代方案，它们使开发人员能够使用相同的DEV环境和堆栈。他们还通过鼓励使用无状态设计来促进DevOps。

• Docker：Docker是一个开源项目，可在软件容器内自动部署Linux应用程序。引用Docker官方描述的功能：Docker容器将一个软件封装在一个完整的文件系统中，该文件系统包含它运行所需的一切：代码、运行时、系统工具、系统库——任何你可以安装在服务器上的东西。这保证了它总是以相同的方式运行，而不管它在什么环境中运行。

微服务

微服务架构一词在过去几年中如雨后春笋般涌现，用来描述将软件应用程序设计为可独立部署的服务套件的特定方式。虽然这种架构风格没有精确的定义，但围绕业务能力、自动化部署、端点智能以及语言和数据的分散控制，围绕组织存在某些共同特征。

版本管理工具

• Git：Git是一个分布式版本控制系统，强调速度、数据完整性和对分布式非线性工作流的支持。Git 最初由 Linus Torvalds 于2005年为Linux内核开发设计和开发，此后成为软件开发中最广泛采用的版本控制系统。

• GitHub：GitHub是一种基于Web的Git存储库托管服务，它提供Git的所有分布式修订控制和源代码管理(SCM)功能以及添加自己的功能。与严格意义上的命令行工具Git不同，GitHub提供基于Web的图形界面和桌面以及移动集成。

测试

A/B测试：一种技术，其中新功能或功能的不同变体可用于不同的用户集，并通过比较指标和用户行为进行评估。

DevOps生态

DevOps导论 - 第二讲 - 云计算和云时代运维

从云计算（Cloud Computing）谈起

云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问， 进入可配置的计算资源共享池（资源包括网络，服务器，存储，应用软件，服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。

• 服务模式：SaaS、PaaS、IaaS等

• 部署模式：私有云、社区（行业）云、公有云、混合云等

XaaS——“X”as a Service

表示一切皆服务，它是一个统称(anything as s Service或everything as a Service )

XaaS强调的是下游对上游按照契约提供服务，隐藏实现细节，并且通常是通过网络的形式来提供服务

最典型的三大XaaS

• Software as a Service (SaaS) - 软件即服务，软件分发方式，中心化，服务供用户订阅

• Infrastructure as a Service (IaaS) - 基础设施及服务，虚拟化，用户需要配置和部署中间件和应用服务

• Platform as a service (PaaS) - 平台即服务，服务供应商提供开发的整体环境.

自建、IaaS、PaaS以及SaaS的区分

云计算变形

边缘计算

边缘计算面临的挑战

• 可编程性：异构平台和系统

• 命名规则：数量众多的边缘设备

• 数据抽象：数据多样性（频率、格式等）

• 服务管理：D（差异性）E（可扩展性）I（隔离性）R（可靠性）模型

• 数据隐私保护及安全：隐私、数据权属等

• 理论基础：多学科协同

• 商业模式：协调利益相关者

雾计算

云、雾和边缘计算的层次结构

IT服务标准

DevOps中“Ops”端最常见的形式就是以各种服务的方式提供给用户，因此，需要遵循一定的标准和要求

例如： CMMI-SVC，ITIL， ISO20000， ITSS

CMMI-SVC

拥有五个等级

与服务有关的实践:

ITIL服务

全称Information Technology Infrastructure Library（信息技术基础架构库）

ITIL最佳实践主要围绕5个部分：

• 服务战略

• 服务设计

• 服务转换

• 服务运营

• 服务改进

ISO20000

国际标准化组织发布的第一部针对信息技术服务管理(IT Service Management)领域的国际标准

定义了“策划-实施-检查-处置”(PDCA)方法论应用于服务管理

体系(SMS)和服务的所有部分：

• P-策划：建立书面和协定的服务管理体系；

• D-实施：实施和运行服务管理体系，以设计、转换、交付和改进服务；

• C-检查：根据方针、目标、计划和服务需求，对服务管理体系进行监视、测量和回顾，并报告结果；

• A-处置：采取措施，以持续改进服务管理体系和服务的绩效。

ITSS

信息技术服务标准(Information Technology Service Standards，简称ITSS)是一套成体系和综合配套的信息技术服务标准库

• 基础标准旨在阐述信息技术服务的业务分类和服务原理、服务质量评价方法、服务人员能力要求等。

• 服务管控标准是指通过对信息技术服务的治理、管理和监理活动，以确保信息技术服务的经济有效。

• 业务标准按业务类型分为面向IT 的服务标准（咨询设计标准、集成实施标准和运行维护标准）和IT 驱动的服务标准（服务运营标准）。

• 服务外包标准是对信息技术服务采用外包方式时的通用要求及规范。安全标准重点规定事前预防、事中控制、事后审计服务安全以及整个过程的持续改进，并提出组织的服务安全治理规范，以确保服务安全可控。

• 行业应用标准是对各行业进行定制化应用落地的实施指南。

运维

主要指软件系统测试交付后的发布和管理工作，其核心目标是将交付的业务软件和硬件基础设施高效合理的整合，转换为可持续提供高质量服务的产品，同时最大限度降低服务运行的成本，保障服务运行的安全

• 第一层，提供低成本、高质量、高效率、可扩展的基础运维服务，保证业务持续稳定运行。

• 第二层，通过运维数据的挖掘、分析，为业务发展方向提供决策支撑，即业务系统的运营。

• 第三层，将运维资源和技术打包成基础的IT计算服务，向外部客户提供服务，进一步为企业创造价值。

运维技术能力要求

传统运维的转型之路

互联网式运维

快速迭代、快速发布、灰度发布、安全

云计算下的运维

云计算系统本身的运维和基于云计算的应用系统运维；快速部署、快速更新、实时监控、自动化、动态扩容或者缩小系统部署、适应平台差异

大规模下的运维

标准化、自动化、智能化

“提前”运维

介入系统可监控性、可运维性方面的设计；将系统的监控和运维接口设计提前到软件开发设计阶段

运维挑战

一

多层次，海量数据/服务，异构系统，动态变化

二

服务数量，庞大服务/数据异构，调用关系复杂，动态变化

DevOps导论 - 第三讲 - 软件架构演进

什么是软件架构

• EEE将软件架构定义为“系统在其环境中的最高层概念”

  • 业务架构——面对不同的业务需求，制定相应用例描述，组成系统。
  • 技术架构——解决技术问题，开展重要的解决方案决策降低后续的重大技术风险。

• CMU/SEI的Bass也对软件架构进行了定义：一种由软件基本元素以及它们的外部可见的属性和它们直接的关系构成的一种结构

  • 根据功能需求，同时兼顾对系统整体的质量、安全性、并行开发以及需求演变等方面的影响，把系统分成独立的组件；
  • 描述每个组件对外的接口，同时定义组件与组件之间的通讯方式；
  • 将所有的组件合在一起协同工作，成为一个可以工作的计算系统或程序

架构解决什么问题？

软件架构的基本诉求是在满足软件功能属性的前提下，关注软件的质量属性。

软件架构所需要解决的根本问题是在软件实际生产环境的诸多限制条件下，对于各种软件质量属性进行取舍和权衡，并为了满足软件架构需求（即质量属性）寻找合适的“战术”

软件架构的不同视角

• 4+1架构模型

逻辑视图 - 面向对象的分解

体现功能需求/服务

一般用类图或ER图来描述

进程视图 - 进程分解

进程视图主要从性能，可用性等一些非功能性需求的角度去描述系统

着重强调系统的并发和分布，系统完整性，容错性

进程(process)是由一组独立任务组成的运行单元，它代表进程视图实际控制的一个层次（如启动，恢复，重置和关闭）

可以被部署多份，用来提高处理能力或者保证高可用性。

在设计进程视图的时候不需要考虑两个进程会运行在同一台机器，或者不同一台机器。

开发视图 - 子系统分解

主要关注在软件开发实现过程中的软件模块及其组织方式

软件由一系列的程序库或者子系统打包而成，子系统又会根据实现需要被分成多个层次，每一层会提供一个定义完善而又简洁的接口给上层调用。

在开发视图中，我们会考虑很多内部的需求：（如何设计让开发变得更容易?如何设计更容易进行开发管理?哪些是共同的，可以重用的组件?需要使用的工具，部署环境或者编程语言有什么限制?）

物理（部署）视图 - 建立软件和硬件之间的映射关系

主要考虑一些非功能性的需求，比如可用性，可靠性（容错性），性能（吞吐量）以及横向扩展性

进程视图的进程会被映射到一组基于网络的计算节点上

由于同一套系统会被部署到不同的环境中（开发环境，测试环境，生产环境），所以这个映射关系必须足够的灵活并且尽可能少得修改源代码

场景视图 - 综合所有的视图

把以上一些视图的设计元素结合在一起，利用对象场景图和对象交互图来描述系统中一些重要用例的场景，对最重要的一些需求进行抽象。

2个目标：

• 作为一个驱动的工具，用来在架构设计过程中发现架构元素。（场景驱动的架构设计）

• 作为一个验证的角色，用来在架构设计完成以后，在纸上进行架构原型的测试与验证

软件架构演进

单体架构和分层模型

软件架构一直是跟随着需求而做出的高层设计决策，由于传统软件一般用户量不大、数据量不大、业务相对固定、变化不大、系统部署相对简单，容易维护等，所以，并不需要一个非常复杂的系统。最常见的方法是采用单体架构，一般所有的层都运行在一个进程里 。

简单的资源分离

• 分离应用程序和数据

  • 应用服务器需要大量的CPU资源处理业务逻辑
  • 数据库服务器需要更快的磁盘和内存来检索磁盘和数据缓存
  • 文件服务器需要大量的磁盘空间存储资源文件。

一体式应用的高性能分布式系统架构

对产生瓶颈的服务器做水平扩展

• 假设应用服务器资源不够，加入更多的应用服务器到集群里，然后通过一个负载均衡服务器来负责分发请求，就可以有效得提升并发能力。

• 假设数据库服务器资源不够，为了减少数据库查询压力，提高整体的数据访问速度，一般架构师都会考虑增加缓存（本地缓存和专门的分布式缓存服务器），把一些频繁用到的查询结果缓存起来。

流量爆炸时代的大型互联网软件架构

• 单体架构在互联网时代面临的挑战

  • 多个团队协作开发效率低，需要额外的协调工作
  • 系统的可维护性非常差，尤其是对大型的应用
  • 任何小的改动部署都得影响整个系统重新部署
  • 系统复杂了以后，很难做扩展
  • 当遇到性能问题的时候，只能整体加机器，难以拆分

• 大型的互联网软件系统又有如下的一些新的挑战

  • 变化快，强调敏捷。
  • 用户量大，并发高
  • 系统多(可能有几个，甚至成百上千个不同功能系统同时运行)
  • 对系统可用性要求更高，追求24x7零宕机时间

大型互联网软件架构

事件驱动架构

事件驱动架构是一种分布式异步架构模型，用来构建高度可伸缩的系统

业务逻辑都集中在每一个单一职责的事件处理器里，这些事件处理组件以非常松耦合的方式，通过消息队列集成一起工作，异步接收和处理事件

有无独立的业务逻辑控制流程，分为Mediator模式和Broker模式

• Broker模式与Mediator模式最大的区别就是没有Event Mediator，它的消息流直接通过消息通道分发到下游的消息处理器。

• Mediator模式的步骤控制放在独立的一个Event Mediator组件里，Event Processor只处理好单一的业务逻辑。

• Broker模式的步骤控制分散在了具体的Event Processor里，某一个Event Processor除了做好自己的业务逻辑，还需要明白事件的来源和去向。

• 当业务流程比较固定的时候，Broker模式比较容易维护；当业务流程变化比较大的时候，采用Mediator模式更易于修改。

Mediator模式示例

搬家之后的保险处理

Broker模式示例

微服务架构

• 它把单体应用垂直拆分，分成一个小的垂直模块，每一个模块都是一个完整的，自包含的服务。

• 在这个垂直服务内，有可能还是采用单体的架构方式。

• 每个服务对外提供API，并且可以独立被调用，可以独立演化

总结

事件驱动架构和微服务架构都能很好得完成应用的垂直划分。两种架构方式并不是完全互斥的，在一个真实的应用场景中，往往会共存，尤其是一个大型应用里面有很多子系统共存的时候。这种情况下，一般用微服务架构为应用提供服务治理的方案，事件驱动架构来异步得整合多个子系统。

微服务系统拆分

强一致性和最终一致性的取舍

• 强一致性意味着，牺牲了系统的可扩展性，放弃了更高的高性能

  • 功能上比较内聚的，尤其是拥有强一致性事务(Transaction)的功能会放在同一个微服务里面

• 最终一致性，更好的性能，但是中间结果未必正确

单体架构

• 一个单体应用程序，通俗来说就是应用程序的全部功能被一起打包作为单个单元或应用程序

• 单体架构更多地描述了应用的部署架构

SOA架构

面向服务的体系结构是构造分布式计算的应用程序的方法

它将应用程序功能作为服务发送给最终用户或者其他服务

SOA架构中一般都会涉及到企业消息总线(Enterprise Service Bus, ESB)和服务编排(Service, Orchestration)。

总之SOA架构是在企业需要把很多系统集成到一起工作的工作中逐步演化而来的，每个系统本身是高内聚，对外以暴露接口的方式提供服务，而SOA架构则会提供ESB以及服务编排，将不同协议的接口编排起来，最后满足特定的业务需求。

分布式架构

分布式系统是大数据时代企业级应用的首选架构模式，它有良好的可扩展性，尤其是横向可扩展性(Scale Out)，使得分布式系统非常灵活，能应对千变万化的企业级需求，而且降低了企业客户对服务器硬件的要求，真正能做到应用服务层面的弹性扩展。微服务架构是典型代表。

架构演进总结

没有完美的架构

在现实中，没有一个架构是完全可以通用的，更没有一个最好的架构可以适用于任何使用场景。软件架构是对用户的需求，公司对业务的需求，公司未来发展的需求，以及成本条件的折中。在这些限制条件下，我们才能探求一个好的架构设计。同时，一个好的架构设计也不是一成不变的，随着时间的发展，公司的业务方向会发生变化，需求会发生变化，相对应的成本预算也会发生变化，所以架构也自然会随着这些先决条件的变化而不断演化。一个好的架构的首要目标是能支持这种演化，让演化能够按照预期的方式进行扩展，而不是整个架构级别的重构。

DevOps导论 - 第四讲 - 软件过程和方法

软件过程概述

软件过程

• 理论基石——软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

• 软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合，这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

软件工程的两大视角

• 管理视角——能否复制成功？

• 技术视角——是否可以将问题解决得更好？

PSP/TSP渊源和作用

过程改进运动

• TQM

• Humphrey早期工作

• PSP/TSP

PSP作用

• 个人级管理实践和过程估算和计划

• 承诺和拒绝承诺

• 理解和改进

• 工业水准的过程和规范

• 客观决策的数据

典型PSP过程

PSP基本原理（Principle）

• 软件系统的整体质量由该系统中质量最差的某些组件所决定；

• 软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过程所决定；

• 作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量；

• 作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践中，也就是说，应当建立持续地自我改进机制。

PSP 不同级别

TSP迭代式开发

TSP团队组建

通用计划框架

挣值管理方法

项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法。

• 每项任务实现附以一定价值（credit）

• 100%完成该项任务，就获得相应价值

EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量

• 简单实现

• 中级实现

• 高级实现

挣值分析图示

EVM应用示例

EVM的局限性

• EVM一般不能应用软件项目的质量管理。

• EVM需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制。

• EVM完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。

极限编程（XP）

极限编程（eXtreme Programming）是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开发实践运用到极致

• 极限编程的有效实践

  • 客户作为开发团队的成员——客户代表
  • 使用用户素材
  • 短交付周期
  • 验收测试
  • 结对编程——结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
  • 测试驱动开发——极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
  • 集体所有
  • 持续集成
  • 可持续的开发速度 <=40h/week
  • 开放的工作空间
  • 重构
  • 使用隐喻

极限编程 (XP)开发过程框架

SCRUM

• Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

• 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队。

形式

• 站立式会议

• 看板

EVM的变形——SCRUM燃尽图

传统软件开发

摩尔定律和反摩尔定律

反摩尔定律

如果我们18个月后卖出和今天相同的产品，就只能得到和今天相比一半的价值

移动互联网时代的产品生命周期

从业务（business）视角看敏捷的目标 - 更快（早）的交付价值

传统方式

敏捷

应对变更

敏捷的（业务）目标2 - 灵活地响应变化

敏捷：创建组织==“更快（早）地交付价值”和“灵活地响应变化”==的能力

精益交付背后的范式变化

从以 资源效率 到 以 流动效率 为核心的改进

对待效率两种不同的视角

• 资源效率

  

• 流动效率

  

	资源效率	流动效率
目标	高资源使用率	高价值流动效率
焦点	资源/职能	客户/价值
视角	局部	系统（端到端）

现实生活中的例子

仅仅聚焦资源效率的结果

-> 低效组织

改进 -> 效率竖井

看板方法

看板：可视化的板

产品开发中的看板

DevOps导论 - 第五讲 - DevSecOps简介

DevSecOps起源

在DevOps模式下，企业能够更快更好地应对复杂多变的市场环境下频繁变更的需求。然而大部分的DevOps实践起初并没有与安全相结合。因此安全常常被视为快速发布上线的障碍，有时导致上线的产品有安全问题。

2012年，Gartner研究员Neil MacDonald在他的一篇博文中指出了 DevOps在安全方面的缺失，并提出将安全融入到DevOps中，以平衡企业 IT功能的速度和敏捷性需求与企业保护关键资产、应用程序和服务的需求

作为DevOps在安全方面的拓展，这被称为SecDevOps、DevSecOps或 DevOpsSec。目前最为常见的说法是DevSecOps

DevSecOps的重要性

不满足安全要求，客户不信任我们的软件，做再多的功能和特性都等于零。

著名的例子：2000年几小时内感染全球数百万Windows电脑的VBS蠕虫病毒

• 当面临在添加 功能和解决安全问题之间做出选择时，需要选择安全”

DevSecOps实践框架

DevSecOps原则

DevSecOps原则是对DevSecOps核心理念的总结，对 DevSecOps实践有着重要的指导作用

• 偏理念的CAMS( Culture, Automation, Measurement, Share)原则

• 偏实践的NCSC(National Cyber Security Center, 英国国家网络安全中 心)安全开发和部署八原则

CAMS原则 - Culture, Automation, Measurement, Sharing

CAMS原则是由John和Damon Edwards两位先驱针对DevOps率先提出，并随着DevOps的不断发展而日趋成熟。CAMS原则从四 个方面高度概括了DevOps价值观，为正确实施DevOps实践提供了概念上的指导。目前，在DevSecOps背景下，CAMS原则也相应地需要在安全领域增添新的内容。

Culture文化

观念上，DevSecOps强调人人对安全负责，发现并解决安全问题不 再是安全人员独有的任务

开发人员需要对自己所生产的代码的安全性负责，参与交付的人员也需要对最终交付的软件产品的安全性负责

所有参与软件生命周期的工作人员都需要提升自身的安全意识和技能， 在完成各自阶段任务时就保障足够的安全性要求

DevSecOps需要Dev, Sec, Ops三个团队之间的理解与配合。安全团 队也不再像以往一样位于整个工作流的末端，而是尽可能将安全左移

Automation自动化

DevOps自动化几乎遍布整个DevOps生命周期

DevSecOps在此基础上，也更加强调安全保障活动的高度自动化，能够在不牺牲软件安全性的条件下跟上DevOps的速度和规 模，避免由于人为干预而可能导致的安全问题。

通过整合自动化的安全检测工具和监控框架等来形成完整的DevSecOps 安全工具链和反馈环，达到全方位保障软件产品的安全性要求。

Measurement度量

DevOps中，度量是提高流程可见性的一个重要手段，通过相关的度量指 标（如关键性能指标，新版本对系统稳定性影响指标等），任何人都能够知道在什么时候发生了什么事情，进而了解到当前系统的状态，并及时思考如何进行改进等

DevSecOps环境下，我们仍然需要始终掌握项目进展、系统状态等信息， 同时，DevSecOps也更加推崇使用度量标准来评估、控制和改善整个软件开发过程。

• 如组织可以根据对漏洞的定位和修复时间信息来衡量DevSecOps所产生的效果并考验组织的应变能力。

Sharing分享

在DevSecOps中，开发团队、运维团队和安全团队仍需要通过共享工具和技能的方式来协同保障软件的安全开发和运维。

安全团队需要为开发团队和运维团队找到合适的、统一的安全工具来满足日常的安全开发活动，三个团队通过共享的安全工具来将安全检查左移到开发阶段，让安全问题在早期就能够得以发现并解决

NCSC 原则

NCSC安全开发和部署八原则从具体实践的角度出发，更为具体地阐述了DevSecOps在实际开发和部署中所应当参考的原则标准，为进行 DevSecOps最佳实践指明了方向。

原则 1 – 安全开发是每个人的责任

• 安全性应该被认为是整个开发过程中的团队工作，每个团队都需要安全专家，但这并不意味着每个团队成员都要成为安全专家。

• 在设计和交付的过程中，需要不断地识别和讨论潜在的安全问题，通过相互协作的 方式来解决相应的安全问题。

• 整个团队也应当将安全性作为日常实践的一部分，将相应的安全责任落实到个人，并大力在组织内鼓励分享和讨论不同的安全问题，提高团队成员的安全意识和责任感

原则 2 – 保持安全知识的“锋利性”

• 需要了解常见的攻击类型，还要有能力识 别出这些攻击的基本特征，掌握抵御这些攻击的技术，这就要求开发人员和安全人员不断学习安全相关领域的最新知识

• 只有及时更新自己的知识储备，才有足够的把握来面对如今全新的安全形势，才更有可能在代码中实现较为恰当的安全控制

原则 3 – 交付整洁和可维护的代码

• 编写出来的代码布局不当，缺乏一致性，还缺乏相关文档的话，那 么无疑就会增加系统的总体复杂度，而一些难以发现的安全漏洞往往会 隐藏其中，从而导致严重的后果

• 为减少可能隐藏在复杂度背后的漏洞，我们需要交付整洁且易于理解的代码，这样的代码需要符合团队既定的编码标准

• 通过交付易于理解且整洁的代码不仅便于今后的维护，也可以用来降低攻击者利用隐藏的漏洞找到攻入系统的风险。

原则 4 – 保障开发环境安全

• 如果开发环境本身就不够安全，那么就很难保证交付出来的代码的安全性。

• 对开发环境的保护并不是为了阻止开发人员的工作，而是在适当的地方应用安全控制技术，如身份验证等来确保基础设施、整体环境的安全可靠，为开发人员提供一个同时兼顾安全性与可用性的开发环境，降低设备的安全风险。

原则 5 – 保护代码库

• 代码库能够极大地方便对代码的集中管理，因此如何确保使代码库始终处于安全的状态也就变得非常重要

• 访问凭据的泄露或者丢失都有可能使得攻击者在我们不知道的情况下，对我们的代码库进行修改

• 但是，我们不能因为存在被攻击的风险而不使用代码库，我们需要采取适当的安全措施，比如密钥、权限的管理，来保障它的安全访问，最大化利用代码库所带来的好处。

原则 6 – 保障构建和部署流水线安全

• 持续集成、持续部署的现代化方法，对于常规的代码提交，能够以自动化的方式触发构建，并进行相应的安全测试，最大限度地减少手动操作

  • 在通过安全测试之后也允许进行常规生产部署，从而极大地提高实际开发、部署的效率，也避免了可能的人为操作失误。

• 为了确保这种自动化的稳定执行，我们更应该重视整个流水线的安全稳定。我们必须确保使用的构建和部署工具不会破坏代码的完整性，并严格控制进入流水线中的代码来源，在完成变更之前不能绕过流水线中设置的安全流程

• 为了追求快速的集成和部署，我们进行的安全控制手段也绝不能阻碍流水线推进的进程，这就要求我们根据项目的实际要求，达到一种安全与效率平衡

原则 7 – 持续测试安全性

• 执行全面的安全测试对于检测和修复常规安全漏洞是非常重要的，它能够帮助我们获得信心，保障我们开发的代码可以按照预期的方向继续运行

• 自动化的安全测试能够帮助我们减少重复性工作的负担，但与此同时，我们也不能放弃手动测试的形式。我们仍然需要就那些细微和不常见的漏洞进行手动测试，或者根据系统特性进行针对性的手动测试

• 手动测试的代价较为昂贵，在进行手动测试之前，我们必须保障进行了相应的自动化测试，从而有效利用两种不同的测试方式，保障测试结果的可靠，多方位确保产品的安全性

原则 8 – 为安全缺陷制定计划

• 在为安全缺陷制定计划之前，我们必须要承认，所有的代码都容易受到安全漏洞的影响，所有的软件也都有可能存在漏洞

• 为尽可能避免已存在漏洞的不良影响，我们需要通过建立一个捕获和管理这些漏洞的体系，来追踪代码中可能存在的已识别过的漏洞，并反馈到测试过程中，避免在今后开发的产品中出现相同的漏洞威胁

DevSecOps典型实践

DevSecOps原则揭示了DevSecOps的基本思想以及核心理念，但是如何通过具体实践将这些原则落实到日常的开发和运维活动中，目前仍然是一个业界公认的难题。

作为一个新的趋势，DevSecOps领域缺少权威性的实践指南，大部分企业仍然处于对DevSecOps实践的探索阶段。在这样一个大环境下，我们很难给出一份普适性的DevSecOps实践指导，因此我们将对现有的一些DevSecOps典型实践进行整理，并将其分为阶段实践和通用实践

DevSecOps阶段实践

计划阶段

• 安全知识管理：安全知识管理要求组织在管理显性知识的时候加入信息安全的知识体系。

• 安全需求工程：DevOps对安全需求工程提出了更多响应速度上的要求。

• 固有风险评估：风险评估的目的在于识别威胁(Threat)、判断威胁转变成现实可能带来的影响以及判断这种转变的可能性。

• 威胁建模：威胁建模是一种用来识别、量化并正确应对系统所面临的威胁的结构化方法。

创建阶段

• 开发环境扫描：为了始终保障开发环境本身的安全可靠，我们需要对开发环境进行一定的安全扫描工作 。

• 开源组件安全扫描：我们需要通过合适的安全扫描工具，如FOSSID、BlackDuck等，来对项目中使用的开源组件进行安全扫描 。

• 容器安全扫描：容器安全扫描保障的是镜像源和镜像文件本身的安全。

• 集成安全插件：为及时发现自身开发的代码中的安全问题，我们鼓励开发人员在集成开发环境中安装统一的安全插件。

• 安全框架：使用全面的安全框架能够很好地处理常见的安全问题，能够极大地提高开发人员的开发效率和编码质量。

• 代码审查：一般是通过人工审阅的方式来查看提交的代码是否合乎公司的代码规范，是否功能齐全，是否使用了危险函数，是否考虑到安全编码等相关问题。

• 编码规范：趋于一致的代码风格反而会有助于公司进行代码审查，来降低隐藏在高复杂度背后的漏洞风险，也能够提高代码的可读性和健壮性。

• 可重复性构建：相同的源代码在经过两次编译后，应当能够始终输出比特位相同的二进制，这对于我们确保源代码到二进制的过程中没有被中途篡改，具有重要意义。

验证阶段

• SAST：Static Application Security Testing，即静态应用程序安全检测，是进一步加强代码安全的手段之一。

• DAST：Dynamic Application Security Testing，即动态应用程序安全检测。

• IAST：Interactive Application Security Testing，即交互式应用程序安全检测，IAST分为主动IAST和被动IAST。

• TDS：Test Driven Security，即测试驱动安全，是由Mozilla提出的。TDS主张将安全测试集成到交付管道中，是验证系统、网络和服务是否符合安全策略的过程。

预生产阶段

• 渗透测试：渗透测试是从攻击者的视角出发，通过模拟恶意黑客的进攻手段对系统进行攻击，主动去发现系统中存在的安全隐患和弱点的一种测试方法 。

• 模糊测试：模糊测试是一种向系统提供非预期的随机输入，并监视可能发生的异常结果的自动化技术。

• 混沌工程：混沌工程是一门在生产中对软件系统进行试验的学科，其目的是建立对系统抵抗动荡和意外情况能力的信心。该方法允许在生产中 随机关闭服务、模拟网络故障等多种手段来测试系统的弹性恢复能力， 以保证系统在部分节点故障的情况下，仍然能够提供高质量的服务。

发布阶段

• 强化云部署：DevOps与云技术结合得愈加紧密，在多云环境中进行安全 部署仍然需要考虑很多方面的问题，比如，如何在确保安全的情况下保障计算资源的高可用、如何实现相对均衡的负载、如何对存储资源进行合理分配等等。

• 添加数字签名：在发布软件包之前，都应该为其添加数字签名，以增加该软件的可信度和公信力。

• 容器加固：在确保容器镜像来源和镜像内容本身的安全可靠之后，容器安全还需要其他的加固保护措施，其目的主要是为了减小潜在的攻击面。

预防阶段

• 数字签名检查：在使用相关应用或者文件前，我们应当检查它们是否含有数字签名。

• 证书完整性验证：数字证书由受信任的第三方颁发，用于验证证书持有者的身份。

• 敏感信息保护：大多数应用系统在正常工作时需要访问敏感信息，而这些敏感信息如果不加以管理和保护，可以在互联网上肆意传播，这无疑会大大增加系统的安全漏洞风险。

• 安全漏洞修复计划：组织内应该具备这样一个流程，专门用于支持安全漏洞的确认以及采取相应补救措施，从而达到持续保护整个应用系统的安全性能的目的。

检测阶段

• 欺诈检测：欺诈问题涉及多个行业，据不完全统计，每年因被欺诈而损失数亿美元。

• 合规监控：合规监控是评估我们对公司政策和程序的遵守程度，这些政策和程序控制着对业务构成合规风险的活动，并帮助业务在持续的基础上有效地管理风险。

• 入侵检测：入侵检测系统是一种检测网络流量以发现可疑活动，并在发现此类活动时发出警报的检测系统。

• 红蓝对抗：红蓝对抗是在了解企业实际安全状况的基础上，针对企业重要的核心业务模拟真实的网络攻防场景，从而揭示系统中实际存在的脆弱环节，主动提升企业自身的安全能力。

响应阶段

• 问题跟踪：问题跟踪系统是一种软件应用程序，它允许企业记录和跟踪计算机系统用户识别的每个问题或“问题”的进展，直到问题得到解决。

• 应用屏蔽：应用屏蔽技术是一项修改应用程序的二进制代码的技术，用以加强应用程序抵御入侵、篡改和逆向工程的能力。使用应用屏蔽技术可以很好地保护应用软件的资产安全，防止出现盗版、数字信息盗窃等情况。

预测阶段

• 舆情监控：在实际应用正式发布前，由于时间要求、测试资源限制等因素，我们很难测试出全部的安全威胁。很多被忽视的安全漏洞，往往是在生产环境下由用户发现的，因此企业应当密切关注各大网站、各大论坛讨论的安全问题和安全动态，在可能的安全漏洞被利用之前，尽快完成相应的检查和修复工作。

• 漏洞智能分析预测：对特定的软件系统使用漏洞智能分析技术，我们一般需要提取出漏洞的基本特征，并使用机器学习方法进行建模、训练，再对系统中潜在漏洞进行预测。

调整阶段

• 控制技术债务：技术债务是指在进行软件开发时，开发团队从短期效应的角度选择了易于实现的解决方案而导致的额外的返工成本。技术债务的不断积累，会严重阻碍系统长期的可扩展性和安全性，并使得公司需要花费更多的时间来解决这些债务。

• 调整安全机制：系统的整体运行应当具备动态调整功能，管理人员可以根据实际业务目标或者资源限制等，根据既定的优先级，对整个系统的安全机制做出动态的调整。

DevSecOps通用实践

通过阶段实践，可以在DevOps的各个阶段中集成安全性实践，从而实现“安全左移”，帮助组织更早更快地发现和解决安全问题。然而DevSecOps的落地并不只是体现在对原有DevOps阶段的改进，它还要求组织在内部建立一种安全文化，使得开发、运维和安全团队能够高效地协同工作，实现快速、安全的产品交付。为实现这一目标，组织需要通过一系列实践调整自身的组织结构和工作流程，由于这些实践的适用范围并不局限于软件开发生命周期中的某个阶段，我们将其统称为通用实践。

协作实践

• 开发/运维人员安全培训：DevSecOps要求团队中的每一个成员都需要具备一定的安全意识。

• 任命DevSecOps团队负责人：任命一些DevSecOps的负责人来推动项目的进行。

• 安全责任共享：安全是整个IT团队每个人的责任。

• 常用工具共享：在大多数情况下，开发、运维和安全人员很少使用相同的工具， 这使得他们相互之间难以高效地进行协作。

• 建立知识共享体系：知识共享是消除不同部门之间的分歧的有效手段之一。

过程实践

• 创建安全反馈循环：正如CI/CD可以通过持续测试和建立反馈循环更早更快地发现并处理软件产品中的Bug以提高软件质量，安全反馈循环的建立也可以帮助软件开发团队高效地处理安全问题。

• 事件管理：DevOps中提出了智能运维的理念，使用脚本化、自动化的方式来处理一些重复出现的常见运维问题，DevSecOps对这一理念在安全领域进行了拓展，即对于安全事件采用标准化的方式进行响应。

• 变更管理：变更管理包括了所有与应用程序和平台本身的版本控制相关的标准和规范，对代码的任何更改在部署到生产环境之前都需要通过变更管理进行审查和批准。

DevSecOps相关标准

目前学术界和工业界对于DevSecOps的研究仍然处于探索阶段，还没有正式的DevSecOps标准出台，因此这里主要介绍一些与DevSecOps相关的领域中常用的标准。

这些标准能够为DevOps组织选择安全实践提供指导，部分标准中提出的度量标准有助于组织衡量自身生产流程以及最终产品的安全性。

相关标准

• BS 10754 ：由英国标准协会（British Standards Institution，BSI）发行

• NIST SP 800系列标准：是美国国家标准与技术研究院（National Institute of Standards and Technology）发布的一系列关于信息安全的指南。

• GDPR：即通用数据保护条例（General Data Protection Regulation），该条例由欧盟发布，其前身为欧盟在1995年制定的《计算机数据保护法》。

• GB/T 35273个人信息安全规范：本标准针对个人信息面临的安全问题，根据《中华人民共和国网络安全法等相关法律，规范个人信息控制者在收集、存储、使用、共享、转让、公开披露等信息处理环节中的相关行为，旨在遏制个人信息非法收集、滥用、泄漏等乱象，最大程度地保障个人的合法权益和社会公共利益。2020年10月施行。

• CSA云计算关键领域安全指南： CSA（Cloud Security Alliance，云安全联盟）在2009年出版了第一版的《云计算关键领域安全指南》，在当时缺乏业界广泛认可和普遍遵从的国际性云安全标准的形势下，该指南提出了一些高屋建瓴而又不乏具体的策略和实施建议。

DevSecOps的裨益

• 应用DevSecOps可以提高软件组织的安全开发效率，让他们有更多的时间和预算来实现安全生产环境的目标。

• DevSecOps提倡一种安全文化，它的应用在开发人员、运营人员和安全人员之间架起了桥梁。

• DevSecOps的应用可以提升软件组织的安全成熟度以及其开发的软件质量。使软件组织的业务更活跃以及使软件组织的内部更安全等。

DevSecOps的挑战

• 如何掌握DevOps的敏捷性与安全之间的平衡是一个需要解决的重要挑战。

• 软件组织缺乏DevSecOps安全专家 。

• DevSecOps可能会要求改变一些流程，团队和专家需要调整自己以适应新的组织结构，需要开发新的技能，需要集成新的工具，这里最大的问题是，如果没有适当的监督，团队和管理层可能会做出危险的选择 。

• DevOps是云的支持者，使用容器是一个普遍现象，这使得安全团队需要有更多的安全方面的考虑 。

• 缺乏自动化、集成的安全工具也是一点挑战，传统的安全工具缺乏自动化安全管理和集成到 DevOps所需的API。

• DevSecOps虽然可以为组织节省金钱与时间，从而降低预算，但是在初始阶段，它需要更多的预算来集成安全性，这方面给一些软件组织造成困扰 。

DevOps导论 - 第十讲 - AIOps和可观测性

从AIOps到可观测性

AIOps是人工智能运维的简称，是一种利用人工智能和机器学习技术来优化IT运维的方法。AIOps可以通过以下方式提高IT运维效率

• 自动化监控：AIOps可以自动监控IT基础架构，从而减少手动监控的需要

• 自动化分析：AIOps可以自动分析监控数据，从而识别潜在的问题并提供解决方案。

• 自动化管理：AIOps可以自动管理IT基础架构，从而减少手动干预的需要。

• 自动化响应：AIOps可以自动响应事件，从而加快故障排除和修复的速度。

• 自动化优化：AIOps可以自动优化IT基础架构，从而提高性能并降低成本

可观察性是指在分布式系统中，通过收集、分析和可视化数据来了解系统的运行状况和性能

• 更快的故障排除：帮助IT团队更快地识别和解决潜在的问题

• 更好的性能优化：帮助企业更好地理解其IT基础架构，并识别潜在的性能问题

• 更好的容量规划：帮助企业更好地了解其IT基础架构的容量需求

• 更好的安全性：帮助企业更好地了解其IT基础架构的安全状况

• 更好的用户体验：帮助企业更好地了解其用户体验

AIOps可以通过自动化监控、分析、管理、响应和优化IT基础架构来提高IT运维效率。而可观察性则可以帮助企业更好地了解其IT基础架构的运行状况和性能，从而更好地利用AIOps提供的自动化功能

面临挑战

服务数量庞大

服务/数据异构

调用关系复杂

动态变化

三源合一的可观测性

Metrics（指标）

基本原理

• 异常呈现在关键指标上的重复性的影响

研究思路

• 构建模型

• 比较分析

Tracing（链路）

基本原理

• 链路信息包含服务与服务之间的关联信息，因而可以通过这种关联关系寻找根因

研究思路

• 使用链路的信息关联系统中的各类实体，通过图算法模拟故障传播的过程，从而定位异常实体

主要问题

• 如何获取或构建合理范围的链路信息

• 如何模拟异常传播的非确定过程

• 微服务的数量增加对算法的效率和性能的影响

Logging（日志）

研究思路

• 通过基于规则或自然语言处理的方法对日志信息进行分类，从而发现包含异常的日志信息

基本原理

• 日志相比于指标数据和链路数据

• 包含了更丰富的信息包含异常的日志往往具有一定的特征或模式

主要问题

• 日志天然具有异构特征

• 日志信息的不确定性大，无法避免会产生信息的缺失

• 日志仅记录事件，难以确定根本原因

Metrics + Tracing（指标+链路）

基本原理

• 通过微服务的调用拓扑关系，结合对应指标信息，捕捉服务链路上的异常，定位异常实体

主要问题

• 底层微服务数量众多

• 众多的底层微服务拥有复杂的关联关系

• 调用时间等指标和调用路径存在依赖关系

Tracing + Logging（链路+日志）

研究思路

• 按时间区间关联指标与日志

主要问题

• 仅对链路和日志信息关联，并未对关联后数据的分析相关研究不多

• 日志信息仍然存在异构等问题，对其分析仍然大量依赖人工和人员经验

Metrics + Tracing（指标+日志）

基本原理

• 结合指标中的调用链信息和日志中的事件可以更加精确发现和诊断问题

主要问题

• 日志中记录的信息不全面

• 部分错误不会记录在日志中

• 指标如何与日志信息进行关联

Metrics + Tracing + Logging（指标+链路+日志）

研究思路

• 利用图将三源数据聚合，并使用基于图的算法或机器学习进行根因定位和分析

主要问题

• 海量异构数据

• 数据关联困难

典型步骤

• 不同的运维数据之间的关联关系天然可以利用图进行表示

• 图结构表示异常传播的过程

• 对图进行分析的过程模拟了人工定位异常原因的过程

  • 利用蒙特卡洛：模拟人工排查的过程
  • 利用历史数据：模拟查询知识库的过程

Docker容器技术基础

Docker简介

什么是 Docker

Docker 是 Docker 公司开源的一种最流行的容器实现方案，极大方便了应用服务部署。其容器技术已经成为容器行业的技术标准

Docker 可以将应用、配置和环境打包，形成一个独立的类似于 iOS APP 形式的「应用」。此「应用」可以直接分发到任意一个支持 Docker 的环境中，通过简单的命令即可运行

• Docker 的用途

  • 提供一次性的环境
    • 比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。
  • 提供弹性的云服务
    • 因为 Docker 容器可以随开随关，很适合动态扩容和缩容。
  • 组建微服务架构
    • 因为 Docker 容器非常地轻量，在一台机器通过运行多个容器就可以跑多个服务。

集装箱对 Docker 的启发

环境配置难题：

• 用户计算机的环境都不相同，你怎么知道自家的软件，能在哪些机器跑起来？

• 用户必须保证两件事：操作系统的设置，各种库和组件的安装。只有它们都正确，软件才能运行

Docker 对世界的改变：

• 容器技术跟集装箱一样，给云计算行业带来了极大的技术变革，快速改变了公司和用户创建、发布、运行分布式应用的方式

• Docker 使得容器化技术使用非常方便，极大地推进了容器行业的发展与容器技术标准化

  • 容器镜像格式标准
  • 容器运行标准化
  • 可以让开发者打包他们的应用及其依赖的环境到一个容器中，然后快速部署到任何一台Linux机器上。

Docker 的口号： Build Once，Run Anywhere

Docker 的特点

• Docker 的优势

  • 环境一致性 Build Once，Run Anywhere
  • 资源独立与隔离
  • 轻量化

• 容器与虚拟机对比

特性	虚拟机	容器
隔离级别	系统级	进程级
隔离技术	Hypervisor 虚拟化整套硬件环境	Cgroups + Namespace 虚拟化进程运行环境
系统内核	独立内核	共享内核
性能开销	2~5%	< 0.5%
启动时间	分钟级	秒级
磁盘占用	GB级	MB级
部署密度	单机一般几十个	单机支持上千个容器

• 容器的特点

  • 容器是自包含的
  • 容器是可移植的
  • 容器是相互隔离的
  • 容器是轻量级的

• 容器与虚拟机使用上的差异

  • 一个容器中只干一件事
  • 容器的使用观念是我要启动一个 APP，而 VM 使用观念是我需要一个 OS
  • 容器通常是短暂性的，频繁更新的
  • 更新整个容器而非到容器中单独更新某个组件
  • 容器不需要热迁移
  • 容器镜像通常很小（相比于VM），分发十分快速
  • 创建容器非常方便，而创建VM相对复杂。
  • 容器与 host 共享内核
  • 容器中没有 systemd，1号进程就是应用进程本身

Docker入门

docker基础概念

从镜像仓库中拉取到容器镜像，使用容器镜像在宿主机上运行容器。

• 宿主机（Host） - Docker所在的物理机，是容器运行的系统环境

• 镜像 （Image） - 镜像相当于一个程序模板，通过这个模板可以启动多个相似的容器

  • 完整的镜像名由（远端仓库地址、项目、 镜像名 组成）:（标记镜像的版本）两部分组成

• 容器（Container） - 容器是docker运行的最小对象单元，是通过镜像实例化出来的一个运行中的对象

• 仓库（Registry） - 镜像仓库是集中式的管理、存储镜像的仓库，类似Git管理代码的仓库一样，可以管理多版本的镜像

常用命令

• 列出镜像：docker images

• 拉取镜像到本地：docker pull [OPTIONS] NAME[:TAG|@DIGEST]

• 给镜像打 tag：docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

• 上传本地镜像：docker pull [OPTIONS] NAME[:TAG|@DIGEST]

• 删除本地镜像：docker rmi [OPTIONS] IMAGE [IMAGE…]

Docker	Git
镜像仓库（docker-registry、harbor）	代码仓库（github、gitlab）
用户（user）	用户（user）
仓库（repository)	仓库（repository)
镜像（image）	分支（branch）
镜像层（layers）	代码提交（commits）
docker pull	git pull
docker push	git push
docker commit	git commit
docker diff	git diff
docker history	git log
镜像表示：registry.transwarp.io/demo/centos:latest	代码仓库表示：https://gitlab.transwarp.io/demo/centos.git