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执行，则会失败。我能得到的唯一例外是连接被拒绝。

服务端口是否未正确显示？ 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连接到您的邮件服务器。

Gitlab CI服务端口是如何暴露的？

1 个答案: