Docker概念简介Docker是一个开放源代码的APP应用程序容器引擎，基于Go语言，并且符合Apache2.0协议的开放源代码。 使用Docker，开发人员可以通过将APP应用程序和依赖包打包到轻量级、可移植的容器中并发布到常见的Linux计算机上来实现虚拟化。 容器完全使用沙盒机制，相互之间没有接口(类似iPhone上的app )。 更重要的是，容器的性能开销非常低。 Docker与传统虚拟化方法的区别在于，容器在操作系统级别虚拟化，本地主机操作系统直接复用，传统方法在硬件级别实现。 http://www.Sina.com/web APP应用程序的自动打包和发布。 自动化测试、持续集成和发布。 在服务环境中部署和协调数据库和其他后台APP应用程序。 从一开始就编译或扩展现有的OpenShift或Cloud Foundry平台，以创建自己的PaaS环境。Docker的应用场景更快的交付和部署代理完全可以帮助您在整个开发周期中实现快速交付。 Docker允许开发人员在安装了APP应用程序和服务的本地容器上进行开发。 可以直接集成到可持续发展进程中。 例如，开发人员可以使用标准镜像构建一系列开发容器，开发完成后承运人可以直接使用此容器部署代码。 Docker可以快速创建容器、快速重复APP应用程序和可视化整个过程，从而使团队中的其他成员更容易了解APP应用程序是如何创建和运行的。 Docker容器又轻又快！ 容器的启动时间以秒为单位，大大节省了开发、测试和部署的时间。 的高效部署和扩展Docker容器几乎可以在任何平台上运行，包括物理机、虚拟机、公共云、私有云、PC和服务器。 这种兼容性允许用户将一个APP应用程序从一个平台直接迁移到另一个平台。 Docker的兼容性和轻量级简化了负载的动态管理。 可以快速扩展，并提供方便的脱机APP应用和服务。 这个速度接近实时。 提高资源利用率Docker的系统资源利用率高，可以在一台主机上同时运行数千个Docker容器。 容器除执行其中的APP应用外，很少消耗额外的系统资源，所以APP应用性能高，系统开销最小。 传统的虚拟机方法在运行10个不同的APP应用程序时会启动10个虚拟机，而Docker只需要启动10个隔离的APP应用程序。 更简单的管理使用Docker，只需进行小的修改，就可以代替以往的大量更新工作。 所有更改都是分阶段分发和更新的，从而实现自动化和高效管理。Docker的优势Docker使用C/S体系结构，客户端通过接口与Server进程通信以构建、运行和发布容器。 客户端和服务器可以在同一群集上运行，也可以在主机之间远程通信。Docker架构镜像(image docker镜像)是只读模板。 镜像可以用于创建Docker容器，并且一个镜像可以创建许多容器。 Docker提供了创建镜像和更新现有镜像的简单机制。 用户也可以直接从其他用户下载创建的镜像并直接使用。 “容器”(container ) Docker是一个或多个使用容器独立运行的APP应用程序。 容器是通过镜像创建的执行实例。 可以启动、开始、停止和删除。 各容器相互隔离，是保证安全的平台。 可以将容器视为Linux环境(如root用户权限、进程区域、用户区域和网络区域)和其中运行的APP应用程序的简化版本。 容器的定义与镜像几乎相同，也是很多层的统一观点。 唯一的区别是容器的最上层是可写的。 “仓库”(repository )仓库是镜像文件的集中存储位置。
仓库可能与仓库注册服务器(Registry )混淆，因此没有严格区分。 事实上，仓库注册服务器通常存储多个仓库，每个仓库包含多个镜像，每个镜像都有不同的标签(tag )。 仓库分为公开仓库(Public )和私有仓库(Public )两种形式。 最大的公共仓库是Docker Hub，其中存储了大量的镜像供用户下载。 国内的公开仓库包括时速云、网络易云等，让大陆用户更稳定、更快速地访问。 当然，用户也可以在本地网络中创建私有仓库。 创建自己的镜像后，用户可以使用推送命令将其上传到公共或专用仓库。 这样，下次在另一台机器上使用此镜像时，只需从仓库中拉入即可。 Docker仓库的概念与Git相似，注册服务可以理解为GitHub这样的托管服务。Dorcker核心概念Dockerfile是软件的素材，Docker镜像是软件的交付，Docker容器可以被认为是软件的运行状态。 从APP应用的角度看，Dockerfile、Docker镜像和Docker容器分别代表了软件的三个不同阶段，Dockerfile是面向开发的，Docker镜像是交货标准，而简而言之，Doc
kerfile构建出Docker镜像，通过Docker镜像运行Docker容器。 我们可以从Docker容器的角度，来反推三者的关系。首先可以来看下图：我们假设这个容器的镜像通过以下Dockerfile构建而得： FROM ubuntu:14.04
ADD run.sh /
VOLUME /data
CMD ["./run.sh"] Dockerfile与Docker镜像 首先，我们结合上图来看看Dockerfile与Docker镜像之间的关系。 FROM ubuntu:14.04：设置基础镜像，此时会使用基础镜像 ubuntu:14.04 的所有镜像层，为简单起见，图中将其作为一个整体展示。 ADD run.sh /：将 Dockerfile 所在目录的文件 run.sh 加至镜像的根目录，此时新一层的镜像只有一项内容，即根目录下的 run.sh。 VOLUME /data：设定镜像的 VOLUME，此 VOLUME 在容器内部的路径为 /data。需要注意的是，此时并未在新一层的镜像中添加任何文件，即构建出的磁层镜像中文件为空，但更新了镜像的 json 文件，以便通过此镜像启动容器时获取这方面的信息。 CMD ["./run.sh"]：设置镜像的默认执行入口，此命令同样不会在新建镜像中添加任何文件，仅仅在上一层镜像 json 文件的基础上更新新建镜像的 json 文件。 因此，通过以上分析，以上的Dockerfile可以构建出一个新的镜像，包含4个镜像层，每一条命令会和一个镜像层对应，镜像之间会存在父子关系。图中很清楚的表明了这些关系。 Docker镜像与Docker容器的关系 Docker镜像是Docker容器运行的基础，没有Docker镜像，就不可能有Docker容器，这也是Docker的设计原则之一。 可以理解的是：Docker镜像毕竟是镜像，属于静态的内容；而Docker容器就不一样了，容器属于动态的内容。动态的内容，大家很容易联想到进程，内存，CPU等之类的东西。的确，Docker容器作为动态的内容，都会包含这些。 为了便于理解，大家可以把Docker容器，理解为一个或多个运行进程，而这些运行进程将占有相应的内存，相应的CPU计算资源，相应的虚拟网络设备以及相应的文件系统资源。而Docker容器所占用的文件系统资源，则通过Docker镜像的镜像层文件来提供。 那么作为静态的镜像，如何才有能力转化为一个动态的Docker容器呢？此时，我们可以想象：第一，转化的依据是什么；第二，由谁来执行这个转化操作。 其实，转化的依据是每个镜像的json文件，Docker可以通过解析Docker镜像的json的文件，获知应该在这个镜像之上运行什么样的进程，应该为进程配置怎么样的环境变量，此时也就实现了静态向动态的转变。 谁来执行这个转化工作？答案是Docker守护进程。也许大家早就理解这样一句 话：Docker容器实质上就是一个或者多个进程，而容器的父进程就是Docker守护进程。这样的，转化工作的执行就不难理解了：Docker守护进程 手握Docker镜像的json文件，为容器配置相应的环境，并真正运行Docker镜像所指定的进程，完成Docker容器的真正创建。 Docker容器运行起来之后，Docker镜像json文件就失去作用了。此时Docker镜像的绝大部分作用就是：为Docker容器提供一个文件系统的视角，供容器内部的进程访问文件资源。 再次回到上图，我们再来看看容器和镜像之间的一些特殊关系。首先，之前已经提及Docker镜像是分层管理的，管理Docker容器的时候，Docker镜像仍然是分层管理的。由于此时动态的容器中已经存在进程，进程就会对文件系统视角内的文件进行读写操作，因此，就会涉及一个问题：容器是否会篡改Docker镜像的内容？ 答案自然是不会的。统一来讲，正如上图，所有的Docker镜像层对于容器来说，都是只读的，容器对于文件的写操作绝对不会作用在镜像中。 既然如此，实现的原理就很重要，究其根本：Docker守护进程会在Docker镜像的 最上层之上，再添加一个可读写层，容器所有的写操作都会作用到这一层中。而如果Docker容器需要写底层Docker镜像中的文件，那么此时就会涉及一 个叫Copy－on－Write的机制，即aufs等联合文件系统保证：首先将此文件从Docker镜像层中拷贝至最上层的可读写层，然后容器进程再对读 写层中的副本进行写操纵。对于容器进程来讲，它只能看到最上层的文件。 那最后我们再来说说：Docker容器的文件系统视角中，到底是不是存在一些内容，不是存储于Docker镜像中的？ 这次的答案依旧是肯定的。 再次重申一点，Docker镜像中存储的都是一些静态文件。这些文件原则上应该和容器具体信息以及主机信息完全解藕。那么Docker容器中不存在Docker镜像中的内容主要有以下几点： 1./proc以及/sys等虚拟文件系统的内容 2.容器的hosts文件，hostname文件以及resolv.conf文件，这些事具体环境的信息，原则上的确不应该被打入镜像。 3.容器的Volume路径，这部分的视角来源于从宿主机上挂载到容器内部的路径 4.部分的设备文件
Docker特性 文件系统隔离：每个进程容器运行在完全独立的根文件系统里。 资源隔离：可以使用cgroup为每个进程容器分配不同的系统资源，例如CPU和内存。 网络隔离：每个进程容器运行在自己的网络命名空间里，拥有自己的虚拟接口和IP地址。 写时复制：采用写时复制方式创建根文件系统，这让部署变得极其快捷，并且节省内存和硬盘空间。 日志记录：Docker将会收集和记录每个进程容器的标准流（stdout/stderr/stdin），用于实时检索或批量检索。 变更管理：容器文件系统的变更可以提交到新的映像中，并可重复使用以创建更多的容器。无需使用模板或手动配置。 交互式Shell：Docker可以分配一个虚拟终端并关联到任何容器的标准输入上，例如运行一个一次性交互 shell。 传统虚拟技术的区别 Docker类似虚拟机的概念，但是与虚拟化技术的不同点在于下面几点： 1. 虚拟化技术依赖物理CPU和内存，是硬件级别的；而docker构建在操作系统上，利用操作系统的containerization技术，所以docker甚至可以在虚拟机上运行 2. 虚拟化系统一般都是指操作系统镜像，比较复杂，称为“系统”；而docker开源而且轻量，称为“容器”，单个容器适合部署少量应用，比如部署一个redis、一个memcached。 3. 传统的虚拟化技术使用快照来保存状态；而docker在保存状态上不仅更为轻便和低成本，而且引入了类似源代码管理机制，将容器的快照历史版本一一记录，切换成本很低。 4. 传统的虚拟化技术在构建系统的时候较为复杂，需要大量的人力；而docker可以通过Dockfile来构建整个容器，重启和构建速度很快。更重要的是Dockfile可以手动编写，这样应用程序开发人员可以通过发布Dockfile来指导系统环境和依赖，这样对于持续交付十分有利。 5. Dockerfile可以基于已经构建好的容器镜像，创建新容器。Dockerfile可以通过社区分享和下载，有利于该技术的推广。Docker会像一个可移植的容器引擎那样工作。它把应用程序及所有程序的依赖环境打包到一个虚拟容器中，这个虚拟容器可以运行在任何一种 Linux服务器上。这大大地提高了程序运行的灵活性和可移植性，无论需不需要许可、是在公共云还是私密云、是不是裸机环境等等。 docker 的四种网络模式 host模式 container模式 none模式 bridge模式默认模式 docker run -it --rm --net=host centos_with_net bash 使用 --net=container :container_id/container_name，多个容器使用共同的网络看到的ip是一样 使用 --net=none 指定，这种模式下不会配置任何网络。 使用 --net=bridge 指定，不用指定默认就是这种网络模式。这种模式会为每个容器分配一个独立的Network Namespace。类似于Vmware的nat网络模式。同一个宿主机上的所有容器会在同一个网段下，相互之间是可以通信的。 host模式 如果启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。 但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。 container模式 Container模式指定新创建的容器和已经存在的一个容器共享一个Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过lo网卡设备通信。 none模式 使用none模式，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。 bridge模式 bridge模式是Docker默认的网络设置，此模式会为每一个容器分配Network Namespace、设置IP等，并将一个主机上的Docker容器连接到一个虚拟网桥上。