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..

推荐答案

来自官方文档：

服务关键字定义只是在您的工作期间运行的另一个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 文件中的c>关键字。因此，您的作业 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容器中运行，则此容器将链接到您服务的容器。 链接是Docker的遗留功能，但与通过容器连接的两个容器非常相似一个单独的网络。这与一个组成文件中相互通信的多个服务非常相似。

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

这里不需要手动公开任何端口。撰写文件中的 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 的东西进行连接您的CI作业中通过IMAP发送邮件服务器。

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

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