作者：雪雁
文章转载出自这里：https://www.cnblogs.com/codelove/
前言
随着生产力的发展尤其是弹性架构的广泛应用（如微服务），许多一流开发者都将应用托管到了应用容器上，如Google、微软、亚马逊、阿里、京东、新浪等等。
从未来的发展方向来看，容器引擎将会越来越成为主流，哪怕不是弹性架构，托管到应用容器也将是一种趋势——因为更低的开发运维和托管成本以及对服务器资源的优化配置，而且未来一个很大的趋势是————无服务器计算服务
因为相对于软件、硬件在本地设备上的分裂，云计算的一大特性就是将服务构建在云上，供多种设备同时无缝调用。但事实上，云服务在发展的过程中还没能实现共融共通的理想————比如，各家的云服务是相对割裂的，开发者基于Google云服务构建的软件拿到亚马逊的AWS上也许就不能用了，阿里云的应用迁移到腾讯云可能就存在问题了；在任务执行层面，为防止互相干扰，云服务厂商在同一台服务器上执行多个任务时也会将他们隔离进行、很明显，这样的实例情况和云服务器的初始理念相去甚远。而利用容器技术，软件可以快速在各类云服务和基础设施上转换。而且，当割裂问题被解决后，软件也有希望在瞬间获取大量的计算能力。
而Docker,就是容器引擎中的佼佼者，并且已经得到了广泛的实践和应用。有了Docker之后，软件的开发工作将会变得更加容易。如：开发者在笔记本电脑上写完一个软件后，可以将它转移到云服务上运行而无需做出更改；无论是自己的服务器、数据中心还是Google、微软、阿里云的云计算服务器，开发人员都可以按自己的想法在任何基础设施之间转移自己的软件。这也是未来的一个愿景——————机器和基础设施之间是可以互相替代的，整个互联网就是一个巨大的计算机。
Docker是如此的令人向往和引人深入，但是在国内，开发者普遍迁移到云端基本上也都是只用到了虚拟机等基础设施，其实大家都听过Docker,但是有一些偏见：
- 缺乏完整的系统的教程和实践。开发者普遍认为使用Docker很麻烦，只有大公司用，门槛高‘
- 云端容器服务产品用户体验不多，对于初学者门槛太高——————此处是指消化这列概念和理念，并且能够掌握和可控。
- 对容器服务的认知还不够，对它的好处及吸引之处不太了解。
- 认为对现有系统、架构改造太大，成本太高；
- 认为Docker只是一种单纯的相对先进的技术，并不能给现有的开发带来什么概念；
1 什么是Docker
Docker是一个开源的应用容器引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者在本地编译通过的容器可以批量的在生产环境中部署，包括VMs(虚拟机)、bare metal、OpenStack集群和其他的基础应用平台。
简单理解，Docker类似于集装箱，各式各样的货物，经过集装箱的标准化进行托管，而集装箱和集装箱之间没有影响。也就是说，Docker平台就是一个软件集装箱化平台，这就意味着我们可以构建应用程序，将其依赖关系一起打包到一个容器中，然后这容器就很容易运送到其他的机器上进行运行，而且非常易于装载、复制、移除，非常适合软件弹性架构。
因此，就像船只、火车或卡车运输集装箱而不论其内部的货物一样，软件容器就充当着 软件部署 的标准单元，其中可以包含不同的代码和依赖项。按照这种方式的容器化软件。开发人员和IT专业人员只需要进行极少修改或者不修改，即可将其部署到不同的环境。
总而言这，Docker是一个开放平台，使开发人员和管理员可以在称为容器的松散隔离的环境中构建镜像、交付和运行分布式应用程序。以便在开发、QA和生产环境之间进行高效的应用程序生命周期管理。
2 Docker和虚拟机的区别
如上图所示，由于容器所需的资源要少很多（例如，他们不需要一个完整的OS），所以它们易于部署且可以快速启动、这使得你能够具有更高部署密度。即允许在同一硬件单元上运行更多服务，从而降低了成本。
在同一内核上运行的时候，你获得的隔离比VM少。
镜像的主要目标是使环境（依赖项）在不同的部署中保持不变。，即可以在计算机上调试它，然后将其部署到保证具有相同环境的另一台计算机上。
借助容器镜像，可打包应用或者服务 并采用可靠且可重现的方式对其进行部署。可以说Docker不只是一种技术，还是一种原理和过程。
在使用Docker之前，经常听到，“这个问题在开发环境是正常的！”。而在使用Docker后，你不会听到开发人员说：“为什么它能在我的计算机上使用却不能用在生产中？”。开发人员只需要说 “它在Docker上运行”，因为打包的Docker应用程序可在任何支持的Docker环境上执行，而且它在所有部署目标（开发、QA、暂停和生产）上都按期运行。
3 基本概念
3.1 镜像：一个特殊的文件系统
操作系统分为内核和用户空间。对于Linux而言，内核启动后，会挂在root文件系统为其提供用户空间支持。而Docker镜像相当于是一个root文件系统。
Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（匿名卷、环境变量、用户等）。
镜像是不包含任何动态数据，其内容在构建之后也不会被改变。
Docker设计时。就充分利用 Union FS技术，将其设计为分层存储的架构。镜像实际是由多层文件系统联合组成。
镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。
比如：删除前一层文件的操作，实际上不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。
在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。
因此，在构建镜像时，需要额外小心，每一层尽量只包含该层需要添加的东西，任何额外的东西应该在该层构建结束前清理掉。
分层存储的特征还使得镜像的复用、定制变得更为容易，甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的容器，构建新的镜像。
3.2 容器：镜像运行时的实体
镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中 类 和 实例一样，镜像时静态的定义，容器是进行运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己独立的命名空间，前面说过镜像使用的是分层存储，容器也是如此。
容器存储层的生命周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。
按着Docker最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态变化。
所有文件的写入操作，都应该使用数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。
数据卷的生命周期独立于容器，容器消亡，数据卷不会消亡。因此使用数据卷后，容器可以随意删除、重新run，数据却不会丢失。
注意：
容器在整个应用程序生命周期工作流中提供以下优点：隔离性、可移植性、灵活性、可伸缩性和可控性。最重要的优点是可在开发和运营之间提供隔离。
3.3 仓库：集中存放镜像文件的地方
镜像构建完成后，可以很容易的在当前宿主上运行，但是，如果需要在其他服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务。Docker Registry就是这样的服务。
一个Docker Registry 中可以包含多个仓库（Repository）:每个仓库可以包含多个标签（Tag）;每个标签对应一个镜像。
所以说，镜像仓库是Docker用来集中存放镜像文件的地方，类似于我们之前的代码仓库。
通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。
我们可以通过<仓库名>:<标签>的格式来指定具体是这个软件那个版本的镜像。如果不给出标签，将以latest作为默认标签。
这里补充一下：Docker Registry公开服务和私有 Docker Registry 的概念。
一般这类公共服务允许用户免费上传、下载公开镜像，并可能提供收费服务供用户管理私有镜像。
最常用的Registry 公开服务是官方的 Docker Hub，这也是默认的Registry，并拥有大量的高质量的官方镜像。
在国内访问Docker Hub可能比较慢，国内有一些云服务商提供类似于Docker Hub的公开服务。
除了公开服务外，用户还可以在本地搭建私有Docker Registry。Docker官方提供了 Docker Registry 镜像，可以直接使用作为私有Registry服务。
开源的 Docker Registry 镜像只提供了 Docker Registry API的服务端实现，足以支持Docker命令，不影响使用，但不含图形界面，以及镜像维护、用户管理、访问控制等高级功能。
4 Docker的主要应用场景
4.1 简化配置
虚拟机的最大好处是能在你的硬件设施上运行各种配置不一样的平台（软件、系统），Docker在降低额外开销的情况下提供了同样的功能。它能让你将运行环境和配置放在代码中然后部署，同一个Docker的配置可以在不同的环境中使用，这样就降低了硬件要求和应用环境之间耦合度。
简单来说，容器镜像打包完成后，它就是个独立的个体了，丢到哪里都能跑，而无需针对各个平台去独立配置。
4.2 代码流水线（Code Pipeline）管理
前一个场景对于管理代码的流水线起到了很大的帮助。代码从开发者的机器到最终在生产环境上的部署，需要经过很多的中间环境。而每一个中间环境都有自己微小的差别，Docker给应用提供了一个从开发到上线均一致的环境，让代码的流水线变得简单不少。
4.3 提高开发效率
不同的开发环境中，我们都想把两件事做好。一是我们想让开发环境尽量贴近生产环境，二是我们想要快速搭建开发环境。
使用Docker非常简单的就能实现这两点，哪怕是开发环境的机器配置一般的情况下搭建多个生产服务应用。一台一般配置服务器或者开发机器也能轻松的跑起多个Docker应用，而无需额外增加机器配置。因为Docker有个非常NB的特性，拥有虚拟化的特性，而几乎没有额外的开销。
4.4 隔离应用
很多情况下，我们需要在一台服务器上运行多个不同的应用，比如上面提到的提高开发效率的场景等。
考虑三点：一是因为要降低成本而进行服务器整合，二是讲一个整体式的应用拆分成松耦合的单个服务（如微服务架构），三是还需要考虑应用之间的兼容性。而对于Docker来说，支持起来非常简单。同一台机器，可以同时运行N个Docker Web应用，托管到不同的Web服务器（Kestrel、Nginx、Tomcat），而无需担心他们会搞起3Q大战，也不用担心开发机器跑步起来。
4.5 整合服务器
虚拟机可以整合多个应用，Docker隔离应用的能力使得Docker可以整合多个服务器以降低成本。由于没有多个操作系统的内存占用，以及能在多个实例之间共享没有使用的内存，Docker可以比虚拟机提供更好的服务器整合解决方案。
这意味着资源得到更有效的利用——————可以做更多的衣服，而且没有边角料，成本更低。
4.6 调试能力
Docker提供很多的工具，这些工具不一定只是针对容器，但是却适用于容器。它们提供了很多功能，包含可以设置容器检查点、设置版本和查看两个容器之间的差别，这些特性可以帮助调试Bug。
4.7 多租户环境
在多租户的应用中，它可以避免关键应用的重写。比如IoT(物联网)的应用中，开发一个快速、易用的多租户环境。这种多租户的基本代码非常复杂，很难处理，重新规划这样一个应用不但消耗时间、也浪费金钱。
使用Docker，可以为每一个租户的应用层的多个实例创建隔离的环境，这不仅简单而且成本低廉，当然这一切得益于Docker环境的启动速度和其高效的diff命令。
就如同我们现在写了一个不支持多租户的业务程序，而实际的业务中经常会出现需要支持多租户或者有新客户需要使用的场景，这时们通常的简单是——————部署一套新的代码。当站点达到一定量的适合，要么重写程序，要么维护人员Game Over。
4.8 快速部署
在虚拟机之前，引入新的硬件资源需要消耗几天的时间。虚拟化技术（Virtualization）将这个时间缩短到了分钟级别。而Docker通过为进程仅仅创建一个容器而无需启动一个操作系统，再次将这个过程缩短到了秒级。
你可以在服务器中或云端创建销毁资源而无需担心重新启动带来的开销。通常情况下，服务器的资源利用率只有30%，而通过使用Docker并进行有效的资源分配可以提高资源的利用率。
Docker 带来的敏捷性（响应速度和灵活性）吸引了越来越多的开发者。他们不仅能知道容器内部到底跑了什么，也能进一步理解 Docker 如何加速了软件开发进程。另外，41% 的用户表示应用的可移植性是他们决定使用 Docker 的关键因素。
通过 DevOps 的实践，Docker 正在给应用交付带来很多可以量化的提升
大约一半的受访者表示已经采用了持续集成（CI）和 DevOps，并且希望把这些实战经验应用到生产环境的持续交付中。剩下的受访者则准备尽快跟上步伐，尽快尝试 DevOps 和持续集成。另外，据调查显示，用户使用 Docker 发布应用的频率平均提升了 13 倍。
Docker 对混合云策略至关重要，它使得用户可以根据需求自由选择私有和公有环境
通过容器来交付的应用可以在任何基础设施之上灵活迁移，同时这些基础设施又可以提供不同层次的应用管理方式，而当业务在多个服务供应商之中寻求混合云或全云模式时，又可以完美避免被平台捆绑。
对于按需部署或部署到云环境，Docker 提供了独一无二的选择。 80% 的用户表示 Docker 已经成为他们云策略的一部分，超过 35% 的用户使用 Docker 来避免被云服务供应商绑定。
Docker 实现了微服务架构，也让遗留的单体应用转变为现代应用
Docker 使得微服务架构的快速发展成为可能，同时它也将传统的业务迁移到容器环境中，以此使得应用程序变得更加可移植。使用微服务架构进行交付是 Docker 的关键优势！
5 Docker改变了什么？
Docker改变了云服务，使云服务的共融共通的理想逐步成为了可能。并且Docker 已经是云策略的一部分，许多开发者正在计划使用 Docker 将业务迁移到云端。另外，为了避免被云服务供应商绑定，Docker成为很多开发者的首选。
Docker改变了产品交付，为产品的整个生命周期提供了一整套的解决方案和流程。
Docker改变了开发方式，提供了简化的环境配置、封装的运行环境以及统一的环境。并且提供了快速部署的方式。
Docker改变了测试，多版本测试变得极为方便，快速构建测试环境也变得更加简单并且无需开发人员干预或者搭建。
Docker改变了运维，环境的一致性让运维变得更加简单，同时热更新的支持让运维不再需要半夜加班部署更新，更新可以随时进行。当出现重大问题时，还能快速回滚到指定版本。
Docker改变了架构，自动化扩容支持让架构变得更加简单，分布式系统也更加易于搭建和支持。同时遗留的单体应用也很易于转变为现代应用。
总之，在某种程度上，Docker改变了产品开发中的一些游戏规则。虽然Docker是一项技术，但是它也带来了新的思维，新的流程和工作方法，Docker在推动行业的发展，Docker已经在改变世界，并且在逐步的变为事实……
6 Docker持续开发工作流
7 DockerFile
虽然我们可以通过docker commit命令来手动创建镜像，但是通过Dockerfile文件，可以帮助我们自动创建镜像，并且能够自定义创建过程。本质上，Dockerfile就是由一系列命令和参数构成的脚本，这些命令应用于基础镜像并最终创建一个新的镜像。它简化了从头到尾的构建流程并极大的简化了部署工作。使用dockerfile构建镜像有以下好处：
像编程一样构建镜像，支持分层构建以及缓存；
可以快速而精确地重新创建镜像以便于维护和升级；
便于持续集成；
可以在任何地方快速构建镜像
7.1 Dockerfile 指令
Dockerfile 指令为 Docker 引擎提供了创建容器映像所需的步骤。这些指令按顺序逐一执行。
7.1.1 FROM
ROM 指令用于设置在新镜像创建过程期间将使用的容器映像。
格式：FROM
示例：
FROM nginx
7.1.2 RUN
RUN 指令指定将要运行并捕获到新容器映像中的命令。 这些命令包括安装软件、创建文件和目录，以及创建环境配置等。
格式：
RUN [“”, “”, “”]
RUN
示例：
RUN apt-get update
RUN mkdir -p /usr/src/redis
RUN apt-get update && apt-get install -y libgdiplus
RUN [“apt-get”,”install”,”-y”,”nginx”]
注意：每一个指令都会创建一层，并构成新的镜像。当运行多个指令时，会产生一些非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。因此，在很多情况下，我们可以合并指令并运行，例如：RUN apt-get update && apt-get install -y libgdiplus。在命令过多时，一定要注意格式，比如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。使用换行符时，可能会遇到一些问题，具体可以参阅下节的转义字符。
7.1.3 COPY
COPY 指令将文件和目录复制到容器的文件系统。文件和目录需位于相对于 Dockerfile 的路径中。
式：
COPY
如果源或目标包含空格，请将路径括在方括号和双引号中。
COPY [“”, “”]
示例：
COPY . .
COPY nginx.conf /etc/nginx/nginx.conf
COPY . /usr/share/nginx/html
COPY hom* /mydir/
7.1.4 ADD
ADD 指令与 COPY 指令非常类似，但它包含更多功能。除了将文件从主机复制到容器映像，ADD 指令还可以使用 URL 规范从远程位置复制文件。
格式：
ADD
示例：
ADD https://www.python.org/ftp/python/3.5.1/python-3.5.1.exe /temp/python-3.5.1.exe
此示例会将 Python for Windows下载到容器映像的 c:\temp 目录。
7.1.5 WORKDIR
WORKDIR 指令用于为其他 Dockerfile 指令（如 RUN、CMD）设置一个工作目录，并且还设置用于运行容器映像实例的工作目录。
格式：
WORKDIR
示例：
WORKDIR /app
7.1.6 CMD
CMD指令用于设置部署容器映像的实例时要运行的默认命令。例如，如果该容器将承载 NGINX Web 服务器，则 CMD 可能包括用于启动Web服务器的指令，如 nginx.exe。 如果 Dockerfile 中指定了多个CMD 指令，只会计算最后一个指令。
格式：
CMD [“<executable”, “
CMD
示例：
CMD [“c:\Apache24\bin\httpd.exe”, “-w”]
CMD c:\Apache24\bin\httpd.exe -w
7.1.7 ENTRYPOINT
配置容器启动后执行的命令，并且不可被 docker run 提供的参数覆盖。每个 Dockerfile 中只能有一个ENTRYPOINT，当指定多个时，只有最后一个起效。
格式：
ENTRYPOINT [“”, “”]
示例：
ENTRYPOINT [“dotnet”, “Magicodes.Admin.Web.Host.dll”]
7.1.8 ENV
ENV命令用于设置环境变量。这些变量以”key=value”的形式存在，并可以在容器内被脚本或者程序调用。这个机制给在容器中运行应用带来了极大的便利。
格式：
ENV==…
示例：
ENV VERSION=1.0 DEBUG=on
NAME=”Magicodes”
7.1.9 EXPOSE
EXPOSE用来指定端口，使容器内的应用可以通过端口和外界交互。
格式：
EXPOSE
示例：
EXPOSE 80
8 优化
有几点值得注意的是：
不能忽视dockerfile的优化，通常情况下，我们可以忽略那些细小的优化，但是我们需要知道优化的原理，为什么要优化
不能为了优化而优化。镜像的构建过程视业务情况情况不同，指令就有多到少的区别，在很多情况下，我们先要以满足业务目标为准，而不是镜像层数。如果需要减少镜像的层数，我们一定要选择合适的基础镜像，或者创建符合我们需要的基础镜像。
优化准则：
选择合适的基础镜像
这点相对最为重要。为什么这么说，我们结合现实社会也可以看到，在大部分情况下，一个人一生的成就更多的是看出身。很多情况下，基因和出身决定了你的高度和终点，这点拿到技术层面来说，也是有很大道理的，因此我们需要选择合适的父母——一个合适的镜像。
一个合适的基础镜像是指能满足运行应用所需要的最小的镜像，理论上是能用小的就不要用大的，能用轻量的就不要用重量级的，能用性能好的就不要用性能差的。这里有时候还需要考虑那些能够减少我们构建层数的基础镜像。
优化指令顺序
Docker会缓存Dockerfile中尚未更改的所有步骤，但是，如果更改任何指令，将重做其后的所有步骤。也就是指令3有变动，那么4、5、6就会重做。因此，我们需要将最不可能产生更改的指令放在前面，按照这个顺序来编写dockerfile指令。这样，在构建过程中，就可以节省很多时间。比如，我们可以把WORKDIR、ENV等命令放前面，COPY、ADD放后面。
合并指令
前面其实我们提到过这点，甚至还特地讲到了转义字符，其实主要是为此服务。前面我们说到了，每一个指令都会创建一层，并构成新的镜像。当运行多个指令时，会产生一些非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。因此，在很多情况下，我们可以合并指令并运行，例如：RUN apt-get update && apt-get install -y libgdiplus。在命令过多时，一定要注意格式，比如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。
删除多余文件和清理没用的中间结果
这点很易于理解，通常来讲，体积更小，部署更快！因此在构建过程中，我们需要清理那些最终不需要的代码或文件。比如说，临时文件、源代码、缓存等等。
使用 .dockerignore
.dockerignore文件用于忽略那些镜像构建时非必须的文件，这些文件可以是开发文档、日志、其他无用的文件。例如:
9 创建自定义Docker镜像
创建了Dockerfile之后，需为应用程序中的每项服务创建一个相关镜像。如果应用程序由单个服务或 Web 应用程序组成，则只需创建一个镜像。
我们可以使用docker build命令来创建镜像，例如：
docker build ./ -t {镜像名称}
镜像打包好后，我们使用docker image ls命令即可查看当前镜像。
注意：Docker镜像使用分层存储的架构，也就是说镜像实际是由多层文件系统联合组成。镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。因为分层存储的特征，使得镜像的复用、定制变的更为容易。甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的内容，构建新的镜像。所以，当我们使用Docker images命令，会列出这么多的镜像，我们可以定期清理那些无用的镜像。
10 在 docker-compose.yml中定义服务
10.1 关于 Compose
Compose是一个用于定义和运行多Docker应用程序的工具。使用Compose，我们可以使用YAML文件来配置应用程序的服务。然后，使用单个命令，我们就可以从配置中创建并启动所有服务。
Compose适用于所有环境：生产环境、模拟（演示）环境、开发环境和测试环境以及CI工作流程。
主要功能和特性：
单个主机上的多个隔离环境
Compose使用项目名称来隔离环境，因此可以根据不同的环境要求来进行定义。
创建容器时保留卷数据
Compose会保留服务使用的所有卷和数据。当使用docker-compose up命令运行时，如果发现该服务之前运行过，它会将进行增量操作，可确保在卷中创建的数据都不会丢失。
仅重新创建已更改的容器
Compose存在缓存，可用于创建容器。当重新启动未更改的服务时，Compose将重用现有容器。
可以定义变量，而且可以根据不同环境不同用户之间进行组合使用
Compose支持Compose文件的变量定义，我们可以使用这些变量为不同环境或不同用户进行自定义组合。
另外，Compose能够通过命令管理应用程序的整个生命周期，通过命令可以：
启动，停止和重建服务等
查看正在运行的服务的状态
通过流输出正在运行的服务的日志
对某个服务执行命令
11 常见场景
开发或本地环境运行多个服务
在开发过程时，在隔离环境中运行应用程序并与之交互的能力至关重要。Compose命令行工具可用于创建环境并与之交互。比如通过Compose文件，配置所有应用程序的服务依赖（数据库，消息队列，高速缓存，Web服务的API，等等），然后使用单个命令（docker-compose up）为每个依赖项创建和启动一个或多个容器，使整个程序能够正常运行起来。
自动化测试环境
任何持续部署或持续集成过程的一个重要部分是自动化测试套件。自动化端到端测试需要一个运行测试的环境。Compose提供了一种方便的方法来创建和销毁隔离的测试环境。我们只需要通过在Compose文件，即可定义完整环境，并且可以在几个命令中创建和销毁这些环境，如下所示：
12 使用Compose
使用Compose有以下三个步骤：
使用Dockerfile定义应用环境，以便在任意地方进行复制
在 docker-compose.yml 中定义组合应用，以便它们可以在隔离的环境中一起运行
最后，执行docker-compose up命令，Compose 将启动并运行整个应用程序。
13 了解docker-compose.yml
借助 docker-compose.yml 文件，我们可以定义一组相关服务，通过部署命令将其部署为组合应用程序。简单的说，我们可以通过docker-compose.yml来定义多个服务，以便一次执行。
14 了解YAML语言
YAML 是一种简洁的非标记语言。YAML以数据为中心，使用空白，缩进，分行组织数据，从而使得表示更加简洁易读。
这里提供一个YAML语法验证网站：http://nodeca.github.io/js-yaml/
基本规则
大小写敏感
使用缩进表示层级关系
禁止使用tab缩进，只能使用空格键
缩进长度没有限制，只要元素对齐就表示这些元素属于一个层级
使用#表示注释
字符串可以不用引号标注
YAML中允许表示三种格式，分别是常量值，对象和数组，如下所示：
15 docker-compose.yml文件配置项
docker-compose.yml 文件不仅指定正在使用的容器，还指定如何单独配置各容器。常用的配置项如下所示：
uild：定义镜像生成，可以指定Dockerfile文件所在的目录路径，支持绝对路径和相对路径；
image：从指定的镜像中启动容器，可以是存储仓库、标签以及镜像 ID，如果镜像不存在，Compose 会自动拉去镜像；
environment：定义环境变量和配置；
ports：定义端口映射，比如上面配置中将容器上的公开端口 80 转接到主机上的外部端口 9901和9902；
depends_on，定义依赖关系。此定义会让当前服务处于等待状态，直到这些依赖服务启动。比如某个服务依赖数据库服务，那么通过此配置解决了服务的启动顺序的问题；
volumes，挂载一个目录或者一个已存在的数据卷容器，可以直接使用 HOST:CONTAINER 这样的格式，或者使用 HOST:CONTAINER:ro 这样的格式，后者对于容器来说，数据卷是只读的，这样可以有效保护宿主机的文件系统；
context，指定Dockerfile 的文件路径，也可以是到链接到 git 仓库的 url；
args,指定构建参数，这些参数只能在构建过程中访问；
target，定义构建指定的阶段Dockerfile，比如针对不同阶段使用不同的dockerfile，开发阶段使用支持编译调试的dockerfile，而生产环境，则使用轻量级的dockerfile；command，覆盖默认命令；
container_name，指定自定义容器名称，而不是生成的默认名称。
小技巧：
可以通过配置项depends_on来定义依赖关系，这点对于控制服务的执行顺序尤为重要，比如先启动数据库然后再启动web服务。
如何使用JSON文件进行配置？可以指定文件名称，如下所示：
docker-compose -f docker-compose.json up
如何分阶段构建？推荐使用target配置项。