【云驻共创】Docker是什么？有哪些应用场景？

前言

随着云计算的蓬勃发展，众多的应用技术也早已形成一整套体系与架构，如今，听到最多的，非云原生莫属。而容器化，微服务化则为云原生的一大特征，并在云原生开发中占据了核心位置。

此处引用CNCF（云原生计算基金会）关于云原生的定义：

云原生定义（Cloud Native Definition）

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

不难看出，作为云原生代表技术，容器技术是重中之重。如果用先后顺序来说，是先有容器，再有后面的微服务、服务网格，容器可以说是它们底层的技术支撑，容器更是云计算、微服务等诸多软件业界核心技术的共同基石。

那，我们应该怎么理解容器，而容器又是什么呢？

---

容器技术的起源

在很多互联网公司的日常工作中， 一款核心产品从需求调研，到开发设计，再到上线运行和后续运营，离不开4类人的参与：产品经理、开发人员（程序员）、测试（测试工程师）、运维（运维工程师）。产品经理做整个产品的规划和需求分析设计等，开发人员负责按需求编写代码，测试负责功能测试并反馈BUG等，运维则负责部署上线和产品的后续运维。

最经典的扯皮战争：产品规划了一个“金鱼哥看金鱼”的APP，把需求给到开发；开发从头到尾搭建好整套运行环境，开始写代码并把成果交给测试的同事进行测试；测试的同学在测试环境中按开发的指示部署好环境，但期间出现问题，开发此时一句：“在我这边运行可是正常的，你检查一下是不是哪里没弄好。”经过几番周折，测试同事也终于部署好环境，告知产品，可上线了，之后产品告知运维同学，可进行后续上线了；运维的同学又要为了这套产品重新部署好环境，在部署应用上线的时候突然各种报错，什么error，什么OOM各种信息出现，此时，开发，测试都凭借“演员的自我修养”，也一句：“在我这边运行可是正常的，你检查一下是不是哪里没弄好。”从此上演着各种恩怨情仇。

此处不难看出，在搭建环境方面，不同的技术人员在搭建环境的时候，由于各种技术水平参差不齐和习惯的不同，难以保证共同环境的统一，也浪费时间和效率低下。最经典的例子是很多技术人员在Windows机器上进行开发与调试，上线的时候则需要部署到Linux系统上，很容易由于环境不同而出现各种部署问题。更不用说要做应用迁移，更是一件麻烦事。

“要把一个不知道打过多少个升级补丁，不知道经历了多少任管理员的系统迁移到其他机器上，毫无疑问会是一场灾难。”（引用自《Trash Your Servers and Burn Your Code》）这个在现时年代，也经常遇见，也让运维人员成为历史上的“背锅侠”。

有了问题，后面也诞生了解决问题的方法，那就是容器技术。

---

什么是容器？

容器，英文container的意思，其实，还有集装箱的意思。

集装箱，英文名container。是能装载包装或无包装货进行运输，并便于用机械设备进行装卸搬运的一种成组工具。

集装箱最大的成功在于其产品的标准化以及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化，并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多式联运相配套的物流系统，这的确堪称人类有史以来创造的伟大奇迹之一。（摘自百度百科）

那，技术中的容器又是什么呢？

其实，容器和集装箱的概念上很相似的。容器是一个标准化的软件单元，它将代码及其所有依赖关系打包，以便应用程序从一个计算环境可靠快速地运行到另一个计算环境。（摘自Docker官网）

这不就可以解决刚才上面所说的恩怨情仇吗？

容器是一种更轻量、更敏捷的虚拟化实现方式，它和虚拟机具有相似的资源隔离和分配优势，但功能不同，容器更便携、更高效；我们也会叫做“操作系统虚拟化”（containers virtualize the operating system instead of hardware）。它不需要用到Hypervisor，也没有跑在Hypervisor上“臃肿”的操作系统（Guest OS），因此容器的部署效率得到了很大的提升。

容器可以使应用程序在几乎任何地方以相同的方式运行。技术人员只要创建并测试好的容器，无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。

---

容器与虚拟机

容器是应用层的抽象，它将代码和依赖项打包在一起。多个容器可以在同一台机器上运行，并与其他容器共享操作系统内核，每个容器在用户空间中作为独立进程运行。与 VM 相比，容器占用的空间更少（容器映像的大小通常为数十MB），可以处理更多应用程序并且需要更少的 VM 和操作系统。

虚拟机 (VM) 是物理硬件的抽象，可将一台服务器变成多台服务器。管理程序允许多个虚拟机在单台机器上运行。每个 VM 都包含操作系统、应用程序、必要的二进制文件和库的完整副本——占用数十 GB。VM 的启动速度也可能很慢。

由于所有的容器共享同一个 Host OS，这使得容器在体积上要比虚拟机小很多。另外，启动容器不需要启动整个操作系统，所以容器部署和启动速度更快，开销更小，也更容易迁移。

• 传统部署时代：资源分配冲突、资源利用效率低下
• 虚拟化部署时代：提高资源的高效利用、灵活的应用访问
• 容器部署时代：应用与底层基础架构分离，实现更灵活的业务管理。

---

为什么需要容器？

上面的论述中已经有了类似的说明，如果再用一句话来概括，那就是：容器使应用具备了超强的可移植能力。

如今的应用系统需要使用多种服务（MQ，缓存，微服务等）来进行构建和组装应用，而且这些应用会部署到不同的环境中（虚拟主机，私有云，公有云，混合云等），在以往如果要迁移这些应用是一件非常麻烦的事情。因为主流的软件部署过程是由管理员（运维，系统管理员，开发人员等）编译或下载好二进制安装包，根据软件的部署说明文档准备好正确的操作系统、第三方库、配置文件、资源权限等各种前置依赖以后，才能将程序正确地运行起来。

但容器的出现，改变了现状，容器让软件分发部署过程从传统的发布安装包或人工部署转变为直接发布已经部署好的、包含整套运行环境的容器镜像。只要我们直接运行容器镜像，就可以运行对应的环境。

容器的灵活性和可移植性优势使得它非常完美地契合了混合云部署的需要，使得我们产品团队的成员（开发，测试，运维）掌握更多的灵活性来处理和面对复杂且多环境部署的需要。

---

容器的优势

容器技术是虚拟化、云计算、大数据之后的一门新兴的并且是炙手可热的新技术，容器技术提高了硬件资源利用率、 方便了企业的业务快速横向扩容（可以达到秒级快速扩容）、 实现了业务宕机自愈功能（配合K8S可以实现），这是一个对于 IT 行业来说非常有影响和价值的技术。

---

对于开发人员 - Build Once, Run Anywhere

容器意味着环境隔离和可重复性。开发人员只需为应用创建一次运行环境，然后打包成容器便可在其他机器上运行。另外，容器环境与所在的 Host 环境是隔离的，就像虚拟机一样，但更快更简单。

对于运维人员 - Configure Once, Run Anything

只需要配置好标准的 runtime 环境，服务器就可以运行任何容器。这使得运维人员的工作变得更高效，一致和可重复。容器消除了开发、测试、生产环境的不一致性。

---

Docker是什么？

Docker是一个开源的应用容器引擎，是容器技术的一种，采用Go编程语言编写。虽然 Docker把容器技术推向了巅峰，但其实，还有其他容器技术，比如LXC、CoreOS 的RKT等，只是Docker是最知名和运用最广泛的一个。

有个有趣的事是：Docker的Logo，就是一堆集装箱，不就是喻意“Container”吗？

既然Docker是容器技术的一种，那他当然拥有容器的各种特征和优势，用Docker官网的概述：Docker 是一个用于开发、发布和运行应用程序的开放平台。Docker 使您能够将应用程序与基础架构分离，以便您可以快速交付软件。使用 Docker，您可以像管理应用程序一样管理基础设施。通过利用 Docker 快速交付、测试和部署代码的方法，您可以显着减少编写代码和在生产环境中运行之间的延迟。

Docker 提供工具和平台来管理容器的生命周期：

• 使用容器开发应用程序及其支持组件。
• 容器成为分发和测试应用程序的单元。
• 准备就绪后，将应用程序部署到生产环境中，作为容器或编排的服务。无论生产环境是本地数据中心、云提供商还是两者的混合，这都是一样的。

Docker镜像在Docker Engine上运行时变成容器。可用于 Linux 和基于 Windows 的应用程序，无论基础设施如何，容器化软件将始终以相同的方式运行。容器将软件与其环境隔离开来，并确保尽管存在差异，但它仍能统一工作。

• 标准： Docker 为容器创建了行业标准，因此它们可以在任何地方移植。
• 轻量级： 容器共享机器的操作系统内核，因此每个应用程序不需要操作系统，从而提高服务器效率并降低服务器和许可成本。
• 安全： 应用在容器中更安全，Docker 提供业界最强的默认隔离能力。

最后用一句话概括：Docker是解决了运行环境和配置问题的软件容器，方便做持续集成并有助于整体发布的容器虚拟化技术。

---

Docker的应用场景

对Docker有了初步的了解后，那这个蓝鲸鱼可以游去哪里，又有怎样的游泳方式呢？

在某次以Docker为中心的技术大会中，有一张很经典的图片，介绍了常用的8个Docker的真实使用场景，分别是简化配置、代码流水线管理、提高开发效率、隔离应用、整合服务器、调试能力、多租户环境、快速开发。

这里，以此为参考，讲述Docker的应用场景。

1. 多版本多种类软件与系统的测试

这个对于测试和运维的同学应该最深刻，在各种软件不同版本的兼容性需求中进行各种测试，那如何快速部署好所需要的环境呢？

例如以下的各种需求：

• 需要一个CentOS7的系统做测试。
• 需要一个CentOS8的系统做测试。
• 需要一个Ubuntu的系统做测试。
• 需要一个Mysql5.7的DB做测试。
• 需要一个Mysql8.0的DB做测试。
• 需要一个……

曾经的我们可能千辛万苦地配置好所需要的环境，结果对方用了10分钟不到就要求更换基础环境；有些软件应用，以传统的方式来部署的话，你可能需要用半天的时间，甚至1天都还未搞完；……

曾经的我们，效率太低下了，但此时用Docker只需要几个命令，甚至半分钟不到就可以完成以上需求。

---

2. 环境一致性

这个不就可以解决本文上面所论述的有关开发与运维的恩怨情仇吗？

开发在Windows系统上编写代码，但测试和生产环境都是Linux系统，由于基础环境的不一致和个人技术习惯的问题，很容易就出现运行环境不一致的问题：应用程序在开发本地的运行环境没有问题，但到了测试或者生产环境就各种报错，那是否有方案可以统一各处环境呢？

此时的我们只需要将所部署的应用打包成容器镜像，就可以用Docker来愉快地玩耍。Docker镜像封装运行环境，一次构建，到处运行；新增的应用系统也能快速部署。

---

3. 部署分发

传统的项目部署方式是带上安装文档去到客户现场，然后进行各种安装与配置：准备好系统，安装并配置好系统运行环境，上传项目应用程序，运行，调试，之后重复各种操作。

现在的我们，只要将环境与项目程序代码封装成Docker镜像，然后带着镜像去到客户现场，在系统中安装Docker并启动，之后导入镜像就可以直接运行了，最后，准点下班。

---

4. CI/CD

CI（持续集成）/CD（持续部署、持续交付）是一个现时很火的开发模式体系理念，已经在各大企业中不断运用。CI/CD是一个周期性自动化项目测试流程，包括构建、部署、测试、发布等工作，很少需要人工干预。

而Docker天生适合CI/CD，在CI/CD中使用Docker，整个过程将变得非常简单，只要代码编写完推送到git或svn后，就可自动触发代码下载、编译并构建成Docker镜像，再替换成测试环境的容器服务，自动在Jenkins运行单元/集成测试，最后测试通过后，马上就能自动将新版本镜像更新到线上，完成服务升级（上线）。整个过程，全程自动化，一气呵成，最大程度简化了运维成本，保证线上和线下环境完全一致。

---

5. 微服务架构使用

首先，微服务的目的是有效的拆分应用，实现敏捷开发和部署。在这个云原生的年代中，微服务架构早已成熟，并已是现时为人熟知的架构。

微服务的核心价值就是拆分之后的系统能够让局部的单个服务有可能实现敏捷地卸载、部署、开发、升级，局部的持续更迭。在这方面，不刚好也是Docker容器的设计原则吗？一个容器一个服务，容器之间相互隔离，是独立的服务部署单元。

在华为《云原生2.0架构白皮书》的资料中，也阐述了云原生的技术特征之一就是容器化，微服务化。不难看出，这两者奠定了云原生的架构基础。

---

6. 弹性伸缩

在容器编排中，弹性伸缩是一大亮点功能，可以根据负载情况而进行扩容和缩容，应对高并发的场景或者以免资源的浪费。

而Docker容器快速启动的特性，正是弹性伸缩所依赖的基础，可以快速的启动几十个、上百个容器来支撑更多的并发和资源的利用率。

---

小结

通过上述的讲解，相信大家应该对容器和Docker有所了解。这只是云原生的开始，后续的学习才是戏肉。

---

题外

有很多同学会说，现在Docker不是要被淘汰了吗？那我们是不是不用继续学习Docker了？

其实不然，如果对这段历程有所了解的同学应该知道，runC和containerd这两个项目的捐赠托管是Docker，很多其他的容器运营厂商最底层的runc仍然是Docker在维护的。而K8S废弃的只是dockershim（在1.24版本正式废弃使用），但采用的容器运行时，还是containerd，而且容器镜像也是遵循OCI标准的，直白说，你使用Docker所制作的镜像是完全可以在K8S中运行。

因此，已经习惯了使用Docker的同学无需担心，可继续使用，对Docker不了解的同学，也可以进行学习。Docker目前仍然是最主流的容器引擎技术。本身也很难彻底消亡，毕竟已经形成成熟生态的镜像仓库，还有已经养成习惯的大量用户。只是在容器编排领域，Docker已经难以有一席之地，现时的Docker只会以 runC 和 containerd 的形式存续下去。

---

本文参与华为云社区【内容共创】活动第20期。

https://bbs.huaweicloud.cn/blogs/374925

任务33：Docker是什么？有哪些应用场景？