01-Docker理论知识¶
什么是LXC¶
LXC为Linux Container的简写。可以提供轻量级的虚拟化,以便隔离进程和资源,而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace。容器有效地将由单个操作系统管理的资源划分到孤立的组中,以更好地在孤立的组之间平衡有冲突的资源使用需求。
与传统虚拟化技术相比,它的优势在于:
(1)与宿主机使用同一个内核,性能损耗小;
(2)不需要指令级模拟;
(3)不需要即时(Just-in-time)编译;
(4)容器可以在CPU核心的本地运行指令,不需要任何专门的解释机制;
(5)避免了准虚拟化和系统调用替换中的复杂性;
(6)轻量级隔离,在隔离的同时还提供共享机制,以实现容器与宿主机的资源共享。
总结:Linux Container是一种轻量级的虚拟化的手段。
Linux Container提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制。Linux Container有点像chroot,提供了一个拥有自己进程和网络空间的虚拟环境,但又有别于虚拟机,因为lxc是一种操作系统层次上的资源的虚拟化。
LXC与docker什么关系
docker并不是LXC替代品,docker底层使用了LXC来实现,LXC将linux进程沙盒化,使得进程之间相互隔离,并且能够课哦内阁制各进程的资源分配。 在LXC的基础之上,docker提供了一系列更强大的功能。
什么是Docker¶
Docker是Docker.inc公司开源的一个基于LXC技术之上构建的Container容器引擎,源代码托管在GitHub上,基于Go语言并遵从Apache2.0协议开源(可以商业)。
Docker项目的目标是实现轻量级的操作系统虚拟化解决方案。
Docker是通过内核虚拟化技术(namespaces及cgroups等)来提供容器的资源隔离与安全保障等。由于Docker通过操作系统层的虚拟化实现隔离,所以Docker容器在运行时,不需要类似虚拟机VM额外的操作系统开销,提高资源利用率。
下面图比较了Docker和传统虚拟化方式的不同之处,可见容器是在操作系统层面上实现虚拟化,直接复制本地主机的操作系统,而传统方式则是在硬件层面实现。
docker的理念:构建,运输,运行
Docker 是Docker.lnc公司开源的一个基于LXC技术之上构建的contailer容器引擎,源代码托管在github上,基于go语言并遵从Apache2.0协议开源。
Docker是通过内核虚拟化技术(namespace及cgroups等)来提供容器的资源隔离与安全保障等,由于Docker通过操作系统层的虚拟化实现隔离,所以Docker容器在运行时,不需要类似虚拟机VM额外的操作系统开销,提高资源利用率。
Docker的三大核心¶
Docker 的组成
docker client
docker server
镜像
Docker镜像(Image)类似与虚拟机的镜像,可以将他理解为一个面向Docker引擎的只读模板,包含了文件系统。
例如:一个镜像可以完全包含了Ubuntu操作系统环境,可以把它称作一个Ubuntu镜像。镜像也可以安装了Apache应用程序(或其他软件),可以把它称为一个Apache镜像。
镜像是创建Docker容器的基础,通过版本管理和增量的文件系统,Docker提供了一套十分简单的机制来创建和更新现有的镜像。
用户可以从网上下载一个已经做好的应用镜像,并通过命令直接使用。
总之,应用运行是需要环境的,而镜像就是来提供这种环境。
容器
Docker容器(Container)类似于一个轻量级的沙箱子(因为Docker是基于Linux内核的虚拟技术,所以消耗资源十分少),Docker利用容器来运行和隔离应用。
容器是从镜像创建的应用运行实例,可以将其启动、开始、停止、删除,而这些容器都是相互隔离、互不可见的。
可以把每个容器看作一个简易版的Linux系统环境(包括了root用户权限、进程空间、用户空间和网络空间),以及与运行在其中的应用程序打包而成的应用盒子。
镜像自身是只读的。容器从镜像启动的时候,Docker会在镜像的最上层创建一个可写层,镜像本身将保持不变。就像用ISO装系统之后,ISO并没有什么变化一样。
仓库
Docker仓库(Repository)类似与代码仓库,是Docker集中存放镜像文件的场所。
有时候会看到有资料将Docker仓库和注册服务器(Registry)混为一谈,并不严格区分。实际上,注册服务器是存放仓库的地方,其上往往存放着多个仓库。每个仓库集中存放某一类镜像,往往包括多个镜像文件,通过不同的标签(tag)来进行区分。例如存放Ubuntu操作系统镜像的仓库,称为Ubuntu仓库,其中可能包括14.04,12.04等不同版本的镜像。
根据存储的镜像公开分享与否,Docker仓库分为公开仓库(Public)和私有仓库(Private)两种形式。
目前,最大的公开仓库是Docker Hub,存放了数量庞大的镜像供用户下载。国内的公开仓库包括Docker Pool等,可以提供稳定的国内访问。
如果用户不希望公开分享自己的镜像文件,Docker也支持用户在本地网络内创建一个只能自己访问的私有仓库。
当用户创建了自己的镜像之后就可以使用push明亮将它上传到指定的公有或则私有仓库。这样用户下次在另一台机器上使用该镜像时,只需将其从仓库pull下来就可以了。
Docker利用仓库管理镜像的设计理念甚至命令和git非常相似,也就意味着非常好上手。
Docker的工作模式¶
学习Docker的源码并不是一个枯燥的过程,反而可以从中理解Docker架构的设计原理。
Docker对使用者来讲是一个C/S模式的架构,而Docker的后端是一个非常松耦合的架构,模块各司其职,并有机组合,支撑Docker的运行。
用户是使用Docker Client与Docker Daemon建立通信,并发送请求给后者。
而Docker Daemon作为Docker架构中的主体部分,首先提供Server的功能使其可以接受Docker Client的请求;而后Engine执行Docker内部的一系列工作,每一项工作都是以一个Job的形式的存在。
Job的运行过程中,当需要容器镜像时,则从Docker Registry中下载镜像,并通过镜像管理驱动graphdriver将下载镜像以Graph的形式存储;当需要为Docker创建网络环境时,通过网络管理驱动networkdriver创建并配置Docker容器网络环境;当需要限制Docker容器运行资源或执行用户指令等操作时,则通过execdriver来完成。而libcontainer是一项独立的容器管理包,networkdriver以及execdriver都是通过libcontainer来实现具体对容器进行的操作。当执行完运行容器的命令后,一个实际的Docker容器就处于运行状态,该容器拥有独立的文件系统,独立并且安全的运行环境等。
CLI交互模型
RemoteAPI交互模型
Docker八种应用场景¶
1、简化配置,统一配置,通过镜像快速启动(Simplifying)
2、代码流水线管理,开发环境->测试环境->预生产环境->灰度发布->正式发布,docker在这里实现了快速迁移(Code Oioeline Management)
3、开发效率,对开发人员,有了镜像,直接启动容器即可(Developer Productivity)
4、应用隔离,相对于虚拟机的完全隔离会占用资源,docker会比较节约资源(App lsolation)
5、服务器整合,一台服务器跑多个docker容器,提高服务器的利用率(Server Consolidation)
6、调试能力,debug调试(Debugging Capabilties)
7、多租户,一个租户多个用户,类似于阿里公有云的一个project下多个用户(Multi-tenancy)
8、快速部署,不需要启动操作系统,实现秒级部署(Rapid Deplovment)
docker的主要用途¶
官方就是Bulid 、ship、run any app/any where,编译、装载、运行、任何app/在任意地放都能运行。 就是实现了应用的封装、部署、运行的生命周期管理只要在glibc的环境下,都可以运行。 运维生成环境中:docker化。 发布服务不用担心服务器的运行环境,所有的服务器都是自动分配docker,自动部署,自动安装,自动运行
再不用担心其他服务引擎的磁盘问题,cpu问题,系统问题了
资源利用更出色
自动迁移,可以制作镜像,迁移使用自定义的镜像即可迁移,不会出现什么问题
管理更加方便了
docker与openstack对比¶
docker与docker,openstack对比
类别 | Docker | Openstack |
---|---|---|
部署难度 | 非常简单 | 组件多,部署复杂 |
启动速度 | 秒极 | 分钟级 |
执行性能 | 和物理系统几乎一致 | VM会占用一些资源 |
镜像体积 | 镜像是MB级别 | 镜像是GB级别 |
管理效率 | 管理简单 | 组件相互依赖,管理复杂 |
隔离性 | 隔离性高 | 彻底隔离 |
可管理性 | 单进程,不建议启动SSH | 完整的系统管理 |
网络连接 | 比较弱 | 借助neutron组件可以灵活各类网络架构 |
企业使用docker的原因
(1)技术储备
(2)跟上节奏,提升自身技术
(3)符合当前业务需求
(4)docker的启动块
Docker改变了什么¶
面向产品:产品交付
面向开发:简化环境配置
面向测试:多版本测试
面向运维:环境一致性,环境回滚。
面向架构:自动化扩容(微服务)
一:Docker更快速的交付和部署
对于开发和人员来说,最希望的就是一次创建和配置,可以在任意地方正常运行。
开发者可以使用一个标准的镜像来构建一套开发容器,开发完成之后,运维人员可以直接使用这个容器来部署代码。Docker可以快速创建容器,快速迭代应用程序,并让整个过程全称可见,使团队中的其他成员更容易理解应用程序是如何创建和工作。Docker容器很轻很快!容器的启动时间是秒级的,大量第节约开发、测试、部署的时间。
二:Docker更高效的虚拟化
Docker容器的运行不需要额外的Hypervisor支持,它是内核级的虚拟化,因此可以实现更高的性能和效率。
三:Docker更轻松的迁移和扩展
Docker容器几乎可以字啊任意的平台上运行,包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。这种兼容性可以让用户把一个应用程序从一个平台直接迁移到另外一个。
四:Docker更简单的管理
使用Docker,只需要小小的修改,就可以替代往大量的更新工作。所有的修改都以增量的方式被分发和更新,从而实现自动化并且高效的管理。
Docker容器十诫¶
当你刚开始使用容器时,会发现容器能解决许多问题,而且好处很多:
首先:容器是不可变的 —— 操作系统、库版本、配置、文件夹以及应用全都包裹在容器内。你可以确保,在 QA 阶段测试的一张图片,肯定会在生产环境中出现,并且行为保持一致。
其次:容器是轻量级的 —— 容器的内存占用很小。容器只会给主进程分配内存,因此无需十几万个 MB 的内存空间。
最后:容器速度很快 —— 启动容器就跟启动典型的 linux 进程一样快。无需好几分钟,一个新的容器可以在几秒内启动完毕。
然而,许多用户仍然只是将容器视为典型的虚拟机。他们忘记了容器的一个重要特征:容器是可丢弃的。
围绕容器的咒语:“容器是临时的”。
鉴于这一特征,用户必须转变他们使用以及管理容器时的心态。下面,笔者将介绍为了充分利用 Docker 容器的好处,用户应该避免的十个陷阱:
1)不要在容器内存储数据 —— 容器可以被停止、销毁或者取代。运行在容器中的应用1.0版本应该能够轻易地被1.1版本所取代,且不产生任何影响或数据丢失。因此,如果你需要存储数据,请将其存储在卷组(volume)中。在这种情况下,你要格外小心两个容器向同一卷组写入数据的情况,因为这很容易导致数据污染。总之,要确保自己的应用向共享的数据存储区填写数据。
2)不要将应用分开发布 —— 有些人会将容器视为虚拟机,他们中的大部分人认为,应该在现有的运行容器中部署应用。在开发阶段,因为需要不断地修改配置并调试应用,这样做无可厚非。但是,当持续交付管道行进至 QA 与生产阶段时,不应该把镜像和应用分开。记住:容器是不可变的。
3)不要创建太大的镜像 —— 镜像越大,越难以分发。确保只留有运行应用或进程所需的文件和库。不要安装不必要的包或运行“update”(yum update)指令下载太多文件到新的镜像层。
更新:关于这条建议,有一篇解释更为详尽的文章:《保持小巧:细究 Docker 镜像大小》,网址为:http://developers.redhat.com/blog/2016/03/09/more-about-docker-images-size/
4)不要使用单层镜像 —— 为了有效利用分层的文件系统,总是为操作系统创建基础镜像层,此外,分别为用户名定义、运行时安装、配置、以及自己的应用创建不同的镜像层。这样一来,重现、管理以及传送镜像会变得更为简单。
5)不用为运行中的容器创建镜像 —— 换句话说,不要使用 “docker commit” 指令创建镜像。这种创建镜像的方法是不可重现的,应该完全避免。相反,总是使用 Dockerfile 或任何 S2I (source-to-image,源码到镜像) —— 完全可重现的方法来创建镜像。这样一来,如果你将 Dockerfile 保存在源码存储控制库(git)内,就可以追踪其后续变化。
6)不要单独使用“latest(最新)”标签 —— 最新标签就像 Maven 用户眼中的 “SNAPSHOT(快照)”。因为容器本身的分层式文件系统,我们鼓励使用标签。但是,你可不想在几个月后正打算创建镜像时,却惊讶地发现应用无法运行,而原因居然是一个父层(Dockerfile 中的 FROM)已经被无法向后兼容的新版取代,或是创建缓存中检索出的“最新”版本是错的。此外,由于你无法追踪当前运行镜像的版本,“最新”标签也不应该在生产环境中部署容器时使用。
7)不要在一个容器内运行多个进程 —— 容器在运行单一进程(http 后台进程、应用服务器、数据库)时几乎无可挑剔,但是,如果运行多个进程,你可能会在管理、检索日志以及独个更新进程时遇到麻烦。
8)不要在镜像中存储凭证 —— 使用环境变量。不要将镜像中的任何用户名或密码写死。使用环境变量从容器外部检索这些信息。Postgress 镜像就是践行该准则的好榜样。
9)不要以 root 用户运行进程 —— “默认情况下,docker 容器以 root 权限运行。(…)随着 Docker 的不断完善,更多安全的默认选项会逐渐出现。就当下而言,要求 root 权限对有些用户而言比较危险,可能无法在所有环境中实现。你的镜像应该使用 USER 指令为容器确定一个非 root 运行权限。”(摘自《Docker 镜像作者指南》)
10)不要依赖 IP 地址 —— 每个容器都有其内部 IP 地址,该地址可能因为启动或停止容器而发生改变。如果你的应用或微服务需要与另一个容器交换消息,应该使用环境变量在容器间传送合适的主机名与端口号。
Docker资源隔离¶
Namespace资源隔离
pid namespace
不同用户的进程就是通过pid namespace隔离开的,且不同 namespace 中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程,每个lxc进程具有不同的namespace。同时由于允许嵌套,因此可以很方便的实现 Docker in Docker。
net namespace
有了 pid namespace, 每个namespace中的pid能够相互隔离,但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的, 每个net namespace有独立的 network devices, IP addresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge: docker0连接在一起。
ipc namespace
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication – IPC), 包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是,container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互,因此需要在IPC资源申请时加入namespace信息 – 每个IPC资源有一个唯一的 32 位 ID。
mnt namespace
类似chroot,将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同,这样每个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不同,每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
uts namespace
UTS(“UNIX Time-sharing System”) namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
user namespace
每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户。
Docker拓展知识¶
可配额/可度量 – Control Groups (cgroups)
cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单,提供类似文件的接口,在 /cgroup目录下新建一个文件夹即可新建一个group,在此文件夹中新建task文件,并将pid写入该文件,即可实现对该进程的资源控制。groups可以限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系统的资源,以下是每个子系统的详细说明(可以使用docker run –help查看):
blkio 这个子系统设置限制每个块设备的输入输出控制。例如:磁盘,光盘以及usb等等。
cpu 这个子系统使用调度程序为cgroup任务提供cpu的访问。
cpuacct 产生cgroup任务的cpu资源报告。
cpuset 如果是多核心的cpu,这个子系统会为cgroup任务分配单独的cpu和内存。
devices 允许或拒绝cgroup任务对设备的访问。
freezer 暂停和恢复cgroup任务。
memory 设置每个cgroup的内存限制以及产生内存资源报告。
net_cls 标记每个网络包以供cgroup方便使用。
ns 名称空间子系统。