我有一个.gitlab-ci.yml file:
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运行时可能会出现什么问题？我怎样才能以不同的方式测试它？
抱歉问了很多问题，我只是绝望地迷路了..
来自官方文档 https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-a-service:
The services关键字定义了在您的工作期间运行的另一个 Docker 映像，并链接到该 Docker 映像image关键字定义。这允许您在构建期间访问服务映像。
没有image您的关键字.gitlab-ci.yml文件。因此，你的工作地点实际上是不可预测的integration_test runs.
如果您的作业在 Docker 容器内运行，则该容器将链接到您的服务的容器。Links https://docs.docker.com/network/links/是 Docker 的遗留功能，但它与通过单独网络连接的两个容器非常相似。这与一个组合文件中相互通信的多个服务非常相似。
在作业容器中执行的所有内容都可以通过其名称或别名访问您的服务（mail.email）。看看邮件服务器的 Dockerfile https://hub.docker.com/r/tvial/docker-mailserver/dockerfile查看服务监听哪些端口：
EXPOSE 25 587 143 465 993 110 995 4190
这里不需要手动公开任何端口。这ports撰写文件中的关键字将容器的端口公开给主机系统。如果您在 CI 管道中执行类似的操作，它将向运行作业的系统公开端口。这当然不是你想要的。
简而言之：使用类似的东西mail.email:993从 CI 作业中通过 IMAP 连接到邮件服务器。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
