docker - 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 运行它并通过端口 993 上的 IMAP 连接到它，它工作正常。集成测试也运行顺利

但是，如果集成测试由 gitlab CI 执行，则失败。我能得到的唯一异常(exception)是连接被拒绝。

会不会是服务的端口没有正确暴露？ CI 服务器如何确定它必须为所述服务打开的端口？

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

抱歉问了很多问题，我只是绝望地迷路了..

Answer 1

来自 official documentation :

The services keyword defines just another Docker image that is run during your job and is linked to the Docker image that the image keyword defines. This allows you to access the service image during build time.

没有 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 管道中执行类似操作，它将向运行该作业的系统公开端口。这当然不是你想要的。

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