docker: 基本概念理解

收集了一些对docker相关概念比较到位的解释
1.物理机和虚拟机
2.隔离技术
3.云计算和微服务
4.容器，镜像和仓库

物理机和虚拟机

• 物理机：客观存在的真实服务器，能看的到、摸得着的。通常也被叫做宿主机，因为虚拟机“寄宿”在上面。

• 虚拟机：运行在物理机上的，看不见、摸不到、但可以通过网络访问的服务器。通常也叫云服务器。

• 物理硬件：组成物理机的硬件。

• 虚拟硬件：组成虚拟机的硬件，通过虚拟化技术获得。

• OS：Operating System，操作系统。

虚拟机的优点

• 可以把资源分配到不同的虚拟机，达到硬件资源的最大化利用

• 与直接在物理机上部署应用，虚拟更容易扩展应用。

• 云服务：通过虚拟机虚拟出不同的物理资源，可以快速搭建云服务。

虚拟机的不足之处

虚拟机的不足之外来自于对物理服务器资源的消耗，当我们在物理服务器创建一台虚拟机时，便需要虚拟出一套硬件并在上面运行完整的操作系统，每台虚拟机都占用许多的服务器资源。

虚拟机技术开启了云计算时代，Docker，作为下一代虚拟化技术，正在改变我们开发、测试、部署应用的方式。

在几十台服务器里部署同一个程序，传统方式比较慢且麻烦（考虑到不同机器的环境不一致）。Docker image可以快速移植部署，且启动快而稳定，要部署程序的机器再多也不怕了，大大提高了效率。

Docker是在操作系统进程层面的隔离，而虚拟机是在物理资源层面的隔离。

首先，虚拟机的隔离程度比Docker更高，一台物理机的硬件资源被分给多台虚拟机使用，虚拟机与宿主机的接口非常有限，而且虚拟机崩溃一般不会导致宿主机崩溃。
而Docker不是绝对的物理隔离，多个容器是共用宿主机的内核的，如果容器里的应用导致Linux内核崩溃，那么整个系统都会崩溃，这是共用内核导致的固有缺陷。

分配给容器的资源也要加以限制。

Docker解决了程序的环境依赖问题

Docker image包含了程序需要的依赖服务，配置，代码和运行环境，具有高度的可移植性，确保了开发到正式环境的一致性。

以python项目为例，有些时候需要限制模块的版本，如果项目多起来，在同一环境中运行，就可能在同一个模块的版本依赖上有不同的需求。Docker image包含运行环境与配置，避免为了每一个项目搭建一个新的环境导致的耗费人力物力。

容器 + 全虚拟化

在虚拟机中运行容器，容器崩溃如果导致内核崩溃也只是发生在虚拟机中，也不会对宿主机造成什么影响。
这种部署一般应用于安全需求高的场景：如云服务。

微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。

微服务的出现就是用来解决这个问题的——把一个庞大的单体应用横向切割成若干个微服务，每个微服务只做一件事，但它仍然包含展现层、应用层和数据层。微服务单独运行，对外暴露 API 接口供其他程序调用。所以说，微服务侧重于替换企业内部的大型单体应用，以便于应用程序的可持续演进（持续代码完善、持续版本升级、持续缩放部署、DevOps）。

结合Docker的优点以及微服务的需求，也就不难得到基于Docker的微服务架构产生的原因了。

容器，镜像和仓库

如果说镜像是类，那么容器就是类的实例化后的对象。

• 镜像是一个只读的模板，一个独立的文件系统，包括运行容器所需的数据。
  docker镜像实际上是由一层一层的系统文件组成，这种层级的文件系统被称为UnionFS( Union file system 统一文件系统)，镜像可以基于dockerfile构建，dockerfile是一个描述文件，里面包含了若干条密令，每条命令都会对基础文件系统创建新的层次结构。

• 容器在启动的时候创建了一层可写层次作为最上层。

docker run 命令先是利用镜像创建了一个容器，然后运行这个容器。这里隐藏了docker create和docker start两个命令。

在编写Dockerfile来告诉docker我们该如何构建这个镜像时，是基于一个基础镜像的，本地找不到该基础镜像则会去远端拉取。镜像打包制作完成后，需要docker push到镜像仓库，后续有需要再从仓库docker pull下来。

镜像仓库也分公有（如dockerhub）和私有（如harbor）。