容器
如何运行容器？
上一章我们学习了如何构建 Docker 镜像，并通过镜像运行容器。本章将深入讨论容器：学习容器的各种操作，容器各种状态之间如何转换，以及实现容器的底层技术。
运行容器
docker run=docker create + docker start
docker run 是启动容器的方法。在讨论 Dockerfile 时我们已经学习到，可用三种方式指定容器启动时执行的命令：
- CMD 指令。
- ENTRYPOINT 指令。
- 在
docker run命令行中指定。
例如下面的例子：
bash
[root@docker ~]# docker create ubuntu #使用ubuntu镜像创建容器
eb1aa0ca86b2d49250ebe64913af50e88482ad68b9c3e61ef8f8da9c24b00f7a #新创建的容器长ID
[root@docker ~]# docker ps -a #create的容器状态时Created
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
eb1aa0ca86b2 ubuntu "/bin/bash" 2 seconds ago `Created` quizzical_goldwasser
[root@docker ~]# docker start eb1aa0ca86b2 #启动容器，刚创建的容器ID
eb1aa0ca86b2
[root@docker ~]# docker ps -a #查看容器状态，启动了又退出了
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
eb1aa0ca86b2 ubuntu "/bin/bash" 23 seconds ago Exited (0) 3 seconds ago quizzical_goldwasser
shell
[root@docker ~]# docker run ubuntu pwd #使用ubuntu镜像创建容器并执行pwd命令
/
[root@docker ~]#容器启动时执行 pwd，返回的 / 是容器中的当前目录。 执行 docker ps 或 docker container ls 可以查看 Docker host 中当前运行的容器：
bash
[root@docker ~]# docker ps #查看所有正在运行中的容器
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES咦，怎么没有容器？用 docker ps -a 或 docker container ls -a 看看。
-a 会显示所有状态的容器，可以看到，之前的容器已经退出了，状态为Exited。
这种"一闪而过"的容器通常不是我们想要的结果，我们希望容器能够保持 runing 状态，这样才能被我们使用。
让容器长期运行
如何让容器保存运行呢？
因为容器的生命周期依赖于启动时执行的命令，只要该命令不结束，容器也就不会退出。
理解了这个原理，我们就可以通过执行一个长期运行的命令来保持容器的运行状态。例如执行下面的命令：
bash
[root@docker ~]# docker run ubuntu /bin/bash -c "while true ; do sleep 1 ; echo hahaha; done"while 语句让 bash 不会退出。我们可以打开另一个终端查看容器的状态：
可见容器仍处于运行状态。不过这种方法有个缺点：它占用了一个终端。
我们可以加上参数 -d 以后台方式启动容器。
bash
[root@docker ~]# docker run -d ubuntu /bin/bash -c "while true ; do sleep 1 ; echo hahaha; done"
2a0bfa267fe146753b4fc8b23d55b08fbe3a5f9b5e093de6885133f6bbd20c56
[root@docker ~]#容器启动后回到了 docker host 的终端。这里看到 docker 返回了一串字符，这是容器的 ID。通过 docker ps 查看容器：
现在我们有了两个正在运行的容器。这里注意一下容器的 CONTAINER ID和 NAMES 这两个字段。
CONTAINER ID 是容器的 "短ID"，前面启动容器时返回的是 "长ID"。短ID是长ID的前12个字符。
NAMES 字段显示容器的名字，在启动容器时可以通过 --name 参数显示地为容器命名，如果不指定，docker 会自动为容器分配名字。
对于容器的后续操作，我们需要通过 "长ID"、"短ID" 或者 "名称" 来指定要操作的容器。比如下面停止一个容器：
bash
[root@docker ~]# docker stop 081be2bc2e1d
081be2bc2e1d这里我们就是通过 "短ID" 指定了要停止的容器。
通过 while 启动的容器虽然能够保持运行，但实际上没有干什么有意义的事情。容器常见的用途是运行后台服务，例如前面我们已经看到的 http server：
这一次我们用 --name 指定了容器的名字。 我们还看到容器运行的命令是httpd-foreground，通过 docker history 可知这个命令是通过 CMD 指定的。
我们经常需要进到容器里去做一些工作，比如查看日志、调试、启动其他进程等。下一节学习如何进入容器内部。
两种进入容器的方法
我们经常需要进到容器里去做一些工作，比如查看日志、调试、启动其他进程等。有两种方法进入容器：attach 和 exec。
docker attach
通过 docker attach 可以 attach 到容器启动命令的终端，例如：
bash
[root@docker ~]# docker run -d ubuntu /bin/bash -c "while true ; do sleep 1 ; echo I_am_in_container ; done"
dc508b94447f83b46080267580607569a187fcc7f780433f646e9d66949731a6
[root@docker ~]#
[root@docker ~]# docker attach dc508b94447f83b46080267580607569a187fcc7f780433f646e9d66949731a6
I_am_in_container
I_am_in_container
I_am_in_container
I_am_in_container这次我们通过 "长ID" attach 到了容器的启动命令终端，之后看到的是echo 每隔一秒打印的信息。
注：可通过 Ctrl+p 然后 Ctrl+q 组合键退出 attach 终端。
docker exec
通过 docker exec 进入相同的容器：
说明如下：
① -it 以交互模式打开 pseudo-TTY，执行 bash，其结果就是打开了一个 bash 终端。
② 进入到容器中，容器的 hostname 就是其 "短ID"。
③ 可以像在普通 Linux 中一样执行命令。ps -elf 显示了容器启动进程while 以及当前的 bash 进程。
④ 执行 exit 退出容器，回到 docker host。
docker exec -it <container> bash|sh 是执行 exec 最常用的方式。
attach VS exec
attach 与 exec 主要区别如下:
- attach 直接进入容器 启动命令 的终端，不会启动新的进程。
- exec 则是在容器中打开新的终端，并且可以启动新的进程。
- 如果想直接在终端中查看启动命令的输出，用 attach；其他情况使用 exec。
当然，如果只是为了查看启动命令的输出，可以使用 docker logs 命令：
bash
[root@docker ~]# docker logs -f dc508b94447f
I_am_in_container
I_am_in_container
I_am_in_container
I_am_in_container
I_am_in_container
I_am_in_container
I_am_in_container-f 的作用与 tail -f 类似，能够持续打印输出。
下一节聊聊运行容器的最佳实践。
运行容器的最佳实践
按用途容器大致可分为两类：服务类容器 和工具类的容器。
- 服务类容器以 daemon 的形式运行，对外提供服务。比如 web server，数据库等。通过
-d以后台方式启动这类容器是非常合适的。如果要排查问题，可以通过exec -it进入容器。 - 工具类容器通常给能我们提供一个临时的工作环境，通常以
run -it方式运行，比如：
bash
[root@docker ~]# docker run -it busybox
/ #
/ # wget www.baidu.com
Connecting to www.baidu.com (223.109.82.6:80)
saving to 'index.html'
index.html 100% |********************| 2381 0:00:00 ETA
'index.html' saved
/ #
/ # exit
[root@docker ~]#运行 busybox，run -it 的作用是在容器启动后就直接进入。我们这里通过 wget 验证了在容器中访问 internet 的能力。执行 exit 退出终端，同时容器停止。
工具类容器多使用基础镜像，例如 busybox、debian、ubuntu 等。
容器运行小结
容器运行相关的知识点：
- 当 CMD 或 Entrypoint 或 docker run 命令行指定的命令运行结束时，容器停止。
- 通过
-d参数在后台启动容器。 - 通过
exec -it可进入容器并执行命令。
指定容器的三种方法：
- 短ID。
- 长ID。
- 容器名称。 可通过
--name为容器命名。重命名容器可执行docker rename。
容器按用途可分为两类：
- 服务类的容器。
- 工具类的容器。
下一节讨论容器的其他操作，比如 stop, restart, pause, delete。
容器常用操作
前面讨论了如何运行容器，本节学习容器的其他常用操作。
stop/start/restart 容器
通过 docker stop 可以停止运行的容器。
容器在 docker host 中实际上是一个进程，docker stop 命令本质上是向该进程发送一个 SIGTERM 信号。如果想快速停止容器，可使用 docker kill 命令，其作用是向容器进程发送 SIGKILL 信号。
对于处于停止状态的容器，可以通过 docker start 重新启动。
docker start 会保留容器的第一次启动时的所有参数。
docker restart 可以重启容器，其作用就是依次执行 docker stop 和docker start。
容器可能会因某种错误而停止运行。对于服务类容器，我们通常希望在这种情况下容器能够自动重启。启动容器时设置 --restart 就可以达到这个效果。
如果docker run -d httpd不加--restart=always参数，（dock stop不会重启，attach进去ctrl_c（终止进程）会重启）。
--restart=always 意味着无论容器因何种原因退出（不包过docker stop），就立即重启。该参数的形式还可以是 --restart=on-failure:3，意思是如果启动进程退出代码非0，则重启容器，最多重启3次。
pause/unpause 容器
有时我们只是希望暂时让容器暂停工作一段时间，比如要对容器的文件系统打个快照，或者 dcoker host 需要使用 CPU，这时可以执行 docker pause。
处于暂停状态的容器不会占用 CPU 资源，直到通过 docker unpause 恢复运行。
删除容器
使用 docker 一段时间后，host 上可能会有大量已经退出了的容器。
这些容器依然会占用 host 的文件系统资源，如果确认不会再重启此类容器，可以通过 docker rm 删除。
bash
[root@docker ~]# docker rm 35af7150bd17 9769bb915803
35af7150bd17
9769bb915803docker rm 一次可以指定多个容器，如果希望批量删除所有已经退出的容器，可以执行如下命令：
docker rm -f $(docker ps -aq -f status=exited)
bash
# !!!慎用,删除所有状态容器
[root@docker ~]# docker rm -f $(docker ps -aq)顺便说一句：docker rm 是删除容器，而 docker rmi 是删除镜像。
一下学了这么多操作，很有必要做个总结。下一节我们会用一张图来描述容器的状态机。
一张图搞懂容器所有操作
前面我们已经讨论了容器的各种操作，对容器的生命周期有了大致的理解，下面这张状态机很好地总结了容器各种状态之间是如何转换的。
如果掌握了前面的知识，要看懂这张图应该不难。不过有两点还是需要补充一下：
-
可以先创建容器，稍后再启动。
①
docker create创建的容器处于 Created 状态。②
docker start将以后台方式启动容器。docker run命令实际上是docker create和docker start的组合。 -
只有当容器的启动进程 退出 时，
--restart才生效。
退出包括正常退出或者非正常退出。这里举了两个例子：启动进程正常退出或发生 OOM，此时 docker 会根据
--restart的策略判断是否需要重启容器。但如果容器是因为执行docker stop或docker kill退出，则不会自动重启。
bash
#基于httpd镜像创建容器httpd11，重启策略配置为always
[root@docker ~]# docker run -d --restart=always --name httpd11 httpd
7671267fabf6aafe49fe74256af8d0af07cd65e4af4222933385f3203bc0228e
#查看发现多了个httpd11容器
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7671267fabf6 httpd "httpd-foreground" 3 seconds ago Up 2 seconds 80/tcp `httpd11`
27359e7cf87e httpd "httpd-foreground" About a minute ago Up About a minute 80/tcp eager_northcutt
#登陆到容器httpd11，然后执行ctrl_c退出容器(会触发--restart=always参数)
[root@docker ~]# docker attach httpd11
^C[Mon Nov 17 07:48:31.582731 2025] [mpm_event:notice] [pid 1:tid 1] AH00491: caught SIGTERM, shutting down
#发现httpd11重启了
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7671267fabf6 httpd "httpd-foreground" 32 seconds ago Up 2 seconds 80/tcp httpd11
27359e7cf87e httpd "httpd-foreground" 2 minutes ago Up About a minute 80/tcp eager_northcutt
#管理员停止httpd11(不会触发重启)
[root@docker ~]# docker stop httpd11
httpd11
#发现httpd11没有chong
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7671267fabf6 httpd "httpd-foreground" 51 seconds ago Exited (0) 1 second ago httpd11
27359e7cf87e httpd "httpd-foreground" 2 minutes ago Up 2 minutes 80/tcp eager_northcutt
[root@docker ~]# 好了，容器操作就讨论到这里，下一节我们将学习如何限制容器对资源的使用。
限制容器对内存的使用
cgroup简介
docker 通过 cgroup 来控制容器使用的资源配额，包括 CPU、内存、磁盘三大方面，基本覆盖了常见的资源配额和使用量控制。
cgroup 是 Control Groups 的缩写，是 Linux 内核提供的一种可以限制、记录、隔离进程组所使用的物理资源(如 cpu、memory、磁盘IO等等) 的机制，被 LXC、docker 等很多项目用于实现进程资源控制。cgroup 将任意进程进行分组化管理的 Linux 内核功能。cgroup 本身是提供将进程进行分组化管理的功能和接口的基础结构，I/O 或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。这些具体的资源管理功能称为 cgroup 子系统，有以下几大子系统实现：
blkio：设置限制每个块设备的输入输出控制。例如:磁盘，光盘以及 usb 等等。
cpu：使用调度程序为 cgroup 任务提供 cpu 的访问。
cpuacct：产生 cgroup 任务的 cpu 资源报告。
cpuset：如果是多核心的 cpu，这个子系统会为 cgroup 任务分配单独的 cpu 和内存。
devices：允许或拒绝 cgroup 任务对设备的访问。
freezer：暂停和恢复 cgroup 任务。
memory：设置每个 cgroup 的内存限制以及产生内存资源报告。
net_cls：标记每个网络包以供 cgroup 方便使用。
ns：命名空间子系统。
perf_event：增加了对每 group 的监测跟踪的能力，可以监测属于某个特定的 group 的所有线程以及运行在特定CPU上的线程。
stress是什么？
是模拟压力测试的工具
在机器上模拟cpu、内存等使用率
来检测不同状态下的运行情况
目前 docker 只是用了其中一部分子系统，实现对资源配额和使用的控制。
可以使用 stress 工具来测试 CPU 和内存。使用下面的 Dockerfile 来创建一个基于 Ubuntu 的 stress 工具镜像。
Dockerfile
dockerfile
[root@docker dockerfile]# vim Dockerfile
# Version 1
FROM ubuntu
MAINTAINER gaoqd "6946630@qq.com"
RUN apt-get -y update && apt-get -y install stress
ENTRYPOINT ["/usr/bin/stress"] # 以服务或进程的形式运行使用Dockerfile构建镜像ubuntu-with-stress
bash
[root@docker ~]# docker build -t ubuntu-with-stress .一个 docker host 上会运行若干容器，每个容器都需要 CPU、内存和 IO 资源。对于 KVM，VMware 等虚拟化技术，用户可以控制分配多少 CPU、内存资源给每个虚拟机。对于容器，Docker 也提供了类似的机制避免某个容器因占用太多资源而影响其他容器乃至整个 host 的性能。
内存限额
与操作系统类似，容器可使用的内存包括两部分：物理内存和 swap。 Docker 通过下面两组参数来控制容器内存的使用量。
-m或--memory：设置内存的使用限额，例如 100M, 2G。--memory-swap：设置 内存+swap 的使用限额。
当我们执行如下命令：
docker run -m 200M --memory-swap=300M ubuntu
其含义是允许该容器最多使用 200M 的内存和 100M 的 swap。
正常情况下，--memory-swap 的值包含容器可用内存和可用swap。所以 -m 300m --memory-swap=1g 的含义为：容器可用使用300M的物理内存，并且可以使用700M（1G-300）的swap。
如果--memory-swap 设置为0 或者不设置，则容器可以使用的swap大小为-m值的两倍。
如果 --memory-swap 的值和-m 值相同，则容器不能使用swap
如果 --memory-swap值为-1。它表示容器程序使用的内存受限，而可以使用的swap空间不受限制（宿主机有多少swap空间该容器就可以使用多少）
下面我们将使用ubuntu-with-stress镜像来学习如何为容器分配内存。该镜像可用于对容器执行压力测试。执行如下命令：
bash
[root@docker ~]# docker run -it -m 200M --memory-swap=300M ubuntu-with-stress --vm 1 --vm-bytes 280M -v--vm 1：启动 1 个内存工作线程。
--vm-bytes 280M：每个线程分配 280M 内存。
运行结果如下：
因为 280M 在可分配的范围（300M）内，所以工作线程能够正常工作，其过程是：
- 分配 280M 内存。
- 释放 280M 内存。
- 再分配 280M 内存。
- 再释放 280M 内存。
- 一直循环...
如果让工作线程分配的内存超过 300M，结果如下：
分配的内存超过限额，stress 线程报错，容器退出。
如果在启动容器时只指定 -m 而不指定 --memory-swap，那么 --memory-swap 默认为 -m 的两倍，比如：
docker run -it -m 200M ubuntu-with-stress
容器最多使用 200M 物理内存和 200M swap。
内存限额就讨论到这里，下一节我们学习如何限制容器对 CPU 资源的使用。
限制容器对CPU的使用
上节学习了如何限制容器对内存的使用，本节我们来看CPU。
默认设置下，所有容器可以平等地使用 host CPU 资源并且没有限制。
Docker 可以通过 -c 或 --cpu-shares 设置容器使用 CPU 的权重。如果不指定，默认值为 1024。
--cpu-shares的值不能保证可以获得1个 vcpu 或者多少 GHz 的 CPU 资源，仅仅只是一个弹性的加权值。
默认情况下，每个 docker 容器的 cpu 份额都是1024。单独一个容器的份额是没有意义的，只有在同时运行多个容器时，容器的 CPU 加权的效果才能体现出来。例如，两个容器A、B的 CPU 份额分别为1000和500，在 CPU 进行时间片分配的时候，容器 A 比容器 B 多一倍的机会获得 CPU 的时间片，但分配的结果取决于当时主机和其他容器的运行状态，实际上也无法保证容器A一定能获得 CPU 时间片。比如容器A的进程一直是空闲的，那么容器B是可以获取比容器A更多的 CPU 时间片的。极端情况下，比如说主机上只运行了一个容器，即使它的 CPU 份额只有 50，它也可以独占整个主机的 CPU 资源。
cgroups 只在容器分配的资源紧缺时，也就是说在需要对容器使用的资源进行限制时，才会生效。因此，无法单纯根据某个容器的 CPU 份额来确定有多少 CPU 资源分配给它，资源分配结果取决于同时运行的其他容器的 CPU 分配和容器中进程运行情况。
换句话说：通过 cpu share 可以设置容器使用 CPU 的优先级。
比如在 host 中启动了两个容器：
docker run --name "container_A" -c 1024 ubuntu
docker run --name "container_B" -c 512 ubuntu
container_A 的 cpu share 1024，是 container_B 的两倍。当两个容器都需要 CPU 资源时，container_A 可以得到的 CPU 是 container_B 的两倍。
需要特别注意的是，这种按权重分配 CPU 只会发生在 CPU 资源紧张的情况下。如果 container_A 处于空闲状态，这时，为了充分利用 CPU 资源，container_B 也可以分配到全部·可用的 CPU。
下面我们继续用 ubuntu-with-stress 做实验。
-
启动 container_A，cpu share 为 1024：
bash[root@docker ~]# docker run --name "container_A" -it -c 1024 ubuntu-with-stress --cpu 4 -v stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd stress: dbug: [1] using backoff sleep of 12000us stress: dbug: [1] --> hogcpu worker 4 [7] forked stress: dbug: [1] using backoff sleep of 9000us stress: dbug: [1] --> hogcpu worker 3 [8] forked stress: dbug: [1] using backoff sleep of 6000us stress: dbug: [1] --> hogcpu worker 2 [9] forked stress: dbug: [1] using backoff sleep of 3000us stress: dbug: [1] --> hogcpu worker 1 [10] forked #再开一个窗口 #使用如下命令，创建容器，则最终生成的 cgroup 的 CPU 份额配置可以下面的文件中找到。 [root@docker ~]# cat /sys/fs/cgroup/cpu/docker/<容器长ID>/cpu.shares 1024--cpu用来设置工作线程的数量。因为当前 host 有 4颗 CPU，所以要4个工作线程才能将 CPU 压满。如果 host 有多颗 CPU，则需要相应增加--cpu的数量。 -
再开一个窗口，启动 container_B，cpu share 为 512：
bash[root@docker ~]# docker run --name "container_B" -it -c 512 ubuntu-with-stress --cpu 4 -v stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd stress: dbug: [1] using backoff sleep of 12000us stress: dbug: [1] --> hogcpu worker 4 [7] forked stress: dbug: [1] using backoff sleep of 9000us stress: dbug: [1] --> hogcpu worker 3 [8] forked stress: dbug: [1] using backoff sleep of 6000us stress: dbug: [1] --> hogcpu worker 2 [9] forked stress: dbug: [1] using backoff sleep of 3000us stress: dbug: [1] --> hogcpu worker 1 [10] forked [root@docker ~]# cat /sys/fs/cgroup/cpu/docker/<容器长ID>/cpu.shares 512 -
在 host 中执行
top，查看容器对 CPU 的使用情况：
因为我们host是4核所以开启了4个进程，为的就是充分让系统资源变得紧张，只有这样竞争资源，我们设定的资源比例才可以显现出来，如果只运行一个进程，他们会自动分配到空闲的CPU，这样比例就无法看出来。目前可以看到总比例是2:1。
container_A 消耗的 CPU 是 container_B 的两倍。
再开一个窗口
bash[root@docker docker]# docker stats
现在暂停 container_A：
bash
[root@docker ~]# docker pause container_A
container_A
top 显示 container_B 在 container_A 空闲的情况下能够用满整颗 CPU：
export和import容器
export-容器导出
将容器导出为一个tar包
bash
[root@docker ~]# docker export --help
Usage: docker export [OPTIONS] CONTAINER
Export a container's filesystem as a tar archive
Aliases:
docker container export, docker export
Options:
-o, --output string Write to a file, instead of STDOUT不管此时这个容器是否处于运行状态，都可以导出为文件。
示例：
bash
# 创建容器httpd1用于测试
[root@docker ~]# docker run -d --name httpd1 httpd
e4f0a329c4df50ef0afb0bf21e22edc20e5a24c03ae64c6340aa2992d6e32525
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e4f0a329c4df httpd "httpd-foreground" 3 minutes ago Up 3 minutes 80/tcp httpd1
[root@docker ~]# docker export httpd1 -o myhttpd.tar
[root@docker ~]# ls
myhttpd.tarimport-容器tar包导入
import将export导出的tar包导入成为镜像
bash
[root@docker ~]# docker import --help
Usage: docker import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]
Import the contents from a tarball to create a filesystem image
Aliases:
docker image import, docker import
Options:
-c, --change list Apply Dockerfile instruction to the created image
-m, --message string Set commit message for imported image
--platform string Set platform if server is multi-platform capable示例：
bash
[root@docker ~]# docker import myhttpd.tar
sha256:9ae4699fa217a7240c73a50e93a8c1d359d22cf60869d350c8aab8b3c02aabcf
[root@docker ~]# docker import myhttpd.tar myweb:v1
sha256:9fcb90561d2014130ef19f9dd8af5efd7a0a4a2154907bc818ac6b887f13755c
[root@docker ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
myweb v1 9fcb90561d20 3 seconds ago 146MB
<none> <none> 9ae4699fa217 32 seconds ago 146MB
httpd latest 90f191b9781e 11 days ago 148MB
hello-world latest 74cc54e27dc4 6 months ago 10.1kB
[root@docker ~]#docker save和docker export对比：
docker save：将镜像保存为文件，save会保存该镜像的所有元数据和历史记录。docker export：将容器导出为文件，文件会丢失所有元数据和历史记录，仅保存容器当时的状态，再次导入会当作全新的镜像。
思考：docker export导出的文件是否可以使用docker load导入？
bash
[root@docker ~]# docker load -i myhttpd.tar
open /var/lib/docker/tmp/docker-import-3425397234/boot/json: no such file or directory思考：docker save导出的文件是否可以使用docker import导入？
提示：我们可以将docker save保存出来的文件解压后分析文件结构。
实现容器的底层技术
为了更好地理解容器的特性，本节我们将讨论容器的底层实现技术。
cgroup 和 namespace 是最重要的两种技术。cgroup 实现资源限额 ， namespace 实现资源隔离。
cgroup
cgroup 全称 Control Group。Linux 操作系统通过 cgroup 可以设置进程使用 CPU、内存 和 IO 资源的限额。相信你已经猜到了：前面我们看到的--cpu-shares、-m、--device-write-bps 实际上就是在配置 cgroup。
cgroup 到底长什么样子呢？我们可以在 /sys/fs/cgroup 中找到它。还是用例子来说明，启动一个容器，设置 --cpu-shares=512：
bash
[root@docker docker]# docker run -it --cpu-shares 512 ubuntu-with-stress -c 1 -v
stress: info: [1] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [7] forked查看容器的 ID：
在 /sys/fs/cgroup/cpu/docker 目录中，Linux 会为每个容器创建一个 cgroup 目录，以容器长ID 命名：
目录中包含所有与 cpu 相关的 cgroup 配置，文件 cpu.shares 保存的就是 --cpu-shares 的配置，值为 512。
同样的，/sys/fs/cgroup/memory/docker 和 /sys/fs/cgroup/blkio/docker 中保存的是内存以及 Block IO 的 cgroup 配置。
namespace
在每个容器中，我们都可以看到文件系统，网卡等资源，这些资源看上去是容器自己的。拿网卡来说，每个容器都会认为自己有一块独立的网卡，即使 host 上只有一块物理网卡。这种方式非常好，它使得容器更像一个独立的计算机。
Linux 实现这种方式的技术是 namespace。namespace 管理着 host 中全局唯一的资源，并可以让每个容器都觉得只有自己在使用它。换句话说，namespace 实现了容器间资源的隔离。
Linux 使用了六种 namespace，分别对应六种资源：Mount、UTS、IPC、PID、Network 和 User，下面我们分别讨论。
Mount namespace
Mount namespace 让容器看上去拥有整个文件系统。
容器有自己的 / 目录，可以执行 mount 和 umount 命令。当然我们知道这些操作只在当前容器中生效，不会影响到 host 和其他容器。
UTS namespace
简单的说，UTS namespace 让容器有自己的 hostname。 默认情况下，容器的 hostname 是它的短ID，可以通过 -h 或 --hostname 参数设置。
IPC namespace
IPC namespace 让容器拥有自己的共享内存和信号量（semaphore）来实现进程间通信，而不会与 host 和其他容器的 IPC 混在一起。
PID namespace
我们前面提到过，容器在 host 中以进程的形式运行。例如当前 host 中运行了两个容器：
bash
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a80f1f8b692c ubuntu "/bin/bash" 26 seconds ago Up 4 seconds interesting_davinci
835dd4eebda2 httpd "httpd-foreground" 56 seconds ago Up 55 seconds 80/tcp adoring_pare通过 ps axf 可以查看容器进程：
所有容器的进程都挂在 dockerd 进程下，同时也可以看到容器自己的子进程。 如果我们进入到某个容器，ps 就只能看到自己的进程了：
bash
[root@docker ~]# docker exec -it a80f1f8b692c bash
root@a80f1f8b692c:/#
root@a80f1f8b692c:/# ps axf
PID TTY STAT TIME COMMAND
17 pts/1 Ss 0:00 bash
25 pts/1 R+ 0:00 \_ ps axf
1 pts/0 Ss+ 0:00 /bin/bash而且进程的 PID 不同于 host 中对应进程的 PID，容器中 PID=1 的进程当然也不是 host 的 init 进程。也就是说：容器拥有自己独立的一套 PID，这就是 PID namespace 提供的功能。
Network namespace
Network namespace 让容器拥有自己独立的网卡、IP、路由等资源。我们会在后面网络章节详细讨论。
User namespace
User namespace 让容器能够管理自己的用户，host 不能看到容器中创建的用户。
bash
[root@docker ~]# docker exec -it a80f1f8b692c bash
root@a80f1f8b692c:/#
root@a80f1f8b692c:/# useradd gaoqd #容器中创建用户gaoqd
root@a80f1f8b692c:/#
root@a80f1f8b692c:/# exit
exit
[root@docker ~]# su - gaoqd #宿主机中并没有用户gaoqd
su: user gaoqd does not exist在容器中创建了用户 gaoqd，但 host 中并不会创建相应的用户。
小结
本章首先通过大量实验学习了容器的各种操作以及容器状态之间如何转换，然后讨论了限制容器使用 CPU、内存和 Block IO 的方法，最后学习了实现容器的底层技术：cgroup 和 namespace。
下面是容器的常用操作命令：
create 创建容器
run 运行容器
pause 暂停容器
unpause 取消暂停继续运行容器
stop 发送 SIGTERM 停止容器
kill 发送 SIGKILL 快速停止容器
start 启动容器
restart 重启容器
attach attach 到容器启动进程的终端
exec 在容器中启动新进程，通常使用 "-it" 参数
logs 显示容器启动进程的控制台输出，用 "-f" 持续打印
rm 从磁盘中删除容器
到这里，我们已经学习完了容器章节。下一节开始讨论容器网络。
网络
none和host网络的适用场景
本章开始讨论 Docker 网络。
我们会首先学习 Docker 提供的几种原生网络，以及如何创建自定义网络。然后探讨容器之间如何通信，以及容器与外界如何交互。
Docker 网络从覆盖范围可分为单个 host 上的容器网络和跨多个 host 的网络，本章重点讨论前一种。对于更为复杂的多 host 容器网络，我们会在后面进阶技术章节单独讨论。
Docker 安装时会自动在 host 上创建三个网络，我们可用 docker network ls 命令查看：
bash
[root@docker ~]# docker network ls
NETWORK ID NAME DRIVER SCOPE
a1b809382f0d bridge bridge local
6ad21ed9ea1f host host local
4e31521b27c6 none null local下面我们分别讨论它们。
none 网络
none网络的driver类型是null，IPAM字段为空。挂在none网络上的容器只有lo，无法与外界通信。
故名思议，none 网络就是什么都没有的网络。挂在这个网络下的容器除了 lo，没有其他任何网卡。容器创建时，可以通过 --network=none 指定使用 none 网络。
bash
[root@docker ~]# docker run -it --network=none busybox
/ #
/ # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
/ #
/ # hostname
4027da12afaf我们不禁会问，这样一个封闭的网络有什么用呢？
其实还真有应用场景。封闭意味着隔离，一些对安全性要求高并且不需要联网的应用可以使用 none 网络。
比如某个容器的唯一用途是生成随机密码，就可以放到 none 网络中避免密码被窃取。
当然大部分容器是需要网络的，我们接着看 host 网络。
host 网络
挂在host网络上的容器共享宿主机的network namespace。即容器的网络配置与host网络配置完全一样。
连接到 host 网络的容器共享 Docker host 的网络栈，容器的网络配置与 host 完全一样。可以通过 --network=host 指定使用 host 网络。
bash
[root@docker ~]# docker run -it --network=host busybox #容器网络与宿主机相同
/ #
/ # ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 00:0c:29:33:15:f6 brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 02:42:02:fd:82:b3 brd ff:ff:ff:ff:ff:ff
/ #
/ # hostname #容器主机与宿主机相同
docker
/ #在容器中可以看到 host 的所有网卡，并且连 hostname 也是 host 的。host 网络的使用场景又是什么呢？
直接使用 Docker host 的网络最大的好处就是性能，如果容器对网络传输效率有较高要求，则可以选择 host 网络。当然不便之处就是牺牲一些灵活性，比如要考虑端口冲突问题，Docker host 上已经使用的端口就不能再用了。
Docker host 的另一个用途是让容器可以直接配置 host 网路。比如某些跨 host 的网络解决方案，其本身也是以容器方式运行的，这些方案需要对网络进行配置，比如管理 iptables。
下一节讨论应用更广的 bridge 网络。
学容器必须懂brige网络
上一节我们讨论了 none 和 host 类型的容器网络，本节学习应用最广泛也是默认的 bridge 网络。
Docker 安装时会创建一个 命名为 docker0 的 linux bridge，实际上它是 Linux 的一个 bridge (网桥)，可以理解为一个软件交换机，它会在挂载到它的网口之间进行转发。如果不指定--network，创建的容器默认都会挂到 docker0 上。
Docker 就创建了在主机和所有容器之间一个虚拟共享网络 当创建一个 Docker 容器的时候，同时会创建了一对 veth pair 接口（当数据包发送到一个接口时，另外一个接口也可以收到相同的数据包）, 这对接口
- 一端在容器内即 eth0；
- 另一端在本地并被挂载到 docker0 网桥，名称以 veth 开头（例如 vethAQI2QT）
通过这种方式，主机可以跟容器通信，容器之间也可以相互通信。
下面演示：
先配置yum源用于安装软件
bash
[root@docker ~]# cd /etc/yum.repos.d/
[root@docker yum.repos.d]# vim cloud.repo
[centos-openstack-victoria]
name=CentOS 8 - OpenStack victoria
baseurl=https://mirrors.aliyun.com/centos-vault/8-stream/cloud/x86_64/openstack-victoria/
enabled=1
gpgcheck=0
[root@docker yum.repos.d]# yum install -y bridge-utils
bash
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02420be905a5 no当前 docker0 上没有任何其他网络设备，我们创建一个容器看看有什么变化。
bash
[root@docker ~]# docker run -itd --name busybox1 busybox
5225d246f751dbfc4cdf745675d9c79d3de1b91dd4174268c35e671b9f1b0c80
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02420be905a5 no vethddb2744一个新的网络接口 vethddb2744 被挂到了 docker0 上，vethddb2744就是新创建容器的虚拟网卡。
下面看一下容器的网络配置。
bash
[root@docker ~]# docker exec -it busybox1 sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
# 容器里的网卡是24号网卡名字叫eth0，对面是25号网卡
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever容器有一个网卡 eth0@if25。大家可能会问了，为什么不是vethddb2744 呢？
实际上 eth0@if25 和 vethddb2744 是一对 veth pair。veth pair 是一种成对出现的特殊网络设备，可以把它们想象成由一根虚拟网线连接起来的一对网卡，网卡的一头（eth0@if25）在容器中，另一头（vethddb2744）挂在网桥 docker0 上，其效果就是将 eth0@if25 也挂在了 docker0 上。
在宿主机上查看IP地址，可以证明Docker0上的vethddb2744和容器中的eth0@if25 是一对
在宿主机看到有块网卡：25: vethddb2744@if24
宿主机的25号网卡：25: vethddb2744@if24 含义就是宿主机25号网卡对面连接了一块24号网卡，25号网卡的名字叫vethddb2744
证明了容器busybox1里的eth0连接到了docker0网桥的vethddb2744
我们还看到eth0@if25 已经配置了 IP 172.17.0.2，为什么是这个网段呢？让我们通过 docker network inspect bridge 看一下 bridge 网络的配置信息:
bash
[root@docker ~]# docker network inspect bridge
[
{
"Name": "bridge",
"Id": "9c8f4ff0c361c169536a912736d7a305b93abd9f3acc69fee066233260930a69",
"Created": "2025-07-31T13:31:35.155868533+08:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16", `#这是bridge网络分配的网段`
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"5225d246f751dbfc4cdf745675d9c79d3de1b91dd4174268c35e671b9f1b0c80": {
"Name": "busybox1", `#容器busybox1`
"EndpointID": "ecc590ff010723831b97c0439ef9a9ca13fda695185d846d25662caecb066b7f",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16", `分配给busybox1的172.17.0.2`
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]原来 bridge 网络配置的 subnet 就是 172.17.0.0/16，并且网关是 172.17.0.1。这个网关在哪儿呢？大概你已经猜出来了，就是 docker0。
bash
[root@docker ~]# ip a | grep docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0当前容器网络拓扑结构如图所示：
容器创建时，docker 会自动从 172.17.0.0/16 中分配一个 IP，这里 16 位的掩码保证有足够多的 IP 可以供容器使用。
除了 none, host, bridge 这三个自动创建的网络，用户也可以根据业务需要创建 user-defined 网络，下一节我们将详细讨论。
如何自定义容器网络？
除了 none, host, bridge 这三个自动创建的网络，用户也可以根据业务需要创建 user-defined 网络。
Docker 提供三种 user-defined 网络驱动：bridge, overlay 和 macvlan。overlay 和 macvlan 用于创建跨主机的网络。
我们可通过 bridge 驱动创建类似前面默认的 bridge 网络，例如：
bash
[root@docker ~]# docker network create --driver bridge my_net
89f7bc11b602e84452ae01786113ac196a535f7296b9989ad941b3a48a5e6d04查看一下当前 host 的网络结构变化：
bash
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no #my_net，看bridge name和刚才创建的my_net id一样
docker0 8000.02420be905a5 no vethddb2744 新增了一个网桥 br-89f7bc11b602，这里 br-89f7bc11b602 正好是新建 bridge 网络 my_net 的短 id。执行 docker network inspect 查看一下 my_net 的配置信息：
bash
[root@docker ~]# docker network ls
[root@docker ~]# docker network inspect my_net
[
{
"Name": "my_net",
"Id": "89f7bc11b602e84452ae01786113ac196a535f7296b9989ad941b3a48a5e6d04",
"Created": "2025-07-31T15:57:17.487644996+08:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.18.0.0/16", `#这里 172.18.0.0/16 是 Docker 自动分配的 IP 网段。``
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]这里 172.18.0.0/16 是 Docker 自动分配的 IP 网段。
我们可以自己指定 IP 网段吗？
答案是：可以。
只需在创建网段时指定 --subnet 和 --gateway 参数：
bash
[root@docker ~]# docker network create --driver bridge --subnet 172.22.16.0/24 --gateway 172.22.16.1 my_net2
ec761bc51778f67c2245af72fd969f00cd517ee617a10a70dc01904f9c10279d
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no #my_net
br-ec761bc51778 8000.02427fa54b88 no #my_net2
docker0 8000.02420be905a5 no vethddb2744
[root@docker ~]# docker network inspect my_net2
[
{
"Name": "my_net2",
"Id": "ec761bc51778f67c2245af72fd969f00cd517ee617a10a70dc01904f9c10279d",
"Created": "2025-07-31T16:00:06.021244096+08:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.22.16.0/24", #确实是指定的网段
"Gateway": "172.22.16.1" #确实是指定的网关地址
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]这里我们创建了新的 bridge 网络 my_net2，网段为 172.22.16.0/24，网关为 172.22.16.1。与前面一样，网关在 my_net2 对应的网桥 br-ec761bc51778 上：
bash
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no #my_net
br-ec761bc51778 8000.02427fa54b88 no #my_net2
docker0 8000.02420be905a5 no vethddb2744
#同时宿主机上出现了与网桥my_net,my_net2同名的网卡
#查看my_net2网卡
[root@docker ~]# ip a | grep br-ec761bc51778
27: br-ec761bc51778: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
inet 172.22.16.1/24 brd 172.22.16.255 scope global br-ec761bc51778容器要使用新的网络，需要在启动时通过 --network 指定：
bash
[root@docker ~]# docker run -it --network=my_net2 --name busybox2 busybox
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
28: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:16:10:02 brd ff:ff:ff:ff:ff:ff
inet 172.22.16.2/24 brd 172.22.16.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ctrl+P,ctrl+q退出容器
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no
br-ec761bc51778 8000.02427fa54b88 no veth02dd704 #my_net2上新增的接口veth02dd704连接容器busybox2
docker0 8000.02420be905a5 no vethddb2744容器分配到的 IP 为 172.22.16.2。
到目前为止，容器的 IP 都是 docker 自动从 subnet 中分配，我们能否指定一个静态 IP 呢？
答案是：可以，通过--ip指定。
bash
[root@docker ~]# docker run -it --network=my_net2 --ip 172.22.16.8 --name busybox3 busybox
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
30: eth0@if31: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:16:10:08 brd ff:ff:ff:ff:ff:ff
inet 172.22.16.8/24 brd 172.22.16.255 scope global eth0 #确实是指定的IP
valid_lft forever preferred_lft forever
/ # ctrl+P,ctrl+q退出容器
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no #my_net
br-ec761bc51778 8000.02427fa54b88 no veth02dd704 #my_net2
veth5fbb7f6 #veth5fbb7f6是连接busybox3
docker0 8000.02420be905a5 no vethddb2744注：只有使用 --subnet 创建的网络才能指定静态 IP。
my_net 创建时没有指定 --subnet，如果指定静态 IP 报错如下：
bash
[root@docker ~]# docker run -it --network=my_net --ip 172.18.0.8 busybox
docker: Error response from daemon: invalid config for network my_net: invalid endpoint settings:
user specified IP address is supported only when connecting to networks with user configured subnets.
See 'docker run --help'.好了，我们来看看当前 docker host 的网络拓扑结构。
下一节讨论这几个容器之间的连通性。
理解容器之间的连通性
通过前面小节的实践，当前 docker host 的网络拓扑结构如下图所示，今天我们将讨论这几个容器之间的连通性。
busybox2、busybox3 容器都挂在 my_net2 上，应该能够互通，我们验证一下：
bash
# 登陆busybox2 ping busybox3
[root@docker ~]# docker exec -it busybox2 sh
/ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:42:AC:16:10:02
inet addr:172.22.16.2 Bcast:172.22.16.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1436 (1.4 KiB) TX bytes:0 (0.0 B)
/ # ping -c 3 172.22.16.8
PING 172.22.16.8 (172.22.16.8): 56 data bytes
64 bytes from 172.22.16.8: seq=0 ttl=64 time=0.197 ms
64 bytes from 172.22.16.8: seq=1 ttl=64 time=0.137 ms
64 bytes from 172.22.16.8: seq=2 ttl=64 time=0.158 ms
--- 172.22.16.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.137/0.164/0.197 ms
/ #
# ping my_net2网关地址
/ # ping -c 3 172.22.16.1
PING 172.22.16.1 (172.22.16.1): 56 data bytes
64 bytes from 172.22.16.1: seq=0 ttl=64 time=0.149 ms
64 bytes from 172.22.16.1: seq=1 ttl=64 time=0.116 ms
64 bytes from 172.22.16.1: seq=2 ttl=64 time=0.182 ms
--- 172.22.16.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.116/0.149/0.182 ms可见同一网络中的容器、网关之间都是可以通信的。
my_net2 与默认 bridge 网络(docker0)能通信吗？
从拓扑图可知，两个网络属于不同的网桥，应该不能通信，我们通过实验验证一下，让 busybox2 容器 ping buxybox1 容器：
bash
/ # ping -c 3 172.17.0.2
PING 172.17.0.2 (172.17.0.2): 56 data bytes
--- 172.17.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
/ #确实 ping 不通，符合预期。
"等等！不同的网络如果加上路由应该就可以通信了吧？"
这是一个非常非常好的想法。
确实，如果 host 上对每个网络的都有一条路由，同时操作系统上打开了 ip forwarding，host 就成了一个路由器，挂接在不同网桥上的网络就能够相互通信。下面我们来看看 docker host 满不满足这些条件呢？
ip r 查看 host 上的路由表：
bash
[root@docker ~]# ip r
default via 192.168.108.2 dev ens160 proto static metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-a6eff42dc3c6 proto kernel scope link src 172.18.0.1 linkdown
172.22.16.0/24 dev br-c0fc7bdf8143 proto kernel scope link src 172.22.16.1
192.168.108.0/24 dev ens160 proto kernel scope link src 192.168.108.30 metric 100
[root@docker ~]#172.17.0.0/16 和 172.22.16.0/24 两个网络的路由都定义好了。再看看 ip forwarding：
bash
[root@docker ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1ip forwarding 也已经启用了。
条件都满足，为什么不能通行呢？
我们还得看看 iptables：
bash
[root@docker ~]# iptables-save
# Generated by iptables-save v1.8.5 on Thu Jul 31 17:09:34 2025
*filter
:INPUT ACCEPT [69184:9702316]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [113709:49882234]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o br-ec761bc51778 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-ec761bc51778 -j DOCKER
-A FORWARD -i br-ec761bc51778 ! -o br-ec761bc51778 -j ACCEPT
-A FORWARD -i br-ec761bc51778 -o br-ec761bc51778 -j ACCEPT
-A FORWARD -o br-89f7bc11b602 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-89f7bc11b602 -j DOCKER
-A FORWARD -i br-89f7bc11b602 ! -o br-89f7bc11b602 -j ACCEPT
-A FORWARD -i br-89f7bc11b602 -o br-89f7bc11b602 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i br-ec761bc51778 ! -o br-ec761bc51778 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-89f7bc11b602 ! -o br-89f7bc11b602 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o br-ec761bc51778 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-89f7bc11b602 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Thu Jul 31 17:09:34 2025
# Generated by iptables-save v1.8.5 on Thu Jul 31 17:09:34 2025
*security
:INPUT ACCEPT [69166:9698194]
:FORWARD ACCEPT [34:2856]
:OUTPUT ACCEPT [113709:49882234]
COMMIT
# Completed on Thu Jul 31 17:09:34 2025
# Generated by iptables-save v1.8.5 on Thu Jul 31 17:09:34 2025
*raw
:PREROUTING ACCEPT [69554:9733396]
:OUTPUT ACCEPT [113709:49882234]
COMMIT
# Completed on Thu Jul 31 17:09:34 2025
# Generated by iptables-save v1.8.5 on Thu Jul 31 17:09:34 2025
*mangle
:PREROUTING ACCEPT [69554:9733396]
:INPUT ACCEPT [69184:9702316]
:FORWARD ACCEPT [370:31080]
:OUTPUT ACCEPT [113709:49882234]
:POSTROUTING ACCEPT [113743:49885090]
COMMIT
# Completed on Thu Jul 31 17:09:34 2025
# Generated by iptables-save v1.8.5 on Thu Jul 31 17:09:34 2025
*nat
:PREROUTING ACCEPT [367:33182]
:INPUT ACCEPT [9:500]
:POSTROUTING ACCEPT [294:23341]
:OUTPUT ACCEPT [291:23089]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.22.16.0/24 ! -o br-ec761bc51778 -j MASQUERADE
-A POSTROUTING -s 172.18.0.0/16 ! -o br-89f7bc11b602 -j MASQUERADE
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A DOCKER -i br-ec761bc51778 -j RETURN
-A DOCKER -i br-89f7bc11b602 -j RETURN
-A DOCKER -i docker0 -j RETURN
COMMIT
# Completed on Thu Jul 31 17:09:34 2025原因就在这里了：iptables DROP 掉了网桥 docker0 与 br-ec761bc51778(my_net2) 之间双向的流量。
bash
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no
br-ec761bc51778（mynet2） 8000.02427fa54b88 no veth02dd704
veth5fbb7f6
docker0 8000.02420be905a5 no vethddb2744从规则的命名 DOCKER-ISOLATION 可知 docker 在设计上就是要隔离不同的 netwrok。
那么接下来的问题是：怎样才能让 busybox1与busybox2 通信呢？
答案是：为 busybox1 容器添加一块 my_net2 的网卡。这个可以通过docker network connect 命令实现。
bash
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0899976a1c59 busybox "sh" About an hour ago Up About an hour busybox3
e9da18f962d6 busybox "sh" About an hour ago Up About an hour busybox2
5225d246f751 busybox "sh" About an hour ago Up About an hour busybox1
[root@docker ~]# docker network connect my_net2 busybox1我们在 httpd 容器中查看一下网络配置：
bash
[root@docker ~]# docker exec -it busybox1 sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
32: eth1@if33: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:16:10:03 brd ff:ff:ff:ff:ff:ff
inet 172.22.16.3/24 brd 172.22.16.255 scope global eth1
valid_lft forever preferred_lft forever
[root@docker ~]# brctl show
bridge name bridge id STP enabled interfaces
br-89f7bc11b602 8000.0242194d039e no
br-ec761bc51778 8000.02427fa54b88 no veth02dd704 #busybox2
veth5fbb7f6 #busybox3
veth6642cc9 #busybox1
docker0 8000.02420be905a5 no vethddb2744容器中增加了一个网卡 eth1，分配了 my_net2 的 IP 172.22.16.3。现在 busybox2 应该能够访问busybox1 了，验证一下：
bash
[root@docker ~]# docker exec -it busybox2 sh
/ # ping -c 3 172.22.16.3
PING 172.22.16.3 (172.22.16.3): 56 data bytes
64 bytes from 172.22.16.3: seq=0 ttl=64 time=0.199 ms
64 bytes from 172.22.16.3: seq=1 ttl=64 time=0.134 ms
64 bytes from 172.22.16.3: seq=2 ttl=64 time=0.141 ms
--- 172.22.16.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.134/0.158/0.199 ms
/ #busybox 能够 ping 到 busybox2。当前网络结构如图所示：
下一节我们讨论容器间通信的三种方式。
容器通信的三种方式
容器之间可通过 IP，Docker DNS Server 或 joined 容器三种方式通信。
IP 通信
从上一节的例子可以得出这样一个结论：两个容器要能通信，必须要有属于同一个网络的网卡。
满足这个条件后，容器就可以通过 IP 交互了。具体做法是在容器创建时通过 --network 指定相应的网络，或者通过 docker network connect 将现有容器加入到指定网络。可参考上一节 busybox 的例子，这里不再赘述。
Docker DNS Server
通过 IP 访问容器虽然满足了通信的需求，但还是不够灵活。因为我们在部署应用之前可能无法确定 IP，部署之后再指定要访问的 IP 会比较麻烦。对于这个问题，可以通过 docker 自带的 DNS 服务解决。
从 Docker 1.10 版本开始，docker daemon 实现了一个内嵌的 DNS server，使容器可以直接通过"容器名"通信。方法很简单，只要在启动时用 --name 为容器命名就可以了。
下面启动两个容器 bbox1 和 bbox2：
bash
[root@docker ~]# docker run -it --network my_net2 --name bbox1 busybox
/ #
ctrl_p,ctrl_q退出容器
[root@docker ~]# docker run -it --network my_net2 --name bbox2 busybox
/ #
ctrl_p,ctrl_q退出容器然后，bbox2 就可以直接 ping 到 bbox1 了：
bash
[root@docker ~]# docker exec -it bbox2 sh
/ #
/ # ping -c 3 bbox1
PING bbox1 (172.22.16.2): 56 data bytes
64 bytes from 172.22.16.2: seq=0 ttl=64 time=0.177 ms
64 bytes from 172.22.16.2: seq=1 ttl=64 time=0.161 ms
64 bytes from 172.22.16.2: seq=2 ttl=64 time=0.187 ms
--- bbox1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.161/0.175/0.187 ms使用 docker DNS 有个限制：只能在 user-defined 网络中使用。也就是说，默认的 bridge 网络是无法使用 DNS 的。下面验证一下：
创建 bbox3 和 bbox4，均连接到 bridge 网络。
bash
[root@docker ~]# docker run -it --name bbox3 busybox
/ #
ctrl_p,ctrl_q退出容器
[root@docker ~]# docker run -it --name bbox4 busybox
/ #
ctrl_p,ctrl_q退出容器bbox4 无法 ping 到 bbox3。
bash
[root@docker ~]# docker exec -it bbox4 sh
/ # ping -c 3 bbox3
ping: bad address 'bbox3'
/ #joined 容器
joined 容器是另一种实现容器间通信的方式。
joined 容器非常特别，它可以使两个或多个容器共享一个网络栈，共享网卡和配置信息，joined 容器之间可以通过 127.0.0.1 直接通信。请看下面的例子：
先创建一个 httpd 容器，名字为 web1。
bash
[root@docker ~]# docker run -d -it --name web1 httpd
f7641c43eb7021724e869f77bd4541e909ebf0968fc35e6a43e8e674d046ef3f下面我们查看一下 web1 的网络：
bash
[root@docker ~]# docker exec -it web1 bash
root@1d5181ce7a85:/usr/local/apache2# hostname -I
172.17.0.4
# 也可以直接通过hostname -I观察IP地址然后创建 busybox 容器并通过 --network=container:web1 指定 jointed 容器为 web1：
请注意 busybox 容器中的网络配置信息
bash
[root@docker ~]# docker run -it --network container:web1 busybox
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ #看！busybox 和 web1 的网卡 mac 地址与 IP 完全一样，它们共享了相同的网络栈。busybox 可以直接用 127.0.0.1 访问 web1 的 http 服务。
bash
/ # wget 127.0.0.1
Connecting to 127.0.0.1 (127.0.0.1:80)
saving to 'index.html'
index.html 100% |***************************| 45 0:00:00 ETA
'index.html' saved
/ #
/ # cat index.html
<html><body><h1>It works!</h1></body></html>
/ #joined 容器非常适合以下场景：
- 不同容器中的程序希望通过 loopback 高效快速地通信，比如 web server 与 app server。
- 希望监控其他容器的网络流量，比如运行在独立容器中的网络监控程序。
容器之间的通信我们已经搞清楚了，接下来要考虑的是容器如何与外部世界通信？这将是下一节的主题。
容器如何访问外部世界
前面我们已经解决了容器间通信的问题，接下来讨论容器如何与外部世界通信。这里涉及两个方向：
- 容器访问外部世界
- 外部世界访问容器
容器访问外部世界
在我们当前的实验环境下，docker host 是可以访问外网的。
BASH
[root@docker ~]# ping -c 3 www.baidu.com
PING www.baidu.com (223.109.82.6) 56(84) bytes of data.
64 bytes from 223.109.82.6 (223.109.82.6): icmp_seq=1 ttl=128 time=67.8 ms
64 bytes from 223.109.82.6 (223.109.82.6): icmp_seq=2 ttl=128 time=13.0 ms
64 bytes from 223.109.82.6 (223.109.82.6): icmp_seq=3 ttl=128 time=12.5 ms
--- www.baidu.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 12.454/31.074/67.754/25.937 ms我们看一下容器是否也能访问外网呢？
bash
[root@docker ~]# docker run -it --name test1 busybox
/ #
/ # ping -c 3 www.baidu.com
PING www.baidu.com (223.109.82.6): 56 data bytes
64 bytes from 223.109.82.6: seq=0 ttl=127 time=21.240 ms
64 bytes from 223.109.82.6: seq=1 ttl=127 time=14.987 ms
64 bytes from 223.109.82.6: seq=2 ttl=127 time=14.651 ms
--- www.baidu.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 14.651/16.959/21.240 ms可见，容器默认就能访问外网。
请注意：这里外网指的是容器网络以外的网络环境，并非特指 internet。
现象很简单，但更重要的：我们应该理解现象下的本质。
在上面的例子中，busybox 位于 docker0 这个私有 bridge 网络中（172.17.0.0/16），当 busybox 从容器向外 ping 时，数据包是怎样到达 www.baidu.com 的呢？
这里的关键就是 NAT。我们查看一下 docker host 上的 iptables 规则：
bash
[root@docker ~]# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-N DOCKER
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.19.0.0/16 ! -o br-6936dc39839e -j MASQUERADE
-A POSTROUTING -s 172.22.16.0/24 ! -o br-c0fc7bdf8143 -j MASQUERADE
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i br-6936dc39839e -j RETURN
-A DOCKER -i br-c0fc7bdf8143 -j RETURN
[root@docker ~]#在 NAT 表中，有这么一条规则：
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
其含义是：如果网桥 docker0 收到来自 172.17.0.0/16 网段的外出包，把它交给 MASQUERADE 处理。而 MASQUERADE 的处理方式是将包的源地址替换成 host 的地址发送出去，即做了一次网络地址转换（NAT）。
下面我们通过 tcpdump 查看地址是如何转换的。先查看 docker host 的路由表：
bash
[root@docker ~]# ip r
default via 192.168.108.2 dev ens160 proto static metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.19.0.0/16 dev br-6936dc39839e proto kernel scope link src 172.19.0.1 linkdown
172.22.16.0/24 dev br-c0fc7bdf8143 proto kernel scope link src 172.22.16.1 linkdown
192.168.108.0/24 dev ens160 proto kernel scope link src 192.168.108.30 metric 100默认路由通过 ens160 发出去，所以我们要同时监控 ens160 和 docker0 上的 icmp（ping）数据包。
使用tcpdump观察现象
bash
[root@docker ~]# yum install -y tcpdump
[root@docker ~]# tcpdump -i docker0 -n icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on docker0, link-type EN10MB (Ethernet), capture size 262144 bytes
#再开一个窗口
[root@docker ~]# tcpdump -i ens160 -n icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes再开一个窗口， busybox ping www.baidu.com
bash
[root@docker ~]# docker run -it busybox
/ #
/ # ping -c 3 www.baidu.com
PING www.baidu.com (223.109.82.41): 56 data bytes
64 bytes from 223.109.82.41: seq=0 ttl=127 time=12.503 ms
64 bytes from 223.109.82.41: seq=1 ttl=127 time=13.380 ms
64 bytes from 223.109.82.41: seq=2 ttl=127 time=11.507 ms
--- www.baidu.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 11.507/12.463/13.380 ms
/ #tcpdump 输出如下：
查看docker0抓包窗口
bash
[root@docker ~]# tcpdump -i docker0 -n icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on docker0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:23:42.854951 IP 172.17.0.2 > 223.109.82.41: ICMP echo request, id 7, seq 0, length 64
15:23:42.870473 IP 223.109.82.41 > 172.17.0.2: ICMP echo reply, id 7, seq 0, length 64
15:23:43.857551 IP 172.17.0.2 > 223.109.82.41: ICMP echo request, id 7, seq 1, length 64
15:23:43.880065 IP 223.109.82.41 > 172.17.0.2: ICMP echo reply, id 7, seq 1, length 64
15:23:44.869116 IP 172.17.0.2 > 223.109.82.41: ICMP echo request, id 7, seq 2, length 64
15:23:44.883777 IP 223.109.82.41 > 172.17.0.2: ICMP echo reply, id 7, seq 2, length 64docker0 收到 busybox 的 ping 包，源地址为容器 IP 172.17.0.2，这没问题，交给 MASQUERADE 处理。这时，在 ens160 上我们看到了变化：
bash
[root@docker ~]# tcpdump -i ens160 -n icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
15:25:41.886472 IP 192.168.108.30 > 223.109.82.41: ICMP echo request, id 8, seq 0, length 64
15:25:41.906738 IP 223.109.82.41 > 192.168.108.30: ICMP echo reply, id 8, seq 0, length 64
15:25:42.887752 IP 192.168.108.30 > 223.109.82.41: ICMP echo request, id 8, seq 1, length 64
15:25:42.899613 IP 223.109.82.41 > 192.168.108.30: ICMP echo reply, id 8, seq 1, length 64
15:25:43.889467 IP 192.168.108.30 > 223.109.82.41: ICMP echo request, id 8, seq 2, length 64
15:25:43.904277 IP 223.109.82.41 > 192.168.108.30: ICMP echo reply, id 8, seq 2, length 64ping 包的源地址变成了 ens160 的 IP 192.168.108.130
这就是 iptable NAT 规则处理的结果，从而保证数据包能够到达外网。下面用一张图来说明这个过程：
- busybox 发送 ping 包：172.17.0.2 > www.baidu.com。
- docker0 收到包，发现是发送到外网的，交给 NAT 处理。
- NAT 将源地址换成 ens160的 IP：192.168.108.30 > www.baidu.com。
- ping 包从 ens160 发送出去，到达 www.baidu.com。
通过 NAT，docker 实现了容器对外网的访问。
下一节我们讨论另一个方向的流量：外部世界如何访问容器。
外部世界如何访问容器
上节我们学习了容器如何访问外部网络，今天讨论另一个方向：外部网络如何访问到容器？
答案是：端口映射。
docker 可将容器对外提供服务的端口映射到 host 的某个端口，外网通过该端口访问容器。容器启动时通过-p参数映射端口：
容器启动后，可通过 docker ps 或者 docker port 查看到 host 映射的端口。在上面的例子中，httpd 容器的 80 端口被映射到 host 32768 上，这样就可以通过 <host ip>:<32768> 访问容器的 web 服务了。
bash
[root@docker ~]# curl 192.168.108.30:32768
<html><body><h1>It works!</h1></body></html>除了映射动态端口，也可在 -p 中指定映射到 host 某个特定端口，例如可将 80 端口映射到 host 的 8080 端口：
bash
[root@docker ~]# docker run -d -p 8080:80 httpd
25b04cb7f6d6c012c609251a425475fcf7da03c93feb20c1d951eb45cb1ef79b
[root@docker ~]#
[root@docker ~]# curl 192.168.108.30:8080
<html><body><h1>It works!</h1></body></html>每一个映射的端口，host 都会启动一个 docker-proxy 进程来处理访问容器的流量：
以 0.0.0.0:8080->80/tcp 为例分析整个过程：
- docker-proxy 监听 host 的 8080 端口。
- 当 curl 访问 192.168.108.30:8080时，docker-proxy 转发给容器 172.17.0.3:80。
- httpd 容器响应请求并返回结果。
实战：安装tomcat
docker hub上面查找tomcat镜像
bash
[root@docker ~]# docker search tomcat
NAME DESCRIPTION STARS OFFICIAL
tomcat Apache Tomcat is an open source implementati... 3751 [OK]
bitnami/tomcat Bitnami container image for Tomcat 52
bitnamicharts/tomcat Bitnami Helm chart for Apache Tomcat 0
rootpublic/tomcat 0
chainguard/tomcat Build, ship and run secure software with Cha... 0
islandora/tomcat Base tomcat image used for java services. 0
vulhub/tomcat 0
openeuler/tomcat 0
tomcat/tomcat01 0
jelastic/tomcat An image of the Tomcat Java application serv... 4
rightctrl/tomcat CentOS , Oracle Java, tomcat application ssl... 7
amd64/tomcat Apache Tomcat is an open source implementati... 10
softwareplant/tomcat Tomcat images for jira-cloud testing 0
arm64v8/tomcat Apache Tomcat is an open source implementati... 13
appsvc/tomcat 1
s390x/tomcat Apache Tomcat is an open source implementati... 0
ppc64le/tomcat Apache Tomcat is an open source implementati... 1
arm32v7/tomcat Apache Tomcat is an open source implementati... 12
awscory/tomcat tomcat 0
devbeta/tomcat 0
tutum/tomcat Base docker image to run a Tomcat applicatio... 11
qasymphony/tomcat Tomcat images 1
hegand/tomcat docker-tomcat 0
techangels/tomcat 0
cloudesire/tomcat Tomcat server, 6/7/8 14从docker hub上拉取tomcat镜像到本地
bash
[root@docker ~]# docker pull tomcatdocker images查看是否有拉取到的tomcat
bash
[root@docker ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
httpd latest 90f191b9781e 2 weeks ago 148MB
tomcat latest 9ca267cc83c7 3 weeks ago 468MB
hello-world latest 74cc54e27dc4 6 months ago 10.1kB使用tomcat镜像创建容器实例(也叫运行镜像)
bash
[root@docker ~]# docker run -itd -p 8080:8080 tomcat
92d78922526ba2a54ef63c48d2fec80b10997027de93457a4e2d56d7ea7448e2访问tomcat首页
把webapps.dist目录换成webapps
bash
#查看刚才创建的tomcat容器ID
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
92d78922526b tomcat "catalina.sh run" 2 minutes ago Up 2 minutes 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp fervent_brahmagupta
#进入tomcat容器
[root@docker ~]# docker exec -it 92d bash
#查看webapps文件夹为空
root@92d78922526b:/usr/local/tomcat# ls webapps
root@92d78922526b:/usr/local/tomcat#
#文件在webapps.dist
root@92d78922526b:/usr/local/tomcat# ls webapps.dist/
docs examples host-manager manager ROOT
#用webapps.dist替换webapps
root@92d78922526b:/usr/local/tomcat# mv webapps.dist/* webapps再次访问tomcat
思考：我想要基于tomcat镜像做出一个能够直接访问的tomcat镜像该如何做？
存储
Docker的两类存储资源
我们从本章开始讨论 Docker 存储。
Docker 为容器提供了两种存放数据的资源：
- 由 storage driver 管理的镜像层和容器层。
- Data Volume。
我们会详细讨论它们的原理和特性。
storage driver
在前面镜像章节我们学习到 Docker 镜像的分层结构，简单回顾一下。
容器由最上面一个可写的容器层，以及若干只读的镜像层组成，容器的数据就存放在这些层中。这样的分层结构最大的特性是 Copy-on-Write：
- 新数据会直接存放在最上面的容器层。
- 修改现有数据会先从镜像层将数据复制到容器层，修改后的数据直接保存在容器层中，镜像层保持不变。
- 如果多个层中有命名相同的文件，用户只能看到最上面那层中的文件。
分层结构使镜像和容器的创建、共享以及分发变得非常高效，而这些都要归功于 Docker storage driver。正是 storage driver 实现了多层数据的堆叠并为用户提供一个单一的合并之后的统一视图。
Docker 支持多种 storage driver，有 AUFS、Device Mapper、Btrfs、OverlayFS、VFS 和 ZFS。它们都能实现分层的架构，同时又有各自的特性。对于 Docker 用户来说，具体选择使用哪个 storage driver 是一个难题，因为：
- 没有哪个 driver 能够适应所有的场景。
- driver 本身在快速发展和迭代。
不过 Docker 官方给出了一个简单的答案：
优先使用 Linux 发行版默认的 storage driver。
Docker 安装时会根据当前系统的配置选择默认的 driver。默认 driver 具有最好的稳定性，因为默认 driver 在发行版上经过了严格的测试。
运行docker info查看CentOS的默认 driver：
bash
[root@docker ~]# docker info
Client: Docker Engine - Community
Version: 26.1.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.14.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.27.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 2
Running: 0
Paused: 0
Stopped: 2
Images: 16
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: builtin
Kernel Version: 4.18.0-553.6.1.el8.x86_64
Operating System: CentOS Stream 8
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.36GiB
Name: docker
ID: fa9330b1-aebb-4889-a2d6-bc7181d443b2
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8CentOS Stream 8 用的overlay2，底层文件系统是xfs，各层数据存放在 /var/lib/docker。
对于某些容器，直接将数据放在由 storage driver 维护的层中是很好的选择，比如那些无状态的应用。无状态意味着容器没有需要持久化的数据，随时可以从镜像直接创建。
比如 busybox，它是一个工具箱，我们启动 busybox 是为了执行诸如 wget，ping 之类的命令，不需要保存数据供以后使用，使用完直接退出，容器删除时存放在容器层中的工作数据也一起被删除，这没问题，下次再启动新容器即可。
但对于另一类应用这种方式就不合适了，它们有持久化数据的需求，容器启动时需要加载已有的数据，容器销毁时希望保留产生的新数据，也就是说，这类容器是有状态的。
这就要用到 Docker 的另一种存储机制：Data Volume，下一节我们讨论。
Data Volume之bind mount
storage driver 和 data volume 是容器存放数据的两种方式，上一节我们学习了 storage driver，本节开始讨论 Data Volume。
Data Volume 本质上是 Docker Host 文件系统中的目录或文件，能够直接被 mount 到容器的文件系统中。Data Volume 有以下特点：
- Data Volume 是目录或文件，而非没有格式化的磁盘（块设备）。
- 容器可以读写 volume 中的数据。
- volume 数据可以被永久的保存，即使使用它的容器已经销毁。
好，现在我们有数据层（镜像层和容器层）和 volume 都可以用来存放数据，具体使用的时候要怎样选择呢？考虑下面几个场景：
- Database 软件 vs Database 数据
- Web 应用 vs 应用产生的日志
- 数据分析软件 vs input/output 数据
- Apache Server vs 静态 HTML 文件
相信大家会做出这样的选择：
- 前者放在数据层中。因为这部分内容是无状态的，应该作为镜像的一部分。
- 后者放在 Data Volume 中。这是需要持久化的数据，并且应该与镜像分开存放。
还有个大家可能会关心的问题：如何设置 voluem 的容量？
因为 volume 实际上是 docker host 文件系统的一部分，所以 volume 的容量取决于文件系统当前未使用的空间，目前还没有方法设置 volume 的容量。
在具体的使用上，docker 提供了两种类型的 volume：bind mount 和 docker managed volume。
bind mount
bind mount 是将 host 上已存在的目录或文件 mount 到容器。
例如 docker host 上有目录 $HOME/htdocs：
bash
[root@docker ~]# pwd
/root
[root@docker ~]# mkdir htdocs
[root@docker ~]# cd htdocs/
[root@docker htdocs]# touch index.html
[root@docker htdocs]# vim index.html
<html><body><h1>This is a file in host file system !</h1></body></html>
[root@docker htdocs]# cd ..
[root@docker ~]# cat htdocs/index.html
<html><body><h1>This is a file in host file system !</h1></body></html>
[root@docker ~]#通过 -v 将其 mount 到 httpd 容器：
bash
[root@docker ~]# docker run -d -p 80:80 -v ~/htdocs:/usr/local/apache2/htdocs httpd
883f8a22b2be796928d16ad131f6cba922492e325fdadf4275ca9f59eae5ed12-v 的格式为 <host path>:<container path>。/usr/local/apache2/htdocs 就是 apache server 存放静态文件的地方。由于 /usr/local/apache2/htdocs 已经存在，原有数据会被隐藏起来，取而代之的是 host $HOME/htdocs/ 中的数据，这与 linux mount 命令的行为是一致的。
bash
[root@docker ~]# curl 127.0.0.1:80
<html><body><h1>This is a file in host file system !</h1></body></html>curl 显示当前主页确实是 $HOME/htdocs/index.html 中的内容。更新一下，看是否能生效：
bash
[root@docker ~]# echo "updated index page!" > ~/htdocs/index.html
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
updated index page!host 中的修改确实生效了，bind mount 可以让 host 与容器共享数据。这在管理上是非常方便的。
下面我们将容器销毁，看看对 bind mount 有什么影响：
bash
[root@docker ~]# docker stop 883f8a22b2be
883f8a22b2be
[root@docker ~]# docker rm 883f8a22b2be
883f8a22b2be
[root@docker ~]# cat ~/htdocs/index.html
updated index page!
[root@docker ~]#可见，即使容器没有了，bind mount 也还在。这也合理，bind mount 是 host 文件系统中的数据，只是借给容器用用，哪能随便就删了啊。
另外，bind mount 时还可以指定数据的读写权限，默认是可读可写，可指定为只读：
bash
[root@docker ~]# docker run -d -p 80:80 -v ~/htdocs:/usr/local/apache2/htdocs:ro httpd
bf1f526ddde7a7babb29adc091eef039628ba2eb288e6db33c9ccd946cc5d5f1
[root@docker ~]# docker exec -it bf1f526ddde7 bash
root@bf1f526ddde7:/usr/local/apache2# echo "do some changes" > htdocs/index.html
bash: htdocs/index.html: Read-only file systemro 设置了只读权限，在容器中是无法对 bind mount 数据进行修改的。只有 host 有权修改数据，提高了安全性。
除了 bind mount 目录，还可以单独指定一个文件：
bash
# 删除上一个容器不然80端口冲突
[root@docker ~]# docker rm - f bf1f526ddde7
#运行新容器用单独文件绑定
[root@docker ~]# docker run -d -p 80:80 -v ~/htdocs/index.html:/usr/local/apache2/htdocs/new_index.html httpd
643e8820e98a17b977a984903ddfa6f37dcae3d705d45b624d0fce5c94fecb0c
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
<html><body><h1>It works!</h1></body></html>
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80/new_index.html
updated index page!
[root@docker ~]#使用 bind mount 单个文件的场景是：只需要向容器添加文件，不希望覆盖整个目录。在上面的例子中，我们将 html 文件加到 apache 中，同时也保留了容器原有的数据。
使用单一文件有一点要注意：host 中的源文件必须要存在，不然会当作一个新目录 bind mount 给容器。
mount point 有很多应用场景，比如我们可以将源代码目录 mount 到容器中，在 host 中修改代码就能看到应用的实时效果。再比如将 mysql 容器的数据放在 bind mount 里，这样 host 可以方便地备份和迁移数据。
bind mount 的使用直观高效，易于理解，但它也有不足的地方：bind mount 需要指定 host 文件系统的特定路径，这就限制了容器的可移植性，当需要将容器迁移到其他 host，而该 host 没有要 mount 的数据或者数据不在相同的路径时，操作会失败。
移植性更好的方式是 docker managed volume，下一节我们讨论。
Data Volume之docker managed volume
docker managed volume 与 bind mount 在使用上的最大区别是不需要指定 mount 源，指明 mount point 就行了。还是以 httpd 容器为例：
bash
[root@docker ~]# docker run -d -p 80:80 -v /usr/local/apache2/htdocs httpd
c75f36c4bf32e39f2d078d41956be85522c0630cf91498123dcd83ba159ce873我们通过 -v 告诉 docker 需要一个 data volume，并将其 mount 到 /usr/local/apache2/htdocs。那么这个 data volume 具体在哪儿呢？
这个答案可以在容器的配置信息中找到，执行 docker inspect 命令：
bash
[root@docker ~]# docker inspect c75f36c4bf32 #docker inspect后面跟的是容器ID
...
"Mounts": [
{
"Type": "volume",
"Name": "1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16",
"Source": "/var/lib/docker/volumes/1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16/_data",
"Destination": "/usr/local/apache2/htdocs",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
... docker inspect 的输出很多，我们感兴趣的是 Mounts 这部分，这里会显示容器当前使用的所有 data volume，包括 bind mount 和 docker managed volume。
Source 就是该 volume 在 host 上的目录。
原来，每当容器申请 mount docker manged volume 时，docker 都会在/var/lib/docker/volumes 下生成一个目录（例子中是 "/var/lib/docker/volumes/1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16/_data ），这个目录就是 mount 源。
下面继续研究这个 volume，看看里面有些什么东西：
bash
[root@docker ~]# ls -l /var/lib/docker/volumes/1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16/_data
total 4
-rw-r--r-- 1 501 ftp 26 Sep 17 21:08 index.html
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
<html><body><h1>It works!</h1></body></html>volume 的内容跟容器原有 /usr/local/apache2/htdocs 完全一样，这是怎么回事呢？
这是因为：如果 mount point 指向的是已有目录，原有数据会被复制到 volume 中。
但要明确一点：此时的 /usr/local/apache2/htdocs 已经不再是由 storage driver 管理的层数据了，它已经是一个 data volume。我们可以像 bind mount 一样对数据进行操作，例如更新数据：
bash
[root@docker ~]# echo "update volume from host !" > /var/lib/docker/volumes/1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16/_data/index.html
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
update volume from host !简单回顾一下 docker managed volume 的创建过程：
- 容器启动时，简单的告诉 docker "我需要一个 volume 存放数据，帮我 mount 到目录 /abc"。
- docker 在 /var/lib/docker/volumes 中生成一个随机目录作为 mount 源。
- 如果 /abc 已经存在，则将数据复制到 mount 源，
- 将 volume mount 到 /abc
除了通过 docker inspect 查看 volume，我们也可以用 docker volume 命令：
bash
[root@docker ~]# docker volume ls
DRIVER VOLUME NAME
local 1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16
[root@docker ~]#
[root@docker ~]# docker volume inspect 1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16
[
{
"CreatedAt": "2024-09-17T21:04:33+08:00",
"Driver": "local",
"Labels": {
"com.docker.volume.anonymous": ""
},
"Mountpoint": "/var/lib/docker/volumes/1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16/_da
"Name": "1cc915096121dea197bbbb93fc90e6491d530e0c9e2ace1de07e2a635e569d16",
"Options": null,
"Scope": "local"
}
]
[root@docker ~]# 目前，docker volume 只能查看 docker managed volume，还看不到 bind mount；同时也无法知道 volume 对应的容器，这些信息还得靠docker inspect。
我们已经学习了两种 data volume 的原理和基本使用方法，下面做个对比：
- 相同点：两者都是 host 文件系统中的某个路径。
- 不同点：
| bind mount | docker managed volume | |
|---|---|---|
| volume 位置 | 可任意指定 | /var/lib/docker/volumes/... |
| 对已有mount point 影响 | 隐藏并替换为 volume | 原有数据复制到 volume |
| 是否支持单个文件 | 支持 | 不支持，只能是目录 |
| 权限控制 | 可设置为只读，默认为读写权限 | 无控制，均为读写权限 |
| 移植性 | 移植性弱，与 host path 绑定 | 移植性强，无需指定 host 目录 |
下节讨论如何通过 data volume 实现容器与 host，容器与容器共享数据。
如何共享数据
数据共享是 volume 的关键特性，本节我们详细讨论通过 volume 如何在容器与 host 之间，容器与容器之间共享数据。
容器与 host 共享数据
我们有两种类型的 data volume，它们均可实现在容器与 host 之间共享数据，但方式有所区别。
对于 bind mount 是非常明确的：直接将要共享的目录 mount 到容器。具体请参考前面 httpd 的例子，不再赘述。
docker managed volume 就要麻烦点。由于 volume 位于 host 中的目录，是在容器启动时才生成，所以需要将共享数据拷贝到 volume 中。请看下面的例子：
bash
[root@docker ~]# docker run -d -p 80:80 -v /usr/local/apache2/htdocs httpd
889b9d5309bd12499f8e4ee78a491d9ba7acef5660be00f30cda6569c9974c6f
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
<html><body><h1>It works!</h1></body></html>
[root@docker ~]#
[root@docker ~]# docker cp ~/htdocs/index.html 889b9d5309bd:/usr/local/apache2/htdocs #将host os的/root/htdocs/index.html拷贝到容器中的/usr/local/apache2/htdocs目录下
Successfully copied 2.05kB to 889b9d5309bd:/usr/local/apache2/htdocs
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
updated index page!
[root@docker ~]#docker cp 可以在容器和 host 之间拷贝数据，当然我们也可以直接通过 Linux 的 cp 命令复制到 /var/lib/docker/volumes/xxx。
思考：容器中的文件拷贝到host os如何操作
容器之间共享数据
第一种方法是将共享数据放在 bind mount 中，然后将其 mount 到多个容器。还是以 httpd 为例，不过这次的场景复杂些，我们要创建由三个 httpd 容器组成的 web server 集群，它们使用相同的 html 文件，操作如下：
-
将 $HOME/htdocs mount 到三个 httpd 容器。
bash[root@docker ~]# docker run --name web1 -d -p 80 -v ~/htdocs:/usr/local/apache2/htdocs httpd 994e75ef90a80365d7ea7733c727c3b1d24e5423d59a74185304462b7137d774 [root@docker ~]# [root@docker ~]# docker run --name web2 -d -p 80 -v ~/htdocs:/usr/local/apache2/htdocs httpd 28ff7c72d18b30123ff7e383db211890a0007e48817cdc73e7f50e9f2233eee6 [root@docker ~]# [root@docker ~]# docker run --name web3 -d -p 80 -v ~/htdocs:/usr/local/apache2/htdocs httpd 160d823d985bad0ce7c27a0d301956f3c7ab4e9ca34c5be2601b3374fa30f6f1 [root@docker ~]# -
查看当前主页内容。
bash[root@docker ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 160d823d985b httpd "httpd-foreground" 13 seconds ago Up 12 seconds 0.0.0.0:32770->80/tcp, :::32770->80/tcp web3 28ff7c72d18b httpd "httpd-foreground" 19 seconds ago Up 18 seconds 0.0.0.0:32769->80/tcp, :::32769->80/tcp web2 994e75ef90a8 httpd "httpd-foreground" 29 seconds ago Up 27 seconds 0.0.0.0:32768->80/tcp, :::32768->80/tcp web1 [root@docker ~]# [root@docker ~]# curl 127.0.0.1:32770 #这个32770端口是host os映射到web3的duan'kou updated index page! [root@docker ~]# curl 127.0.0.1:32769 updated index page! [root@docker ~]# curl 127.0.0.1:32768 updated index page! [root@docker ~]# -
修改 volume 中的主页文件，再次查看并确认所有容器都使用了新的主页。
bash[root@docker ~]# echo "This is a new index page for web cluster" > ~/htdocs/index.html [root@docker ~]# [root@docker ~]# curl 127.0.0.1:32770 This is a new index page for web cluster [root@docker ~]# curl 127.0.0.1:32769 This is a new index page for web cluster [root@docker ~]# curl 127.0.0.1:32768 This is a new index page for web cluster [root@docker ~]#
另一种在容器之间共享数据的方式是使用 volume container，下节讨论。
用volume container共享数据
volume container 是专门为其他容器提供 volume 的容器。它提供的卷可以是 bind mount，也可以是 docker managed volume。下面我们创建一个 volume container：
bash
[root@docker ~]# docker create --name vc_data \
-v ~/htdocs/:/usr/local/apache2/htdocs \
-v /other/userful/tools \
busybox
bb4a33bf34aa7817ea752db83079aff15a5dfd77c23363f2e8dd3096d1cb910f我们将容器命名为 vc_data（vc 是 volume container 的缩写）。注意这里执行的是 docker create 命令，这是因为 volume container 的作用只是提供数据，它本身不需要处于运行状态。容器 mount 了两个 volume：
- bind mount，存放 web server 的静态文件。
- docker managed volume，存放一些实用工具（当然现在是空的，这里只是做个示例）。
通过 docker inspect 可以查看到这两个 volume。
bash
[root@docker ~]# docker inspect vc_data
...
"Mounts": [
{
"Type": "volume",
"Name": "4500300655eb8e32a5d88174395a61ea394e17266fbde60f224d815a7a9557e0",
"Source": "/var/lib/docker/volumes/4500300655eb8e32a5d88174395a61ea394e17266fbde60f224d815a7a9557e0/_data",
"Destination": "/other/userful/tools",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
},
{
"Type": "bind",
"Source": "/root/htdocs",
"Destination": "/usr/local/apache2/htdocs",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
...其他容器可以通过 --volumes-from 使用 vc_data 这个 volume container：
bash
[root@docker ~]# docker run --name web1 -d -p 80 --volumes-from vc_data httpd
362f039b562e4bf0020c38839a69bfd62733f27fda5481eb5b58178f41318ffe
[root@docker ~]#
[root@docker ~]# docker run --name web2 -d -p 80 --volumes-from vc_data httpd
217c1a243bb9a1f32ccae9ae2792e3720263d36402bbac58f43cfb068bc21e66
[root@docker ~]#
[root@docker ~]# docker run --name web3 -d -p 80 --volumes-from vc_data httpd
ce00b5fa458fc1af01e82ce8b43e8c072c858a669c1298add8053cbc7ac9f49b
[root@docker ~]#三个 httpd 容器都使用了 vc_data，看看它们现在都有哪些 volume，以 web1 为例：
bash
[root@docker ~]# docker inspect web1
...
"Mounts": [
{
"Type": "bind",
"Source": "/root/htdocs",
"Destination": "/usr/local/apache2/htdocs",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "volume",
"Name": "4500300655eb8e32a5d88174395a61ea394e17266fbde60f224d815a7a9557e0",
"Source": "/var/lib/docker/volumes/4500300655eb8e32a5d88174395a61ea394e17266fbde60f224d815a7a9557e0/_data",
"Destination": "/other/userful/tools",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
...web1 容器使用的就是 vc_data 的 volume，而且连 mount point 都是一样的。验证一下数据共享的效果：
bash
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ce00b5fa458f httpd "httpd-foreground" 2 minutes ago Up 2 minutes 0.0.0.0:32773->80/tcp, :::32773->80/tcp web3
217c1a243bb9 httpd "httpd-foreground" 2 minutes ago Up 2 minutes 0.0.0.0:32772->80/tcp, :::32772->80/tcp web2
362f039b562e httpd "httpd-foreground" 2 minutes ago Up 2 minutes 0.0.0.0:32771->80/tcp, :::32771->80/tcp web1
[root@docker ~]#
[root@docker ~]# echo "This content is from a volume container!" > ~/htdocs/index.html
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:32773
This content is from a volume container!
[root@docker ~]# curl 127.0.0.1:32772
This content is from a volume container!
[root@docker ~]# curl 127.0.0.1:32771
This content is from a volume container!可见，三个容器已经成功共享了 volume container 中的 volume。
下面我们讨论一下 volume container 的特点：
- 与 bind mount 相比，不必为每一个容器指定 host path，所有 path 都在 volume container 中定义好了，容器只需与 volume container 关联，实现了容器与 host 的解耦。
- 使用 volume container 的容器其 mount point 是一致的，有利于配置的规范和标准化，但也带来一定的局限，使用时需要综合考虑。
另一种在容器之间共享数据的方式是 data-packed volume container，下一节讨论。
data-packed volume container
在上一节的例子中 volume container 的数据归根到底还是在 host 里，有没有办法将数据完全放到 volume container 中，同时又能与其他容器共享呢？
当然可以，通常我们称这种容器为 data-packed volume container。其原理是将数据打包到镜像中，然后通过 docker managed volume 共享。
我们用下面的 Dockfile 构建镜像：
dockerfile
[root@docker ~]# vim Dockerfile
FROM busybox:latest
ADD htdocs /usr/local/apache2/htdocs
VOLUME /usr/local/apache2/htdocsADD 将静态文件添加到容器目录 /usr/local/apache2/htdocs。
VOLUME 的作用与 -v 等效，用来创建 docker managed volume，mount point 为 /usr/local/apache2/htdocs，因为这个目录就是 ADD 添加的目录，所以会将已有数据拷贝到 volume 中。
修改文本内容
bash
[root@docker ~]# echo "This content is from a data packed volume container!" > htdocs/index.htmlbuild 新镜像 datapacked：
bash
[root@docker ~]# docker build -t datapacked .
用新镜像创建 data-packed volume container：
bash
[root@docker ~]# docker create --name vc_data datapacked
55dc035deeb31907830ea45f7af5e209c7e48078d59732798c529e7445d2a196因为在 Dockerfile 中已经使用了 VOLUME 指令，这里就不需要指定 volume 的 mount point 了。启动 httpd 容器并使用 data-packed volume container：
bash
[root@docker ~]# docker run -d -p 80:80 --volumes-from vc_data httpd
98db78fc661441ec7ce0a2b76d62675fccf3389b7768cc9744b852645323c33b
[root@docker ~]#
[root@docker ~]# curl 127.0.0.1:80
This content is from a data packed volume container!容器能够正确读取 volume 中的数据。data-packed volume container 是自包含的，不依赖 host 提供数据，具有很强的移植性，非常适合 只使用 静态数据的场景，比如应用的配置信息、web server 的静态文件等。
容器数据共享就讨论到这里，下一节我们学习如何对 data volume 的生命周期进行管理。
volume生命周期管理
Data Volume 中存放的是重要的应用数据，如何管理 volume 对应用至关重要。前面我们主要关注的是 volume 的创建、共享和使用，本节将讨论如何备份、恢复、迁移和销毁 volume。
备份
因为 volume 实际上是 host 文件系统中的目录和文件，所以 volume 的备份实际上是对文件系统的备份。
还记得前面我们是如何搭建本地 Registry 的吗？
bash
[root@docker ~]# docker run -d -p 5000:5000 -v /myregistry:/var/lib/registry registry:2
Unable to find image 'registry:2' locally
2: Pulling from library/registry
1cc3d825d8b2: Pull complete
85ab09421e5a: Pull complete
40960af72c1c: Pull complete
e7bb1dbb377e: Pull complete
a538cc9b1ae3: Pull complete
Digest: sha256:ac0192b549007e22998eb74e8d8488dcfe70f1489520c3b144a6047ac5efbe90
Status: Downloaded newer image for registry:2
a8214201171f28a13803c647ef84acdc982465c230cb5c6a034bd05574948408
[root@docker ~]#所有的本地镜像都存在 host 的 /myregistry 目录中，我们要做的就是定期备份这个目录。
恢复
volume 的恢复也很简单，如果数据损坏了，直接用之前备份的数据拷贝到 /myregistry 就可以了。
迁移
如果我们想使用更新版本的 Registry，这就涉及到数据迁移，方法是：
-
docker stop当前 Registry 容器。 -
启动新版本容器并 mount 原有 volume。
docker run -d -p 5000:5000 -v /myregistry:/var/lib/registry registry:latest
当然，在启用新容器前要确保新版本的默认数据路径是否发生变化。
销毁
可以删除不再需要的 volume，但一定要确保知道自己正在做什么，volume 删除后数据是找不回来的。
docker 不会销毁 bind mount，删除数据的工作只能由 host 负责。对于 docker managed volume，在执行 docker rm 删除容器时可以带上 -v 参数，docker 会将容器使用到的 volume 一并删除，但前提是没有其他容器 mount 该 volume，目的是保护数据，非常合理。
如果删除容器时没有带 -v 呢？这样就会产生孤儿 volume，好在 docker 提供了 volume 子命令可以对 docker managed volume 进行维护。请看下面的例子：
bash
[root@docker ~]# docker volume ls
DRIVER VOLUME NAME
[root@docker ~]#
[root@docker ~]# docker run --name bbox -v /test/data busybox
[root@docker ~]#
[root@docker ~]# docker volume ls
DRIVER VOLUME NAME
local 8645b8e2edb91820799e6e8807d8b3476f1c5cec40beb14240b0e5143050e5e1容器 bbox 使用的 docker managed volume 可以通过 docker volume ls 查看到。
删除 bbox：
bash
[root@docker ~]# docker rm bbox
bbox
[root@docker ~]# docker volume ls
DRIVER VOLUME NAME
local 8645b8e2edb91820799e6e8807d8b3476f1c5cec40beb14240b0e5143050e5e1
[root@docker ~]#因为没有使用 -v，volume 遗留了下来。对于这样的孤儿 volume，可以用 docker volume rm 删除：
bash
[root@docker ~]# docker volume rm 8645b8e2edb91820799e6e8807d8b3476f1c5cec40beb14240b0e5143050e5e1
8645b8e2edb91820799e6e8807d8b3476f1c5cec40beb14240b0e5143050e5e1
[root@docker ~]#
[root@docker ~]# docker volume ls
DRIVER VOLUME NAME
[root@docker ~]#如果想批量删除孤儿 volume，可以执行：
docker volume rm $(docker volume ls -q)
docker volume prune
小结
本章我们学习了以下内容：
- docker 为容器提供了两种存储资源：数据层和 Data Volume。
- 数据层包括镜像层和容器层，由 storage driver 管理。
- Data Volume 有两种类型：bind mount 和 docker managed volume。
- bind mount 可实现容器与 host 之间，容器与容器之间共享数据。
- volume container 是一种具有更好移植性的容器间数据共享方案，特别是 data-packed volume container。
- 最后我们学习了如何备份、恢复、迁移和销毁 Data Volume。
容器监控
Docker自带的监控子命令
当Docker部署规模逐步变大后，可视化监控容器环境的性能和健康状态将会变得越来越重要。
ps
docker ps 是我们早已熟悉的命令了，方便我们查看当前运行的容器。前面已经有大量示例，这里就不赘述了。
bash
[root@docker ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9f8bc2c3a5c7 nginx "/docker-entrypoint...." 3 seconds ago Up 2 seconds 80/tcp sad_faraday
1e0b0631cf70 httpd:centos "/bin/sh -c '/usr/sb..." 23 minutes ago Up 23 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp myweb
4b78f371fc06 centos:ssh "/usr/sbin/sshd -D" 32 minutes ago Up 32 minutes 0.0.0.0:2022->22/tcp, :::2022->22/tcp sshtesttop
查看容器的进程
bash
[root@docker ~]# docker top --help
Usage: docker top CONTAINER [ps OPTIONS]
Display the running processes of a container
Aliases:
docker container top, docker top示例：
bash
[root@docker ~]# docker top sshtest #sshtest是容器名，挑一
UID PID PPID C STIME TTY TIME CMD
root 5220 5198 0 21:31 ? 00:00:00 /usr/sbin/sshd -D命令后面还可以跟上 Linux 操作系统 ps 命令的参数显示特定的信息，比如 -au。
bash
[root@docker ~]# docker top sshtest -au
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 5220 0.0 0.0 76532 7080 ? Ss 21:31 0:00 /usr/sbin/sshd -Dstats
列出容器资源使用率
bash
[root@docker ~]# docker stats --help
Usage: docker stats [OPTIONS] [CONTAINER...]
Display a live stream of container(s) resource usage statistics
Aliases:
docker container stats, docker stats
Options:
-a, --all Show all containers (default shows just running)
--format string Format output using a custom template:
'table': Print output in table format with column headers (default)
'table TEMPLATE': Print output in table format using the given Go template
'json': Print in JSON format
'TEMPLATE': Print output using the given Go template.
Refer to https://docs.docker.com/go/formatting/ for more information about formatting output with templates
--no-stream Disable streaming stats and only pull the first result
--no-trunc Do not truncate output示例：
bash
[root@docker ~]# docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
9f8bc2c3a5c7 sad_faraday 0.00% 5.141MiB / 15.36GiB 0.03% 866B / 0B 8.19kB / 26.6kB 5
1e0b0631cf70 myweb 0.06% 38.39MiB / 15.36GiB 0.24% 1.64kB / 609B 0B / 0B 213
4b78f371fc06 sshtest 0.00% 2.258MiB / 15.36GiB 0.01% 9.7kB / 7.99kB 8.19kB / 23.6kB 1默认会显示一个实时变化的列表，展示每个容器的 CPU 使用率，内存使用量和可用量，网络和磁盘的 IO 数据。
注意：容器启动时如果没有特别指定内存 limit，stats 命令会显示 host 的内存总量，但这并不意味着每个 container 都能使用到这么多的内存。
cAdvisor
cAdvisor 是 google 开发的容器监控工具。
bash
[root@docker ~]# docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--publish=8080:8080 \
--detach=true \
--name=cadvisor \
google/cadvisor:latest也可以使用镜像hub.c.163.com/xbingo/cadvisor:latest。
通过 http://Host_IP:8080 访问 cAdvisor。首次打开比较慢，系统需要收集数据并绘制图表。
点击Docker Containers进去看容器具体信息
总结：
- 缺点：操作界面略显简陋，而且需要在不同页面之间跳转，并且只能监控一个 host。
- 优点：可以将监控到的数据导出给第三方工具，由这些工具进一步加工处理。
结论：我们把 cAdvisor 定位为一个监控数据收集器，并导出数据给第三方工具，而非展示数据。
容器日志
高效的监控和日志管理对保持生产系统持续稳定地运行以及排查问题至关重要。
在微服务架构中，由于容器的数量众多以及快速变化的特性使得记录日志和监控变得越来越重要。考虑到容器短暂和不固定的生命周期，当我们需要 debug 问题时有些容器可能已经不存在了。因此，一套集中式的日志管理系统是生产环境中不可或缺的组成部分。
Docker logs
对于一个运行的容器，Docker 会将日志发送到 容器标准输出设备（STDOUT）和标准错误设备（STDERR），STDOUT 和 STDERR 实际上就是容器的控制台终端。
举个例子，用下面的命令运行 httpd 容器：
bash
[root@docker ~]# docker run -p 80:80 httpd
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue Oct 08 14:28:10.312876 2024] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.62 (Unix) configured -- resuming normal operations
[Tue Oct 08 14:28:10.316058 2024] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'我们在启动日志的时候没有用 -d 参数，httpd 容器以前台方式启动，日志会直接打印在当前的终端窗口。
如果加上 -d 参数以后台方式运行容器，我们就看不到输出的日志了。
bash
[root@docker ~]# docker run -d -p 80:80 httpd
a8286845e6f8afc09fdcdf0b94248239963e3ad04495e927a68a2148814c65fd这种情况下如果要查看容器的日志，有两种方法：
- attach 到该容器。
- 用
docker logs命令查看日志。
先来看 attach 的方法。运行 docker attach 命令。
bash
[root@docker ~]# docker attach a8286845e6f8attach 到了 httpd 容器，但并没有任何输出，这是因为当前没有新的日志信息。
为了产生一条新的日志，可以在 host 的另一个命令行终端执行 curl localhost。
终端B：
bash
[root@docker ~]# curl localhost
<html><body><h1>It works!</h1></body></html>
[root@docker ~]# curl localhost
<html><body><h1>It works!</h1></body></html>这时，attach 的终端就会打印出新的日志。
终端A:
bash
[root@docker ~]# docker attach a8286845e6f8
172.17.0.1 - - [08/Oct/2024:14:30:24 +0000] "GET / HTTP/1.1" 200 45
172.17.0.1 - - [08/Oct/2024:14:30:25 +0000] "GET / HTTP/1.1" 200 45attach 的方法在实际使用中不太方便，因为：
- 只能看到 attach 之后的日志，以前的日志不可见。
- 退出 attach 状态比较麻烦（Ctrl+p 然后 Ctrl+q 组合键），一不小心很容器将容器杀掉（比如按下 Ctrl+C）。
查看容器日志推荐的方法是用 docker logs 命令。
bash
[root@docker ~]# docker logs a8286845e6f8
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue Oct 08 14:28:33.168712 2024] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.62 (Unix) configured -- resuming normal operations
[Tue Oct 08 14:28:33.168801 2024] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'
[Tue Oct 08 14:29:37.160729 2024] [mpm_event:notice] [pid 1:tid 1] AH00491: caught SIGTERM, shutting down
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue Oct 08 14:30:08.379226 2024] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.62 (Unix) configured -- resuming normal operations
[Tue Oct 08 14:30:08.379375 2024] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'
172.17.0.1 - - [08/Oct/2024:14:30:24 +0000] "GET / HTTP/1.1" 200 45
172.17.0.1 - - [08/Oct/2024:14:30:25 +0000] "GET / HTTP/1.1" 200 45
[Tue Oct 08 14:31:35.664386 2024] [mpm_event:notice] [pid 1:tid 1] AH00491: caught SIGTERM, shutting down
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue Oct 08 14:31:41.995159 2024] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.62 (Unix) configured -- resuming normal operations
[Tue Oct 08 14:31:41.995339 2024] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'
172.17.0.1 - - [08/Oct/2024:14:30:24 +0000] "GET / HTTP/1.1" 200 45
172.17.0.1 - - [08/Oct/2024:14:30:25 +0000] "GET / HTTP/1.1" 200 45docker logs 能够打印出自容器启动以来完整的日志，并且 -f 参数可以继续打印出新产生的日志，效果上与 Linux 命令 tail -f 一样。
Docker-compose
我们知道使用一个 Dockerfile 模板文件，可以让用户很方便的定义一个单独的应用容器。然而，在日常工作中，经常会碰到需要多个容器相互配合来完成某项任务的情况。例如要实现一个 Web 项目，除了 Web 服务容器本身，往往还需要再加上后端的数据库服务容器，甚至还包括负载均衡容器等。如果每个容器都要按顺序手动启停，那么维护工作量将会很大，而且工作效率也很低。
Docker Compose 可以轻松、高效地管理容器，它是一个用于定义和运行多容器的管理工具。
它通过一个单独的 docker-compose.yml 模板文件（YAML 格式）定义一组相关联资源集。
Compose 中有两个重要的概念：
- 服务 (
service)：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。 - 项目 (
project)：由一组关联的应用容器组成的一个完整业务单元，在docker-compose.yml文件中定义。
Compose 的默认管理对象是项目，通过子命令对项目中的一组容器进行便捷地生命周期管理。
Compose 项目由 Python 编写(后用Go语言重写)，实现上调用了 Docker 服务提供的 API 来对容器进行管理。因此，只要所操作的平台支持 Docker API，就可以在其上利用 Compose 来进行编排管理。
命令说明
bash
[root@docker ~]# docker compose -h
Flag shorthand -h has been deprecated, please use --help
Usage: docker compose [OPTIONS] COMMAND
Define and run multi-container applications with Docker
Options:
--all-resources Include all resources, even those not used by services
--ansi string Control when to print ANSI control characters ("never"|"always"|"auto") (default "auto")
--compatibility Run compose in backward compatibility mode
--dry-run Execute command in dry run mode
--env-file stringArray Specify an alternate environment file
-f, --file stringArray Compose configuration files
--parallel int Control max parallelism, -1 for unlimited (default -1)
--profile stringArray Specify a profile to enable
--progress string Set type of progress output (auto, tty, plain, quiet) (default "auto")
--project-directory string Specify an alternate working directory
(default: the path of the, first specified, Compose file)
-p, --project-name string Project name
Commands:
attach Attach local standard input, output, and error streams to a service's running container
build Build or rebuild services
config Parse, resolve and render compose file in canonical format
cp Copy files/folders between a service container and the local filesystem
create Creates containers for a service
down Stop and remove containers, networks
events Receive real time events from containers
exec Execute a command in a running container
images List images used by the created containers
kill Force stop service containers
logs View output from containers
ls List running compose projects
pause Pause services
port Print the public port for a port binding
ps List containers
pull Pull service images
push Push service images
restart Restart service containers
rm Removes stopped service containers
run Run a one-off command on a service
scale Scale services
start Start services
stats Display a live stream of container(s) resource usage statistics
stop Stop services
top Display the running processes
unpause Unpause services
up Create and start containers
version Show the Docker Compose version information
wait Block until the first service container stops
watch Watch build context for service and rebuild/refresh containers when files are updated
Run 'docker compose COMMAND --help' for more information on a command.version
bash
[root@docker ~]# docker compose version
Docker Compose version v2.27.0Compose 模板
模板文件是使用 Compose 的核心，涉及到的指令关键字也比较多。但大家不用担心，这里面大部分指令跟 docker run 相关参数的含义都是类似的。
默认的模板文件名称为 docker-compose.yml，格式为 YAML 格式。
模板文件结构
- version：用来定义模板文件的版本，不同版本的模板，格式也不一样。
- 资源列表：用来定义资源清单，包括service、secret、network、volume等。
- 注释行：
#开头的注释行。
示例：使用版本2模板，定义一个使用httpd镜像的services。
version: "2"
services:
webapp:
image: httpd详细结构参考官方
Compose文档
- User guide
- Installing Compose
- Compose file versions and upgrading
- Sample apps with Compose
- Command line reference
实战-Wordpress
回顾一下如果用docker run改如何操作：
bash
[root@docker ~]# docker run -tid --name db --restart always -v /db:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=huawei -e MYSQL_DATABASE=wordpress mysql
d3fa1d9e6ecc285427b38bca95130cade90ca69ee9487825db92b3bc8af4c995
[root@docker ~]# docker run -tid --name blog -v /web:/var/www/html -p 80:80 --link db -e WORDPRESS_DB_HOST=db -e WORDPRESS_DB_USER=root -e WORDPRESS_DB_PASSWORD=huawei -e WORDPRESS_DB_NAME=wordpress wordpress
b5b80bd69f57bff576415f2e449a23fe6cb37be353f9b4b69d24d60a2fb9a6e1
[root@docker ~]#
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b5b80bd69f57 wordpress "docker-entrypoint.s..." 13 seconds ago Up 12 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp blog
d3fa1d9e6ecc mysql "docker-entrypoint.s..." 26 seconds ago Up 25 seconds 3306/tcp, 33060/tcp db
MYSQL_DATABASE=wordpress测试效果：
通过docker compose来统一管理这两个容器呢？
假设新建一个名为 wordpress 的文件夹，然后进入这个文件夹，创建 docker-compose.yml 文件
bash
# 删除之前的环境
[root@docker ~]# docker rm -f $(docker ps -aq)
# 通过docker compose实现多个容器一起启动
[root@docker ~]# mkdir wordpress
[root@docker ~]# cd wordpress/
[root@docker wordpress]# vim docker-compose.yml
services:
blog: #服务名字，相当于docker run的时候指定的一个名称
image: wordpress:latest #必选，镜像的名字
restart: always
links:
- db
ports: #可选，等价于 docker run 里的 -p 选项指定端口映射
- "80:80"
environment: #可选，等价于 docker run 里的 --env 选项设置环境变量
- WORDPRESS_DB_HOST=db
- WORDPRESS_DB_USER=root
- WORDPRESS_DB_PASSWORD=huawei
- WORDPRESS_DB_NAME=wordpress
db:
image: mysql:latest
restart: always
environment:
- MYSQL_ROOT_PASSWORD=huawei
- MYSQL_DATABASE=wordpress
[root@docker wordpress]# docker compose config -q #检测语法后端运行
bash
[root@docker wordpress]# docker compose up -d
[+] Running 3/3
✔ Network wordpress_default Created 0.0s
✔ Container wordpress-db-1 Started 0.3s
✔ Container wordpress-blog-1 Started 0.6s 查看现象
bash
[root@docker wordpress]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
85b438b2ff89 wordpress:latest "docker-entrypoint.s..." About a minute ago Up About a minute 0.0.0.0:80->80/tcp, :::80->80/tcp wordpress-blog-1
3c340ed1e299 mysql:latest "docker-entrypoint.s..." About a minute ago Up About a minute 3306/tcp, 33060/tcp wordpress-db-1