Docker最全教程——从理论到实战(一)

容器是应用走向云端以后必然的发展趋势，所以笔者很是乐于和你们分享咱们这段时间对容器的理解、心得和实践。

本篇教程持续编写了2个星期左右，只是为了你们更好地了解、理解和消化这个技术，可以搭上这波车。

你能够和咱们一块儿讨论，咱们但愿可以多多交流，多多分享。

若是以为不错，请多多点赞，大家的支持是咱们前进的最大动力！

 

目录

前言

随着生产力的发展尤为是弹性架构的普遍应用（好比微服务），许多一流开发者都将应用托管到了应用容器上，好比Google、微软、亚马逊、腾讯、阿里、京东和新浪。

 

 

从将来的发展方向来看，容器引擎将会愈来愈成为主流，哪怕不是弹性架构，托管到应用容器也将是一种趋势——由于更低的开发运维和托管成本以及对服务器的资源的优化配置。并且将来一个很大的趋势是——无服务器计算服务。

由于相对于软件、硬件在本地设备中的分裂，云计算的一大特性就是将服务构建在云上，供多种设备同时无缝调用。但事实上，云服务在发展的过程当中还没能实现共融共通的理想——好比，各家的云服务是相对割裂的，开发者基于Google云服务构建的软件拿到亚马逊的AWS上也许就不能用了，阿里云的应用迁移到腾讯云可能就存在问题了；在任务执行层面，为防止互相干扰，云服务厂商在同一台服务器上执行多个任务时也会将它们隔离进行。很明显，这样的实际状况和云服务的初始理念相去甚远。而利用容器技术，软件能够快速在各种云服务和基础设施上转换。并且，当割裂问题被解决以后，软件也有望在瞬间获取大量的计算能力。

 

而Docker，就是容器引擎中的佼佼者，而且已经获得了普遍的实践和应用。有了Docker以后，软件的开发工做将会变得更加容易。好比，开发者们在笔记本电脑上写完一个软件后，能够将它转移到云服务上运行而无需作出更改；不管是本身的服务器、数据中心仍是Google、微软、阿里云的云计算服务器，开发人员均可以按本身的想法在任何基础设施之间转移本身的软件。这也是将来的一个愿景——机器和基础设施是能够互相替代的，整个互联网就是一个巨大的计算机。

Docker是如此使人向往和引人深刻，可是在国内，开发者广泛迁移到云端基本上也都是只用到了虚拟机等基础设施，其实你们都据说过Docker，可是老是有一道门槛挡在你们面前致使你们没法逾越或者产生了一些偏见：

• 缺少完整的系统的教程和实践，开发者广泛认为使用Docker很麻烦，只有大公司能用，门槛很高；

• 云端容器服务产品用户体验不够，对于初学者门槛过高——这个过高指的是消化这些概念和理念，而且可以掌握和可控；

• 对容器服务的认知还不够，对它的好处以及吸引之处还不太了解；

• 认为对现有系统、架构改造太大，成本过高；

• 认为Docker只是一种单纯的相对先进的技术，并不能给现有的开发带来什么改变；

 

什么是Docker

Docker 是一个开源的应用容器引擎，能够轻松的为任何应用建立一个轻量级的、可移植的、自给自足的容器。开发者在本地编译测试经过的容器能够批量地在生产环境中部署，包括VMs（虚拟机）、bare metal、OpenStack 集群和其余的基础应用平台。

简单的理解，Docker相似于集装箱，各式各样的货物，通过集装箱的标准化进行托管，而集装箱和集装箱之间没有影响。也就是说，Docker平台就是一个软件集装箱化平台，这就意味着咱们本身能够构建应用程序，将其依赖关系一块儿打包到一个容器中，而后这容器就很容易运送到其余的机器上进行运行，并且很是易于装载、复制、移除，很是适合软件弹性架构。

所以，就像船只、火车或卡车运输集装箱而不论其内部的货物同样，软件容器充当软件部署的标准单元，其中能够包含不一样的代码和依赖项。 按照这种方式容器化软件，开发人员和 IT 专业人员只需进行极少修改或不修改，便可将其部署到不一样的环境。

总而言之，Docker 是一个开放平台，使开发人员和管理员能够在称为容器的松散隔离的环境中构建镜像、交付和运行分布式应用程序。以便在开发、QA 和生产环境之间进行高效的应用程序生命周期管理。

 

Docker和虚拟机的区别

如上图所示，因为容器所需的资源要少得多（例如，它们不须要一个完整的 OS），因此它们易于部署且可快速启动。这使你可以具备更高的密度，也就是说，这容许你在同一硬件单元上运行更多服务，从而下降了成本。

在同一内核上运行的反作用是，你得到的隔离比 VM 要少。

镜像的主要目标是使环境（依赖项）在不一样的部署中保持不变。 也就是说，能够在计算机上调试它，而后将其部署到保证具备相同环境的另外一台计算机上。

借助容器镜像，可打包应用或服务并采用可靠且可重现的方式对其进行部署。能够说 Docker 不仅是一种技术，仍是一种原理和过程。

在使用Docker以前，咱们常常会听到，“这个问题在开发环境是正常的！”。而在使用 Docker 后，你不会听到开发人员说：“为何它能在个人计算机上使用却不能用在生产中？”。开发人员只需说“它在 Docker 上运行”，由于打包的 Docker 应用程序可在任何支持的 Docker 环境上执行，并且它在全部部署目标（例如，开发、QA、暂存和生产）上都按预期运行。

 

基本概念

镜像：一个特殊的文件系统

操做系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就至关因而一个 root 文件系统。

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。

镜像不包含任何动态数据，其内容在构建以后也不会被改变。

Docker 设计时，就充分利用 Union FS 的技术，将其设计为分层存储的架构。 镜像实际是由多层文件系统联合组成。

镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在本身这一层。

好比，删除前一层文件的操做，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。

在最终容器运行的时候，虽然不会看到这个文件，可是实际上该文件会一直跟随镜像。

所以，在构建镜像的时候，须要额外当心，每一层尽可能只包含该层须要添加的东西，任何额外的东西应该在该层构建结束前清理掉。

分层存储的特征还使得镜像的复用、定制变的更为容易。甚至能够用以前构建好的镜像做为基础层，而后进一步添加新的层，以定制本身所需的内容，构建新的镜像。

 

容器：镜像运行时的实体

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例同样，镜像是静态的定义，容器是镜像运行时的实体。容器能够被建立、启动、中止、删除、暂停等 。

容器的实质是进程，但与直接在宿主执行的进程不一样，容器进程运行于属于本身的独立的命名空间。前面讲过镜像使用的是分层存储，容器也是如此。

容器存储层的生存周期和容器同样，容器消亡时，容器存储层也随之消亡。所以，任何保存于容器存储层的信息都会随容器删除而丢失。

按照 Docker 最佳实践的要求，容器不该该向其存储层内写入任何数据 ，容器存储层要保持无状态化。

全部的文件写入操做，都应该使用数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。所以， 使用数据卷后，容器能够随意删除、从新 run，数据却不会丢失。

注意：

容器在整个应用程序生命周期工做流中提供如下优势：隔离性、可移植性、灵活性、可伸缩性和可控性。 最重要的优势是可在开发和运营之间提供隔离。

 

仓库：集中存放镜像文件的地方

镜像构建完成后，能够很容易的在当前宿主上运行，可是， 若是须要在其余服务器上使用这个镜像，咱们就须要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

一个 Docker Registry 中能够包含多个仓库（Repository）；每一个仓库能够包含多个标签（Tag）；每一个标签对应一个镜像。

因此说，镜像仓库是 Docker 用来集中存放镜像文件的地方，相似于咱们以前经常使用的代码仓库。

一般，一个仓库会包含同一个软件不一样版本的镜像，而标签就经常使用于对应该软件的各个版本 。

咱们能够经过<仓库名>:<标签>的格式来指定具体是这个软件哪一个版本的镜像。若是不给出标签，将以 latest 做为默认标签。

这里补充一下 Docker Registry 公开服务和私有 Docker Registry 的概念：

Docker Registry 公开服务是开放给用户使用、容许用户管理镜像的 Registry 服务。

通常这类公开服务容许用户免费上传、下载公开的镜像，并可能提供收费服务供用户管理私有镜像。

最常使用的 Registry 公开服务是官方的 Docker Hub ，这也是默认的 Registry，并拥有大量的高质量的官方镜像，网址为：hub.docker.com/ 。

在国内访问 Docker Hub 可能会比较慢，国内也有一些云服务商提供相似于 Docker Hub 的公开服务。

除了使用公开服务外，用户还能够在本地搭建私有 Docker Registry 。Docker 官方提供了 Docker Registry 镜像，能够直接使用作为私有 Registry 服务。

 

开源的 Docker Registry 镜像只提供了 Docker Registry API 的服务端实现，足以支持 Docker 命令，不影响使用。但不包含图形界面，以及镜像维护、用户管理、访问控制等高级功能。

 

Docker的主要应用场景

简化配置

虚拟机的最大好处是能在你的硬件设施上运行各类配置不同的平台（软件、系统），Docker在下降额外开销的状况下提供了一样的功能。它能让你将运行环境和配置放在代码中而后部署，同一个Docker的配置能够在不一样的环境中使用，这样就下降了硬件要求和应用环境之间耦合度。

 

简单的来讲，容器镜像打包完成后，它就是个独立的个体了，丢到哪里都能跑，而无需针对各个平台去独立配置。

 

代码流水线（Code Pipeline）管理

前一个场景对于管理代码的流水线起到了很大的帮助。代码从开发者的机器到最终在生产环境上的部署，须要通过不少的中间环境。而每个中间环境都有本身微小的差异，Docker给应用提供了一个从开发到上线均一致的环境，让代码的流水线变得简单很多。

 

提升开发效率

不一样的开发环境中，咱们都想把两件事作好。一是咱们想让开发环境尽可能贴近生产环境，二是咱们想快速搭建开发环境。

 

使用Docker很是简单的就可以实现这两点，并且哪怕是开发环境的机器配置通常的状况下搭建多个生成服务应用。一台通常配置服务器或开发机也能轻松的跑起多个Docker应用，而无需额外增长机器配置。由于Docker有个很是NB的特性，拥有虚拟化的特性，而几乎没有额外的开销。

 

 

 

隔离应用

不少状况下，咱们须要在一台服务器上运行多个不一样的应用，好比上面提到的提升开发效率的场景等。

 

咱们常常须要考虑三点，一是由于要下降成本而进行服务器整合，二是将一个总体式的应用拆分红松耦合的单个服务（好比微服务架构），三是还须要考虑应用之间的兼容性。而对于Docker来讲，支持起来就很是简单了。同一台机器，我能够同时运行N个Docker web应用，托管到不一样的Web服务器（Kestrel、Ngnix、Tomcat），而无需担忧他们会搞起3Q大战，也无需担忧个人开发机器会跑不起来。

 

整合服务器

 

正如经过虚拟机来整合多个应用，Docker隔离应用的能力使得Docker能够整合多个服务器以下降成本。因为没有多个操做系统的内存占用，以及能在多个实例之间共享没有使用的内存，Docker能够比虚拟机提供更好的服务器整合解决方案。

 

这就意味着资源获得更有效的利用——能够作更多衣服，并且尚未边角料，成本还更低。

 

调试能力

Docker提供了不少的工具，这些工具不必定只是针对容器，可是却适用于容器。它们提供了不少的功能，包括能够为容器设置检查点、设置版本和查看两个容器之间的差异，这些特性能够帮助调试Bug。

 

 

多租户环境

在多租户的应用中，它能够避免关键应用的重写。好比IoT（物联网）的应用中，开发一个快速、易用的多租户环境。这种多租户的基本代码很是复杂，很难处理，从新规划这样一个应用不但消耗时间，也浪费金钱。

 

使用Docker，能够为每个租户的应用层的多个实例建立隔离的环境，这不只简单并且成本低廉，固然这一切得益于Docker环境的启动速度和其高效的diff命令。

 

就如同咱们如今写了一个不支持多租户的业务程序，而实际的业务中常常会出现须要支持多租户或者有新客户须要使用的场景，这是咱们一般的简单作法是——部署一套新的代码。当站点达到必定量的适合，要么重写程序，要么维护人员Game over。

 

快速部署

在虚拟机以前，引入新的硬件资源须要消耗几天的时间。虚拟化技术（Virtualization）将这个时间缩短到了分钟级别。而Docker经过为进程仅仅建立一个容器而无需启动一个操做系统，再次将这个过程缩短到了秒级。

 

你能够在服务器中或云端建立销毁资源而无需担忧从新启动带来的开销。一般状况下，服务器的资源利用率只有30%，而经过使用Docker并进行有效的资源分配能够提升资源的利用率。

 

市场实际反馈和调查

咱们来看一份2016年用户调查结果。

Docker为软件供应链提供了应用程序开发的敏捷性，可控性和可移值性

 

 

－ 用户如何使用 Docker？

• 90% 的用户使用 Docker 进行应用开发

• 65% 的用户使用 Docker 进行敏捷开发

• 58% 的用户将 Docker 用于生产

• 48% 的用户使用 Docker 控制应用环境

• 41% 的用户使用 Docker 实现应用的可移植性 

 － Docker 的业务覆盖：

• 78%：网页应用

• 75%：网页 API

• 70%：应用服务端

• 42％：传统数据库

• 27%：分布式数据库

• 13%：大数据

Docker 带来的敏捷性（响应速度和灵活性）吸引了愈来愈多的开发者。他们不只能知道容器内部到底跑了什么，也能进一步理解 Docker 如何加速了软件开发进程。另外，41% 的用户表示应用的可移植性是他们决定使用 Docker 的关键因素。

 

经过 DevOps 的实践，Docker 正在给应用交付带来不少能够量化的提高

 

如图所示：

• 93% 的 Docker 用户已经在开发过程当中得到了益处

• 85% 的 Docker 用户已经在运维过程当中得到了益处

• 57% 的 Docker 用户见证了运维环境管理的提高

• 45% 的 Docker 用户已经提升了软件发布的频率

大约一半的受访者表示已经采用了持续集成（CI）和 DevOps，而且但愿把这些实战经验应用到生产环境的持续交付中。剩下的受访者则准备尽快跟上步伐，尽快尝试 DevOps 和持续集成。另外，据调查显示，用户使用 Docker 发布应用的频率平均提高了 13 倍。

 

Docker 对混合云策略相当重要，它使得用户能够根据需求自由选择私有和公有环境

 

如图所示：

• 80％ 的用户表示 Docker 已是云策略的一部分

• 60% 的用户则正在计划使用 Docker 将业务迁移到云端。

• 41% 的用户但愿实现跨环境的应用移植

• 35+% 的用户但愿避免被云供应商绑定

经过容器来交付的应用能够在任何基础设施之上灵活迁移，同时这些基础设施又能够提供不一样层次的应用管理方式，而当业务在多个服务供应商之中寻求混合云或全云模式时，又能够完美避免被平台捆绑。

 

对于按需部署或部署到云环境，Docker 提供了独一无二的选择。 80% 的用户表示 Docker 已经成为他们云策略的一部分，超过 35% 的用户使用 Docker 来避免被云服务供应商绑定。

 

Docker 实现了微服务架构，也让遗留的单体应用转变为现代应用

 

如图所示：

• 65% 的组织面对遗留应用这一难题

• 59% 的组织受到遗留应用和基础设施僵化的影响

• 44% 的组织正在使用微服务架构

• 39% 的组织让遗留应用焕发新生

Docker 使得微服务架构的快速发展成为可能，同时它也将传统的业务迁移到容器环境中，以此使得应用程序变得更加可移植。使用微服务架构进行交付是 Docker 的关键优点！

 

Docker改变了什么？

综上所述，Docker到底改变了什么？笔者是这么理解的：

• Docker改变了云服务，使云服务的共融共通的理想逐步成为了可能。而且Docker 已是云策略的一部分，许多开发者正在计划使用 Docker 将业务迁移到云端。另外，为了不被云服务供应商绑定，Docker成为不少开发者的首选。

• Docker改变了产品交付，为产品的整个生命周期提供了一整套的解决方案和流程。

• Docker改变了开发方式，提供了简化的环境配置、封装的运行环境以及统一的环境。而且提供了快速部署的方式。

• Docker改变了测试，多版本测试变得极为方便，快速构建测试环境也变得更加简单而且无需开发人员干预或者搭建。

• Docker改变了运维，环境的一致性让运维变得更加简单，同时热更新的支持让运维再也不须要半夜加班部署更新，更新能够随时进行。当出现重大问题时，还能快速回滚到指定版本。

• Docker改变了架构，自动化扩容支持让架构变得更加简单，分布式系统也更加易于搭建和支持。同时遗留的单体应用也很易于转变为现代应用。

总之，在某种程度上，Docker改变了产品开发中的一些游戏规则。虽然Docker是一项技术，可是它也带来了新的思惟，新的流程和工做方法，Docker在推进行业的发展，Docker已经在改变世界，而且在逐步的变为事实……