Docker基础(一):一文初识Docker
目录Docker的意义;Docker与虚拟机的对比;Docker的诞生;Docker三要素;Docker架构
假设你已经开发了一个Java项目,你所用的开发设备上已经配好了所有的相关环境,比如java8/mysql/redis等等。现在,你需要将你的源码交付给其他开发人员和测试人员或者直接打成jar包部署上线。问题来了,每个人机器上的环境都不一样,而你开发的项目依赖于你所选的环境和某些配置文件,这样一来其他人就需要为你的项目重新配好环境,非常麻烦。有没有什么办法可以避免这种头疼的配置协调问题呢?
试想,如果你将jar包或者源码和整个项目需要的所有配置环境和依赖一并打包,使你交付的东西不仅拥有项目本身,还拥有整个环境,这样拉下来之后直接可以运行,问题不就解决了吗。而这,就是 docker
的核心思想!
Docker的意义
在docker出来之前,开发和运维的对调是很麻烦的,经常出现开发者的项目没问题,但是到了运维那就跑不起来了,基本都是环境的问题。比如,你使用java8写了一个项目,但是运维那里用的是java11,你使用mysql5.7.17,但是运维那用mysql8.0.26。
好在,你和运维关系很好,没吵架,他愿意和你协调。于是,你把项目需要的所有配置列成清单给他,他一看,麻了。清单上列的慢慢的环境配置,和他现在用的都不一样,得一个个重新配。很明显,传统项目交接有两个很头痛的毛病
- 环境不一样
- 安装啰嗦,配置麻烦
你以为这样就结束了?不对!假设你写的项目是一个电商平台,每天的数据量非常大,redis必须使用集群。到了双十一附近,交易量猛增,集群必须要迅速的扩容,从原来的3主3从扩到5主5从。在传统的方式中,运维撑破天也无法在秒级
完成这种扩缩容。这就暴露出了第三个缺点:
- 扩缩容慢
Docker的出现得以打破过去「程序即应用」的观念。透过镜像(images)将作业系统核心、运作应用程序所需要的系统环境,由下而上打包,达到应用程式跨平台间的无缝接轨运作。
Docker与虚拟机的对比
docker并不是第一个采用这种思想的技术,在docker出来之前,业界的网红是 虚拟机(virtual machine)
, 它也是一个典型的带环境安装的方案。不管你的物理机是什么系统,只要下载下来OS的镜像(.iso),在VMWare上一跑就行了。
比如Windows10系统里面运行Linux系统CentOS7。应用程序对此毫无感知,因为虚拟机看上去跟真实系统一模一样,而对于底层系统来说,虚拟机就是一个普通文件,不需要了就删掉,对其他部分毫无影响。需要注意的是,虚拟机是要虚拟出一整套硬件
的,然后在其上运行一整个完整的OS。
正因为虚拟机是硬件层面上的虚拟,且要模拟出整套OS,因此体量非常大,故缺点很多比如:
- 资源占用多
- 内存占用大
- 启动慢
- 冗余步骤多,麻烦
由于虚拟机存在这些缺点,Linux发展出了另一种虚拟化技术:
Linux容器(Linux Containers,缩写为LXC)
Linux容器不是模拟一个完整的操作系统,而是对进程进行隔离。有了容器,就可以将软件运行所需要的所有资源打包到一个隔离的容器中。容器于虚拟机不同,不需要捆绑一整套操作系统,只需要软件工作所需的库资源和配置,也就是最小的最必须的环境。系统因此变得高效而轻量,并保证部署在任何环境中的软件都能始终如一地运行。实际上,这个Linux容器技术,后来就发展成了docker
。
Docker容器是在 OS层面
上虚拟化的,直接复用本地主机的OS。与虚拟机相比,Docker启动快速、体积小。
Virtual Machine | Docker | |
---|---|---|
大小 | GB-TB | KB-MB |
启动速度 | 分钟级 | 秒级 |
虚拟层面 | 硬件 | OS |
隔离级别 | OS级 | 进程级 |
集群规模 | 上百 | 上万 |
总结一下就是:
- 传统虚拟机技术是虚拟出一套硬件后,在其上运行一个完整操作系统,在该系统上再运行所需应用进程
- 容器内的应用进程直接运行于宿主的内核,容器内没有自己的内核且也没有进行硬件虚拟。
- 每个容器之间互相隔离,每个容器有自己的文件系统 ,容器之间进程不会相互影响,能区分计算资源。
Docker的诞生
2010年,几个搞IT的年轻人,在美国旧金山成立了一家名叫“dotCloud”的公司。这家公司主要提供基于PaaS的云计算技术服务,具体来说,就是和前面提到的LXC
有关的容器技术。后来,dotCloud公司将自己的容器技术进行了简化和标准化,并将该技术命名为——Docker。
很可惜,Docker技术诞生之后,并没有引起行业的关注。而dotCloud公司,作为一家小型创业企业,在激烈的竞争之下,也步履维艰。那怎么办呢?==> 办不下去就开源!
2013年3月,dotCloud公司的创始人之一,Docker之父,28岁的Solomon Hykes决定,将Docker技术开源。不开则已,一开惊人。越来越多的IT工程师发现了Docker的优点,然后蜂拥而至,加入了Docker开源社区。Docker人气迅速攀升,开源当月,Docker 0.1发布,在此后的每一个月,Docker都会发布一个版本。到2014年6月9日,Docker 1.0版本正式发布。
此时的Docker,已经成为行业里人气最火爆的开源技术,没有之一。甚至像Google、微软、Amazon、VMware这样的巨头,都对它青睐有加,表示将全力支持。Docker火了之后,dotCloud公司干脆把公司名字也改成了Docker Inc。
就在Docker容器技术被炒得热火朝天之时,大家发现,如果想要将Docker应用于具体的业务实现,是存在困难的——编排、管理和调度等各个方面,都不容易。于是,人们迫切需要一套管理系统,对Docker及容器进行更高级更灵活的管理。这个时候,K8S出现了!
K8S,就是基于容器的集群管理平台,它的全称,是kubernetes,8是代表中间8个字母。
和Docker不同,K8S的创造者,是众人皆知的行业巨头——Google。然而,K8S并不是一件全新的发明。它的前身,是Google自己捣鼓了十多年的Borg系统。
其实,在很早之前,Google就用了容器化的技术,并拥有一套完善的集群管理系统——Borg,且不开源。慢慢地,对这种管理系统的需求越来越多,但Google迟迟不开源,没办法,需求者只能自己写。唉,这个时候,Google怕了,万一这种技术出现了,那自己垄断Borg的优势不久荡然无存了。怎么办? ==> 打不过就加入,我开源还不行嘛。于是乎,Google用Go重写了一遍Borg,更名为K8S,将其开源,继续作为领域的领跑者。
2014年6月,Google公司正式公布K8S并宣布开源的。之后的一年内,VMware、HP、Intel等公司,也陆续加入。2015年7月,Google正式加入OpenStack基金会。与此同时,Kuberentes v1.0正式发布。
K8S的架构,相对来说很复杂,组件比较多,交互也复杂,具体的之后再说吧。
Docker三要素
- 镜像(image)
- 容器(container)
- 仓库(repository)
可以用java做一个粗略的类比,所谓镜像,就是java中的一个个class,所谓容器,就是用class来new出来的一个个对象(实例),所谓仓库,就是存储那些镜像的地方。
再生动一些,你住的房子就是你现在所处的容器,假设你要搬家,但是还想住一个和现在一摸一样的家,于是你找来了女巫,女巫用魔法通过你的房子生成了一个一摸一样的模型,整个模型就是镜像
。你将该模型带了一片空地上,女巫瞬间用改模型在地上建立了一个和之前那个一摸一样的新房子,连地基都一样,这个新房子就是一个新的容器
。现在,女巫告诉你她有一个仓库
,你可以将自己房子的镜像上传上去,也可以拉取别人的镜像,里面有中式四合院、欧式别墅、大豪宅、甚至还有非洲茅草屋,只要拉取了镜像,直接可以带地基生成一个完整的房子,岂不美哉?
Docker镜像(image)就是一个只读的模板。镜像可以用来创建Docker容器,一个镜像可以创建很多容器,也可以通过容器来构造一个新的镜像。它也相当于是一个root文件系统,比如官方镜像centos:7就包含了完整的一套centos:7最小系统的root文件系统。
容器就是一个简易版的Linux环境,包括root用户权限、进程空间、用户空间和网络空间等等,外加在其中运行的应用程序。
要注意,Docker本身并不是容器,它是创建容器的工具,是应用容器引擎,即Docker Engine。
至于仓库,就是docker hub,类似于github,官方仓库为:https://hub.docker.com/
基于此,Docker提出了它的两句口号
- Build, Ship and Run; 即“构建,发送,运行”三板斧
- Build once, Run anywhere; 即构建一次,处处能用
Docker架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DORLTkYd-1642773044107)(Docker基础-一-初识/image-20220121170207430.png)]
Docker是一个C/S模式的架构
,后端是一个松耦合架构,众多模块各司其职,Docker运行的基本流程为:
- 用户使用Docker Client与Docker Daemon建立通信,并发送请求给后者。
- Docker Daemon作为Docker架构中的主体部分,首先提供Docker Server的功能使其可以接收Docker Client的请求。
- Docker Engine执行Docker内部的一系列工作,每一项工作都是以一个Job的形式存在的。比如,用
docker run 镜像
命令来创建一个容器,就是一个Job。 - Job运行过程中,当需要镜像时,就会在本地中找,如果本地没有,就去Docker Registry中拉取镜像,并通过镜像管理驱动Graph driver将下载镜像以Graph的形式存储在本地。
- 当需要为Docker容器创建环境时,通过网络管理驱动Network Driver创建并配置Docker容器网络环境。详细情况会在后续Docker network博客讲述。
- 当需要限制Docker容器运行资源或执行用户指令等操作时,则通过Exec Driver来完成。主要为命令:
docker exec [OPTIONS] 容器名/ID [CMD]
,详见后续docker基础命令博客。 - Libcontainer是一项独立的容器管理包,Network driver以及Exec driver都是通过Libcontainer来实现具体对容器进行的操作。
这里借用尚硅谷阳哥的一张图和讲解。
参考:
[1] 10分钟看懂Dokcer和K8S
[2] Docker官网
[3] 尚硅谷
更多推荐
所有评论(0)