特色栏目： python 批处理 net编程 Javascript Php Asp Css Html5 Android seo centos

当前位置 : 主页 > 编程语言 > python >

[Docker系列]1 认识Docker

来源：互联网收集：自由互联发布时间：2022-06-18

这周分享的内容是关于 Docker 的基础，大概的内容分为下面的两个部分，另外还做了个视频，其实这个视频仅仅用来娱乐娱乐而已前言第一趴---Docker容器圈简介第二趴---Docker基本操作

这周分享的内容是关于 Docker 的基础，大概的内容分为下面的两个部分，另外还做了个视频，其实这个视频仅仅用来娱乐娱乐而已

前言

第一趴---Docker容器圈简介

[Docker系列]1 认识Docker_压缩包

第二趴---Docker基本操作

[Docker系列]1 认识Docker_开发者_02

容器圈

容器这个新生事物，现在还可以说是新生事物吗？对于我们学生而言，我觉得没毛病，你说呢？
容器技术可说重塑了整个云计算市场的形态，带动了一批年轻有为的容器技术儿，不过「容器」这个概念是 Docker 公司发明的么，不是，它只是众多 Pass 项目中的最底层，没人关注的那一部分而已。

什么是Pass项目？

Pass 项目之所会被很多公司所接受，自然是因为解放了部分开发人员的劳动力，尽快干玩活儿早点下班。其依赖的就是「应用托管」的能力，在电脑上斗过地主的应该知道，托管了以后就会自动出牌，同样的道理，为了尽量的弥补本地和云上的环境差异，就出现了 Pass 开源项目。

举个例子来说，运维人员小仙云上部署一个 Cloud Foundry 项目，开发人员只需要简单的一行代码就可以实现将本地的应用部署到云上

[Docker系列]1 认识Docker_压缩包_03

就这样一行代码就实现了将本地应用上传到云上，属实很轻松。

那么这个命令执行的基本原理是怎样的？

实际上，我们可以将其最核心的组件理解为一套应用的打包和分发机制。云上部署的 Cloud Foundry 会为大部分编程语言定义一种打包的格式，当开发人员执行命令的时候，实际上是将可执行文件和启动脚本打包上传到云上的Coulud Foudry 中，然后 Cloud Foundry 通过相应的调度器选择一个虚拟机的 Agent 将压缩包下载后启动

那如何区分虚拟机中的不同应用呢？

虚拟机一般不可能只跑一个应用，因为这样确实也太浪费资源了，我们可以想想，现在手上的电脑，可以用 Vmvare 导入几个虚拟机，所以诸如 Cloud Foundry 通过引入操作系统的 Cgroups 和 Namespace 等机制，从而来为每个应用单独创建一个叫做「沙盒」的隔离环境，然后在这些「沙盒」中启动应用，通过这样的方法就让虚拟机中应用各自互不干扰，让其自由翱翔，至于 Cgroups 和 Namespace 的实现原理，后续我们再共同的探讨

这里所谓的隔离环境就是「容器」。

那 Docker 和这 Pass 项目的 Cloud Foundry 的容器有啥不一样？

自然不一样，不然现在我们一旦提到容器，想到的不会是 Docker，而是 Cloud Foundry 了吧。Cloud Foundry 的首席产品经理就觉得没什么，毕竟自己放的屁都是香的！

不一样，而且当时还发了一份报告，报告中还写到：“ Docker 不就是使用了 Cgroups 和 Namespace 实现的「沙盒」而已，不用过于关注”。

没想到的是，随后短短的几个月，Docker 项目迅速起飞以至于其他所有 Paas 社区都还没来及反应过来，就已经宣告出局

什么魔力让 Docker 一发不可收拾？

就是提出了镜像的概念。上面我们说过，Paas 提供的一套应用打包的功能，看起很轻松省事，但是一旦使用了Paas，你就要终身服务于它，毕竟他是提供商，是「爸爸」，用户需要为每个版本，每种语言去维护一个包，这个打包的过程是需要多次的尝试，多次试错后，才能摸清本地应用和远端 Paas 的脾气，从而顺利部署。

而 Docker 镜像恰恰就是解决了打包这一根本问题。

什么是Docker镜像？

Docker 镜像也是一个压缩包，只是这个压缩包不只是可执行文件，环境部署脚本，它还包含了完整的操作系统。因为大部分的镜像都是基于某个操作系统来构建，所以很轻松的就可以构建本地和远端一样的环境。

这就很牛皮了，如果我们的应用是在 Centos7 上部署，我们只需要将项目环境部署在基于 Centos7 的环境中，然后无论在哪里去解压这个压缩包，都可以保证环境的一致性。在整个过程中，我们根本不需要进行任何的配置，因为这个压缩包可以保证：本地的环境和云端是一致的，这也是 Docker 镜像的精髓

开发者体验到了 Docker 的便利，从而很快宣布 Paas 时代的结束，不过对于大规模应用的部署，Docker 能否实现在当时还是个问号

就在 2014 年的 DockerCon 上，紧接着发布了自研的「Docker swarm」，Docker 就这样一度奔向高潮，即将就到达了自己梦想之巅。

为什么会推出Docker Swarm?

虽然 Docker 通过「容器」完成了对 Paas 的「降维打击」，但是 Docker 的目的是：如何让更多的开发者将项目部署在自己的项目上，从技术，商业，市场多方位的争取开发者的群体，为此形成自家的 Paas 平台做铺垫

Docker 项目虽然很受欢迎，就目前看来只是一个创建和启动容器的小工具。需要应该清楚的一点是，用户最终部署的还是他们的网站，服务甚至云计算业务。所以推出一个完整的整体对外提供集群管理功能的 Swarm 势在必行，这个项目中的最大亮点即直接使用了 Docker 原生的 API 来完成对集群的管理。

对于单机项目，只需要执行下面一条语句即可实现容器

[Docker系列]1 认识Docker_docker_04

对于多机的项目，只需要执行

[Docker系列]1 认识Docker_开发者_05

你看，从单机切换到多机，使用的方法也就参数不同而已，所以这样一个原生的「Docker容器集群管理」一发布就受到大家的青睐。随着自身生态的逐渐完善，借助这一波浪潮并通过各种并购来强大自己的平层能力

要说最成功的案例，非 Fig 项目莫属。之所以这么屌，是因为作者提出了「容器编排」的概念。

什么是容器编排？

其实这也不是什么新鲜内容，比如在 Linux 中的 Makefile和常见的 SHELL 脚本，它是一种通过工具或者配置来完成一组虚拟机或者关联资源的定义、配置、创建等工具。

容器的编排是怎么样的呢

我们先以 Fig 为例，假设开发人员小黑，现在要部署一个项目，其中包含了应用容器 A，数据库容器 B，负载容器 C，这个时候 Fig 只需要将三个容器定义在一个配置文件，然后指定他们的关联关系，执行下面的命令即可

[Docker系列]1 认识Docker_docker_06

当然也可以在 Fig 的配置文件中配置各种容器的副本，然后加上 Swarm 的集群管理功能，这样不就是 Paas 了么。只是这个项目被收购以后，修改名字为 compose 了，后续也会的 compose 进行详细的阐述

就这样一个以「鲸鱼」为商标的 Docker，火遍全球，因为它秉持将「开发者」群体放在食物链的顶端。一分钟实现网站的部署，三分钟搭建集群，这么多年以来，很多后端开发者很少将眼光放在 Linux 技术上，开发者们为了深入的了解 Docker 的技术原理，终于将眼光放入诸如 Cgroups 和 Namespace 技术中。

就在这一时之间，后端及云计算领域的大佬都汇聚于这个「小鲸鱼」的身边。随后到了考虑集群的方案，论集群的管理调度能力，还不得不提 Berkeley 的 Mesos，专注于大数据领域，更加关注的是计算密集型的业务。凭借着它天生的两层调度机制，让它很快发布了一个叫做 Marathon 的项目，这个项目随即成为了 Swarm 的有力竞争对手。

这还没完，说了这么久，还没有提到在基础设施领域翘楚的 Google 公司，是的，同在这一年，宣告了一个叫做 Kubernetes 项目的诞生。

随着 Docker 生态的建立，Docker swarm，Docker compose，Machine 形成了三件套，此时大量围绕Docker 项目的网络，存储，监控都涌现。在令人兴奋的背后，是对它更多的担忧，这主要来源于对 Docker 商业化战略的顾虑，Docker 公司对于 Docker 着绝对的权威并在多个场合直接和谷歌，微软对干

其实在 Docker 兴起的时候，谷歌也开源了一个 Linux 容器：Imctfy，在当时这个项目在 Docker 面前真是弟弟，所以向 Docker 公司表示想合作的意愿，Docker 显然不同意，且在之后的不久自己发布了一个容器运行时的库 Libcontainer，可能由于太急躁，其代码可读性极差，不稳定和频繁的变更，让社区叫苦不迭

为了切割 Docker 项目的话语权，决定成立一个中立的基金会。所以于 2015 年将这个 Libcontainer 捐出，并修改名称为 Runc，然后依据 RunC 项目，制定了一套容器和镜像的标准和规范----OCI

什么是OCI

为了让 Docker 不能太嚣张，其他玩家构建自身平台的时候不依赖于 Docker 项目，提出一个标准和规范----OCI。这一标准并没有改变 Docker 在容器领域一家独大的现状。Google 坐不住了，必须得搞点大招

Google 给 RedHat 等伙伴打了电话，说咱们共同牵头发起一个基金会-----CNCF。目的很简单，以 kubernetes 为基础，建立一个以由开源基础设置主导，按照独立基金会方式运营的平台级社区，来对抗 Docker 公司为核心的容器商业生态
为了做好这个事儿，CNCF 必须完成两件事儿

必须在编排领取足够的优势
CNCF 必须以 kubernetes 为核心，覆盖更多的场景

CNCF 如何解决第一个问题----编排能力

Swarm 的无缝集成以及 Mesos 的大规模集群的调度管理能力，很明显，如果继续往这两个方向发展，后面的路不一定好走。所以，kubernetes 选择的方式是 Borg，其基础特性是 Google 在容器化基础设施多年来实践的经验，这也正是项目从一开始就避免了和 Swarm ，mesos 社区同质化的重要手段

看似很有技巧，怎么落地？

RedHat 正好擅长这玩意呀，它能真正的理解开源社区运作和项目研发真谛的合作伙伴。作为 Docker 一方，主要不管的强调「Docker native」，但是由于 kubernetes 没有跟 Swarm 展开同质化的竞争，所以这个「Docker Native」的说法并没有什么杀伤力。反而其独特的设计理念和号召力，让其构建了一个完全与众不同的容器编排管理生态。

就这样很快就把 Swarm 甩在了身后。随机开始探讨第二个问题，CNCF 添加了一系列容器工具和项目，面对这样的压迫，Docker 在2016年决定放弃现有的 Swarm项目，而是将容器编排等全部内置到 Docker 项目中。

而 kubunetes 的应对方案也蛮有意思，开启「民主化架构」，kubernetes 为开发者暴露可以扩展的插件机制，让用户可以随意的通过植入代码的方式介入到 kubernetes 的每一个阶段，很快，整个容器圈出现了优秀的作品：火热的微服务治理项目 lstio 等

面对 kubernetes 的强力攻X，Docker 公司不得不面对失败的事实，只好放弃开源社区专注于商业化转型，所以于2017年将容器运行时部分 containerd 捐赠给了 CNCF，从而将 Docker 项目改名为 Moby，然后交给社区维护，于 2017 年，Docker 公司宣布将在企业版内置 kubernetes 项目，这也标志了 kubernetes「编排之争」的结束