微服务运维实践：隔离数据库运行

可以通过不暴露其端口来隔离数据库服务。这可以通过service create命令轻松完成：

可以通过检查服务来确认端口确实没有暴露：

输出如下：

正如你所看到的，输出里面没有提及任何端口。我们的go-demo-db服务完全隔离，任何人都无法访问。我们希望该服务与其他服务隔离开来，但go-demo除外。可以通过使用Docker Swarm networking来实现这一点。

让我们删除创建的服务并重新开始：

这次应该创建一个网络并确保go-demo-db服务已经连接到它：

我们创建了一个名为go-demo的overlay网络，然后是go-demo-db服务。这次我们使用--network参数将服务连接到网络上。从现在开始，所有连接到go-demo网络的服务都可以互相访问。

让我们检查服务并确认它连接到了网络上：

service inspect命令的输出如下：

正如你所看到的，这一次有一个Networks条目，它的值被设置为我们之前创建的go-demo网络的ID。

让我们确认网络确实有效。为了证明它，下面将创建一个名为util的全局服务：

就像go-demo-db一样，util服务也连上了go-demo网络。

这里用到了一个新参数--mode，当设置为global时，服务将在集群的所有节点上运行。当我们想要建立跨越整个集群的基础设施服务时，这是一个非常有用的功能。

可以通过执行service ps命令来确认它到处都在运行：

输出如下（为简洁起见，删除了IDs和ERROR PORTS列）：

如你所见，util服务运行在所有的三个节点上。

我们正在运行alpine镜像（一个微小的Linux发行版），并让它休眠了很长时间。否则，由于没有进程正在运行，服务将会停止，然后Swarm会重新启动它，它会再次停止，一直这么下去。

util服务的目的是展示我们正在探索的一些概念。我们用exec进入其中并确认networking确实生效了。

要进入util容器，需要找出运行在node-1（本地Docker指向的节点）上的实例ID：

ps命令的静默模式列出了所有进程，以便仅返回IDs（-q），并将结果限制到服务名称util：

结果被存储为环境变量ID。

我们将安装一个名为drill的工具，它是一个用于从DNS获取各种信息的工具，并且很快就会派上用场：

Alpine Linux使用称为apk的包管理，我们利用其添加drill工具。

现在可以看到网络是否真的有效。由于go-demo-db和util服务都属于同一个网络，因此它们应该能够使用DNS名称相互通信。任何时候将服务连接到网络上，都会创建一个新的虚拟IP以及与该服务名称匹配的DNS。(www.xing528.com)

让我们试试看如下：

我们进入到util服务的一个实例并“试验”DNS go-demo-db。输出如下：

响应代码为NOERROR，ANSWER为1表示DNS go-demo-db响应正确，它是可以访问的。

我们也可以观察到go-demo-db DNS与IP 10.0.0.2相关联。连接到网络的每个服务都会得到其IP。请注意，我说的是服务，而不是实例。这是一个巨大的区别，我们将在稍后探讨。目前，重要的是要知道属于同一网络的所有服务都可以通过服务名称访问，如图3-2所示。

图3-2　连接到go-demo网络的go-demo-db服务

让我们回头来看看这些需求。