Docker容器概念介绍

docker定义

根据官方的定义，Docker是以Docker容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员设计的，用于构建、发布和运行分布式应用的平台

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

docker 图标表示着一艘巨轮承载着多个集装箱货物，亦可理解为轮船就是docker，集装箱就是一个个容器

docker解决了什么问题

1. 解决了应用程序本地运行环境与生产运行环境不一致的问题
2. 解决了应用程序资源使用的问题，docker会一开始就为每个程序指定内存分配和CPU分配
3. 让快速扩展、弹性伸缩变得简单

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

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

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

docker技术边界

docker是容器化技术，针对的是应用及应用所依赖的环境做容器化。遵循单一原则，一个容器只运行一 个主进程。多个进程都部署在一个容器中，弊端很多。比如更新某个进程的镜像时，其他进程也会被迫 重启，如果一个进程出问题导致容器挂了，所有进程都将无法访问。再根据官网的提倡的原则而言，容器 = 应用 + 依赖的执行环境而不是像虚拟机一样，把一堆进程都部署在一起。

docker给我们带来了哪些改变

优势

1. 软件交付方式发生了变化
2. 替代了虚拟机
3. 改变了我们体验软件的模式
4. 降低了企业成本
5. 促进了持续集成、持续部署的发展
6. 促进了微服务的发展

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

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

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

docker和虚拟机的区别

1. vm（虚拟机）与docker（容器）框架，直观上来讲vm多了一层guest OS，同时Hypervisor会对硬件资源进行虚拟化，docker直接使用硬件资源，所以资源利用率相对docker低
2. 服务器虚拟化解决的核心问题是资源调配，而容器解决的核心问题是应用开发、测试和部署。
3. 容器技术严格来说并不是虚拟化，没有客户机操作系统，是共享内核的。

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

docker基本架构

基本架构图

涉及概念

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

1. 镜像（Image）：Docker 镜像是用于创建 Docker 容器的模板，比如 Ubuntu 系统
2. 容器（Container）：容器是独立运行的一个或一组应用，是镜像运行时的实体
3. 客户端（client）：Docker 客户端通过命令行或者其他工具使用 Docker SDK (https://docs.docker.com/develop/sdk/)) 与 Docker 的守护进程通信
4. 主机（host）：一个物理或者虚拟的机器用于执行 Docker 守护进程和容器
5. 注册中心（Registry）：Docker 仓库用来保存镜像，可以理解为代码控制中的代码仓库。Docker Hub(https://hub.docker.com)) 提供了庞大的镜像集合供使用。
6. Docker Machine：Docker Machine是一个简化Docker安装的命令行工具，通过一个简单的命令行即可在相应的平台上安装Docker。

Docker的应用场景

本文参考https://blog.csdn.net/jianfeng123123/article/details/128164149

在某次以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了？

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

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