该Compose文件与我们之前使用的文件几乎相同。唯一的区别是添加了networks部分。
我们将不讨论整个定义的细节,而是关注networks。内部的第一个networks部分(在顶部)称为be。它设置为external并且是指网络backend。内部名称是我们将在服务内部使用的引用。如果网络是external网络,则意味着需要在Docker Compose外部手动创建网络。我们已经通过执行docker network create backend做到了这一点。最后,网络名称必须与我们通过命令指定的名称相同。
networks部分代表networks的一般定义。就其本身而言,除非在服务内部定义它,否则它没有任何用途。因此,我们在app服务中指定了be网络。稍后我们将探讨aliases。
我们将从启动目标app两个实例以及它们所依赖的db开始。
docker-compose up -d app docker-compose scale app=2
和以前一样,Docker Compose为docker-compose.yml文件中定义的所有容器创建了一个网络。但是,我们指定了应用程序目标也应该属于后端网络。结果,我们拥有属于两者的容器dns_app_1和dns_app_2 ,而books-ms-db仅位于dns_default网络内部。这本身并没有提供任何新内容。无论有没有后端网络,这三个容器都可以彼此“讲话”。
让我们看看如果我们运行一个新的容器会发生什么,但是这次使用--net参数指定它应该属于后端网络。
docker run -it --rm --net backend alpine ping -c 1 dns_app_1 docker run -it --rm --net backend alpine ping -c 1 books-ms-db
这两个命令的输出如下。
PING dns_app_1 (10.0.0.2): 56 data bytes ping: bad address 'books-ms-db'
由于dns_app_1属于同一网络,因此ping操作成功。另一方面,第二次ping操作失败,因为books-ms-db容器不属于外部网络后端 。
属于同一外部网络的所有容器都可以互相访