Docker 使用 Google 公司推出的 Go 语言 进行开发实现,诞生于2013年初。基于 Linux 内核的 cgroup,namespace,以及 AUFS 类的 Union FS 等技术,对进程进行封装隔离,属于 操作系统层面的虚拟化技术。Docker的主要目标是对应用组件的封装、分发、部署和运行等生命周期管理,达到应用组件的“一次封装、多处运行”。
Docker 在容器的基础上,进行了进一步的封装,从文件系统、网络互联到进程隔离等等,极大的简化了容器的创建和维护。使得 Docker 技术比虚拟机技术更为轻便、快捷。
传统虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统,在该系统上再运行所需应用进程;而容器内的应用进程直接运行于宿主的内核,容器内没有自己的内核,而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。
由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销,Docker 对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度,都要比传统虚拟机技术更高效。因此,相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。
传统的虚拟机技术启动应用服务往往需要数分钟,而 Docker 容器应用,由于直接运行于宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。
开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致,导致有些 bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境,确保了应用运行环境一致性,从而不会再出现 「这段代码在我机器上没问题啊」 这类问题。
由于 Docker 确保了执行环境的一致性,使得应用的迁移更加容易。Docker 可以在很多平台上运行,无论是物理机、虚拟机、公有云、私有云,甚至是笔记本,其运行结果是一致的。因此用户可以很轻易的将在一个平台上运行的应用,迁移到另一个平台上,而不用担心运行环境的变化导致应用无法正常运行的情况。
使用Dockerfile,只需要修改小小的配置更改,就可以替代以往大量的更新工作。
开发人员可以通过 Dockerfile 来进行镜像构建,并结合 持续集成(Continuous Integration) 系统进行集成测试,而运维人员则可以直接在生产环境中快速部署该镜像,甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。
特性 | 容器 | 虚拟机 |
---|---|---|
启动速度 | 秒级 | 分钟级 |
磁盘使用 | 一般为MB | 一般为GB |
系统支持量 | 单机支持上千个容器 | 一般几十个 |
传统的虚拟化方式是在硬件层面实现的虚拟化,需要额外的虚拟机管理应用和虚拟机操作系统层。
Docker容器是操作系统层实现的虚拟化,直接复用本地主机的操作系统。
Docker三大核心概念:镜像、容器、仓库。
Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。 镜像包含操作系统完整的 root 文件系统,其体积往往是庞大的,因此在 Docker 设计时,就充分利用 Union FS 的技术,将其设计为分层存储的架构。所以严格来说,镜像并非是像一个 ISO 那样的打包文件,镜像只是一个虚拟的概念,其实际体现并非由一个文件组成,而是由一组文件系统组成,或者说,由多层文件系统联合组成。镜像构建时,会一层层构建,前一层是后一层的基础。每一层构建完就不会再发生改变,后一层上的任何改变只发生在自己这一层。
镜像是创建Docker容器的基础。通过版本管理和增量的文件系统。Docker提供了一套十分简单的机制来创建和更新现有的镜像。
镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
容器的实质是进程,但与直接在宿主执行的进程不同,容器进程运行于属于自己的独立的 命名空间。因此容器可以拥有自己的 root 文件系统、自己的网络配置、自己的进程空间,甚至自己的用户 ID 空间。容器内的进程是运行在一个隔离的环境里,使用起来,就好像是在一个独立于宿主的系统下操作一样。这种特性使得容器封装的应用比直接在宿主运行更加安全。
Docker仓库类似于代码仓库,是Docker集中存放镜像文件的场所。
一个 Docker Registry 中可以包含多个仓库(Repository);每个仓库可以包含多个标签(Tag);每个标签对应一个镜像。关系图如下:
每次部署项目到测试、生产等环境,都要部署一大堆依赖的软件、工具,而且部署期间出现问题几率很大,不经意就花费了很长时间。
Docker主要理念就是环境打包部署,可在任意Docker Engine运行。前期我们只需要将每个项目环境打包到镜像,push到镜像仓库,当有需要部署这个项目时,直接pull镜像启动容器,这个项目就可以访问了!一次构建多次部署,一劳永逸。
公司有一项这样的业务:有一个产品可以整套部署到客户那里,以往都是派一名实施工程师到客户那部署。如果用了Docker,我们可以前期将这套项目封装打包起来,实现一键部署,分分钟钟搞定,就不需要再派人过去了。比如官方的Docker Compose编排工具。
有时,我们想调研一些开源项目,我们可以直接从公共镜像仓库pull项目官方做好镜像启动容器即可。
开发工程师在Windows系统上开发项目,测试、生产环境操作系统都是Linux系统,这就产生了环境不一致的情况:项目在开发电脑本地运行没问题,到了测试或生产环境就运行不起来,解决这问题最好方式就是这三处环境保持一致。软件版本、操作系统、物理机、云主机......试想下,能做到吗?
Docker将项目环境打包成镜像,可以在任何Docker Engine上浪。此时Docker就是我们这些项目的基石,Docker可移植性,保持运行状态一致性,可想而知,是否更容易解决问题呢?
一个项目版本快速迭代的测试场景,需要一个合理的CI(持续集成)/CD(持续部署)环境支撑。CI/CD是一个周期性自动化项目测试流程,包括构建、部署、测试、发布等工作,很少需要人工干预。
Docker在上面这个图的作用是项目镜像构建和快速部署,打通测试环境与生产环境,高度保持多个环境之间一致性。
微服务是近几年来IT圈内谈论比较多的一个名词,意义也很简单:尽可能细粒度拆分业务程序架构,由多个独立服务组成业务系统。
Docker的容器设计原则:一个容器一个服务,容器之间相互隔离,不妨试想一下,如果容器作为这些独立服务的部署单元,是不是有点恰到好处呢?
当适用Docker技术以后,这种弹性伸缩的单元就是云主机之上的容器了。
容器集群化管理已经有成熟的解决方案,比如:官方的Swarm,谷歌的K8S。
由于Docker容器快速启动特性,可以很快速的启动几十个、上百个容器来提供更多并发和资源利用率。