docker基础知识随意列举（一）网络篇

前言

群里有人连docker如何找到容器都不知道，在这个状态的小白，竟然还鼓吹docker必将一统江湖，我看是一桶浆糊还差不多。稍微随手写点有常用的命令，作为对理论的解释。先看理论性的知识，难以理解的地方，读一读本文没准就搞懂了。有疑惑的地方直接留言问，便于简要回答的会直接在下方补充。

常见有人自作聪明，画蛇添足对生命周期内的系统进行一些奇奇怪怪的操作提升安全性，却很少有人考虑docker的安全性？这是我对容器最顾虑的。

缺点随意列举几个

体积上不占优势，相对于虚拟机，许多的容器功能单一不说，一个容器几个G，这体积，足够承载上千个openwrt x86虚拟机最小镜像了吧，能包装多少东西了。

安全性也不占优势，各种东西动不动就各种依赖，如果真正有官方持续更新、维护的，已经做好了数据持久化存储或者数据不重要的容器，确实是快速发布快速体验应用，秒级升级需要复杂配置环境的软件，但是实际上哪怕是这种级别的应用也没人升级。更别提许许多多容器的使用完全就是虚拟机的逻辑，需要给与容器操作系统的真实root权限。

便捷性相对于有一些依赖复杂确实有所简化。但是大多数的容器没有“介绍使用说明”，实际上不那么简单。更别提一些小作坊级别的容器，不会正确赋予文件权限、运行权限之类的，反而动不动就要求提权，在部署上也费心费力，对于普通Linux包管理能够直接安装的软件，进行docker化实在是画蛇添足。更别提将k8s引入日常，仅仅是为了部署一个wordpress的。就先不说一连串的容器有多少安全需要考虑维护关注，此时的wordpress完全无法将修改迁移到升级版本，只能周而复始的对每次版本升级后进入容器modify。轻松修复了CVM开发过程中加班时长不够的BUG。

引入K8S之类的问题不提，许许多多的“包装”引入了JAVA般内存占用，PHP般性能的python。软件本身实际运行消耗的内存只有几十兆，反而维护的Python脚本开销几百兆内存。当然此处不是说PHP性能差劲，原生调用的PHP本质是C的实现，解释性的部分仅仅是便于编辑管理，如果需要消耗性能的部分均有内置方法能够实现，那么CPU、内存的占用都是相当完美的，PHP7/8的性能提升“微乎其微”。不过要是自我实现，庞大的代码当然又慢又占内存。以ssh2lib为例，1G内存使用典型的ssh2无拓展实现大概能维持20并发，而引入库之后，KB级别的内存占用，甚至有人用来写不正当的东西。

我认为的优势

如果把容器当作一个应用看待。应用本身得到了发行方的“商用级支持”，能够维持软件更新漏洞修补，本身已经有合适的持久化缓存，方便的开箱即用，确实是快速部署。

许多演示目的不如提供一个真正开箱即用导入的虚拟机镜像更方便，许多年久失修的容器却拥有极高的权限相当多的安全漏洞，许多简单的小工具却依赖几个G的镜像，为了便于管理，又往容器安装openssh此类排除在外，再排除一些需要繁琐的配置而程序本身安装就很方便的软件，实际上合适的容器所剩无几。

能有几个容器，不看说明，能够真正直接拉取、运行呢。更不提官方hub速度在国内缓慢，自维护容器，其实不如维护脚本部署更方便？

安装

以基础的docker来说，其实主流的发行版都内置了，哪有常见的那些教程那么麻烦需要引入官方源，然后以缓慢的速度安装呢？

yum install docker -y echo ''> /etc/yum/pluginconf.d/subscription-manager.conf

• 1.
• 2.

以centos 7 为例，这是一个来自内置的extras源的包。只不过由于依赖问题，引入了subscription-manager作用的yum插件，提示需要订阅才能安装软件。虽然软件本身能够正确安装。清空/etc/yum/pluginconf.d/subscription-manager.conf，或者将enable从1改为0，就能禁用这个插件，不再进行这个无意义的提示了。

而docker源本身国内不再有什么可靠的源才是问题。可以选微软源或者是红帽源，都相当快。至于国内云计算厂商提供的那些，还是算了吧。版本落后、限速，以及使用繁琐可能需要注册，如果指定了版本号甚至可能得到不正确的完全无法运行的错误容器。

以官方docker-ce源安装，也是会引入subscription插件的。

Name        : docker
Arch        : x86_64
Epoch       : 2
Version     : 1.13.1
Release     : 209.git7d71120.el7.centos
Size        : 64 M
Repo        : installed
From repo   : extras
Summary     : Automates deployment of containerized applications
URL         : https://github.com/docker/docker
License     : ASL 2.0
Description : Docker is an open-source engine that automates the deployment of
            : any application as a lightweight, portable, self-sufficient
            : container that will run virtually anywhere.
            :
            : Docker containers can encapsulate any payload, and will run
            : consistently on and between virtually any server. The same
            : container that a developer builds and tests on a laptop will run
            : at scale, in production*, on VMs, bare-metal servers, OpenStack
            : clusters, public instances, or combinations of the above.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

网络

docker network ls

• 1.

默认有三种网络类型，无法被删除的。上述命令可以查看当前已存在的虚拟交换机。

bridge，此桥接非彼桥接，可能是vmware市场占有率高，相当“网络教程”将这玩意儿解释为跟vmware虚拟机一样的“桥接”，真是滑稽。

因为虚拟机的理念更为普及，本文章以虚拟机提供的虚拟网络功能作为对照。虽然容器本身不会产生模拟的网卡，实际上与openvz虚拟机是同源的。

Windows 10之类的客户端操作系统内置的Hyper-V默认会创建一个虚拟交换机，VMware workstation也会创建3种虚拟网络，docker的bridge，就类似操作系统自动创建、无法删除的那个虚拟交换机的功能；在VMware下，类似NAT模式。

生成了独立的网段，可以给容器指定IP或者自动指定，理念上其实类似NAT模式了。

如果容器需要对外暴露服务的，需要通过docker-proxy进行端口转发。不指定网络类型的容器就会以这个模式运行，这个状态是可以有-p参数进行端口暴露的，而host模式不可以。

host模式的容器，就很类似本地软件了。如果软件使用的端口本地实际上已经占用，就启用失败。此网络类型不支持-p参数指定端口。容器本身运行使用了什么端口，运行容器的操作系统本身对外提供服务的就是什么端口。

null模式顾名思义，这个状态的容器不会有任何的网络。容器不一定是对外提供服务的，也可以例如进行文件处理之类的本地小工具。

除了默认的三种网络类型，在一些教程中更为常见的macvlan类型。许许多多的“教程”将macvlan描述为“一种网卡虚拟化技术”，实在是离谱。许多的教程作者可能自己就一知半解，在这个网络类型中又融合了系统的VLAN虚网卡的形式，强行解释“这是一种跨物理机传输模式”。

实际上不只是macvlan，bridge模式也是会产生MAC地址的。每个容器都有自己的IP，以及MAC地址。bridge模式下容器通过操作系统本身的默认路由对外访问网络，当然也可以基于容器IP或者其他你意愿的路由方式为容器的网络请求决定出口。指定了端口转发之后，容器的服务端口就可以对外被访问到。如果操作系统默认没有net-tools，而嫌弃安装过程繁琐，/proc也是个不错的方式。

cat /proc/net/arp
1.

通过这个命令就可用看到各端口上“对方计算机”的MAC地址与IP地址的对应关系了。例如默认的eth0，以及容器带来的docker0。

而macvlan相对于bridge模式，VMware上对应的就更接近桥接模式了。这个模式指定的IP段位容器分配的IP，在计算机外可以访问。

docker network create -d macvlan --subnet=100.64.0.0/24 --gateway=100.64.0.1 -o parent=\$(ip route | grep default | awk '{print \$5}') testnet

• 1.

在这个例子中，\$(ip route | grep default | awk '{print \$5}')可以帮助匹配出当前操作系统默认联网的网卡，例如eth0，当然也可以手动修改这部分为em1或者其他实际你期望容器上网的网口。如果容器创建时IP地址不指定，容器会自动从100.64.0.2开始从最小的未用IP地址分配一个给容器。而100.64.0.1是当前例子中容器联网请求的网关，在MACVLAN状态下，操作系统本身并不会充当网关为容器提供NAPT网络连接服务，需要操作系统实际所在的网络实际存在这个网关。

网关IP可以是当前操作系统联网的提供NAT的路由器的IP地址，如果路由器支持多LAN IP，也可以为容器专门创建一段LAN，避免容器被自动分配了实际上局域网内已经存在的IP地址导致IP冲突。

如果运行容器的操作系统是虚拟机，则以下内容尤其需要注意。macvlan模式容器需要通过外部网关联网，外部网络可以直接访问到容器，比如网关端口映射给容器的IP地址。Hyper-V的虚拟机默认是“Access”模式接入的虚拟交换机。一切的包含VLAN标记的数据包会被Drop，如果macvlan指定了vlan，需要修改hyper-v当前虚拟机的端口的VLAN，或者修改为trunk模式，或者增加VLAN ID启用混合模式。另外不管是什么虚拟机，由于容器直接拥有了“外部的”IP地址，自己“拥有”MAC地址，所以虚拟机本身是要打开“允许MAC修改”，或者“MAC欺骗”类似的选项的。否则虚拟机本身的虚拟交换机会丢弃MAC地址非预设的虚拟机IP的数据包向外发送。

结尾

第一篇文章结尾。这是我作为萌新的时候初时docker的疑惑，最开始进行了解到的信息。回应前言开头提到的那个问题。

docker container ls
1.

小白运行docker，但是发现同名容器已经存在，但是执行这个命令却找不到容器百思不得其解。引入帮助，希望这位群友习得一个技能。软件内置的说明书。docker container ls -a，就能够找到目前没有运行的容器。默认状态下只能看到运行中的容器，容器异常崩溃、退出处于非运行状态，而容器没做重启、保活手段，就“找不到”了。下次碰上这种情况，可以docker rm 容器名，先删除重复的同名容器呀。或者将这个挂掉的容器重新start起来。至于在容器内“储存数据”，将容器当成“虚拟机用”，缺点太多了。真的想要虚拟机，本身系统又不能够提供虚拟化，试试openvz吧。

# docker container ls -h Flag shorthand -h has been deprecated, please use --help Usage: docker container ls [OPTIONS] List containers Aliases: ls, ps, list Options: -a, --all Show all containers (default shows just running) -f, --filter filter Filter output based on conditions provided --format string Pretty-print containers using a Go template --help Print usage -n, --last int Show n last created containers (includes all states) (default -1) -l, --latest Show the latest created container (includes all states) --no-trunc Don't truncate output -q, --quiet Only display numeric IDs -s, --size Display total file sizes

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.