AWS服务建设之路-Docker集群

最近的项目处于种种原因要放到亚马逊上面，也正好体验一下世界最大云计算平台的服务。于是又开始了漫长的爬坑路。不得不说AWS的管理交互台设计充满了工业气息，新手很难上手，但熟练工会觉得很直观。

简单来说分4步：

ECR是私有镜像仓库，先把自己的镜像上传上来，这一步的坑就在于要上传镜像不能直接 docker login 需要

ECS有一个很重要的概念，任务定义。这个概念类似于 k8s 的 pod。任务定义抽象出了任务这个概念，一项任务可以包含多个docker镜像及对应的参数/环境配置，并且拥有CPU，内存限额。

任务定义拥有版本号，只能创建新版本不能修改以前版本。

而在集群中的调度则是以任务定义为对象。

所以我们为我们每一个服务创建了1个任务定义，一个任务定义包含1个镜像。

这里有3种网络模式供选择：

大部分情况我们都使用桥接模式，少部分情况使用 awsvpc 。主机模式则尽量不要使用，不利于编排。 awsvpc 的具体使用场景会在下文服务发现章节介绍。

动态端口映射 技术，是指将容器在宿主机上的外部端口随机映射，只在桥接模式下有效。

勾上日志配置，ECS就会自动把镜像的标准输出定向到 CloudWatch，就可以去那里查看镜像日志了，当然专业的日志系统还是得ELK。

ECS有2种集群，Fargate 与 EC2 Linux。

Fargate是很酷炫的架构，特别是在资源占用量不稳定，时间不确定的情况下很合适。而且全部使用awsvpc网络模式，所有的服务都可以拥有独立IP，纯正的无服务器架构。只有一个缺点，贵（同样资源量是EC2的3倍价格

建议创建空集群，再自行添加服务器，不然容易触发一些 keng

上面说了任务定义，那么任务这个概念也很简单，被运行的任务定义。

一个任务可能包含多个容器，这个任务可能是在有限时间内执行完毕就停止的，比如一次性脚本，也可能是无限运行的，比如nginx服务器。

服务这个概念比较复杂，一个服务会管理一个任务定义在运行时的方方面面

服务没有停止功能，只能修改任务数为0。

服务删除后，需要手动停止已经运行的任务。

AWS提供基于Router53(DNS服务)的服务发现，其实很难用，awsvpc模式的很方便，桥接模式下特难用。

在awsvpc模式中 ，因为每个任务都有自己的IP，所以端口可以直接固定，不会存在冲突，配合基于Router53的服务发现可以直接完成完美的服务发现--无论如何更新重启服务，总能通过固定域名访问到服务。但因为一台服务器只能绑定3张网卡，所以只能启动3个awsvpc模式容器。

在桥接模式中 ，每个任务都使用宿主机的ip，以及随机分配的端口，所以服务发现需要带上端口，不然也不能正常发现。AWS提供SRV类型的DNS记录用作服务发现，本身是没有问题，但SRV并不是被广泛接受的记录类型，浏览器与网络库均不能解析SRV记录，所以要访问服务还需要定制DNS解析。

所以我们最终选择使用Eureka作为服务发现服务，使用awsvpc作为补充的服务发现服务，比如将Eureka本身及xxl-job等使用awsvpc部署。

在选用了Eureka之后，又遇到了问题。因为使用了动态端口映射，所以向Eureka注册的端口不是Spring的监听端口，并且容器内部无法知道宿主机的ip与端口。

这里通过多种方式配合破局：

不过要注意，启用元数据服务，需要修改ECS代理配置，而这个配置是在集群创建时就写入服务器的，所以要修改ECS代理配置，必须要先修改自动伸缩组的初始化脚本，再删除伸缩组内所有服务器，再重新添加服务器。

这样就可以在Eureka中心正确展示服务信息了。

查看已经存在的端口映射情况，没配置端口映射情况下没有输出内容

注意此处需要使用Windows PowerShell，用管理员权限打开。

将宿主机任意端口映射到虚拟机22端口

使用SSH工具直接连接宿主机IP和宿主机映射到虚拟机的端口。输入虚拟机密码登录。

Tips：问题还是通过windows配置端口映射的方式进行解决。开发平时可能接触不到，记录一下，留给需要的人。

模板文件是使用 Compose 的核心，涉及到的指令关键字也比较多。大部分指令跟 docker run 相关参数的含义都是类似的。

默认的模板文件名称为 docker-composeyml ，格式为 YAML 格式。

可以将 Compose 文件命名为任何所需内容，以使其在逻辑上具有意义； docker-composeyml 仅为标准名称。我们可以简单地将此文件命名为 docker-stackyml 或更特定于项目的内容

注意每个服务都必须通过 image 指令指定镜像或 build 指令（需要 Dockerfile ）等来自动构建生成镜像。

在 docker stack 下， build 指令不能使用，只能用 image

如果使用 build 指令，在 Dockerfile 中设置的选项(例如： CMD , EXPOSE , VOLUME , ENV 等) 将会自动被获取，无需在 docker-composeyml 中再次设置。

请注意，将 Compose 文件设置为 version:"3" 。本质上，这会使其兼容 swarm mode 。我们可以使用 deploy key （仅可用于 Compose 文件格式版本 3x 及更高版本）及其子选项对每项服务（例如，web）进行负载均衡和优化性能。我们可以使用 docker stack deploy 命令（仅在 Compose 文件版本 3x 及更高版本上受支持）运行此文件。您可以使用 docker-compose up 运行具有 非 swarm 配置的版本 3 文件。

指定 Dockerfile 所在文件夹的路径（可以是绝对路径，或者相对 docker-composeyml 文件的路径）。 Compose 将会利用它自动构建这个镜像，然后使用这个镜像。

也可以使用 context 指令指定 Dockerfile 所在文件夹的路径。

使用 dockerfile 指令指定 Dockerfile 文件名。

使用 arg 指令指定构建镜像时的变量。

使用 cache_from 指定构建镜像的缓存

指定容器的内核能力（capacity）分配。

让容器拥有所有能力可以指定为：

去掉 NET_ADMIN 能力可以指定为：

覆盖容器启动后默认执行的命令。

仅用于 Swarm mode

指定父 cgroup 组，意味着将继承该组的资源限制。

例如，创建了一个 cgroup 组名称为 cgroups_1。

指定容器名称。默认将会使用 项目名称_服务名称_序号 这样的格式。

仅用于 Swarm mode

指定设备映射关系。

解决容器的依赖、启动先后的问题。以下例子中会先启动 redis``db 再启动 web

自定义 DNS 服务器。可以是一个值，也可以是一个列表。

配置 DNS 搜索域。可以是一个值，也可以是一个列表。

挂载一个 tmpfs 文件系统到容器。

从文件中获取环境变量，可以为单独的文件路径或列表。

如果通过 docker-compose -f FILE 方式来指定 Compose 模板文件，则 env_file 中变量的路径会基于模板文件路径。

如果有变量名称与 environment 指令冲突，则按照惯例，以后者为准。

环境变量文件中每一行必须符合格式，支持 # 开头的注释行。

设置环境变量。你可以使用数组或字典两种格式。

只给定名称的变量会自动获取运行 Compose 主机上对应变量的值，可以用来防止泄露不必要的数据。

如果变量名称或者值中用到 true|false ， yes|no 等表达 布尔 含义的词汇，最好放到引号里，避免 YAML 自动解析某些内容为对应的布尔语义。这些特定词汇，包括

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

暴露端口，但不映射到宿主机，只被连接的服务访问。

仅可以指定内部端口为参数

类似 Docker 中的 --add-host 参数，指定额外的 host 名称映射信息。

会在启动后的服务容器中 /etc/hosts 文件中添加如下两条条目。

通过命令检查容器是否健康运行。

指定为 镜像名称或镜像 ID 。如果镜像在本地不存在， Compose 将会尝试拉取这个镜像。

为容器添加 Docker 元数据（metadata）信息。例如可以为容器添加辅助说明信息。

配置日志选项。

目前支持三种日志驱动类型:

options 配置日志驱动的相关参数:

设置网络模式。使用和 docker run 的 --network 参数一样的值。

配置容器连接的网络。

跟主机系统共享进程命名空间。打开该选项的容器之间，以及容器和宿主机系统之间可以通过 进程ID 来相互访问和 *** 作。

暴露端口信息。

使用宿主端口：容器端口 (HOST:CONTAINER) 格式，或者仅仅指定容器的端口（宿主将会随机选择端口）都可以。

存储敏感数据，例如 mysql 服务密码。

指定容器模板标签（label）机制的默认属性（用户、角色、类型、级别等）。例如配置标签的用户名和角色名。

设置另一个信号来停止容器。在默认情况下使用的是 SIGTERM 停止容器。

配置容器内核参数。

指定容器的 ulimits 限制值。

例如，指定最大进程数为 65535，指定文件句柄数为 20000（软限制，应用可以随时修改，不能超过硬限制） 和 40000（系统硬限制，只能 root 用户提高）。

数据卷所挂载路径设置。可以设置宿主机路径 （HOST:CONTAINER） 或加上访问模式 （HOST:CONTAINER:ro） 。

该指令中路径支持相对路径。

此外，还有包括 domainname , entrypoint , hostname , ipc , mac_address , privileged , read_only , shm_size , restart , stdin_open , tty , user , working_dir 等指令，基本跟 docker run 中对应参数的功能一致。

指定服务容器启动后执行的入口文件。

指定容器中运行应用的用户名。

指定容器中工作目录。

指定容器中搜索域名、主机名、mac 地址等。

允许容器中运行一些特权命令。

指定容器退出后的重启策略为始终重启。该命令对保持服务始终运行十分有效，在生产环境中推荐配置为 always 或者 unless-stopped 。

以只读模式挂载容器的 root 文件系统，意味着不能对容器内容进行修改。

打开标准输入，可以接受外部输入。

模拟一个伪终端。

Compose 模板文件支持动态读取主机的系统环境变量和当前目录下的 env 文件中的变量。

例如，下面的 Compose 文件将从运行它的环境中读取变量 ${MONGO_VERSION} 的值，并写入执行的指令中。

如果执行 MONGO_VERSION=32 docker-compose up 则会启动一个 mongo:32 镜像的容器；如果执行 MONGO_VERSION=28 docker-compose up 则会启动一个 mongo:28 镜像的容器。

若当前目录存在 env 文件，执行 docker-compose 命令时将从该文件中读取变量。

在当前目录新建 env 文件并写入以下内容。

执行 docker-compose up 则会启动一个 mongo:36 镜像的容器。

踩坑完毕，回到主线。

前面关于port的理解存在偏差，需要用实验来确认port配置的含义。

k8s官方文档对于对于这些配置项的解释还是没有很完善。下面是在其他博文中找到的解释。

已知：

从k8s集群内部的宿主机（物理机、虚拟机）可以直接访问pod的服务地址 ip:80

未知（需要测试）：

1、同一局域网内，但没有加入k8s集群的其他服务器能否访问pod的服务地址 ip:80---无法访问

2、能否跳过pod直接访问容器的服务地址 ip:80---没查到ip

首先要知道容器的IP地址

可以看到上面的命令查出的结果是 - 无法看出ip，尝试进入容器查看

然后我就没辙了，不过根据linux系统的精神，所有内容都是文件，但是我google了好久也没找到ip地址到底存在哪一个文件中。然后我就怀疑是不是一定要容器开放端口，ip地址才可以用docker inspect查询，起了一个不开端口的容器，结果也是有ip的。后来问了一个底层开发的朋友，据说ip是不写文件的。

那只能先认为通过k8s启动的容器其实是没有容器ip的。

从侧面看，也很有可能k8s启动的容器确实没有ip

3、访问pod所在的主机的80端口能否返回相同的响应---无法访问

从以上的信息来看，这个port配置应该和docker中暴露端口的意思是一样的，例如下面的例子

来做一下实验：

在我们之前的pod配置文件上增加配置，如下

结果和我们之前的猜测保持一致，增加ports的配置之后，访问宿主机的ip:80也可以访问到pod的内容了。

我这里pod ip 是 101913067，宿主机是 101001237。curl 101913067 和 curl 101001237 得到的结果是一样的。正当我想再仔细看看的时候，服务器又挂了，wc，只能明天找网管重启了。

---第二天

昨天，我还想看看

1、关了这个pod之后是否就不能访问了

启动了2个pod如下，mynginx1没有配置ports，mynginx2配置了ports。

当我关了pod-mynginx2之后访问宿主机101002167应该就不能通了，结果居然是---能访问到！

大吃一惊！结果ip弄错了，宿主机不是101002167，而是101001237，犯了个低级错误。

结果如下：这回和预期的结果终于一样了。

2、宿主机上是不是本身就开启了nginx，所以恰巧就能访问

确认宿主机上没有开启nginx

3、宿主机上的端口开放情况

使用netstat查看宿主机的端口开放，居然没有发现80端口开着，好奇怪。

那如果在101001237宿主机上启动一个nginx端口开在80，结果会是什么样子呢。

我居然启动了，没有端口已被占用的报错。现在把宿主机上的nginx的index页面的内容改一下，看访问101001237:80时，到底访问的是哪一个nginx。

分别从集群内部3台服务器和集群外部1台服务器的机器取访问101001237:80，访问到的都是pod中的nginx。

会不会跟启动顺序有关，因为现在的情况是先启动了pod-nignx，后启动 宿主机-nginx，那现在将pod-nginx关闭，访问101001237:80，看是啥。

集群内部3台服务器和集群外部1台服务器访问101001237:80，结果一致，都是宿主机-nginx。

再启动pod-nginx，查看结果。

访问结果又变回pod-nginx了，4台服务器结果一致。

再去看一下宿主机-nginx的日志，有没有报错信息-----------没有错误日志

现在基本可以得出结论了：当pod和宿主机同时使用某一个端口时，不会因为冲突而报错，但是pod会优先占用端口，而与启动顺序无关。

至于为什么会这样，就不去深究了，毕竟精力有限，作为运维实施，了解到这样子的程度应该够用了。

关于桥接网络：

]Host的物理网卡和Guest的网卡在VMnet0交换机上通过虚拟网桥进行桥接，这也就是说，我的物理网卡和Guest的虚拟网卡（注：这个虚拟网卡不等于VMwareNetworkAdapterVMnet1或者VMwareNetworkAdapterVMnet8）处于同等地位，此时的Guest就好像我的Host所在的一个网段上的另外一台机器。我的Host的物理网卡配置如下：IP地址为手工指定方式，网关为19216801，那么我的Guest就应该和我的Host处于同一个网段，它的配置可为：

Ethernetadapter本地连接:

Connection-specificDNSSuffix:

Description:BroadcomNetXtreme57xxGigabitController

PhysicalAddress:00-1A-A0-A9-DC-1B

DhcpEnabled:No

IPAddress:19216802

SubnetMask:2552552550

DefaultGateway:19216801

IP地址为手工指定方式，网关为19216801，那么我的Guest就应该和我的Host处于同一个网段，它的配置为：

EthernetadapterBridged:

Connection-specificDNSSuffix:

Description:BroadcomNetXtreme57xxGigabitController

PhysicalAddress:00-1A-A0-A9-DC-1B

DhcpEnabled:No

IPAddress:192168010

SubnetMask:2552552550

DefaultGateway:19216801

同样，IP地址也为手工指定方式，网关也为19216801，这样的话，IP地址为19216802的Host和IP地址为

192168010的Guest就可以互通了：

EthernetadapterBridged:

Connection-specificDNSSuffix:

Description:BroadcomNetXtreme57xxGigabitController

PhysicalAddress:00-1A-A0-A9-DC-1B

DhcpEnabled:No

IPAddress:192168010

SubnetMask:2552552550

DefaultGateway:19216801

Pinging19216810010with32bytesofdata:

Replyfrom19216810010:bytes=32timeReplyfrom19216810010:bytes=32timeReplyfrom19216810010:bytes=32timeReplyfrom19216810010:bytes=32time

Pingstatisticsfor19216810010:

Packets:Sent=4,Received=4,Lost=0(0%loss),

Approximateroundtriptimesinmilli-seconds:

Minimum=0ms,Maximum=0ms,Average=0ms

当然，Guest所配置的IP地址一定要在1921680网段没有被占用，而且我的网络管理员允许我来使用这个IP地址。如果在1921680网段，存在DHCP服务器，那么Host和Guest都可以把IP地址获取方式设置为DHCP方式。

关于NAT网络

在NAT网络中，会使用到VMnet8虚拟交换机，Host上的VMwareNetworkAdapterVMnet8虚拟网卡被连接到VMnet8交换机上，来与Guest进行通信，但是VMwareNetworkAdapterVMnet8虚拟网卡仅仅是用于和VMnet8网段通信用的，它并不为VMnet8网段提供路由功能，处于虚拟NAT网络下的Guest是使用虚拟的NAT服务器来连接到Internet的。VMware功能非常强大，在NAT网络下，我们甚至可使用PortForwarding功能，来把Host的某一个TCP或者UDP端口映射到Guest上！我的VMwareNetworkAdapterVMnet8虚拟网卡的IP地址配置如下：Ethernetadapter本地连接:

EthernetadapterVMwareNetworkAdapterVMnet8:

Connection-specificDNSSuffix:

Description:VMwareVirtualEthernetAdapterforVMnet8

PhysicalAddress:00-50-56-C0-00-08

DhcpEnabled:No

IPAddress:1921681531

SubnetMask:2552552550

DefaultGateway:

IP地址是手工填写的，但却不是由我来指定的，而是VMware在安装的时候自动随机指定的一个IP地址（注意，不要修改VMwareNetworkAdapterVMnet8虚拟网卡所在的网络ID，这样的话会造成Host和Guest无法通信）。那么，我的NAT网络的虚拟机的IP地址也为1921681530这个网段，其IP地址配置为：

WindowsIPConfiguration

HostName:Lineage

PrimaryDnsSuffix:

NodeType:Unknown

IPRoutingEnabled:no

WINSProxyEnabled:No

EthernetadapterNAT:

Connection-specificDNSSuffix:

Description:VMwarePCIEthernetAdapter

PhysicalAddress:00-50-56-C0-00-08

DhcpEnabled:Yes

AutoconfigurerationEnanble:Yes

IPAddress:19216815310

SubnetMask:2552552550

DefaultGateway:1921681532

DHCPServer:192168153254

可以看到，它的IP地址分是由DHCP服务器分配的的，DHCP服务器的地址为19216885254，那为什么会有DHCP服务器存在呢？

这是因为VMware安装之后，会有一台虚拟的DHCP服务器为虚拟机来分配IP地址，这个DHCP服务器，你可以ping通它，但是无法进行访问，因为实际上它就是一个系统服务而已，在开始——>运行中输入servicesmsc，就会看到这个服务

此时可以看到，Guest的网卡和Host上的VMwareNetworkAdapterVMnet8虚拟网卡拥有相同的网络ID，这样的话，在Guest中，ping通Host就没有问题了：

Pinging1921681531with32bytesofdata:

Replyfrom1921681531:bytes=32timeReplyfrom1921681531:bytes=32timeReplyfrom1921681531:bytes=32timeReplyfrom1921681531:bytes=32time

Pingstatisticsfor1921681531:

Packets:Sent=4,Received=4,Lost=0(0%loss),

Approximateroundtriptimesinmilli-seconds:

Minimum=0ms,Maximum=0ms,Average=0ms

有一点需要说明的是，在NAT方式的网络中，Guest的Gateway都指向了192168X2，在本例中，X=153，也就是那个虚拟的NAT服务器的地址，这个服务器是一台虚拟的NAT服务器，可以ping通它，但是却无法访问到这台虚拟机，因为这同样也是一个系统服务：这时候，我的Guest和Host就可以实现互访了，并且如果我的Host此时已经连接到了Internet，那么我的Guest也就可以连上Internet了。那么Host上的VMwareNetworkAdapterVMnet8虚拟网卡在这里扮演了一个什么角色呢？它仅仅是为Host和NAT虚拟网络提供了一个通信接口，所以，即便在Host中Disable掉这块虚拟网卡，Guest仍然是可以上网的，只是Host无法再访问VMnet8网段，也即是无法访问Guest而已。

关于Host-Only网络

在Host-Only网络中，Host-Only网络被用来设计成一个与外界隔绝的（isolated）网络，其实Host-Only网络和NAT网络非常相似，唯一不同的地方就是在Host-Only网络中，没有用到NAT服务，没有服务器为VMnet1网络做路由，它当然就没有办法访问Internet啦，可是如果此时我的Host要和Guest通信怎么办呢？当然就要用到VMwareNetworkAdapterVMnet1这块虚拟网卡了。

如下图，这是我的Host上的VMwareNetworkAdapterVMnet1虚拟网卡的配置，同样，VMware也为我自动随机分配好了它的IP：

EthernetadapterVMwareNetworkAdapterVMnet1:

Connection-specificDNSSuffix:

Description:VMwareVirtualEthernetAdapterforVMnet1

PhysicalAddress:00-50-56-C0-00-01

DhcpEnabled:No

IPAddress:1921682011

SubnetMask:2552552550

DefaultGateway:

那么如果我把Guest的网络设置成了Host-Only的话，把它的IP获取方式设置为DHCP，它会到虚拟的DHCP服务器上拿到IP，这个DHCP服务器仍然是一个虚拟的DHCP服务器（仅仅是一个系统服务而已），而且在下图中，可以看到，这个DHCP服务器的IP地址仍然是192168X254，这里X=201，因为要和我的VMnet1的网络ID相同。所以，Guest所获得的IP和我的Host的VMwareNetworkAdapterVMnet1虚拟网卡的IP使用同一个网络ID：

WindowsIPConfiguration

HostName:Lineage

PrimaryDnsSuffix:

NodeType:Unknown

IPRoutingEnabled:no

WINSProxyEnabled:No

EthernetadapterHost-Only:

Connection-specificDNSSuffix:

Description:VMwarePCIEthernetAdapter

PhysicalAddress:00-50-58-C0-50-0d

DhcpEnabled:Yes

AutoconfigurerationEnanble:Yes

IPAddress:19216820110

SubnetMask:2552552550

DefaultGateway:

DHCPServer:192168153254

可以看到，在Host-Only网络下，Guest的DefaultGateway被设置为NULL，这是由于没有默认路由器为它到外部网络提供路由的缘故，也即是上边说到的Host-Only网络没有NAT服务器！如果使用routeadd命令加上某个地址做为它的路由器，它仍然不能访问Internet（实际上也没有地址可加）。这样，我的Guest虽然没有办法访问Internet，但是仍然可以和我的Host进行通信，这正是因为我的Host上的VMwareNetworkAdapterVMnet1虚拟网卡起到了作用，它负责和VMnet1网络相连，为我访问Host-Only网络下的Guest提供了通信接口。下图显示了在Host-Only网络中的Guest与我的Host的通信情况：

Pinging1921682011with32bytesofdata:

Replyfrom1921682011:bytes=32timeReplyfrom1921682011:bytes=32timeReplyfrom1921682011:bytes=32timeReplyfrom1921682011:bytes=32time

Pingstatisticsfor1921682011:

Packets:Sent=4,Received=4,Lost=0(0%loss),

Approximateroundtriptimesinmilli-seconds:

Minimum=0ms,Maximum=0ms,Average=0ms

至于为何要把Host-Only网络设置为没有DefaultGateway的方式，这是VMware的设计使然，它就是让我们建立一个与外界隔离（isolated）的网络时而使用的。事实上，如果我足够BT，也可以在Host上来为VMwareNetworkAdapterVMnet1虚拟网卡来做路由。比如，我可以用Windows2000的RRAS来做，这样的话，处于Host-Only网络下的Guest就又可以上网了，它们只需要使用routeadd命令把自己的DefaultGateway指向Host上的VMwareNetworkAdapterVMnet1虚拟网卡即可，不过这样做不推荐，也没有必要

至此，VMware的3种网络，就应该可以理解可以看到，如果想要Guest上网，在3种网络模型中，

最为简单的方式就是NAT，因为它不需要任何的网卡设置，IP地址也可以从虚拟的DHCP服务器来获得，要做的仅仅就是把它的网络设置为NAT方式即可。

至于Bridged模式，则需要额外的IP地址，这有可能会实现不了，因为并不是每个ISP都那么大方。

如果是Host-Only，则又需要设置RRAS，没有几个人会愿意为了让虚拟机上网而换OS的，所以就用NAT最好了。

在这里要强调的一点是，如果设置了Host-Only网络，非要为VMnet1做路由，一定要用RRAS，而不要用WindowsXP或者2000的ICS，因为它会自动把内网的接口地址改为19216801。你在安装虚拟机的时候，VMware不会正好给你的VMwareNetworkAdapterVMnet1虚拟网卡分配为19216801的地址吧？这样的话会造成VMwareNetworkAdapterVMnet1虚拟网卡和VMnet1网段的网络ID不一致，自然，你的Guest就没有办法和Host通信了！

实际上经常还会遇到这样的情况：比如VMware为我分配的网络ID在将来会被我用到，或者嫌VMware为你分配的网络不好（比如它给你分了个1921681480的网络ID），那么可以到这里来修改：

单击VMware的“Host”菜单，选择“VirtualNetworkSettings”

选择“HostVirtualNetworkMapping”中，VMnet1所在的虚拟网络，单击后边的按钮，选择“Subnet”菜单，即可以调整你的网络ID。

以上就是关于AWS服务建设之路-Docker集群全部的内容，包括:AWS服务建设之路-Docker集群、WindowsServer端口映射到Linux虚拟机、docker-compose.yml说明和编写等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！