DevOps(10)

56.Docker的架构？

57.Docker镜像相关操作有哪些？

58.Docker容器相关操作有哪些？

编辑59.如何查看Docker容器的日志？

60.如何启动Docker容器？参数含义？

61.如何进入Docker后台模式？有什么区别？

62.什么是CI？

63.什么是CD？

64.什么是CI/CD管道？

65.如何理解DevOps?

56.Docker的架构？

Docker使用客户端－服务器（C/S）架构模式，使用远程API来管理和创建Docker容器。

Docker客户端（Client）：Docker客户端通过命令行或者其他工具使用Docker SDK(https://docs.docker.com/develop/sdk/)与Docker的守护进程通信。

Docker主机（Host）：一个物理或者虚拟的机器用于执行Docker守护进程和容器。

Docker包括三个基本概念：

镜像（Image):Docker镜像（Image），就相当于一个root文件系统。比如官方镜像ubuntu:16.04就包括了完整的一套Ubuntu16.04最小系统的root文件系统。

容器（Container):镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是静态的定义，容器是镜像运行时的实体。容器可以被创建，启动，停止，删除，暂停等。

仓库（Repository):仓库可看着一个代码控制中心，用来保存镜像。

57.Docker镜像相关操作有哪些？

58.Docker容器相关操作有哪些？

59.如何查看Docker容器的日志？

60.如何启动Docker容器？参数含义？

－t:在新容器内指定一个伪终端或者终端。

－i:允许你对容器内的标准输入（STDIN）进行交互

－d:后台模式

61.如何进入Docker后台模式？有什么区别？

第一种：docker attach

第二种：docker exec

注意：

我特意在容器停止状态下执行了docker exec,是让你看到docker exec是在容器启动状态下用的，且注意下错误信息；

推荐大家使用docker exec命令，因此此退出容器终端，不会导致容器的停止。

62.什么是CI？

CI的英文名称是Continuous Integration，中文翻译为：持续集成。

CI中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试进行验证。持续集成（CI）是在源代码变更后自动检测，拉取，构建和（大多数情况下）进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。CI的流程执行和理论实践让我么可以确定新代码和原有代码是否正确地集成在一起。

通俗点讲就是：通过持续集成，开发人员能够在任何时候多次向仓库提交作品，而不是独立的开发每个功能模块并在开发周期结束时一一提交。这里的一个重要思想就是让开发人员更快更频繁地做到这一线，从而降低集成的开销。实际情况中，开发人员在继承时经常会发现新代码和已有代码存在冲突。如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。当然，这里也有一些权衡，这个流程不提供额外的质量保障。事实上，许多组织发现这样的集成方式开销更大，因为他们依赖人工确保新代码不会引起新的Bug或者破坏现有代码。为了减少集成期间的摩擦，持续集成依赖于测试套件和自动化测试。然而，要认识到自动化测试和持续测试是完全不同的这一点很重要。

CI的目标是将继承简化成一个简单，易于重复的日常开发任务，这样有助于降低总体的构建成本并在开发周期的早期发现缺陷。要想有效的使用CI必须转变开发团队的习惯，要鼓励频繁迭代构建，并且在发现bug的早期积极解决。

63.什么是CD？

这里的CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment。下面我们分别来看看上面是持续交付和持续部署。

持续交付

持续交付（CD）实际上是CI的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生产环境中。成熟的持续交付方案也展示了一个始终可部署的代码库。使用CD后，软件发布将成为一个没有任何紧张感的例行事件。开发团队可以在日常开发的任何时间进行产品级的发布，而不需要详细的发布方案或者特殊的后期测试。

完成CI中构建以及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都设计测试自动化和代码发布自动化。在流程结束时，运维团队可以快速，轻松的将应用部署到生产环境中或发布给最终使用的用户。

CD集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统，可以针对构建执行一组渐进的测试套件。CD具有高度的自动化，并且在一些云计算环境中也易于配置。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。否则，将继续进入下一个测试，并在连续通过测试后自动进入下一个阶段。流水线的最后一部分会将构建部署到和生产环境等效的环境中。这是一个整体的过程，因为构建，部署和环境都是一起执行和测试的，他能让构建在实际的生产环境可部署和可验证。

持续部署

持续部署扩展了持续交付，以便软件构建在通过所有测试时自动部署。在这样的流程中，不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件，功能模块或修复补丁，并准确说明当前提供的内容。采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速的处理任何明显的缺陷。用户对无用或者误解需求的功能快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。

随着DevOps的发展，新的用来实现CI/CD流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合，包括像GitHub这样的代码仓库和Jira这样的Bug跟踪工具。此外，随着SaaS这种交付方式变得更受欢迎，许多工具都可以在现代开发人员运行程序的云环境中运行，例如GCP和AWS。但是对于一个成熟的CI/CD管道（Pipeline)来说，最后的阶段是持续部署。作为持续交付－自动将生产就绪型构建版本发布到代码存储库－的延伸，持续部署可以自动将应用发布到生产环境中。