在Gitlab CI中配置Redis主从架构跨服务通信

如何解决在Gitlab CI中配置Redis主从架构跨服务通信

我正在尝试仅使用以下两种服务来设置简单的Redis配置：主服务器和从服务器。

这是我的.gitlab-ci.yml的一部分，具有主从设置：

integration:
  extends: .test
  variables:
    FF_NETWORK_PER_BUILD: "true"
  services:
    - name: redis:latest
      alias: "redis-master"
      command: [ "redis-server","--port","6379" ]
    - name: redis:latest
      alias: "redis-slave"
      command: [ "redis-server","--slaveof","slave-master","6379" ]
script:
    - nc -z -v -w30 -n redis-master 6379 // fails to resolve hostname redis-master ...
    // wait for readiness of both databases
    // run tests

出于隐私原因将其简化

由于我需要这些服务之间的通信，因此我知道我需要使用称为FF_NETWORK_PER_BUILD的功能标志，

每次构建都创建并使用新的用户定义的Docker brdge网络。

上述文档还指出

构建作业容器和服务容器都将是 能够解析彼此的主机名（和别名）。

在 redis-master 和 redis-slave 之间进行连接时，一切正常，并且slave与master正确同步，但是当我尝试使用它们与他们连接时脚本部分中的别名会导致错误：

Could not resolve hostname "redis-master": Name or service not known. QUITTING.

所以问题是为什么我不能在脚本部分使用别名？如果不可能的话，如何获得它们的IP，以便在它们准备好连接时可以ping通它们？

旁注：

当我不使用 FF_NETWORK_PER_BUILD 标志别名时，更有趣的是在脚本部分中可以正常工作（但同时 redis-slave 无法与 redis-master ，所以这就是我不能忽略此标志的原因。

解决方法

在您的nc命令中，您使用的是-n选项，每个人都执行以下操作

-n不要在任何指定的地址，主机名或端口上进行任何DNS或服务查找。

因此，实际上您是在关闭dns搜索，这是一个小测试来说明：

$ nc -z google.com 80; echo $?
0
$ nc -n -z google.com 80; echo $?
nc: getaddrinfo for host "google.com" port 80: Name or service not known
1

删除-n应该可以解决您的管道问题