初识Docker，概念-架构-相关术语

介绍Docker概念与平台架构，相关术语

1. Docker的历史

诞生

Docker 是Docker.Inc 公司开源的一个基于 LXC技术之上构建的Container容器引擎，基于Google 公司推出的 Go语言实现的云开源项目，诞生于 2013 年初，最初是 dotCloud 公司内部的一个业余项目。项目后来加入了 Linux 基金会，遵从了 Apache 2.0 协议，项目代码在 GitHub 上进行维护。而且居然只有 1W 行就完成了这些功能。如果想尝试一下的话可以看 官方介绍了。

 

Docker的主要目标是"Build，Ship and Run Any App,Anywhere"，也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的APP（可以是一个WEB应用或者数据库应用等等）及其运行环境能够做到"一次封装，到处运行"

 

历史发展

Docker 自开源后受到广泛的关注和讨论，以至于 dotCloud 公司后来都改名为Docker Inc。Redhat 已经在其 RHEL6.5 中集中支持 Docker；Google 也在其 PaaS 产品中广泛应用。

Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。 Docker 的基础是 Linux 容器（LXC）等技术。在 LXC 的基础上 Docker 进行了进一步的封装，让用户不需要去关心容器的管理，使得操作更为简便。用户操作 Docker 的容器就像操作一个快速轻量级的虚拟机一样简单。

Docker在2014年6月召开DockerConf 2014技术大会吸引了IBM、Google、RedHat等业界知名公司的关注和技术支持，无论是从 GitHub 上的代码活跃度，还是Redhat宣布在RHEL7中正式支持Docker, 都给业界一个信号，这是一项创新型的技术解决方案。 就连 Google 公司的 Compute Engine 也支持 docker 在其之上运行, 国内"BAT"先锋企业百度Baidu App Engine(BAE)平台也是以Docker作为其PaaS云基础。

 

Docker 的创始人 Solomon Hykes 在2017年大会上介绍，对于即将推出的 Docker 平台新版本，开发人员将能够在其工作站中的 Kubernetes 上直接进行生产应用程序的构建与测试。而运营人员则能够从 Docker 企业版中获得各种帮助，具体包括多租户安全保护，镜像扫描以及基于角色的访问控制等，同时配合 Kubernetes 或者 Swarm 在生产环境中实现应用运行。

 

Docker 从 0.9 版本开始使用 libcontainer 替代 lxc，

2017/3/3 Docker版本从1.13.*直接跳入17.03

CE和EE在各发行版的支持情况为：

Platform

Docker EE

Docker CE

Ubuntu

yes

yes

Debian

  

yes

Red Hat Enterprise Linux

yes

  

CentOS

yes

yes

Fedora

  

yes

Oracle Linux

yes

  

SUSE Linux Enterprise Server

yes

  

Microsoft Windows Server 2016

yes

  

Microsoft Windows 10

  

yes

macOS

  

yes

Microsoft Azure

yes

yes

Amazon Web Services

yes

yes

17.03与1.13版本说明

2017年2月份，Docker公司发布了全新的Docker版本：V1.13.0。从2017年3月1号开始，Docker的版本命名发生如下变化：

项目

说明

版本格式

YY.MM

stable版本

每个季度发行

edge版本

每个月发行

同时将Docker分成CE和EE 2个版本。CE版本即社区版（免费，支持周期三个月），EE即企业版，强调安全，付费使用。

Docker版本从1.13.*直接跳入17.03，该版本的意思是17年3月。同时，还声明了Docker以后会以CE（Community Edition）和EE（Enterprise Edition）的形式发布。其中，CE版本每个月发布一次，也就是说，随后的版本就是17.03、17.04、17.05等，而EE的版本是没三个月发布一次，对应的就是17.03、17.06等。对于发布的每个EE版本，Docker官网都会提供一年的技术支持。

Docker 会每月发布一个 edge 版本(17.03, 17.04, 17.05...)，每三个月发布一个 stable 版本(17.03, 17.06, 17.09...)，企业版(EE) 和 stable 版本号保持一致，但每个版本提供一年维护。

Docker 的 Linux 发行版的软件仓库也从以前的https://apt.dockerproject.org和https://yum.dockerproject.org 变更为目前的 https://download.docker.com 。软件包名变更为 docker-ce(社区版) 和 docker-ee(企业版)。

当前的CE版本为17.03.0，基于V1.13.0。主要修复错误，没有重大功能增加，API亦保持不变。此版本17.03的发行说明，请参考：ttps://github.com/docker/docker/releases

1. 为什么选择Docker

快速交付应用程序

• 我们希望你的开发环境能够更好的提高你的工作效率。Docker容器能够帮助开发人员、系统管理员、QA和版本控制工程师在一个生产环节中一起协同工作。我们制定了一套容器标准，而这套容器标准能够使系统管理员更改容器的时候，程序员不需要关心容器的变化，而更专注自己的应用程序代码。从而隔离开了开发和管理，简化了开发和部署的成本。
• 我们使应用的构建方式更加简单，可以快速的迭代你的应用，并且可以可视化的来查看应用的细微更改。这能够帮助组织里边的成员来更好的理解一个应用从构建到运行的过程。
• Docker 是一个轻量级的容器，所以它的速度是非常快的，而容器的启动时间只需要一秒钟，从而大大的减少了开发、测试和部署的时间。

轻松部署和扩展

• Docker 容器可以运行在大多数的环境中，你可以在桌面环境、物理主机、虚拟主机再到数据中，私有或者公有云中部署。
• 因为 Docker 可以从多平台下运行。你可以很容器的迁移你的应用程序。如果需要，你可以非常简单的将应用程序从测试环境迁移到云，或者从云迁移到测试环境。
• Docker 是一个轻量级的容器，因此它可以在很短的时间内启动和关闭。当你需要的时候，你可以启动多个容器引擎，并且在不需要使用他们的时候，可以将他们全部关闭。

Get higher density and run more workloads

Docker的容器本身不需要额外创建虚拟机管理系统，因此你可以启动多套Docker容器，这样就可以充分发挥主机服务器的物理资源，也可以降低因为采购服务器licenses而带来的额外成本。

快速构建 轻松管理

因为Docker上述轻便，快速的特性。可以使您的应用达到快速迭代的目的。每次小的变更，马上就可以看到效果。而不用将若干个小变更积攒到一定程度再变更。每次变更一小部分其实是一种非常安全的方式。

 

好的案例说明为啥要用"容器"的好处

专业的叫法是应用容器（Application Container）。那么应用容器长什么样子呢，一个做好的应用容器长得就好像一个装好了一组特定应用的虚拟机一样。比如我现在想用MySQL那我就找个装好MySQL的容器，运行起来，那么我就可以使用 MySQL了。

那么我直接装个 MySQL不就好了，何必还需要这个容器这么诡异的概念？话是这么说，可是你要真装MySQL的话可能要再装一堆依赖库，根据你的操作系统平台和版本进行设置，有时候还要从源代码编译报出一堆莫名其妙的错误，可不是这么好装。而且万一你机器挂了，所有的东西都要重新来，可能还要把配置在重新弄一遍。但是有了容器，你就相当于有了一个可以运行起来的虚拟机，只要你能运行容器，MySQL的配置就全省了。而且一旦你想换台机器，直接把这个容器端起来，再放到另一个机器就好了。硬件，操作系统，运行环境什么的都不需要考虑了。

在公司中的一个很大的用途就是可以保证线下的开发环境、测试环境和线上的生产环境一致。当年在 Baidu 经常碰到这样的事情，开发把东西做好了给测试去测，一般会给一坨代码和一个介绍上线步骤的上线单。结果代码在测试机跑不起来，开发就跑来跑去看问题，一会儿啊这个配置文件忘了提交了，一会儿啊这个上线命令写错了。找到了一个 bug 提上去，开发一看，啊我怎么又忘了把这个命令写在上线单上了。类似的事情在上线的时候还会发生，变成啊你这个软件的版本和我机器上的不一样……在 Amazon 的时候，由于一个开发直接担任上述三个职位，而且有一套自动化部署的机制所以问题会少一点，但是上线的时候大家还是胆战心惊。

若果利用容器的话，那么开发直接在容器里开发，提测的时候把整个容器给测试，测好了把改动改在容器里再上线就好了。通过容器，整个开发、测试和生产环境可以保持高度的一致。

此外容器也和VM一样具有着一定的隔离性，各个容器之间的数据和内存空间相互隔离，可以保证一定的安全性。

 

1. Docker&虚拟机VM的不同

二者框架上的不同处

下面的图片比较了 Docker 和传统虚拟化方式的不同之处，可见容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。直观上来讲vm多了一层guest OS，同时Hypervisor会对硬件资源进行虚拟化，docker直接使用硬件资源，所以资源利用率相对docker低也是比较容易理解的

官网的说法是：虚拟机上的应用不仅包含了应用本身、必要的依赖（二进制和库包等），还包括整个操作系统；而docker应用不同，共享系统内核，仅仅包含应用本身和依赖。

 

虚拟化的核心是对资源进行抽象，目标往往是为了在同一个机器上运行多个系统或应用，从而提高系统资源的利用率。虚拟化分为很多类型，比如常见的硬件辅助虚拟化（VMware workstation、 KVM等）。Docker所代表的容器虚拟化技术属于操作系统级虚拟化：内核通过创建多个虚拟的操作系统实例（内核和库）来隔离不同的进程。

传统虚拟化和容器技术结构比较：传统虚拟化技术是在硬件层面实现虚拟化，增加了系统调用链路的环节，有性能损耗；容器虚拟化技术以共享Kernel的方式实现，几乎没有性能损耗。

二者性能、安全等方面的对比

 为啥隔离性VM强：VM各个系统用各自内核，而Docker共用一个。

 

虚拟机的概念

先来理解一下虚拟机概念，广义来说，虚拟机是一种模拟系统，即在软件层面上通过模拟硬件的输入和输出，让虚拟机的操作系统得以运行在没有物理硬件的环境中（也就是宿主机的操作系统上），其中能够模拟出硬件输入输出，让虚拟机的操作系统可以启动起来的程序，被叫做hypervisor。用一张图来说明这个关系就是：

• 在这张图中：
• 物理机被称为宿主机
• 虚拟机也被称为guest OS
• 而被hypervisor虚拟出来的硬件被称为虚拟硬件

 

比如，举一个大家都很熟悉的例子，在编写android程序时，调试和测试运行都可以在X86架构的台式机或笔记本进行，这就是一个典型的虚拟机例子，在这之中：

 

• 宿主机就是台式机或笔记本
• 虚拟机就是虚拟出来的android
• 而模拟android的软件就是android box
•  

当然android模拟机一个大问题就是：启动速度非常慢，最长可达10分钟或以上，这是因为单纯模拟硬件的输入输出，效率是很差的，所以这样的虚拟机如果真部署在服务器上，速度是感人的。

这个时候，就有计算机科学家提出了非常偷懒的想法：假如我们不模拟硬件输入输出，只是做下真实硬件输入输出的搬运工，那么虚拟机的指令执行速度，就可以和宿主机一致了。当然这前提是宿主机的硬件架构必须和虚拟硬件架构一致。比如，

我们可以在linux的台式机上轻松模拟windows，而且这个windows的运行速度基本上和原生装一个windows速度差不多，因为windows也能被直接安装在这台台式机上。

这个思路对于在windows系统中运行android系统不管用，因为android系统的运行硬件一般是手机（arm系统，可以理解为不同的硬件架构体系和cpu指令集），所以android模拟机还是一样的慢。

 

容器的概念

一般来说，虚拟机都会有自己的kernel，自己的硬件，这样虚拟机启动的时候需要先做开机自检，启动kernel，启动用户进程等一系列行为，虽然现在电脑运行速度挺快，但是这一系列检查做下来，也要几十秒，也就是虚拟机需要几十秒来启动。

重新来理解虚拟机的概念，计算机科学家发现其实我们创建虚拟机也不一定需要模拟硬件的输入和输出，假如宿主机和虚拟机他们的kernel是一致的，就不用做硬件输入输出的搬运工了，只需要做kernel输入输出的搬运工即可，为了有别于硬件层面的虚拟机，这种虚拟机被命名为 操作系统层虚拟化：Operating-system-level virtualization 也被叫做容器

让我们来回顾虚拟机的概念，在虚拟机的系统中，虚拟机认为自己有独立的文件系统，进程系统，内存系统，等等一系列，所以为了让容器接近虚拟机，也需要有独立的文件系统，进程系统，内存系统，等等一系列，为了达成这一目的，主机系统采用的办法是：只要隔离容器不让它看到主机的文件系统，进程系统，内存系统，等等一系列，那么容器系统就是一个接近虚拟机的玩意了。

Docker 容器有自己的kernel吗， 答案：没有，docker和宿主机共享kernel

 docker的kernel version由镜像确定还是由宿主机确定：答案： 由宿主机决定。

 

详细对比二者的例子

首先，大家需要明确一点，Docker容器不是虚拟机。Docker不停地给大家宣传，"虚拟机需要数分钟启动，而Docker容器只需要50毫秒"。

然而，Docker容器并非虚拟机，我们不妨来比较一下它们。

理解虚拟机

使用虚拟机运行多个相互隔离的应用时，如下图:

从下到上理解上图:

• 基础设施(Infrastructure)。它可以是你的个人电脑，数据中心的服务器，或者是云主机。
• 虚拟机管理系统(Hypervisor)。利用Hypervisor，可以在主操作系统之上运行多个不同的从操作系统。类型1的Hypervisor有支持MacOS的HyperKit，支持Windows的Hyper-V、Xen以及KVM。类型2的Hypervisor有VirtualBox和VMWare workstation。
• 客户机操作系统(Guest Operating System)。假设你需要运行3个相互隔离的应用，则需要使用Hypervisor启动3个客户机操作系统，也就是3个虚拟机。这些虚拟机都非常大，也许有700MB，这就意味着它们将占用2.1GB的磁盘空间。更糟糕的是，它们还会消耗很多CPU和内存。
• 各种依赖。每一个客户机操作系统都需要安装许多依赖。如果你的应用需要连接PostgreSQL的话，则需要安装libpq-dev；如果你使用Ruby的话，应该需要安装gems；如果使用其他编程语言，比如Python或者Node.js，都会需要安装对应的依赖库。
• 应用。安装依赖之后，就可以在各个客户机操作系统分别运行应用了，这样各个应用就是相互隔离的。

理解Docker容器

使用Docker容器运行多个相互隔离的应用时，如下图:

不难发现，相比于虚拟机，Docker要简洁很多。因为我们不需要运行一个臃肿的客户机操作系统了。

从下到上理解上图:

• 基础设施(Infrastructure)。
• 主操作系统(Host Operating System)。所有主流的Linux发行版都可以运行Docker。对于MacOS和Windows，也有一些办法"运行"Docker。
• Docker守护进程(Docker Daemon)。Docker守护进程取代了Hypervisor，它是运行在操作系统之上的后台进程，负责管理Docker容器。
• 各种依赖。对于Docker，应用的所有依赖都打包在Docker镜像中，Docker容器是基于Docker镜像创建的。
• 应用。应用的源代码与它的依赖都打包在Docker镜像中，不同的应用需要不同的Docker镜像。不同的应用运行在不同的Docker容器中，它们是相互隔离的。

对比虚拟机与Docker

Docker守护进程可以直接与主操作系统进行通信，为各个Docker容器分配资源；它还可以将容器与主操作系统隔离，并将各个容器互相隔离。虚拟机启动需要数分钟，而Docker容器可以在数毫秒内启动。由于没有臃肿的从操作系统，Docker可以节省大量的磁盘空间以及其他系统资源。

说了这么多Docker的优势，大家也没有必要完全否定虚拟机技术，因为两者有不同的使用场景。虚拟机更擅长于彻底隔离整个运行环境。例如，云服务提供商通常采用虚拟机技术隔离不同的用户。而Docker通常用于隔离不同的应用，例如前端，后端以及数据库。

服务器虚拟化vs Docker

服务器好比运输码头：拥有场地和各种设备（服务器硬件资源）

服务器虚拟化好比作码头上的仓库：拥有独立的空间堆放各种货物或集装箱

(仓库之间完全独立，独立的应用系统和操作系统）

Docker比作集装箱：各种货物的打包

(将各种应用程序和他们所依赖的运行环境打包成标准的容器,容器之间隔离)

Docker有着小巧、迁移部署快速、运行高效等特点，但隔离性比服务器虚拟化差：不同的集装箱属于不同的运单（Docker上运行不同的应用实例），相互独立（隔离）。但由同一个库管人员管理（主机操作系统内核），因此通过库管人员可以看到所有集装箱的相关信息（因为共享操作系统内核，因此相关信息会共享）。

服务器虚拟化就好比在码头上（物理主机及虚拟化层），建立了多个独立的"小码头"—仓库（虚拟机）。其拥有完全独立（隔离）的空间，属于不同的客户（虚拟机所有者）。每个仓库有各自的库管人员（当前虚拟机的操作系统内核），无法管理其它仓库。不存在信息共享的情况

因此，我们需要根据不同的应用场景和需求采用不同的方式使用Docker技术或使用服务器虚拟化技术。例如一个典型的Docker应用场景是当主机上的Docker实例属于单一用户的情况下，在保证安全的同时可以充分发挥Docker的技术优势。对于隔离要求较高的环境如混合用户环境，就可以使用服务器虚拟化技术。正则科技提供了丰富的Docker应用实例，满足您的各种应用需求，并且支持在已经安装了自在（Isvara）服务器虚拟化软件的主机上同时使用服务器虚拟化技术和Docker技术提供不同技术场景。

 

 

4.Docker的基本相关概念

docker定义

Docker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。一款轻量级容器管理引擎.

Docker可以让你像使用集装箱一样快速的组合成应用、屏蔽代码层面的差异，会尽可能的缩短从代码测试到产品部署的时间。

Docker系统有两个程序：Docker Daemon和docker client.

 

 

 

 

Docker Platform (docker平台)

Docker Engine+docker hub =docker platform

Docker engine引擎

docker引擎是一个c/s结构的应用， 是一个基于虚拟化技术的轻量级并且功能强大的开源容器引擎管理工具。它可以将不同的 work flow 组合起来构建成你的应用。主要组件见下图：

 

Server是一个常驻进程

REST API 实现了client和server间的交互协议

CLI 实现容器和镜像的管理，为用户提供统一的操作界面

 

 

 

Docker引擎的基础是Linux自带的容器（Linux Containers,LXC）技术。IBM对于容器技术的准确描述如下：

容器有效的将单个操作系统管理的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求。与虚拟化相比，这样既不需要指令级模拟，也不需要即时编译。容器可以在核心CPU本地运行指令，而不需要任何专门的解释机制。此外，也避免了准虚拟化（paravirtualization）和系统调用替换中的复杂性。

我们可以将容器理解为一种沙盒。每个容器内运行一个应用，不同的容器相互隔离，容器之间可以建立通信机制。容器的创建和停止都十分快速（秒级），容器自身对资源的需求十分有限，远比虚拟机本身占用的资源少。

 

 

Docker hub

Docker Hub: 用于分享、管理 Docker 容器的 Docker SaaS 平台，可以分享和管理你的images镜像的一个 Saas 服务平台–https://hub.docker.com/

Docker Hub是一个由Docker公司负责维护的公共注册中心，它包含了超过15,000个可用来下载和构建容器的镜像，并且还提供认证、工作组结构、工作流工具（比如webhooks）、构建触发器以及私有工具（比如私有仓库可用于存储你并不想公开分享的镜像）。

Docker hub的界面

 

 

 

Docker Daemon（docker服务端）

Docker 架构中常驻后台的系统进程，是一个服务进程，负责接收处理用户发送的请求和管理所有的 Docker 容器，所谓的运行 Docker 即代表运行 Docker Daemon。

 

Docker Client（docker客户端）

Docker 架构中用户与 Docker Daemon 建立通信的客户端。扮演着docker服务端的远程控制器，可以用来控制docker的服务端进程。大部分情况下，docker服务端和客户端运行在一台机器上。

 

 

 

 

 

 

 

Docker的内部构建

要理解 Docker 内部构建，需要理解以下三种部件：

Docker 镜像 - Docker images

Docker 仓库 - Docker registeries

Docker 容器 - Docker containers

Docker images- docker镜像

 

Docker镜像类似于虚拟机镜像，是一个只读模板，并且包含了文件系统。一个只读层被称为镜像，一个镜像是永久不会变的。

一个镜像可以只包含一个操作系统环境（比如SUSE镜像），也可以安装了用户程序及其运行环境（比如eBackup镜像）。镜像其实就是一个文件，任何用户程序都可以成为镜像的一部分。

镜像=操作系统+软件运行环境+用户程序

由于 Docker 使用一个统一文件系统，Docker 进程认为整个文件系统是以读写方式挂载的。但是所有的变更都发生顶层的可写层，而下层的原始的只读镜像文件并未变化。由于镜像不可写，所以镜像是无状态的。

镜像可以用来创建 Docker 容器，一个镜像可以创建很多容器。Docker 提供了一个很简单的机制来创建镜像或者更新现有的镜像，用户甚至可以直接从其他人那里下载一个已经做好的镜像来直接使用。

镜像（Image）就是一堆只读层（read-only layer）的统一视角，也许这个定义有些难以理解，看看下面这张图

右边我们看到了多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在docker宿主机的文件系统上访问到。统一文件系统（Union File System）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件系统。

 

 

 

 

 

Images与container的关系

Image是创建container的基础。镜像是 Docker 应用的静态表示，是应用的交付件，镜像中包含了应用运行所需的所有依赖，包括应用代码、应用依赖库、应用运行时和操作系统。

Dockerfile 是一个描述文件，描述了产生 Docker 镜像的过程，详细文档可以参见官方文档 Dockerfile reference。一个应用 Docker 化的第一步就是通过 Dockerfile 产生应用镜像。

 

 

 

如上图，一个layer就是一个image，多个image又可以打包成一个image。

Image类似一个单链表系统，每个image包含一个指向parent image的指针，没有parent image的image是baseimage（image的指针靠sqlite数据库来保存）。

最上面的一层（不属于image）是可写的,上面的内容依赖于下面的内容，如果要修改下面的内容，先将下面的内容复制到上面再进行修改。

 

 

关于image的一些命令：

docker pull     //从网络上下载镜像

docker images  //查看本地主机已经存在的镜像

 

 

 

父镜像

每一个镜像都可能依赖于由一个或多个下层的组成的另一个镜像。我们有时说，下层那个镜像是上层镜像的父镜像。

基础镜像

一个没有任何父镜像的镜像，谓之基础镜像。

镜像ID

所有镜像都是通过一个 64 位十六进制字符串（内部是一个 256 bit 的值）来标识的。为简化使用，前 12 个字符可以组成一个短ID，可以在命令行中使用。短ID还是有一定的碰撞机率，所以服务器总是返回长ID。

 

Docker仓库-Docker registries

Docker 仓库用来保存镜像，可以理解为代码控制中的代码仓库。同样的，Docker 仓库也有公有和私有的概念。公有的 Docker 仓库名字是 Docker Hub。Docker Hub 提供了庞大的镜像集合供使用。这些镜像可以是自己创建，或者在别人的镜像基础上创建。Docker 仓库是 Docker 的分发部分。

仓库（Repository）是集中存放镜像文件的场所。有时候会把仓库和仓库注册服务器（Registry）混为一谈，并不严格区分。实际上，仓库注册服务器上往往存放着多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）。

仓库分为公开仓库（Public）和私有仓库（Private）两种形式。最大的公开仓库是 Docker Hub，存放了数量庞大的镜像供用户下载。国内的公开仓库包括时速云、网易云等，可以提供大陆用户更稳定快速的访问。当然，用户也可以在本地网络内创建一个私有仓库。

当用户创建了自己的镜像之后就可以使用 push 命令将它上传到公有或者私有仓库，这样下次在另外一台机器上使用这个镜像时候，只需要从仓库上 pull 下来就可以了。

Docker 仓库的概念跟 Git 类似，注册服务器可以理解为 GitHub 这样的托管服务。

Docker容器- Docker containers

容器是镜像运行时的动态表示，如果把镜像想象为一个 Class 那么容器就是这个 Class 的一个实例。

Docker 容器和文件夹很类似，一个Docker容器包含了所有的某个应用运行所需要的环境。每一个 Docker 容器都是从 Docker 镜像创建的。Docker 容器可以运行、开始、停止、移动和删除。每一个 Docker 容器都是独立和安全的应用平台，Docker 容器是 Docker 的运行部分。

 

Docker 利用容器（Container）来运行应用。容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看做是一个简易版的 Linux 环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。

容器的定义和镜像几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。

一个运行态容器被定义为一个可读写的统一文件系统加上隔离的进程空间和包含其中的进程。下面这张图片展示了一个运行中的容器。

 

 

正是文件系统隔离技术使得Docker成为了一个非常有潜力的虚拟化技术。一个容器中的进程可能会对文件进行修改、删除、创建，这些改变都将作用于可读写层。

 

5.Docker相关的附属工具与概念

Docker Machine

Docker 官方提供的部署工具。帮助用户快速在运行环境中创建虚拟机服务节点，在虚拟机中安装并配置 Docker，最终帮助用户配置 Docker Client，使得 Docker Client 有能力与虚拟机中的 Docker 建立通信。

 

Docker Compose

Docker 官方提供的容器编配工具。随着服务的复杂度增长，容器管理过程的配置项将变得冗长，Compose 可有效帮助用户缓解甚至解决容器部署的复杂性。

Docker Compose 是 Docker 容器进行编排的工具，定义和运行多容器的应用，可以一条命令启动多个容器。

使用Compose 基本上分为三步：

1. Dockerfile 定义应用的运行环境
2. docker-compose.yml 定义组成应用的各服务
3. docker-compose up 启动整个应用

    

   Docker 加速器

   使用 Docker 的时候，需要经常从官方获取镜像，但是由于显而易见的网络原因，拉取镜像的过程非常耗时，严重影响使用 Docker 的体验。因此 DaoCloud 或阿里云等公司推出 Docker 加速器解决这个难题，通过智能路由和缓存机制，极大提升了国内网络访问 Docker Hub 的速度，目前已经拥有了广泛的用户群体，并得到了 Docker 官方的大力推荐。如果您是在国内的网络环境使用 Docker，那么 Docker 加速器一定能帮到您。目前已知的DaoCloud 或阿里云加速器服务是永久免费的，并且无流量限制，请放心使用

   docker toolbox

   不推荐使用，建议使用新的 docker for mac 及 docker for windows 以在这两种平台运行 docker 

   6.容器技术

   现代化IT管理中，容器技术已经成为一种潮流。越来越多的企业选择容器技术来分发业务，越来越多的数据中心采纳容器技术来管理资源。而阿里巴巴作为全球业务场景最复杂的互联网服务提供商，其背后自然少不了容器技术的支撑。从现场发布可知，如今这项技术已经覆盖阿里内部绝大部分事业部，在阿里的数据中心运行有数十万个Pouch容器，大规模支撑内部离线在线业务的混部，且100%在线业务已通过Pouch容器化对外服务

   lxc；

   第一个完整意义的容器管理技术，可方便的创建、启动及停止容器，也可以同过lxc操作容器中的应用或查看容器运行状态。

   libcontainer：

   Docker开发的原生的容器管理技术来代替lxc。

   Pouch

   2017年10月12日，在以"飞天·智能"为主题的2017杭州云栖大会上，阿里内部自研容器技术Pouch宣布开源。在阿里的数据中心运行有数十万个Pouch容器，大规模支撑内部离线在线业务的混部，且100%在线业务已通过Pouch容器化对外服务。

    

   

   7.Docker的架构

   Docker 架构模式

   Docker使用C/S（客户端/服务端）架构，Client 通过接口与Server进程通信实现容器的构建，运行和发布。client和server可以运行在同一台集群，也可以通过跨主机实现远程通信。

    

   Docker daemon会处理复杂繁重的任务，例如建立、运行、发布你的 Docker 容器。Docker 客户端和daemon可以运行在同一个系统上，当然你也可以使用 Docker 客户端去连接一个远程的 Docker daemon程。Docker 客户端和daemon之间通过 socket 或者 RESTful API 进行通信。

    

   

    

    

   

    

   Docker构造：Client-Server

   

   8.Docker技术原理

   技术原理

    
   execdriver：存储了容器定义的配置信息。libcontainer拿到配置信息后将会调用namespace，cgroups等技术完成容器的创建及管理。 
   networkdriver：完成容器网络环境的配置。 
   graphdriver：管理容器镜像。

   Docker容器的3种状态

   三种状态： 
   

   Docker镜像

    
   镜像下载到容器后，run启动容器； 
   容器修改后，commit保存新的镜像（然而Dockerfile的build更常用）。 
   层级结构。

   build，ship，run

    
   一次构建，任何地方运行。

   Docker数据卷

   数据卷存在的意义：

   1. 容器运行时可使用数据卷中的文件。
   2. 数据卷可在多个容器间共享。
   3. 存储容器运行过程中产生的数据。
   4. 方便主机对容器数据的访问。

   Docker网络模式

   Bridged：容器可与主机上的容器，主机外部进行通信。 
   Host：容器只能与主机通信。 
   Container：容器只能与容器通信。 
   None：没网。

   Docker平台架构

   

   9容器平台技术

   

   9.1容器编排

   概念

   据2017年03年美国一家公司统计，在使用了docker的公司里，有40%也使用了Kubernetes、Mesos、Amazon ECS、Google Container Engine或其他编排引擎。有些企业使用Docker内置的编排引擎，不过它们未能生成可识别的度量指标，所以无法对其进行可靠的统计。
   
   对于同时使用了Docker和AWS（Amazon Web Service）的企业来说，他们更倾向于选择Amazon ECS，正如所预期的那样：超过35%的公司使用了ECS。不过也有很大一部分使用了其他编排引擎，特别是Kubernetes。

   管理容器下的主机，容器及容器及其逻辑关系。 
   

    

   9.2容器编排的应用场景

   快速交付与CICD

   

   云间迁移

   

   弹性扩展

    
   容器化后，应用扩展其实就是拉取镜像部署更多容器的过程。

   10.Docker平台三大容器编排工具

   - Mesos

   Mesos构建的Docker平台中，容器为最小的单元！ 
   Slave安装在集群节点上，会将节点的资源使用情况周期性的报告给Master。 
   Master为管理集群节点。 
   Executer为容器的引擎。 
    
   Mesos配合计算架构的Framework进行资源调度。 
   1. Master定期将所有主机的计算机资源使用情况报告给Framework Scheduler； 
   2.Scheduler调配后下发部署的任务给集群节点； 
   3.节点上的Framework Executor获取任务进行容器的部署； 
   4.节点将部署结果反馈给Master； 
   5.Master会更新最新的主机资源状态给Scheduler。 
   Mesos一般与Marathon，Zookeeper一起使用构建Docker平台，如图，Mesos为一个可调用Docker引擎的Framework，Marathon可将容器按一定的调度策略部署到合适的主机上，Zookeeper保证Mesos和Marathon管理节点的高可用性，当Master节点宕机后，可快速选出新的Master节点，从而不影响整个逻辑架构。Zookeeper本身也为分布式的高可用架构。 
   

   - Kubernetes（2017年docker公司宣布新版本支持kubernetes）

   Kubernetes构建的单元中，pod是最小的单元，容器封装在pod中！（2017年docker公司宣布新版本支持kubernetes和SWARM）

   pod

   同一个pod中的容器可方便的共享存储； 
   当一个存储目录挂载到一个容器下时，同个pod中的另一个容器也可以访问到这个存储。

   架构

   etcd:集群管理工具。 
   minion：普通节点。 
   master：管理节点。

    
   minion的kublet结合其cAdvisior及etcd将节点信息汇总到master。 
   master使用scheduler按一定的调度策略将pod调度到各个minion，使用repulatation，controller控制pod的数量及伸缩，使用services分配pod的IP和处理pod的负载均衡。

   - Swarm（Docker原生开源容器管理项目）

   

   三者对比

    
   Mwsos经历了大规模集群运行多年的考验； 
   Kubernetes本身就脱胎于谷歌的集群管理工具； 
   Swarm与Docker结合更为紧密。

   11.负载均衡与服务发现

   负载均衡：请求到达负载均衡器上时，负载均衡器将其平均分配到每个容器。 
   常用的负载均衡技术：haproxy,LVS,F5,Nginx. 
   服务发现：自动将容器的配置信息，包括IP，端口，域名等上传到配置中心。负载均衡器会周期性的从配置中心获取相关的配置信息，并且将容器加入相关的负载均衡器访问架构中。 
   常用的服务发现技术：Etcd，Zookeeper，Consul。 
   

   12.日志管理

   容器时代对日志处理平台的要求是：集中化、海量存储、灵活过滤、快速查询、伸缩性架构、高可用、强大的UI。

   13.Docker监控

   

   14.AWS ECS

   ECS（亚马逊弹性计算云容器服务）是一项高度可扩展的，高性能的软件容器管理服务，它支持Docker 软件容器，并允许您轻松地在受 Amazon EC2 实例管理的集群中运行应用程序。

   在基于软件容器的架构中部署应用时，通常需要在每一个亚马逊EC2实例上运行一个特定的代理来处理操作或安全事宜（例如监控，安全，测量指标，业务发现，日志等）。传统的方法是使EC2实例在用户数据脚本或init系统（例如Upstart或Systemd）中为每一个代理调用Docker运行命令。虽然这种方法很奏效，但是它有一些缺陷，因为亚马逊ECS对软件容器一无所知，因此不能追踪容器的CPU，内存，和使用的端口。当需要添加，修改，或从实例中删除代理时，使用这种方法也很难管理这些实例，因为这些改变需要在本地对每一个EC2实例进行操作，需要您使用SSH方法连接到每个机器来启动和停止这些容器。