关于如何在Gitlab CI Runner中使用Systemd启动Docker的微型说明。 也许有人会有用，也许有人已经以其他方式解决了类似的问题，如果您分享评论，那将会很有趣。
前言Gitlab Runner已部署在Docker容器内。 在某个时候，提出了将所有必要的基础结构（例如PostgreSQL和Tomcat）收集在一个容器中的想法，以便在编译阶段和自动测试运行之后安装应用程序。 基础架构容器本身已经基于Systemd的Debian映像构建，并且运行良好。 但是在Runner中使用时，出现了意外的问题。 为了简单起见，我们将步骤代码说成这样：
run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar
一切似乎都很正常，但是在启动时，该步骤将失败，并出现一个错误，即systemd没有作为ID为1的进程运行，或者另一个错误可能是systemd根本没有运行。
有什么问题吗？
事实证明-关于Gitlab本身的一个新问题，我不是唯一遇到此问题的人。
问题是Docker容器的Gitlab Runner始终会覆盖CMD命令，即 使用以下命令启动容器：
docker run --cmd /bin/bash ...
而且，重新定义Gitlab CMD是不可能的，您只能在ci脚本中使用入口点，但是与之跳舞并不会导致任何结果。
分子测试涵盖了所有角色，并且他们在GitLab运行程序中成功通过了测试。 考虑到这一点，我想，为什么不在启动的Runner g * mor中启动带有systemd的容器，但是结果对我来说比困难更重要。 可以使用docker命令简单地启动一个容器，但是它没有效果，并且不会有任何错误处理-某种程度上它可能不太可预测，所以我决定用Python写一些手工制作的文章，将其启动容器，并在必要时复制归档文件文件并在容器内执行命令列表。
→代码在这里：
GitHub您可以这样运行它：
cd <path-with-code> pip install virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt python main.py \ --image dramaturg/docker-debian-systemd
[]中的命令是可选的。 需要外壳程序的命令（例如ls -la等）需要一个特殊的{bash}宏，它将在运行时被
/ bin / bash -c“ command”代替。
我是第一次用Python写的，所以不要骂。 也许在代码中或启动时会出现问题，我将尝试快速修复它。 在这里，我试图解释启动方法的一般简单思想。 如果您遇到类似的问题，请分享您的经验。
关于Dramaturg / docker-debian-systemd使用的映像对此映像没有任何抱怨，但是首先在主机控制台中弹出一个错误，表明systemd创建的某些文件已经存在。 Nginx服务中没有这样的问题，但是它们出现在PostgreSQL中。 解决方案是删除块“ VOLUME [” / sys / fs / cgroup”，“ / run”，“ / run / lock”，“ / tmp”]，然后一切都像时钟一样工作。