第 2 章 Docker 核心技术
Docker的核心技术内容很多,我们学习则从以下四个方面来介绍Docker的核心技术
镜像、容器、数据、网络
2.1 docker镜像管理
2.1.1 镜像简介
Docker镜像是什么?
镜像是一个Docker的可执行文件,其中包括运行应用程序所需的所有代码内容、依赖库、环境变量和配置文件等。
通过镜像可以创建一个或多个容器。
2.1.2 搜索、查看、获取
搜索镜像
1 | 作用 |
获取镜像
1 | 作用: |
查看镜像
1 | 作用: |
2.1.3 重命名、删除
镜像重命名
1 | 作用: |
删除镜像
1 | 作用: |
2.1.4 导出、导入
导出镜像
将已经下载好的镜像,导出到本地,以备后用。
1 | 作用: |
导入镜像
1 | 作用: |
2.1.5 历史、创建
查看镜像历史
1 | 作用: |
镜像详细信息
1 | 作用: |
2.1.6总结
2.2 容器管理
docker容器技术指Docker是一个由GO语言写的程序运行的“容器”(Linux containers, LXCs)
containers的中文解释是集装箱。
Docker则实现了一种应用程序级别的隔离,它改变我们基本的开发、操作单元,由直接操作虚拟主机(VM),转换到操作程序运行的“容器”上来。
2.2.1 容器简介
容器是什么?
容器(Container):容器是一种轻量级、可移植、并将应用程序进行的打包的技术,使应用程序可以在几乎任何地方以相同的方式运行
•Docker将镜像文件运行起来后,产生的对象就是容器。容器相当于是镜像运行起来的一个实例。
•容器具备一定的生命周期。
•另外,可以借助docker ps命令查看运行的容器,如同在linux上利用ps命令查看运行着的进程那样。
我们就可以理解容器就是被封装起来的进程操作,只不过现在的进程可以简单也可以复杂,复杂的话可以运行1个操作系统.简单的话可以运行1个回显字符串.
容器与虚拟机的相同点
•容器和虚拟机一样,都会对物理硬件资源进行共享使用。
•容器和虚拟机的生命周期比较相似(创建、运行、暂停、关闭等等)。
•容器中或虚拟机中都可以安装各种应用,如redis、mysql、nginx等。也就是说,在容器中的操作,如同在一个虚拟机(操作系统)中操作一样。
•同虚拟机一样,容器创建后,会存储在宿主机上:linux上位于/var/lib/docker/containers下
容器与虚拟机的不同点
注意:容器并不是虚拟机,但它们有很多相似的地方
•虚拟机的创建、启动和关闭都是基于一个完整的操作系统。一个虚拟机就是一个完整的操作系统。而容器直接运行在宿主机的内核上,其本质上以一系列进程的结合。
•容器是轻量级的,虚拟机是重量级的。
首先容器不需要额外的资源来管理,虚拟机额外更多的性能消耗;
其次创建、启动或关闭容器,如同创建、启动或者关闭进程那么轻松,而创建、启动、关闭一个操作系统就没那么方便了。
•也因此,意味着在给定的硬件上能运行更多数量的容器,甚至可以直接把Docker运行在虚拟机上。
2.2.2 查看、创建、启动
查看容器
1 | 作用 |
创建待启动容器
1 | 作用: |
启动容器
启动容器有三种方式
1、启动待启动或已关闭容器
2、基于镜像新建一个容器并启动
3、守护进程方式启动docker
启动容器
1 | 作用: |
创建新容器并启动
1 | 作用: |
守护进程方式启动容器<常用的方式>
更多的时候,需要让Docker容器在后台以守护形式运行。此时可以通过添加-d参数来实现
1 | 命令格式: |
2.2.3暂停与取消暂停与重启
容器暂停
1 | 作用: |
容器取消暂停
1 | 作用: |
重启
1 | 作用: |
2.2.4 关闭、终止、删除
关闭容器
在生产中,我们会以为临时情况,要关闭某些容器,我们使用 stop 命令来关闭某个容器
1 | 作用: |
终止容器
1 | 作用: |
删除容器
删除容器有三种方法:
正常删除 — 删除已关闭的
强制删除 — 删除正在运行的
强制批量删除 — 删除全部的容器
正常删除容器
1 | 作用: |
1 | Error response from daemon: You cannot remove a running container c7f5e7fe5aca00e0cb987d486dab3502ac93d7180016cfae9ddcc64e56149fc9. Stop the container before attempting removal or force remove |
强制删除运行容器
1 | 作用: |
拓展批量关闭容器
1 | 作用: |
2.2.5 进入、退出
进入容器我们学习三种方法:
1、创建容器的同时进入容器
2、手工方式进入容器
创建并进入容器
1 | 命令格式: |
退出容器:
1 | 方法一: |
手工方式进入容器
1 | 命令格式: |
2.2.6 基于容器创建镜像
导出镜像的第二种方式:
1 | 命令格式: |
导出(export)导入(import)与保存(save)加载(load)的恩怨情仇 |
---|
import与load的区别: import可以重新指定镜像的名字,docker load不可以 |
export 与 保存 save 的区别: 1、export导出的镜像文件大小,小于 save保存的镜像。 2、export 导出(import导入)是根据容器拿到的镜像,再导入时会丢失镜像所有的历史。 |
2.2.7 日志、信息、端口、重命名
查看容器运行日志
1 | 命令格式: |
查看容器详细信息
1 | 命令格式: |
查看容器端口信息
1 | 命令格式: |
容器重命名
1 | 作用: |
总结
2.3 数据管理
生产环境使用Docker的过程中,往往需要对数据进行持久化保存,或者需要更多容器之间进行数据共享,那我们需要怎么要的操作呢?
答案就是:数据卷(Data Volumes)和数据卷容器(Data Volume Containers)
2.3.1 数据卷简介
什么是数据卷?
就是将宿主机的某个目录,映射到容器中,作为数据存储的目录,我们就可以在宿主机对数据进行存储
数据卷(Data Volumes):容器内数据直接映射到本地主机环境
数据卷特性
1、数据卷可以在容器之间共享和重用,本地与容器间传递数据更高效;
2、对数据卷的修改会立马有效,容器内部与本地目录均可;
3、对数据卷的更新,不会影响镜像,对数据与应用进行了解耦操作;
4、卷会一直存在,直到没有容器使用。
docker 数据卷命令详解
1 | :~$ docker run --help |
我们可以使用命令 docker run 用来创建容器,可以在使用docker run 命令时添加 -v 参数,就可以创建并挂载一个到多个数据卷到当前运行的容器中。
-v 参数的作用是将宿主机的一个目录作为容器的数据卷挂载到docker容器中,使宿主机和容器之间可以共享一个 目录,如果本地路径不存在,Docker也会自动创建。
2.3.2 数据卷实践
关于数据卷的管理我们从两个方面来说:
1、目录
2、普通文件
数据卷实践 之 目录
1 | 命令格式: |
数据卷实践 之 文件{不推荐}
1 | 命令格式: |
注意:
1 | 1、Docker挂载数据卷的默认读写权限(rw),用户可以通过ro设置为只读 |
2.3.3 数据卷容器简介
什么是数据卷容器?
需要在多个容器之间共享一些持续更新的数据,最简单的方式是使用数据卷容器。数据卷容器也是一个容器,但是它的目的是专门用来提供数据卷供其他容器挂载。
数据卷容器(Data Volume Containers):使用特定容器维护数据卷
简单点:数据卷容器就是为其他容器提供数据交互存储的容器
docker 数据卷命令详解
1 | :~$ docker run --help |
数据卷容器操作流程
如果使用数据卷容器,在多个容器间共享数据,并永久保存这些数据,需要有一个规范的流程才能做得到:
1、创建数据卷容器
2、其他容器挂载数据卷容器
注意:
数据卷容器自身并不需要启动,但是启动的时候依然可以进行数据卷容器的工作。
2.3.4 数据卷容器实践
数据卷容器实践包括两部分:创建数据卷容器和使用数据卷容器
创建一个数据卷容器
1 | 命令格式: |
创建两个容器,同时挂载数据卷容器
1 | 命令格式: |
确认卷容器共享
1 | 进入vc-test1,操作数据卷容器: |
2.3.5 数据备份原理
为什么需要数据备份和恢复?
工作中很多的容器的数据需要查看,所有需要备份将数据很轻松的拿到本地目录。
原理图:
数据备份方案:
1 创建一个挂载数据卷容器的容器
2 挂载宿主机本地目录作为备份数据卷
3 将数据卷容器的内容备份到宿主机本地目录挂载的数据卷中
4 完成备份操作后销毁刚创建的容器
2.3.6 数据备份实践
在2.3.4的数据卷容器基础上做数据的备份
1 | 命令格式: |
注释:
-P:使用原文件的原来属性(属性不会依据使用者而变),恢复字段到它们的原始方式,忽略现有的用户权限屏蔽位(umask)。 加了-p之后,tar进行解压后,生成的文件的权限,是直接取自tar包里面文件的权限(不会再使用该用户的umask值进行运算),那么不加-p参数,将还要再减去umask的值(位运算的减),但是如果使用root用户进行操作,加不加-p参数都一样。
2.3.7 数据还原原理
原理图:
数据恢复方案
1、创建一个新的数据卷容器(或删除原数据卷容器的内容)
2、创建一个新容器,挂载数据卷容器,同时挂载本地的备份目录作为数据卷
3、将要恢复的数据解压到容器中
4、完成还原操作后销毁刚创建的容器
2.3.8 数据还原实践
1 | 命令格式: |
注意:
解压的时候,如果使用目录的话,一定要在解压的时候使用 -C 制定挂载的数据卷容器,不然的话容器数据是无法恢复的,因为容器中默认的backup目录不是数据卷,即使解压后,也看不到文件。
数据是最宝贵的资源,docker在设计上考虑到了这点,并且为数据的操作提供了充分的支持。
2.4 网络管理
Docker 网络很重要,重要的,我们在上面学到的所有东西都依赖于网络才能工作。我们从两个方面来学习网络:端口映射和网络模式
为什么先学端口映射呢?
在一台主机上学习网络,学习端口映射最简单,避免过多干扰。
2.4.1 端口映射详解
默认情况下,容器和宿主机之间网络是隔离的,我们可以通过端口映射的方式,将容器中的端口,映射到宿主机的某个端口上。这样我们就可以通过宿主机的ip+port的方式来访问容器里的内容
Docker的端口映射
1、随机映射 -P(大写)
2、指定映射 -p 宿主机ip:宿主机端口:容器端口
注意:
生产场景一般不使用随机映射,但是随机映射的好处就是由docker分配,端口不会冲突,
不管哪种映射都会有所消耗,影响性能。
2.4.2 随机映射实践
随机映射我们从两个方面来学习:
1、默认随机映射
2、指定主机随机映射
默认随机映射
1 | 命令格式: |
1 | 启动一个默认随机映射的nginx镜像 |
注意:
宿主机的32768被映射到容器的80端口
-P 自动绑定所有对外提供服务的容器端口,映射的端口将会从没有使用的端口池中自动随机选择,
但是如果连续启动多个容器的话,则下一个容器的端口默认是当前容器占用端口号+1
在浏览器中访问http://192.168.110.20:32768
效果显示
注意:
浏览器输入的格式是: docker容器宿主机的ip:容器映射的端口
指定主机随机映射
1 | 命令格式 |
2.4.3 指定映射实践
指定端口映射我们从二个方面来讲:
指定端口映射
指定多端口映射
指定端口映射
1 | 命令格式: |
多端口映射方法
1 | 命令格式 |
2.4.4 网络管理基础
docker网络命令
1 | 查看网络命令帮助 |
经常使用的网络查看命令
1 | 查看当前主机网络 |
1 | 查看bridge的网络内部信息 |
回忆一下
查看容器详细信息
1 | 命令格式: |
查看容器端口信息
1 | 命令格式: |
2.4.5 网络模式简介
从1.7.0版本开始,Docker正式把网络跟存储这两个部分的功能实现都以插件化的形式剥离出来,允许用户通过指令来选择不同的后端实现。这也就是Docker希望构建围绕着容器的强大生态系统的一些积极尝试。
剥离出来的独立网络项目叫做libnetwork,libnetwork中的网络模型(Container Networking Model ,CNM)十分简洁,可以让上层的大量应用容器最大程度上不去关心底层实现。
docker的常用的网络模式
bridge模式:
简单来说:就是穿马甲,打着宿主机的旗号,做自己的事情。
Docker的默认模式,它会在docker容器启动时候,自动配置好自己的网络信息,同一宿主机的所有容器都在一个网络下,彼此间可以通信。
利用宿主机的网卡进行通信,因为涉及到网络转换,所以会造成资源消耗,网络效率会低。
host模式:
简单来说,就是鸠占鹊巢,用着宿主机的东西,干自己的事情。容器使用宿主机的ip地址进行通信。
特点:容器和宿主机共享网络
container模式:
新创建的容器间使用,使用已创建的容器网络,类似一个局域网。
特点:容器和容器共享网络
none模式:
这种模式最纯粹,不会帮你做任何网络的配置,可以最大限度的定制化。
不提供网络服务,容器启动后无网络连接。
overlay模式:
容器彼此不再同一网络,而且能互相通行。
2.4.6 bridge模型实践
其实我们在端口映射的部分就是bridge模式的简单演示了,因为他们使用的是默认bridge网络模式,现在我们来自定义桥接网络。
这一部分我们从三个方面来演示:
创建桥接网络
使用自定义网络创建容器
容器断开、连接网络
创建网络
1 | 命令格式: |
自定义网段与网关
1 | 自定义网段与网关 |
在自定义网络中启动容器
1 | 命令格式: |
容器断开网络
1 | 命令格式: |
容器连接网络
1 | 命令格式: |
2.4.7 host模型实践
host模型我们知道,容器使用宿主机的ip地址进行对外提供服务,本身没有ip地址。
1 | 命令格式: |
查看网络运行效果
http://192.168.110.4
此处IP为对应宿主机ip并不固定
host特点:
host模型比较适合于,一台宿主机跑一个固定的容器,比较稳定,或者一个宿主机跑多个占用不同端口的应用的场景,他的网络性能是很高的。
host模型启动的容器不会有任何地址,他其实是使用了宿主机的所有信息