Gitlab CI服务端口如何暴露？

Question

我有一个.gitlab-ci.yml文件：

integration_test:
  services:
    - name: registry.gitlab.com/group/project/testmailserver:1.1
      alias: "mail.email"
  stage: test
  script:
    - ./gradlew -g /cache/.gradle --stacktrace --info integrationTest

该服务是基于此的完整堆栈电子邮件服务器：tvial/docker-mailserver:latest。使用docker-compose配置在本地可以运行它并连接到它。

version: '2'

services:
  mail:
    image: registry.gitlab.com/group/project/testmailserver:1.1
    hostname: mail
    domainname: localhost
    ports:
      - "25:25"
      - "143:143"
      - "587:587"
      - "993:993"
    environment:
      - ONE_DIR=1
      - DMS_DEBUG=0
      - MAIL_USER=invoicereader
      - MAIL_PASS=invoicereader
    cap_add:
      - NET_ADMIN

如果我使用docker-compose up运行它，并通过IMAP在端口993上连接到它，则可以正常工作。集成测试也顺利进行

但是，如果集成测试是由gitlab CI执行的，它将失败。我唯一能得到的例外是拒绝连接。

可能是服务的端口未正确公开吗？ CI服务器如何确定必须为该服务打开的端口？

使用CI运行时可能会出现什么问题？我该如何进行不同的测试？

很抱歉，我有很多疑问，我只是无可救药地迷失了。。

Answer 1

从official documentation：

services关键字仅定义在您的工作期间运行的另一个Docker映像，并链接到image关键字定义的Docker映像。这使您可以在构建期间访问服务映像。

image文件中没有.gitlab-ci.yml关键字。因此，作业integration_test的运行位置实际上是无法预测的。

如果您的工作在Docker容器中运行，则此容器将链接到您服务的容器。 Links是Docker的传统功能，但与通过单独网络连接的两个容器非常相似。这与一个组成文件中相互通信的多个服务非常相似。

作业容器中执行的所有内容都可以通过其名称或别名（mail.email）访问您的服务。看一下Dockerfile of you mail server，以查看服务侦听的端口：

EXPOSE 25 587 143 465 993 110 995 4190

这里无需手动公开任何端口。撰写文件中的ports关键字将容器的端口公开给主机系统。如果您在CI管道中执行类似的操作，它将把端口暴露给运行作业的系统。这当然不是您想要的。

简而言之：在CI作业中使用mail.email:993之类的东西通过IMAP连接到您的邮件服务器。