内容简介:从图中我们很容器看出,容器技术资源占用比较少,由于虚拟机需要模拟硬件的行为,对CUP和内存的损耗比较大。所以同样配置的服务器,容器技术就有以下优点:那既然容器有这些优点,为什么直到Docker的出现,才真正的被关注呢?一个重要原因就是容器技术的复杂性。容器本身就很复杂,他依赖于Linux内核的很多特性,而且他不易安装,也不易于管理和实现自动化。而Docker就是为了改变这一切而产生的。Docker 包含了一下几个重要主要部分:
从图中我们很容器看出,容器技术资源占用比较少,由于虚拟机需要模拟硬件的行为,对CUP和内存的损耗比较大。所以同样配置的服务器,容器技术就有以下优点:
- 资源占用比较少
- CPU/内存消耗低
那既然容器有这些优点,为什么直到 Docker 的出现,才真正的被关注呢?一个重要原因就是容器技术的复杂性。容器本身就很复杂,他依赖于 Linux 内核的很多特性,而且他不易安装,也不易于管理和实现自动化。而Docker就是为了改变这一切而产生的。
什么是Docker ?
- 将应用自动部署到容器的开源引擎
- Go语言实现的开源项目,诞生于2013年初,最初发起者是dotCloud公司
Docker的特点
- 提供简单轻量的建模方式 :简单,Docker非常容器上手,用户只需要几分钟,就能把自己的项目Docker化。
- 职责的逻辑分离 :使用Docker,开发人员只需要关心容器中运行的程序,运维人员只需要关心如何管理容器;Docker设计的目的就是加强开发人员写代码的环境与应用程序要部署的生成环境的一致性。
- 快速高效的开发生命周期 :Docker的目标之一是缩短代码开发到测试到部署上线的运行周期,让应用程序具备可移植性,在容器中开发,以容器的形式交付和分发,这样开发、测试、生产,都使用相同的环境,这样也就避免了额外的调试和部署上的开销,这样就能有效的缩短产品的上线周期。
- 鼓励使用面向服务的架构 :Docker推荐单个容器只运行一个应用程序或者进程,这样就形成了一个分布式的应用程序模型,在这种模式下应用程序或服务都可以表述为一系列内部互联的容器,从而使分布式部署应用程序扩展或调试都变得非常简单。这就像我们开发中常用的思想;高内聚,低耦合,单一任务。这样就能避免在同一服务器上部署不同服务时,可能带来的服务之间相互影响。这样服务运行中出现问题时,也比较容易定位问题的所在。
Docker的使用场景
-
- 使用Docker容器开发、测试、部署服务 :因为Docker本身非常轻量化,所以本地开发人员可以构建、运行并分享Docker容器。容器可以在开发环境中创建,然后再提交到测试,最终进入生产环境。
-
- 创建隔离的运行环境 :在很多企业应用中,同一服务的不同版本可能服务于不同的用户,那么使用Docker非常容易创建不同的生成环境来运行不同的服务。
-
- 搭建测试环境 :由于Docker的轻量化,所以开发者很容易利用Docker在本地搭建测试环境,用来测试程序在不用系统下的兼容性;甚至搭建集群的部署测试。
-
- 构建多用户的平台即服务(PaaS)基础设施 。
-
- 提供软件即服务(SaaS)应用程序 。
-
- 高性能、超大规模的宿主机部署 。
二、Docker的基本组成
Docker 包含了一下几个重要主要部分:
- Docker Client 客户端
- Docker Daemon 守护进程
- Docker Image 镜像
- Docker Container 容器
- Docker Registry 仓库
Docker 客户端 / 守护进程
- Docker是C/S架构的程序:Docker客户端向Docker服务器端,也就是Docker的守护进程发出请求,守护进程处理完所有的请求工作并返回结果。
- Docker 客户端对服务器端的访问既可以是本地也可以通过远程来访问。
Docker Image 镜像
- 镜像是Docker容器的基石,容器基于镜像启动和运行。镜像就好比容器的源代码,保存了用于启动容器的各种条件。
- Docker镜像是一个层叠的只读文件系统。
- Docker镜像使用联合加载技术
docker的镜像是一个层叠的只读文件系统,最低端是一个引导文件系统(即bootfs),第二层是root文件系统(即rootfs),它位于bootfs之上,可以是一种或多种操作系统,比如ubuntu或者centos。在docker中,root文件系统永远只能是只读状态,并且docker运用联合加载技术又会在root文件系统之上加载更多的只读文件系统,联合加载指的是一次加载多个文件系统,但是在外面看起来只能看到一个文件系统,联合加载会将各层文件系统叠加到一起,这样最终的文件系统会包含所有的底层文件和目录,docker将这样的文件系统称为镜像。
Docker Container 容器
- 容器通过镜像来启动,Docker的容器是Docker的执行来源,容器中可以运行客户的一个或多个进程,如果说镜像是Docker声明周期中的构建和打包阶段,那么容器则是启动和执行阶段。
当一个容器启动时,docker会在该镜像的最顶层加载一个读写文件系统,也就是一个可写的文件层,我们在docker运行的程序,就是在这个层中进行执行的,当docker第一次启动一个容器时,初始的读写层是空的,当文件系统发生变化时,这些变化都会应用到这一层上,比如像修改一个文件,该文件首先会从读写层下面的只读层复制到该读写层,该文件的只读版本依然存在,但是已经被读写层中的该文件副本所隐藏,这就是docker的一个重要技术:写时复制(copy on write)。每个只读镜像层都是只读的,永远不会变化,当创建一个新容器时,docker会构建出一个镜像栈,如下图所示:
Docker Registry 仓库
- docker用仓库来保存用户构建的镜像,仓库分为公有和私有两种,Docker公司提供了一个公有的仓库Docker Hub。
三、Docker 依赖的 Linux内核特性
Docker依赖于Linux内核的两个重要特性:
- Namespaces 命名空间
- Control groups (cgroups) 控制组
Namespaces 命名空间
很多编程语言都包含了“命名空间”的概念,我们可以认为“命名空间”是一种“封装”的概念, 而“封装”本身实际上实现的是代码的隔离。而在操作系统中,命名空间提供的是系统资源的隔离,而系统资源包括了进程、网络、文件系统等。
我们从Docker公开的文档来看,它使用了5种命名空间:
- PID(Process ID) 进程隔离
- NET(Network)管理网络接口
- IPC(InterProcess Communication)管理跨进程通信的访问
- MNT(Mount)管理挂载点
- UTS(Unix Timesharing System) 隔离内核和版本标识
那么,这些隔离的资源,是如何被管理起来的呢?这就需要用到——Control groups(cgroup)控制组了。
Control groups (cgroups) 控制组
Control groups是Linux内核提供的,一种可以限制、记录、隔离进程组所使用的物理资源的机制。 最初是由google工程师提出,并且在2007年时被Linux的内核的2.6.24版本引进。可以说,Control groups就是为容器而生的,没有Control groups就没有容器技术的今天。
Control groups提供了以下功能:
-
资源限制:例如,memory(内存)子系统可以为进程组设定一个内存使用的上限,一旦进程组使用的内存达到了限额,该进程组再发出内存申请时,就会发出“out of memory”(内存溢出)的警告。
-
优先级设定:它可以设定哪些进程组可以使用更大的CPU或者磁盘IO的资源。
-
资源计量:它可以计算进程组使用了多少系统资源。尤其是在计费系统中,这一点十分重要。
-
资源控制:它可以将进程组挂起或恢复。
Namespace 和 cgroup带给Docker的能力
到这里我们了解了Namespace和CGroup的概念和职能,而这两个特性带给了Docker哪些能力呢?如下:
-
文件系统隔离:首先是文件系统的隔离,每个Docker的容器,都可以拥有自己的root文件系统。
-
进程隔离:每个容器都运行在自己的进程环境中。
-
网络隔离:容器间的虚拟网络接口和IP地址都是分开的。
-
资源的隔离和分组:使用cgroups将cpu和内存之类的资源独立分配给每个Docker容器。
欢迎扫码或微信搜索公众号《程序员果果》关注我,关注有惊喜~
以上所述就是小编给大家介绍的《Docker 的基本概念和框架》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Angular 核心概念与框架演进
- 自定义MVC框架一概念
- Spring 框架核心概念IoC 随笔
- Spring 框架核心 AOP(LTW) 概念随笔
- 原 荐 一, 跨语言微服务框架 - Istio 简绍和概念
- Swoole 开发框架 imi v1.1.0 发布,重磅引入 Partial 概念
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Head First Design Patterns
Elisabeth Freeman、Eric Freeman、Bert Bates、Kathy Sierra、Elisabeth Robson / O'Reilly Media / 2004-11-1 / USD 49.99
You're not alone. At any given moment, somewhere in the world someone struggles with the same software design problems you have. You know you don't want to reinvent the wheel (or worse, a flat tire),......一起来看看 《Head First Design Patterns》 这本书的介绍吧!