Gitlab CI 服务端口是如何暴露的? [英] How are Gitlab CI service ports exposed?

问题描述

我有一个 .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 配置，我可以运行它并连接到它.

The service is a full stack email server based on this: tvial/docker-mailserver:latest. Locally with my docker-compose config I'm able to run it and connect to it.

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 连接到它，它工作正常.集成测试也运行顺利

If I run it with docker-compose up and connect to it via IMAP on port 993 it works fine. Also the integration test runs smoothly

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

However, if the integration test is executed by gitlab CI, it fails. The only exception I could get is Connection refused.

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

Can it be that the ports of the service are not exposed properly? How does the CI server determine the ports it has to open to said service?

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

What might be the problem when running with CI? How can I test it differently?

抱歉问了这么多问题，我真是迷路了..

Sorry for the lot of questions, I'm just hopelessly lost..

推荐答案

来自 官方文档:

services 关键字仅定义另一个在您的作业期间运行的 Docker 映像，并链接到 image 关键字定义的 Docker 映像.这允许您在构建期间访问服务映像.

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.

您的 .gitlab-ci.yml 文件中没有 image 关键字.因此，您的作业 integration_test 在哪里运行实际上是不可预测的.

There is no image keyword in your .gitlab-ci.yml file. Therefore, it's actually unpredictable where your job integration_test runs.

如果您的作业在 Docker 容器中运行，则该容器将链接到您的服务容器.Links 是 Docker 的遗留功能，但它非常类似于两个通过以下方式连接的容器一个单独的网络.这与一个 compose 文件中的多个服务相互通信非常相似.

If your job runs inside a Docker container, this container is linked to the container of your service. Links are a legacy feature of Docker, but it's quite similar to two containers that are connected via a separate network. This is quite similar to multiple services in one compose file that communicate with each other.

在您的作业容器中执行的所有内容都可以通过其名称或别名 (mail.email) 访问您的服务.查看 您的邮件服务器的 Dockerfile 以查看哪些端口服务监听:

Everything that is executed in your job's container can access your service via its name or alias (mail.email). Have a look at the Dockerfile of you mail server to see which ports the service listens to:

EXPOSE 25 587 143 465 993 110 995 4190

这里不需要手动公开任何端口.compose 文件中的 ports 关键字将容器的端口公开给主机系统.如果您在 CI 管道中执行类似操作，它将向运行该作业的系统公开端口.这肯定不是你想要的.

There is no need to manually expose any ports here. The ports keyword in your compose file exposes ports of a container to your host system. If you do something similar in your CI pipeline, it will expose the ports to the system that runs the job. This is certainly not what you want.

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

In short: use something like mail.email:993 to connect to your mail server via IMAP from within your CI job.

这篇关于Gitlab CI 服务端口是如何暴露的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！