从零开始学习docker（十九）Swarm mode 集群服务间通信--RoutingMesh

最新推荐文章于 2023-07-08 12:06:59 发布
最新推荐文章于 2023-07-08 12:06:59 发布
阅读量425 收藏 2
点赞数
文章标签： 运维 网络 php
原文链接：https://my.oschina.net/duanvincent/blog/3071202
版权

在上一节中，我们介绍了通过service create部署了wordpress和mysql，我们发现了几个问题：

不同节点之间如何通信？

通过service创建，将mysql和wordpress部署到cluster中，然后这两个service位于不同的节点上，这两个节点之间是可以相互通信的，并且可以通过service name进行通信，这里面就涉及到一个DNS服务发现的问题。

我们在之前将docker-compose时讲过，我们通过docker-compose部署一个application，这个application中的service 如果是连在了同一个网络上，那么他们之间是可以通过service name相互访问的。这个底层是通过DNS服务去实现的。这是docker-compose在单机的情况下。

今天我们在swarm cluster中我们的service是位于不同的节点上面，他们之间也可以通过service name进行通信的，所以说这也是DNS的功劳在里面。对于swarm来讲，我们有内置的DNS服务发现功能，通过swarm创建一个service时，如果是连到了一个overlay上，就可以为所有连到这个overlay上的service增加一条DNS记录，然后通过DNS记录就可以得到IP地址，然后就可以访问服务了。如下图所示：

eb69b83c912366e805baf0080f22072912d.jpg

其中DNS的name用service name来表示，而对应的记录IP并不是service所在容器的IP，而是一个虚拟IP（Virtual IP）。

为什么会这样？我们想一想，如果我们的service有一个横向的扩展（scale），那么service就不一定会在哪个节点上面，有一种情况是：某个节点的service down掉了，我们在其他节点上重新启动一个service，这时他的IP地址发生了变化；还有一种情况：有多个service，因此会对应多个IP地址。如果我们在DNS中通过实际的容器地址去表示IP地址，那么这会产生不稳定的现象，因为IP地址有可能发生变化。这时我们如果通过虚拟IP来解决这个问题。我们通过service来分配一个虚拟IP，而这个虚拟IP是不会变化的，也就是说一旦我们的service创建之后，IP就不会发生变化。但是这个虚拟IP地址背后，它所指的是实际IP（也就是容器IP），这时通过LVS实现的。

下面我们通过实验来具体演示一下。

准备环境

创建一个overlay类型的网络，名称叫my-demo

iie4bu@hostdocker:~$ docker network create -d overlay my-demo
cojus8blvkdozz8ykefozf7ml

创建一个service：这个service使用一个whoami的image，这个image会提供一个web服务的，如果我们访问他的8000端口的话，它会返回容器的hostname。

iie4bu@hostdocker:~$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                   PORTS
9i6wz6cg4koc        whoami              replicated          1/1                 jwilder/whoami:latest   *:8000->8000/tcp

查看whoami 运行在哪个节点：

iie4bu@swarm-manager:~$ docker service ps whoami
ID                  NAME                IMAGE                   NODE                DESIRED STATE       CURRENT STATE             ERROR               PORTS
6hhuf528spdw        whoami.1            jwilder/whoami:latest   swarm-manager       Running             Running 23 minutes ago

可以看到运行在swarm-manager节点上，可以通过docker container ls 看到这个容器：

iie4bu@swarm-manager:~$ docker container ls
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
cc9f97cc5056        jwilder/whoami:latest   "/app/http"         23 minutes ago      Up 23 minutes       8000/tcp            whoami.1.6hhuf528spdw9j9pla7l3tv3t

监听了本地的8000端口，

iie4bu@swarm-manager:~$ curl 127.0.0.1:8000
I'm cc9f97cc5056

返回了hostname。

然后我们再创建一个service，也连到这个my-demo上面，这个service是busyboxservice。

iie4bu@swarm-manager:~$ docker service create --name client -d --network my-demo busybox sh -c "while true; do sleep 3600; done"
jsj6euq2qlwljg421bet1d8cr

然后查看service：

iie4bu@swarm-manager:~$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                   PORTS
jsj6euq2qlwl        client              replicated          1/1                 busybox:latest          
9i6wz6cg4koc        whoami              replicated          1/1                 jwilder/whoami:latest   *:8000->8000/tcp

当client的REPLICAS变为1/1之后，说明已经启动成功。

查看client位于哪个节点：

iie4bu@swarm-manager:~$ docker service ps client
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE                ERROR               PORTS
czotxqi6bi5k        client.1            busybox:latest      swarm-worker2       Running             Running about a minute ago

可以看到是位于swarm-worker2节点上。

进入到swarm-worker2节点中，查看client的容器：

iie4bu@swarm-worker2:~$ docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
f84e7570ee1c        busybox:latest      "sh -c 'while true; …"   4 minutes ago       Up 4 minutes                            client.1.czotxqi6bi5k8uwkgzxcrwp1r

实验

进入swarm-worker2的client容器中，然后去ping whoami

iie4bu@swarm-worker2:~$ docker exec -it f84e sh
/ # ping whoami
PING whoami (10.0.2.5): 56 data bytes
64 bytes from 10.0.2.5: seq=0 ttl=64 time=0.085 ms
64 bytes from 10.0.2.5: seq=1 ttl=64 time=0.078 ms
64 bytes from 10.0.2.5: seq=2 ttl=64 time=0.077 ms
^C
--- whoami ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.077/0.080/0.085 ms

发现是可以ping通whoami的，并且是ping的10.0.2.5这个IP地址。而我们是在swarm-worker2节点中，去ping swarm-manager节点。说明是可以通过name访问到service，但是这个ip 10.0.2.5地址并不是whoami容器的ip地址。

思考：我们将whoami服务scale变成多个，那么在ping whoami的时候地址会不会变呢？

扩展whoami：

iie4bu@swarm-manager:~$ docker service scale whoami=2
whoami scaled to 2
overall progress: 2 out of 2 tasks 
1/2: running   [==================================================>] 
2/2: running   [==================================================>] 
verify: Service converged

然后我们查看whoami这个服务：

iie4bu@swarm-manager:~$ docker service ps whoami
ID                  NAME                IMAGE                   NODE                DESIRED STATE       CURRENT STATE               ERROR               PORTS
6hhuf528spdw        whoami.1            jwilder/whoami:latest   swarm-manager       Running             Running about an hour ago                                                
bw90ld3onwya        whoami.2            jwilder/whoami:latest   swarm-worker1       Running             Running 42 seconds ago

可以看到，service被分别部署到了swarm-manager和swarm-worker1上。 

在swarm-worker1上查看：

iie4bu@swarm-worker1:~$ docker container ls
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                       PORTS                                                          NAMES
5559895ccaea        jwilder/whoami:latest     "/app/http"         2 minutes ago       Up 2 minutes                 8000/tcp                                                       whoami.2.bw90ld3onwyabn3vv9rfoj9qf

发现确实，在swarm-worker1中有了一个whoami容器。

然后我们在client中再去ping一下whoami

/ # ping whoami
PING whoami (10.0.2.5): 56 data bytes
64 bytes from 10.0.2.5: seq=0 ttl=64 time=0.083 ms
64 bytes from 10.0.2.5: seq=1 ttl=64 time=0.073 ms
64 bytes from 10.0.2.5: seq=2 ttl=64 time=0.072 ms
64 bytes from 10.0.2.5: seq=3 ttl=64 time=0.072 ms
64 bytes from 10.0.2.5: seq=4 ttl=64 time=0.072 ms
64 bytes from 10.0.2.5: seq=5 ttl=64 time=0.072 ms

可以看到：我们在ping whoami 的时候可以ping通，而且地址还是10.0.2.5 是不是很奇怪？我们现在有两个whoami，它ping的一个地址到底是谁的呢？

其实ip地址10.0.2.5并不是我们任何一个whoami service容器的地址，而是一个VIP（虚拟IP）。如何证明？

使用nslookup命令可以证明。这个命令就是用来查询DNS的。可以去DNS服务器上查询一个DNS name。

 例如通过nslookup查询百度的IP地址：

iie4bu@swarm-manager:~$ nslookup www.baidu.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
www.baidu.com	canonical name = www.a.shifen.com.
www.a.shifen.com	canonical name = www.wshifen.com.
Name:	www.wshifen.com
Address: 103.235.46.39

然后我们在client容器中运行nslookup。

/ # nslookup whoami
Server:		127.0.0.11
Address:	127.0.0.11:53

Non-authoritative answer:

*** Can't find whoami: No answer

/ #

127.0.0.11为DNS服务器的地址，这个DNS服务器是有cluster维护的，而我们现在并没有返回正确结果，原因是新版busybox镜像的问题，使用旧版本即可，如1.28.3版。
删除busybox服务后，重新运行：

iie4bu@swarm-manager:~$ docker service rm client
client
iie4bu@swarm-manager:~$ docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                   PORTS
9i6wz6cg4koc        whoami              replicated          2/2                 jwilder/whoami:latest   *:8000->8000/tcp
iie4bu@swarm-manager:~$ docker service create --name client -d --network my-demo busybox:1.28.3 sh -c "while true; do sleep 3600; done"
h4wlczp85sw5ez5op51plfazn
overall progress: 1 out of 1 tasks 
1/1: running   [==================================================>] 
verify: Service converged

再次进入到容器中：

iie4bu@swarm-worker2:~$ docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
633ddfc082b9        busybox:1.28.3      "sh -c 'while true; …"   53 seconds ago      Up 52 seconds                           client.1.3iv3gworpyr5vdo0h9eortlw0
iie4bu@swarm-worker2:~$ docker exec -it 633 sh
/ #

然后执行nslookup：

iie4bu@swarm-worker2:~$ docker exec -it 633 sh
/ # nslookup whoami
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      whoami
Address 1: 10.0.2.5

返回了whoami的IP地址是10.0.2.5，但是这个地址既不是swarm-manager上的ip又不是swarm-worker1上面的ip。

看一下swarm-manager上面的whoami 的 ip：

iie4bu@swarm-manager:~$ docker container ls
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
cc9f97cc5056        jwilder/whoami:latest   "/app/http"         About an hour ago   Up About an hour    8000/tcp            whoami.1.6hhuf528spdw9j9pla7l3tv3t
iie4bu@swarm-manager:~$ docker exec -it cc9f97cc5056 sh
/app # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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
    inet 10.255.0.168/32 brd 10.255.0.168 scope global lo
       valid_lft forever preferred_lft forever
    inet 10.0.2.5/32 brd 10.0.2.5 scope global lo
       valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:ff:00:05 brd ff:ff:ff:ff:ff:ff
    inet 10.255.0.5/16 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
20: eth1@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:12:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.3/16 brd 172.18.255.255 scope global eth1
       valid_lft forever preferred_lft forever
23: eth2@if24: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:00:02:07 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.7/24 brd 10.0.2.255 scope global eth2
       valid_lft forever preferred_lft forever
/app #

在swarm-worker2上面查看一下whoami的ip：

iie4bu@swarm-worker1:~$ docker exec -it 5559895ccaea sh
/app # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:ff:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.255.0.6/16 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
22: eth2@if23: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:13:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.3/16 brd 172.19.255.255 scope global eth2
       valid_lft forever preferred_lft forever
24: eth1@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:00:02:0a brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.10/24 brd 10.0.2.255 scope global eth1
       valid_lft forever preferred_lft forever
/app #

发现都没有10.0.2.5IP地址。

然后在client中使用命令nslookup tasks.whoami

/ # nslookup tasks.whoami
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      tasks.whoami
Address 1: 10.0.2.10 whoami.2.bw90ld3onwyabn3vv9rfoj9qf.my-demo
Address 2: 10.0.2.7 whoami.1.6hhuf528spdw9j9pla7l3tv3t.my-demo
/ #

我们看到tasks.whoami一共有两个地址，一个是10.0.2.7，一个是10.0.2.10，跟我们上面的container中查看的一致。这才是真正的ip地址。所以通过tasks.whoami可以查看到真正的容器地址。

如果我们把whoami横向扩展成3个，会怎么样？

在swarm-manager中设置scale whoami=3

iie4bu@swarm-manager:~$ docker service scale whoami=3
whoami scaled to 3
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged
iie4bu@swarm-manager:~$ docker service ps whoami
ID                  NAME                IMAGE                   NODE                DESIRED STATE       CURRENT STATE               ERROR               PORTS
6hhuf528spdw        whoami.1            jwilder/whoami:latest   swarm-manager       Running             Running 2 hours ago                                                       
bw90ld3onwya        whoami.2            jwilder/whoami:latest   swarm-worker1       Running             Running about an hour ago                       
9idgk9jbrlcm        whoami.3            jwilder/whoami:latest   swarm-worker2       Running             Running 49 seconds ago

现在whoami位于三个容器，分别位于swarm-manager、swarm-worker1、swam-worker2。

这时返回到client，在执行nslookup tasks.whoami

/ # nslookup tasks.whoami
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      tasks.whoami
Address 1: 10.0.2.10 whoami.2.bw90ld3onwyabn3vv9rfoj9qf.my-demo
Address 2: 10.0.2.13 whoami.3.9idgk9jbrlcm3ufvkmbmvv2t8.my-demo
Address 3: 10.0.2.7 whoami.1.6hhuf528spdw9j9pla7l3tv3t.my-demo

可以看到又多了一条记录。

新增的10.0.2.13就是新增的service的地址，可以验证一下，在swarm-worker:

iie4bu@swarm-worker2:~$ docker exec -it f47e05019fd9 sh
/app # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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
    inet 10.255.0.168/32 brd 10.255.0.168 scope global lo
       valid_lft forever preferred_lft forever
    inet 10.0.2.5/32 brd 10.0.2.5 scope global lo
       valid_lft forever preferred_lft forever
24: eth2@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:00:02:0d brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.13/24 brd 10.0.2.255 scope global eth2
       valid_lft forever preferred_lft forever
26: eth1@if27: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:12:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.4/16 brd 172.18.255.255 scope global eth1
       valid_lft forever preferred_lft forever
28: eth0@if29: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 02:42:0a:ff:00:07 brd ff:ff:ff:ff:ff:ff
    inet 10.255.0.7/16 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever

可以看到10.0.2.13。

实际上任何一个连到my-demo网络上的容器执行nslookup都会的到这个结果。

总结：

    在client中ping whoami，返回的ip是10.0.2.5

    而使用命令nslookup tasks.whoami 返回的ip并没有10.0.2.5。

 ip：10.0.2.5就是虚拟ip。

这个虚拟IP是不会变的。因为service的数量会有变化的。而虚拟的ip与实际的container ip有一个map关系。通过这个map关系去找到了这个虚拟ip

访问whoami这个service具体情况 

因为我们的busybox没有装curl，所以我们用wget模拟请求。

在client container中访问whoami:8000

/ # wget whoami:8000
Connecting to whoami:8000 (10.0.2.5:8000)
index.html           100% |*******************************|    17   0:00:00 ETA
/ # more index.html 
I'm f47e05019fd9
/ #

可以正常访问到。其中f47e05019fd9是container的id。

将index.html删掉，然后在访问一遍whoami：

/ # wget whoami:8000
Connecting to whoami:8000 (10.0.2.5:8000)
index.html           100% |*******************************|    17   0:00:00 ETA
/ # more index.html 
I'm cc9f97cc5056
/ #

发现container的id变为cc9f97cc5056。

可以说每次访问whoami：8000返回内容都是不一样的，也就是说我们做了一个负载均衡。也就是说10.0.2.5背后其实是 10.0.2.10、10.0.2.13和10.0.2.7这三个web服务器。每次访问10.0.2.5,都会做一个负载均衡。第一次是 10.0.2.10给的响应，第二次是10.0.2.13依次循环。

这些负载均衡、VIP都是通过LVS帮我们实现的。

1c00d86652a4e6bf24539cb1b9e6970ac6a.jpg

ed4f82893f6847a74804c3038c465feef9d.jpg

简单总结一下：

8f88d864622f16f1608a8d04d84e76cc31e.jpg

我们这节讲的其实就是Routing Mesh。这一节讲的是Internal 网络。

Internal网络：我们在swarm中连接到同一个overlay网络中的容器是通过service name通信的，然后这个service name对应的ip地址并不是容器的具体ip地址，而是一个虚拟ip，而且如果容器做了scale，那么通过VIP去访问服务的时候Internal会帮我们做负载均衡。

Ingress网络：如果service有绑定端口，比如说我们本节的whoami绑定的8000端口，上一节的wordpress绑定的80端口，虽然这个service在cluster中的部分节点中运行，但是可以在swarm的任何节点通过对应的端口访问到服务，这就是Ingress Routing Mesh。

426c1cdb465904e99211f37546b92c7f196.jpg

下一节详细介绍Ingress网络。

 

转载于:https://my.oschina.net/duanvincent/blog/3071202

chikoucha6215
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Dokcer Swarm 集群容器无法跨节点访问端口问题
blacksiders的博客
03-17 1468
假设一台manager节点和一台worker节点，各自包含一个服务容器监听tcp 9999，通过overlay网络互联，在worker节点上的服务容器无法访问manager上的服务容器的tcp 9999端口，但是可以ping通。显示udp报文异常：bad udp cksum 0x174d -> 0x4773，原因是linux默认开启了内核计算cksum和网卡计算cksum，此处一般为网卡计算cksum错误，需要关闭网卡计算的功能。
Docker笔记-10 Swarm mode
07-15 741
Docker Swarm mode 简单讲解
iptable开启转发功能（接docker warm部署pxc集群 本地有无问题服务器部署出现网路不通）
方方园园的博客
02-12 225
https://blog.csdn.net/freflying1119/article/details/100127411
快速上手 Swarm mode搭建集群
weixin_33755649的博客
12-11 119
2019独角兽企业重金招聘Python工程师标准>>> ...
docker Swarm多态主机实现网络互通
最新发布
p715306030的博客
07-08 401
准备好三台安装好docker的主机、虚拟机或者云服务器均可，并且这些主机在同一局域网内部。
docker-ingress-routing-daemon:Docker swarm守护程序，可修改入口网格路由以将真实的客户端IP暴露给服务容器
05-07
据我们所知，在编写docker-ingress-routing-daemon时，这是从docker服务启动的容器内访问客户端IP的最轻便的方法。 功能摘要： 支持为所有已发布服务或仅针对指定TCP或UDP端口上的指定服务使用传入流量上的路由...
ansible-dockerswarm：使用“ Swarm Mode”和Ansible的Docker引擎集群
01-31
该角色支持Docker Engine的“ Swarm Mode”（ ）创建Docker节点集群。要求Ansible 2.7或更高版本的安装。 该角色利用了Ansible json_filter ，后者需要将jmespath安装在Ansible机器上。 有关该角色所需的jmespath...
docker-swarm-mode-getting-started：我的Pluralsight课程的存储库Docker Swarm模式入门
02-06
docker-swarm-mode-getting-started：我的Pluralsight课程的存储库Docker Swarm模式入门
terraform-digitalocean-docker-swarm-mode：用于在DigitalOcean上预配Docker Swarm模式集群的Terraform模块
02-04
terraform-digitalocean-docker-swarm-mode：用于在DigitalOcean上预配Docker Swarm模式集群的Terraform模块
详解基于docker-swarm搭建持续集成集群服务
01-10
为了能在本机（macOS)模拟集群环境，使用了vb和docker-machine。整体持续集成的几个机器设施如下： 1、服务节点：三个manager节点，一个worker节点。manager需要占用更多的资源，manager配置尽量高一些。swarm的...
DockerSwarm里集群服务间通信
weixin_40364776的博客
02-21 2036
Routing MeshInternalIngress Routing Mesh 是集群服务之间的通讯技术主要包括2方面Internal和Ingress Internal Container 和Container 之间的访问通过overlay网络，而service和service之间的通讯是通过VIP（虚拟IP）实现的。 主要意义是Internal Load Balancing 实现 下面是对I...
Docker Swarm实现跨宿主机容器间访问
水岸梦城 技术博客
05-27 2829
使用Docker Swarm实现跨宿主机容器间访问 背景： 在SerA服务器，运行了一个任务调度系统xxl容器ConA。 在SerB服务器，运行了一个SpringBoot服务ConB，注册到任务调度系统中。 在任务调度系统中，看到的调度器节点IP是SerB服务器分配给ConB容器的IP地址。 导致任务调度系统调度失败，提示ConB地址链接不上。 分析下来，是由于ConA和ConB是跨宿主机的容器，无法通信。 网上看到了很多方案，包括Overlay网络、OpenvSwitch、consul方案等，最终
解决多个Docker stack/swarm/compose集群之间网络无法访问的解决方案，Docker集群间通讯访问
懒懒的树懒熊
01-05 3345
1.先创建network XXXXX表示网络名称 此步可以不创建网络，使用现有网络 docker network create --driver=overlay --attachable XXXXX 2.修改docker-stack.yml文件 在docker-stack.yml里面增加上一步创建的网络，然后添加external配置，external表示外部网络 core-infra可以改为现有的任意网络，使用docker network ls查看现有网络 networks: core-infra:
docker的优势
weixin_46941625的博客
08-05 790
Docker 优势： 1、交付物标准化 Docker的标准化交付物称为"镜像"，它包含了应用程序及其所依赖的运行环境，大大简化了应用交付的模式。 2、应用隔离 Docker可以隔离不同应用程序之间的相互影响，但是比虚拟机开销更小。总之，容器技术部署速度快，开发、测试更敏捷；提高系统利用率，降低资源成本. 3、一次构建，多次交付 类似于集装箱的"一次装箱，多次运输"，Docker镜像可以做到"一次构建，多次交付"。 Docker的度量： Docker是利用容器来实现的一种轻量级的虚拟技术，从而在保证
从零开始学习docker（十五）Swarm mode 介绍
chikoucha6215的博客
07-05 177
一般情况下，我们都在一台机器下部署容器，但实际情况下，应用如果只在一台机器上无法满足我们的需求，包含的容器比较多。因此在生产环境下部署我们的应用就会涉及到非常多的容器，这样就会给我们带来一系列的问题： 怎么去管理这么多的容器？ 怎么能方便的横向扩展？ 如果容器down了，怎么能...
Docker19版部署及基本操作
热门推荐
LS19990712的博客
12-24 8万+
⭐部署19版docker⭐ 安装依赖包 yum install -y yum-utils device-mapper-persistent-data lvm2 设置阿里云镜像源 yum-config-manager --add-repo https://mirrors.a...
swarm mode集群搭建及简单概念
一个真实、有温度的无名小卒
08-27 1069
1.环境搭建 准备三台虚拟机，当然有实体机更好，我这里是： 192.168.1.101 ubuntu01 192.168.1.102 ubuntu02 192.168.1.103 ubuntu03 分别安装docker 在101机器上执行 docker swarm init --advertise-addr 192.168.1.101 该命令执行后会弹出加入该管理节点的命令...
docker笔记
zjq852533445的博客
05-09 1438
docker入门： 1、首先是安装docker desktop，下载链接 2、安装完成之后运行hello-world; 在网易蜂巢hub，找到helloworld镜像 复制后在powershell里面运行，镜像拉取下来后，使用docker images命令找到本地镜像。 4、使用docker run 镜像名称运行镜像。当然docker run 常会带三个参数，...
【Core】.NET Core 部署（ Docker + CentOS）
weixin_30527423的博客
08-14 492
CentOS下 Docker安装 使用脚本安装 Docker （1）安装docker sudo yuminstalldocker （2）启动docker systemctl start docker.service （3）配置开机启动 systemctlenabledocker.service （4）查看docker版本信息 docker version （5...
docker-compose在swarm集群部署服务
05-30
在Docker Swarm集群中使用Docker Compose可以快速地构建和部署服务。 以下是在Docker Swarm集群中使用Docker Compose部署服务的一些步骤： 1. 编写Docker Compose文件：在本地编写一个Docker Compose文件，描述...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值