Ⅰ Docker基础
Docker 是一个开源的应用容器引擎，基于Go 语言 并遵从 Apache2.0 协议开源。
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 linux 机器上，也可以实现虚拟化。
容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。
Docker最早是在Ubuntu 12.04上开发实现的；
Red Hat则从RHEL6.5开始对Docker进行支持。
而后Windows和Mac上也相应有了Docker版本支持。
在Docker容器技术出现之前，Linux上是已经有一个docker的工具的，但此docker非彼Docker。
这个docker是一个窗口停靠栏程序，就像苹果的Mac系统中的dock那个程序一样的一个工具。
为了区分开来，我们以Docker和docker来进行区分。
Docker：指容器技术。
docker：指窗口停靠栏程序。
Docker技术出来后，因为Linux系统上已经有了docker这个工具，所以Docker软件名也不能跟人家重名啊，要不然没办法安装。
由于那个时候Docker的官网是docker.io，所以就在软件名称上加了io的后缀，在Ubuntu中就是docker.io，在CentOS中就是docker-io。
但是虽然软件名跟docker程序不一样了，但软件安装后的操作命令还是一样的，都是docker的这个命令，所以要安装Docker软件，要先看看有没有安装了那个停靠栏程序docker，有的话要先卸载才行，要不然执行的命令是不对的。
这个时期要安装Docker，就要用docker加io后缀的方式来安装。
Docker容器使用docker.io和docker-io为软件名，主要是前期的一段时间。
后来随着Docker的发展，软件包名改成了docker-engine,不同系统中名称达到了统一。
再后来，随着Docker技术的火爆，在征得docker停靠栏程序作者同意下，原先的停靠栏程序docker名称改掉了，改成了wmdocker，Docker容器技术的软件包名才正式成了docker这个名称，Docker软件包的名称又得到了一次完全的统一。
到Docker1.13.1版本之前，Docker软件包的名称有两次变化，从docker-io(docker.io)到docker-engine,再到docker。
Docker发展到1.13.1版本号后，Docker公司把Docker分成了社区版(免费)Docker CE和商业版(付费)Docker EE两种形式，并且版本号命名方式也改了，以前是那种常用的版本号命令方式，比如0.1、0.2、1.0之类的，现在分社区和商业版后，版本号是“年.月”的形式命名的，比如2019年10月发布的，版本号就是19.10。
所以在Docker1.13.1之后，直接是Docker-ce 17.03.0版本了，也就是2017年03月发布的。
现在要安装最新版的Docker软件包，就是使用docker-ce这个名称了，如果是商业版的就是docker-ee了。
目前docker的默认存储引擎为overlay2，不同的存储引擎需要相应的文件系统支持，如需要磁盘分区的时候传递d-type稳健分层功能，即需要传递内核参数并开启格式化磁盘的时候指定的功能。
存储引擎的选择文档
AUFS
AUFSAnotherUnionFileSystem是一种UnionFS。V2版本后更名为 advanced multi‐layered unification fileystem，即高级多层统一文件系统。所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种系统可以一层一层的叠加修改文件。无论底下有多少层都是只读，只有最上层的文件系统是可读写。当需要修改一个文件时，AUFS创建该文件的一个副本。使用CoWCopy-on-Write将文件从只读层复制到可写层进行修改，结果也保留在可写层、在Docker中。底下的制度层就是image，可写层就是Container。
Overlay
一种Union FS文件系统，Linux内核3.18后支持
Overlay2
overlay的升级版，到目前为止，所有Linux发行版推荐使用的存储类型
devicemapper
是CentOS和RHEL的推荐存储驱动程序，但是依赖于direct-lvm，存在空间受限的问题，虽然可以通过后期配置解决；因为之前的内核版本不支持overlay2（集中在Centos/RHEL7.2之前版本）；但当前较新版本Centos和RHEL现已经支持overlay2。
https://www.cnblogs.com/youruncloud/p/5736718.html
zfs/btrfs(Oracle-2007)
目前没有广泛应用；这些文件系统允许使用高级选项，例如创建“快照”，但需要更多的维护和设置。并且每一个都依赖于正确配置的后备文件系统。
vfs
用于测试环境，适用于无法适用Cow文件系统的情况。此存储驱动程序的性能很差，通常不建议在生产中使用。
1）overlay存储驱动程序已在Docker Engine-Enterprise 18.09中弃用，并将在以后的版本中删除。建议将overlay存储驱动程序的用户迁移到overlay2。
2）devicemapper存储驱动程序已在Docker Engine 18.09中弃用，并将在以后的版本中删除。建议将devicemapper存储驱动程序的用户迁移到overlay2。
建议使用overlay2存储驱动程序。首次安装Docker时，默认情况下使用overlay2。早期版本，默认情况下会使用aufs。如果要在新版本中使用aufs，则需要对其配置，并且可能需要安装其他软件包，例如linux-image-extra。
对于Docker，支持文件系统是所在的文件系统 /var/lib/docker/。一些存储驱动程序仅适用于特定的后备文件系统。
配置 Docker 存储驱动非常简单，只需要修改配置文件即可。
Ⅱ VsCode轻松使用docker容器-Remote Containers
演示视频： BiliBili
使用docker容器过程中，最常见的操作是进入容器内查看文件、修改配置等操作
使用shell进入容器内，使用linux命令操作
像VsCode操作本地文件一样去查看文件、修改配置。可以界面化得操作文件，不需要使用shell命令（如:ls cat echo vi等）
开发过程中，往往部署服务会在服务器上，所以需要远程到服务器上部署docker，下面服务器为ubuntu
远程到服务器后，很多操作需要输入密码，使用起来不方便，可以使用SSH key减少密码输入
Ⅲ Docker容器网络-实现篇
前面介绍了： Docker容器网络-基础篇
前文说到容器网络对Linux虚拟化技术的依赖，这一篇章我们将一探究竟，看看Docker究竟是怎么做的。通常，Linux容器的网络是被隔离在它自己的Network Namespace中，其中就包括：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和iptables规则。对于一个进程来说，这些要素，就构成了它发起和响应网络请求的基本环境。
我们在执行 docker run -d --name xxx 之后，进入容器内部：
并执行 ifconfig：
我们看到一张叫eth0的网卡，它正是一个Veth Pair设备在容器的这一端。
我们再通过 route 查看该容器的路由表：
我们可以看到这个eth0是这个容器的默认路由设备。我们也可以通过第二条路由规则，看到所有对 169.254.1.1/16 网段的请求都会交由eth0来处理。
而Veth Pair 设备的另一端，则在宿主机上，我们同样也可以通过查看宿主机的网络设备来查看它：
在宿主机上，容器对应的Veth Pair设备是一张虚拟网卡，我们再用 brctl show 命令查看网桥：
可以清楚的看到Veth Pair的一端 vethd08be47 就插在 docker0 上。
我现在执行docker run 启动两个容器，就会发现docker0上插入两个容器的 Veth Pair的一端。如果我们在一个容器内部互相ping另外一个容器的IP地址，是不是也能ping通？
容器1：
容器2：
从一个容器ping另外一个容器：
我们看到，在一个容器内部ping另外一个容器的ip，是可以ping通的。也就意味着，这两个容器是可以互相通信的。
我们不妨结合前文时所说的，理解下为什么一个容器能访问另一个容器？先简单看如一幅图：
当在容器1里访问容器2的地址，这个时候目的IP地址会匹配到容器1的第二条路由规则，这条路由规则的Gateway是0.0.0.0，意味着这是一条直连规则，也就是说凡是匹配到这个路由规则的请求，会直接通过eth0网卡，通过二层网络发往目的主机。而要通过二层网络到达容器2，就需要127.17.0.3对应的MAC地址。所以，容器1的网络协议栈就需要通过eth0网卡来发送一个ARP广播，通过IP找到MAC地址。
所谓ARP（Address Resolution Protocol），就是通过三层IP地址找到二层的MAC地址的协议。这里说到的eth0，就是Veth Pair的一端，另一端则插在了宿主机的docker0网桥上。eth0这样的虚拟网卡插在docker0上，也就意味着eth0变成docker0网桥的“从设备”。从设备会降级成docker0设备的端口，而调用网络协议栈处理数据包的资格全部交给docker0网桥。
所以，在收到ARP请求之后，docker0就会扮演二层交换机的角色，把ARP广播发给其它插在docker0网桥的虚拟网卡上，这样，127.17.0.3就会收到这个广播，并把其MAC地址返回给容器1。有了这个MAC地址，容器1的eth0的网卡就可以把数据包发送出去。这个数据包会经过Veth Pair在宿主机的另一端veth26cf2cc，直接交给docker0。
docker0转发的过程，就是继续扮演二层交换机，docker0根据数据包的目标MAC地址，在CAM表查到对应的端口为veth8762ad2，然后把数据包发往这个端口。而这个端口，就是容器2的Veth Pair在宿主机的另一端，这样，数据包就进入了容器2的Network Namespace，最终容器2将响应（Ping）返回给容器1。在真实的数据传递中，Linux内核Netfilter/Iptables也会参与其中，这里不再赘述。
CAM就是交换机通过MAC地址学习维护端口和MAC地址的对应表
这里介绍的容器间的通信方式就是docker中最常见的bridge模式，当然此外还有host模式、container模式、none模式等，对其它模式有兴趣的可以去阅读相关资料。
好了，这里不禁问个问题，到目前为止只是单主机内部的容器间通信，那跨主机网络呢？在Docker默认配置下，一台宿主机的docker0网桥是无法和其它宿主机连通的，它们之间没有任何关联，所以这些网桥上的容器，自然就没办法多主机之间互相通信。但是无论怎么变化，道理都是一样的，如果我们创建一个公共的网桥，是不是集群中所有容器都可以通过这个公共网桥去连接？
当然在正常的情况下，节点与节点的通信往往可以通过NAT的方式，但是，这个在互联网发展的今天，在容器化环境下未必适用。例如在向注册中心注册实例的时候，肯定会携带IP，在正常物理机内的应用当然没有问题，但是容器化环境却未必，容器内的IP很可能就是上文所说的172.17.0.2，多个节点都会存在这个IP，大概率这个IP是冲突的。
如果我们想避免这个问题，就会携带宿主机的IP和映射的端口去注册。但是这又带来一个问题，即容器内的应用去意识到这是一个容器，而非物理机，当在容器内，应用需要去拿容器所在的物理机的IP，当在容器外，应用需要去拿当前物理机的IP。显然，这并不是一个很好的设计，这需要应用去配合配置。所以，基于此，我们肯定要寻找其他的容器网络解决方案。
在上图这种容器网络中，我们需要在我们已有的主机网络上，通过软件构建一个覆盖在多个主机之上，且能把所有容器连通的虚拟网络。这种就是Overlay Network（覆盖网络）。
关于这些具体的网络解决方案，例如Flannel、Calico等，我会在后续篇幅继续陈述。
Ⅳ Docker容器间网络互联原理，讲不明白算我输
如上红字所描述：同一个宿主机上的不同容器之间的网络如何互通的？？？
我们安装完docker之后，docker daemon会为我们自动创建3个网络，如下：
其实docker有4种网络通信模型，分别是：bridge、host、none、container
默认的使用的网络模型是bridge，也是我们生产上会使用到的网络模型。
下文中跟大家分享docker容器互通原理到时候呢，用到的也是bridge网络模型
另外，当我们安装完docker之后，docker会为我们创建一个叫docker0的网络设备
通过ifconfig命令可以查看到它，看起来它貌似和eth0网络地位相当，像是一张网卡。然而并不是，docker0其实是一个Linux网桥
何以见得？可以通过下面的命令查看操作系统上的网桥信息
那大家怎么理解Linux网桥的概念呢？
其实大家可以把docker0理解成一台虚拟的交换机！然后像下面这样类比着理解，就会豁然开朗
1、它好比是大学在机房上课时，老师旁边的那个大大的交换机设备。
2、把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。
3、把交换机和机房中的机器的ip在同一个网段，类比成docker0、和你启动的docker容器的ip也同属于172网段。
类比成这样：
我们刚才做类比理解docker0的时候说：把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。那具体的实现落地实现用的是啥技术呢？
答案是：veth pair
veth pair的全称是：virtual ethernet，就是虚拟的以太网卡。
说到以太网卡大家都不陌生呀，不就是我们常见的那种叫eth0或者是ens的网络设备吗？
那这个veth pair是怎么玩的呢？有啥用呢？大家可以看下面这张图
veth-pair设备总是会成对的出现，用于连接两个不同network-namespace.
就上图来说，从network-namespace1的veth0中发送的数据会出现在 network-namespace2的veth1设备中。
虽然这种特性很好，但是如果出现有多个容器，你就会发现组织架构会越来越复杂，越来越乱
不过好在我们已经循序渐进的了解Linux网桥（docker0），以及这里的veth-pair设备，于是我们可以把整体的架构图重新绘制成下面这样
因为不同容器有自己隔离后的network-namespace所以他们都有自己的网络协议栈
那我们能不能找到容器里面的网卡和物理机上的哪张卡是一对网络vethpair设备呢？
如下：
回到宿主机
意思是就是说，容器545ed62d3abf的eth0网卡和宿主机通过ip addr命令查看的网络设备标号55的设备组成一对vethpair设备，彼此流量互通！
先看个简单的，同一个局域网中的不同主机A、B之间是如何互联交换数据的。如下图
那，既然是同一个局域网中，说明A、B的ip地址在同一个网段，如上图就假设它们都在192.168.1.0网段。
还得再看下面这张OSI 7层网络模型图。
主机A向主机B发送数据，对主机A来说数据会从最上层的应用层一路往下层传递。比如应用层使用的http协议、传输层使用的TCP协议，那数据在往下层传递的过程中，会根据该层的协议添加上不同的协议头等信息。
根据OSI7层网络模型的设定，对于接受数据的主机B来说，它会接收到很多数据包！这些数据包会从最下层的物理层依次往上层传递，依次根据每一层的网络协议进行拆包。一直到应用层取出主机A发送给他的数据。
那么问题来了，主机B怎么判断它收到的数据包是否是发送给自己的呢？万一有人发错了呢？
答案是：根据MAC地址，逻辑如下。
那对于主机A来说，它想发送给主机B数据包，还不能让主机B把这个数据包扔掉，它只能中规中矩的按以太网网络协议要求封装将要发送出去的数据包，往下传递到数据链路层（这一层传输的数据要求，必须要有目标mac地址，因为数据链路层是基于mac地址做数据传输的）。
那数据包中都需要哪些字段呢？如下：
其中的dst ip好说，我们可以直接固定写，或者通过DNS解析域名得到目标ip。
那dst mac怎么获取呢？
这就不得不说ARP协议了! ARP其实是一种地址解析协议，它的作用就是：以目标ip为线索，找到目的ip所在机器的mac地址。也就是帮我们找到dst mac地址！大概的过程如下几个step
推荐阅读：白日梦的DNS笔记
简述这个过程：主机A想给主机B发包，那需要知道主机B的mac地址。
嗯，在arp协议的帮助下，主机A顺利拿到了主机B的mac地址。于是数据包从网络层流转到数据链路层时已经被封装成了下面的样子：
根据OIS7层网络模型，我们都知道数据包经过物理层发送到机器B，机器B接收到数据包后，再将数据包向上流转，拆包。流转到主机B的数据链路层。
那主机B是如何判断这个在数据链路层的包是否是发给自己的呢？
答案前面说了，根据目的mac地址判断。
这个例子比较简单，dst ip就是主机B的本机ip 所以它自己会处理这个数据包。
那数据包处理完之后是需要给主机A一个响应包，那问题又来了，响应包该封装成什么样子呢？对主机B来说响应包也需要src ip、src mac、dst ip、dst mac
同样的道理，响应包也会按照如下的逻辑被主机A接受，处理。
这一次，让我在网络告诉你，当你请求 www..com 时都发生了什么？
有了上面那些知识储备呢？再看我们今天要探究的问题，就不难了。
如下红字部分：同一个宿主机上的不同容器是如何互通的？
那我们先分别登陆容器记录下他们的ip
先看实验效果：在9001上curl9002
实验结果是网络互通！
我们再完善一下上面的图，把docker0、以及两个容器的ip补充上去，如下图：
那两台机器之前要通信是要遵循OSI网络模型、和以太网协议的。
我们管172.17.0.2叫做容器2
我们管172.17.0.3叫做容器3
比如我们现在是从：容器2上curl 容器3，那么容器2也必须按照以太网协议将数据包封装好，如下
那现在的问题是容器3的mac地址是多少？
容器2会先查自己的本地缓存，如果之前没有访问过，那么缓存中也没有任何记录！
不过没关系，还有arp机制兜底，于是容器2会发送arp请求包，大概如下
容器2会查询自己的路由表，将这个arp请求从自己的gateway发送出去
我们发现容器2的网关对应的网络设备的ip就是docker0的ip地址，并且经由eth0发送出去！
哎？eth0不就是我们之前说的veth-pair设备吗？
并且我们通过下面的命令可以知道它的另一端对应着宿主机上的哪个网络设备：
而且我们可以下面的小实验，验证上面的观点是否正确
所以说从容器2的eth0出去的arp请求报文会同等的出现在宿主机的第53个网络设备上。
通过下面的这张图，你也知道第53个网络设备其实就是下图中的veth0-1
所以这个arp请求包会被发送到docker0上，由docker0拿到这个arp包发现，目标ip是172.17.0.3并不是自己，所以docker0会进一步将这个arp请求报文广播出去，所有在172.17.0.0网段的容器都能收到这个报文！其中就包含了容器3！
那容器3收到这个arp报文后，会判断，哦！目标ip就是自己的ip，于是它将自己的mac地址填充到arp报文中返回给docker0！
同样的我们可以通过抓包验证，在宿主机上
于是容器2就拿到了容器3的mac地址，以太网数据包需要的信息也就齐全了！如下：
再之后容器2就可以和容器3正常互联了！
容器3会收到很多数据包，那它怎么知道哪些包是发给自己的，那些不是呢？可以参考如下的判断逻辑
Ⅳ 如何进入 Docker 容器
如何进入Docker容器
概述
在使用Docker创建了容器之后，大家比较关心的就是如何进入该容器了，其实进入docker容器有好几多种方式，这里我们就讲一下常用的几种进入Docker容器的方法。
进入Docker容器比较常见的几种做法如下：
使用docker attach
使用SSH
使用nsenter
使用exec
下面我们来逐一讲一下每种方式。
一、使用docker attach进入Docker容器
Docker提供了attach命令来进入Docker容器。
接下来我们创建一个守护态的Docker容器，然后使用docker attach命令进入该容器。
[plain] view plain
$ sudo docker run -itd ubuntu:14.04 /bin/bash
然后我们使用docker ps查看到该容器信息，接下来就使用docker attach进入该容器
[plain] view plain
$ sudo docker attach 44fc0f0582d9
可以看到我们已经进入到该容器中了。
但在，使用该命令有一个问题。当多个窗口同时使用该命令进入该容器时，所有的窗口都会同步显示。如果有一个窗口阻塞了，那么其他窗口也无法再进行操作。下来我们来演示一下。打开两个窗口，都使用attach命令进入同一个容器里面。如下所示：
接下来我们只在第一个窗口进行操作，可以看到第一个窗口的操作同步到第二个窗口显示了，如下：
因为这个原因，所以docker attach命令不太适合于生产环境，平时自己开发应用时可以使用该命令。
二、使用SSH进入Docker容器
在生产环境中排除了使用docker attach命令进入容器之后，相信大家第一个想到的就是ssh。在镜像（或容器）中安装SSH Server，这样就能保证多人进入容器且相互之间不受干扰了，相信大家在当前的生产环境中（没有使用Docker的情况）也是这样做的。但是使用了Docker容器之后不建议使用ssh进入到Docker容器内。关于为什么不建议使用，请参考如下几篇文章：
Why you don't need to run SSHd in your Docker containers
上面这篇文章是英文的，如果英语不好的话可以参考如下译文
为什么不需要在 Docker 容器中运行 sshd
三、使用nsenter进入Docker容器
在上面两种方式都不适合的情况下，还有一种比较方便的方法，即使用nsenter进入Docker容器。关于什么是nsenter请参考如下文章：
https://github.com/jpetazzo/nsenter
在了解了什么是nsenter之后，我们需要把nsenter安装到主机中（注意是主机而非容器或镜像），具体的安装命令如下：
[plain] view plain
$ wget https:/。。。r.gz
$ tar -xzvf util-linux-2.24.tar.gz
$ cd util-linux-2.24/
$ ./configure --without-ncurses
$ make nsenter
$ sudo cp nsenter /usr/local/bin
安装好nsenter之后可以查看一下该命令的使用。
nsenter可以访问另一个进程的名称空间。所以为了连接到某个容器我们还需要获取该容器的第一个进程的PID。可以使用docker inspect命令来拿到该PID。
docker inspect命令使用如下：
[plain] view plain
$ sudo docker inspect --help
inspect命令可以分层级显示一个镜像或容器的信息。比如我们当前有一个正在运行的容器
可以使用docker inspect来查看该容器的详细信息。
[plain] view plain
$ sudo docker inspect 44fc0f0582d9
由其该信息非常多，此处只截取了其中一部分进行展示。如果要显示该容器第一个进行的PID可以使用如下方式
[plain] view plain
$ sudo docker inspect -f {{.State.Pid}} 44fc0f0582d9
在拿到该进程PID之后我们就可以使用nsenter命令访问该容器了。
[plain] view plain
$ sudo nsenter --target 3326 --mount --uts --ipc --net --pid
其中的3326即刚才拿到的进程的PID
当然，如果你认为每次都输入那么多参数太麻烦的话，网上也有许多做好的脚本供大家使用。
地址如下：
四、使用docker exec进入Docker容器
除了上面几种做法之外，docker在1.3.X版本之后还提供了一个新的命令exec用于进入容器，这种方式相对更简单一些，下面我们来看一下该命令的使用：
[plain] view plain
$ sudo docker exec --help
接下来我们使用该命令进入一个已经在运行的容器
[plain] view plain
$ sudo docker ps
$ sudo docker exec -it 775c7c9ee1e1 /bin/bash
网上还有一种做法是使用nsinit，没有亲身实践过所以不在此罗列了，有兴趣的话可以尝试一下。
Ⅵ Docker(5)——数据管理
docker 容器的文件系统在宿主机上存在的方式很复杂，这会带来下面几个问题：
为了能够 保存（持久化） 数据以及 共享 容器间的数据，docker 引入了数据卷(volume) 机制。数据卷是存在于一个或多个容器中的特定文件或文件夹，它可以绕过默认的联合文件系统，以正常的文件或者目录的形式存在于宿主机上。
其生存周期独立于容器的生存周期。
容器中主要有 两种 管理数据方式： 数据卷(Data Volumes) ， 数据卷容器(Data Volume Containers) 。
数据卷是一个可供容器使用的特殊目录，它绕过文件系统，可以提供很多有用的特性：
数据卷的使用类似 linux 下对目录或文件进行 mount 操作，目前Docker提供了 三种 不同的方式将数据从宿主机挂载到容器中，分别是
其中 volume 、 bind mount 比较常用， tmpfs mount 基本不会用.
volumes作为Docker管理宿主机文件系统的一部分 ，默认位于 /var/lib/docker/volumes 目录中，不是宿主机已有数据，而是新建的。
docker 专门提供了 volume 子命令来操作数据卷：
先创建一个名称为 hello 的数据卷并通过 ls 命令进行查看：
然后可以使用 inspect 命令看看数据卷hello的详细信息
该数据卷使用的 Driver 为默认的 local ，表示数据卷使用宿主机的本地存储;
Mountpoint 是 volumes 的挂载点，默认是本机 /var/lib/docker/volumes 下的一个目录。
所有Container的数据都保存在了这个目录下边，由于没有在创建时指定卷，所以Docker帮我们默认创建许多匿名卷。
使用 -v 选项也可以指定挂载一个本地的已有目录到容器中去作为数据卷：
docker run -it –-name robot1 -v /var/data:/opt/mydata ros/kinetic /bin/bash
上面的命令挂载主机的 /var/data 目录到容器的 /opt/mydata 目录。
这个功能在测试的时候特别方便，比如用户可以放置一些程序或数据到本地目录中，然后在容器中使用。另外，本地目录的路径必须是绝对路径，如果目录不存在，Docker 会自动创建。
Docker 挂载数据卷的默认权限是可读写 rw ，用户也可以通过 ro 标记指定为只读：
docker run -it –-name robot1 -v /var/data:/opt/mydata:ro ros/kinetic /bin/bash
加了 :ro 之后，容器内挂载的数据卷内的数据就变成只读的了。
除了把数据卷中的数据存储在宿主机，docker 还允许我们通过指定 volume driver 的方式把数据卷中的数据存储在其它的地方，比如 Azrue Storge 或 AWS 。
通过 vieux/sshfs 驱动把数据卷的存储在云主机上，docker 默认是不安装 vieux/sshfs 插件的，我们可以通过下面的命令进行安装：
docker plugin install --grant-all-permissions vieux/sshfs
然后通过 vieux/sshfs 驱动创建数据卷，并指定远程主机的登录用户名、密码和数据存放目录：
注意：确保指定的远程主机上的挂载点 /home/nick/sshvolume 目录是存在的，否则在启动容器时会报错。
最后在启动容器时指定挂载这个数据卷：
在容器中 /world 目录下操作的文件都存储在远程主机的 /home/nick/sshvolume 目录中。进入容器 testcon 然后在 /world 目录中创建一个文件，然后打开远程主机的 /home/nick/sshvolume 目录进行查看，新建的文件会出现在那里。
当使用 bind mounts 将主机上的目录挂载到容器中时，目录由其在主机上的完整或相对路径引用。
bind mount 和 volume 其实都是利用宿主机的文件系统，不同之处在于volume是docker自身管理的目录中的子目录，所以不存在权限引发的挂载的问题，并且目录路径是docker自身管理的，所以也不需要在不同的服务器上指定不同的路径，不需要关心路径
bind mounts 可以挂载在宿主机系统的任意位置 ，但 bind mount 在不同的宿主机系统是不可移植的，比如Windows和Linux的目录结构是不一样的， bind mount 所指向的 host 目录也不能一样。这也是为什么 bind mount 不能出现在Dockerfile中的原因，因为这样Dockerfile就不可移植了。
如果使用 Bind mounts 挂载 宿主机目录 到 容器内非空目录 ，那么 此容器中的非空目录中的文件会被隐藏 ，容器访问这个目录时能够访问到的文件均来自于宿主机目录。这也是Bind mounts模式和Volumes模式最大的行为上的不同。
挂载存储在宿主机系统的内存中，而不会写入宿主机的文件系统；
这张图说明 bind mount 和 volume 其实都是利用宿主机的文件系统， Bind mounts 模式是将宿主机上的任意文件或文件夹挂载到容器，而 Volumes 本质上是将Docker服务管理的一块区域（默认是 /var/lib/docker/volumes 下的文件夹）挂载到容器。所以 volume 不存在权限引发的挂载的问题，并且目录路径是docker自身管理的，所以也不需要在不同的服务器上指定不同的路径，不需要关心路径。
相对于 bind mount ， volume 是Docker Engine在自己的“地盘”分配了一个路径作为挂载点，自己地盘的权限肯定是安排的明明白白。所以，以上挂载宿主机路径的问题都解决了。
在使用 volume 作为数据卷挂载到容器时，直接用 volume 名称代替宿主机路径名就行：
docker run -d -v test_vol:/var/data some_image
这样就将数据卷 test_vol 挂载到了容器内的 /var/data 目录下。
命名的容器挂载数据卷，其它容器通过挂载这个(父容器)实现数据共享，挂载数据卷的容器，称之为数据卷容器
可以利用数据卷容器对其中的数据卷进行备份、恢复，以实现数据的迁移。
备份
使用下面的命令来备份 mydata 数据卷容器内的数据卷：
sudo docker run --volumes-from mydata -v $(pwd):/backup –-name worker ubuntu tar cvf /backup/backup.tar /data
这个命令首先利用 Ubuntu 镜像创建了一个容器 worker。又使用 --volumes-from mydata 参数来让 worker 容器挂载 mydata 容器的数据卷。接下来使用 -v $(pwd):/backup 参数来挂载本地的当前目录到 worker 容器的 /backup 目录。
在 worker 容器启动后，使用了 tar cvf /backup/backup.tar /data 命令来将 /data 下内容备份为容器内的 /backup/backup.tar，即宿主主机的当前目录下的backup.tar。
恢复
如果要恢复数据到一个容器，可以按照下面的操作。首先创建一个带有数据卷的容器 mydata2:
sudo docker run -v /data –-name mydata2 ubuntu /bin/bash
然后创建另一个新的容器，挂载 mydata2 的数据卷，并使用 tar 解压缩备份文件到所挂载的容器卷中：
sudo docker run --volumes-from mydata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
如果用户需要在容器之间共享一些持续更新的数据，最简单的方式是使用数据卷容器。数据卷容器其实就是一个普通的容器，专门用它提供数据卷供其他容器挂载。下面简单介绍其使用方法。
首先要创建一个数据卷容器 mydata，并在其中创建一个数据卷挂载到 /data 目录。
sudo docker run -it -v /data –-name mydata ubuntu
然后在其他容器中使用 --volumes-from 来挂载 mydata 容器中的数据卷。例如创建两个容器 mycon1 和 mycon2，并从 mydata 容器挂载数据卷：
sudo docker run -it --volumes-from mydata –-name mycon1 ubuntu
sudo docker run -it --volumes-from mydata –-name mycon2 ubuntu
(注意，命令中没有指定数据卷的信息，也就是说新容器中挂载数据卷的目录和源容器中是一样的。)
此时容器 mycon1 和 mycon2 都挂载同一个数据卷到相同的目录 /data。三个容器任何一个在该目录下写入数据其他容器都能看到。
可以多次使用 --volumes-from 参数来从多个容器挂载多个数据卷。还可以从其他已经挂载了容器的容器来挂载数据卷。并且使用 --volumes-from 参数所挂载数据卷的容器自身并不需要保持在运行状态。
但删除挂载了数据卷的容器时，数据卷并不会被自动删除。如果要删除一个数据卷，必须在删除最后一个还挂载着它的容器时显式的使用 docker rm -v 命令来指定同时删除关联的容器。
如何对已经运行的容器挂载目录？
https://blog.51cto.com/hjun169/2440799
手动修改mount挂载的json文件，狂神的那个视频里面也有写。
深刻理解Docker镜像大小
https://blog.csdn.net/shlazww/article/details/47375009
理解docker的分层镜像实现 base 镜像共享（DockerFile）
https://blog.csdn.net/lu_1110/article/details/106533490
Ⅶ Docker容器使用--net=host的方式启动后怎样访问
<ol><li>如果容器里没有运行sshd，可以登录宿主机后执行docker exec -it CONTAINER_NAME_OR_ID /bin/sh</li><li>可以在容器里运行个sshd，通过SSH客户端登录。 但由于是用的host网络，所以容器里的sshd进程无法使用默认端口，需要修改其配置文件把端口改成非22端口</li></ol>
Ⅷ docker 外网访问不了docker容器
出现问题的原因有3种，
1：你安装docker的服务器没有关闭防火墙，也就是说你访问你安装docker的物理机都访问不了，物理机里的docker就更访问不了了。
2：docker在创建镜像的时候没有做端口映射，这是就出现能访问物理机，但访问不了docker，你可以使用docker ps 查看镜像的端口映射情况。
3：端口映射不正确，如你docker中某一容器的8080端口映射到安装docker物理机的80端口，加入你在镜像里面安装了tomcat,但是你tomcat使用的是8080以外的任意端口，这是你访问物理机ip+80端口也无法访问。
Ⅸ 如何解决docker宿主机无法访问容器中的服务
有时候，查看资源管理器你会发现一个奇怪的现象。物理内存使用率没超过50%，就开始使用swap空间了。用swap显然没有使用物理内存快。如何修改？
在ubuntu 里面，swappiness的值的大小对如何使用swap分区是有着很大的联系的。
swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间；swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。两个极端，对于 ubuntu的默认设置，这个值等于60，建议修改为10。具体这样做：
1、查看你的系统里面的swappiness，在终端输入 cat /proc/sys/vm/swappiness，不出意外结果应该是60
2、修改swappiness值为10。在终端输入 sudo gedit /etc/sysctl.conf ，然后在最后一行添加 vm.swappiness=10 ，保存。
3、重启电脑，使设置生效。
这样Ubuntu就能最大限度使用物理内存了！！
Ⅹ 20在群晖系统安装使用Docker容器
学过linux的都知道，docker是一项非常好的开源容器引擎，它不单单能在linux和windows系统运行，还可以在群晖系统中运行，我们这里就演示一下怎么在群晖系统中运行docker容器。
1、首先安装docker容器套件，在套件中心搜索docker，就能找到docker安装套件，直接点击安装套件即可，非常简单。
2、打开docker套件，首先看到的是帮助页面。
3、我们点开软件中的注册表（我们以安装nginx容器为例），选中nginx，点击上面的下载，然后选择容器标签，默认latest，为最新版。
4、下载完成完成后，我们选中镜像，下载nginx镜像就在这里，我们点击启动。
5、打开容器创建页面，填写容器名称，使用高权限执行容器和启用资源限制，根据需求选择，然后点击“高级设置”
6、容器的高级设置页面，我们选中“启用自动重新启动”，这样容器遇到关机时会自动重新启动。
7、存储空间页面，添加docker容器在群晖存储上的装载路径。
8、端口页面设置nginx容器端口和群晖本地端口
9、信息摘要
10、创建完成，点击docker的容器，我们看到一个启动的nginx容器已经生成。
11、在你的电脑上，通过浏览器访问nginx容器，运行正常。