Docker 创建容器时指定容器ip

在上一篇 《 docker 网络（host&none&bridge） 》中，我们介绍了docker自带网络的三种模式。

其中提到过bridge（docker0）网络由于是docker安装时就创建的，无法在创建容器的时候指定容器ip。

那么在实际部署中，我们需要指定容器ip，不允许其自行分配ip，防止容器ip混乱。

有什么办法可以在创建容器时指定容器ip呢？很简单，自己创建一个新的bridge网络bridge1，在创建bridge1的时候同时创建子网，那么在创建容器的时候指定网络为bridge1并指定ip即可。

光说不练假把式，我们一起实战吧！！！

好的，现在自定义的网络已经创建好了，之后在创建容器的时候，我们就可以指定IP了。

此时指定的容器ip为172161212。

如果没有指定容器ip，将会自动分一个17216120/16网段内的ip。

在多机器上docker部署Spring Cloud发现有一个问题，即在docker容器内部，Spring Cloud eureka实例只能获取到docker内部网络的IP，如172xxx，并将其注册到注册中心，此时其他服务通过该IP在docker外部无法访问该服务。以下有两种解决方法：

启动容器时将宿主机的IP加到容器环境变量中然后在Spring Boot applicationyml 中使用该环境变量。

applicationyml

启动docker时加入 HOST 环境变量：

或使用docker-compose：

将容器以host模式运行

在Spring Cloud中配置IP访问

多网卡的情况

指定IP在某些场景下很有用，如某台服务器有eth0、eth1和eth2三块网卡，但是eth1可以被其它的服务器访问；如果Eureka Client将eth0或者eth2注册到Eureka Server上，其它微服务就无法通过这个IP调用该微服务的接口。

若在生产环境中使用，一般就不会直接使用IP注册到eureka注册中心了，由于生产环境通常由k8s集群或其他类似docker集群进行管理，因此一般会使用服务名等进行注册，由k8s再转发到具体的服务上。

参考链接：

首先定义一个 IP Pool，比如：

cat << EOF | calicoctl create -f -

- apiVersion: v1

kind: ipPool

metadata:

cidr: 17200/16

EOF

用此 IP Pool 创建 calico 网络。

docker network create --driver calico --ipam-driver calico-ipam --subnet=17200/16 my_net

此时运行容器将分配到指定 subnet 中的 IP。

当然也可以通过 --ip 为容器指定 IP，但必须在 subnet 范围之内。

至此，我们已经讨论了 Docker 的多种跨主机网络方案，下一节将从多个维度比较各种方案的优缺点。

--name 给新生成的容器命名

--privileged=true 给容器访问Linux内核特权,后面要访问systemctl

返回一串容器ID表示容器生成成功

修改如下：

(Failed to get D-Bus connection: Operation not permitted)

这里如果报这个错误说明容器权限不足,第2步执行有误

-m:来指定提交的说明信息，跟我们使用的版本控制工具一样

-a 可以指定更新的用户信息

ffe81683c404： 创建镜像的容器的ID，就是上面的容器id，也就是我们刚才进入的容器id

centos: 目标镜像的仓库名

我们用centos基础容器修改配置后已经生成了所需要的镜像，之前的构建容器就可以删除了

ip: 为宿主主机的ip

端口:就是上面的22

用户名： root

密码： 就是上面password部分设置的密码

在mac上可通过ssh root@127001 -p:22 登录新生成的容器

至此ssh连接docker容器连接成功。

命令成功后，就会创建一个名字为centos:100的image，可以使用“docker images”来查看

ip: 为宿主主机的ip

端口:就是上面的22

用户名： root

密码： 就是上面password部分设置的密码

在mac上可通过ssh root@127001 -p:22 登录新生成的容器

如上红字所描述：同一个宿主机上的不同容器之间的网络如何互通的？？？

我们安装完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地址在同一个网段，如上图就假设它们都在19216810网段。

还得再看下面这张OSI 7层网络模型图。

主机A向主机B发送数据，对主机A来说数据会从最上层的应用层一路往下层传递。比如应用层使用的>

前面介绍了： Docker容器网络-基础篇

前文说到容器网络对Linux虚拟化技术的依赖，这一篇章我们将一探究竟，看看Docker究竟是怎么做的。通常，Linux容器的网络是被隔离在它自己的Network Namespace中，其中就包括：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和iptables规则。对于一个进程来说，这些要素，就构成了它发起和响应网络请求的基本环境。

我们在执行 docker run -d --name xxx 之后，进入容器内部：

并执行 ifconfig：

我们看到一张叫eth0的网卡，它正是一个Veth Pair设备在容器的这一端。

我们再通过 route 查看该容器的路由表：

我们可以看到这个eth0是这个容器的默认路由设备。我们也可以通过第二条路由规则，看到所有对 16925411/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是0000，意味着这是一条直连规则，也就是说凡是匹配到这个路由规则的请求，会直接通过eth0网卡，通过二层网络发往目的主机。而要通过二层网络到达容器2，就需要1271703对应的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网桥的虚拟网卡上，这样，1271703就会收到这个广播，并把其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很可能就是上文所说的1721702，多个节点都会存在这个IP，大概率这个IP是冲突的。

如果我们想避免这个问题，就会携带宿主机的IP和映射的端口去注册。但是这又带来一个问题，即容器内的应用去意识到这是一个容器，而非物理机，当在容器内，应用需要去拿容器所在的物理机的IP，当在容器外，应用需要去拿当前物理机的IP。显然，这并不是一个很好的设计，这需要应用去配合配置。所以，基于此，我们肯定要寻找其他的容器网络解决方案。

在上图这种容器网络中，我们需要在我们已有的主机网络上，通过软件构建一个覆盖在多个主机之上，且能把所有容器连通的虚拟网络。这种就是Overlay Network（覆盖网络）。

关于这些具体的网络解决方案，例如Flannel、Calico等，我会在后续篇幅继续陈述。

以上就是关于Docker 创建容器时指定容器ip全部的内容，包括:Docker 创建容器时指定容器ip、docker运行Spring Cloud使用外部IP、如何用calico 指定容器ip等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！