修改

Question

我对Gitlab CI完全陌生，但开始阅读文档。在实际构建它之前，我想检查是否按计划进行是个好主意：

我在Gitlab存储库中有一个docker-compose文件和几个Dockerfiles。 docker-compose文件由许多相互依赖的图像组成。我们有两个docker服务器，一个 prod服务器和一个 dev服务器。我们希望实现以下目标：

通过触发器（手动或提交），我们希望减少（通过docker-compose down） dev服务器上的容器
查看存储库的最新/当前版本（包含docker-compose.yml和Dockerfiles）
启动 dev服务器上的所有容器（通过docker-compose up -d）
[以后需要定义]开始测试
如果测试成功或通过手动交互（单击按钮），则应在 prod服务器上部署环境（意味着 prod服务器上的步骤1,2和3

）。
有什么方法可以反对这种方法吗？我目前面临的主要问题是，我不知道如何使用＆＃34; /＆＃34;参考＆＃34;我现有的服务器。因此，我不想采用通常的方法（创建一个新的隔离的docker容器，测试软件并扔掉）但我想按照上面的描述进行操作。

感谢您的帮助！

修改

在做了一些额外的研究之后，我觉得有必要添加一些东西：从我的理解，通常在CI / CD管道中调整Docker容器来测试你的应用程序。由于我实际上正在测试一堆容器/ docker-compose文件，它对docker主机系统有一定的要求，我需要在docker中使用docker之类的东西并在那里部署我的堆栈。但是，在第一阶段我想使用现有的docker服务器，因为我的＆＃34; stack＆＃34;需要进行调整才能从头开始动态创建。

容器对主机系统有要求的原因是我们在这种情况下使用Docker作为基础设施工具。因此，我们使用Docker容器而不是VM。结果是企业应用程序的完整环境，其中不同的服务（管理接口，存储库等）是单独的容器。

希望这会有所帮助。如果有什么不清楚，请问。

Answer 1

您描述的设置非常典型，可用于运行集成测试，您可以使用或多或少的完整系统进行测试。有不同的方法可以解决这个问题，但这是我的看法：

1）使用单独的GitLab CI构建服务器（gitlab-ci-runner）而不是开发服务器。它可以是任何类型：shell，docker等。通过这种方式，您可以将部署环境与构建服务器分开。

2）在CI管道中，在构建所有代码，单元测试等之后添加手动作业（https://docs.gitlab.com/ee/ci/yaml/README.html#when-manual）以启动对dev / staging服务器的集成测试

3）手动作业只需使用秘密变量（https://docs.gitlab.com/ee/ci/variables/README.html#secret-variables）中的凭证ssh到dev服务器。然后它会执行docker-compose down，docker-compose pull，docker-compose up，假设最新的docker镜像已经在构建阶段构建并部署到私有docker注册表。

4）管道中的另一项工作开始测试

5）一旦测试完成，您可以拥有另一个阶段，该阶段仅手动触发或推送某个git标签，例如release/v*（https://docs.gitlab.com/ee/ci/yaml/README.html#only-and-except-simplified）。在此作业中，您将ssh到prod服务器并再次执行docker-compose down，docker-compose pull，docker-compose up，假设已经构建了版本的docker镜像。也就是说，您不在部署计算机上构建和标记docker镜像 - 只在那里运行容器。

要在构建服务器上构建docker镜像，可以使用shell executor，docker-in-docker或docker socket binding：https://docs.gitlab.com/ee/ci/docker/using_docker_build.html

shell方法是最简单的。

Answer 2

我已经通过以下方式做到这一点：

1）gitlab运行程序，与主机上的docker连接

sudo gitlab-runner register -n \
  --url https://gitlab.YOURSITE.com/ \
  --registration-token YOUR_TOKEN \
  --executor docker \
  --description "runner #1" \
  --docker-image "docker:stable" \
  --docker-privileged \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
  --docker-volumes /home/gitlab-runner/docker-cache \

最后两行带有卷，允许在两次启动之间共享缓存，并可以在gitlab运行器所在的同一服务器上启动容器

2）用于测试/集成

integration:
  stage: integration
  when: manual
  script:
    - docker-compose -p integration -f docker-compose.integration.yml down -v
    - docker-compose -p integration -f docker-compose.integration.yml build --compress 
    - docker-compose -p integration -f docker-compose.integration.yml up -d

请注意，dovn -v将删除卷，并使用up使用默认数据重新创建它们

3）在生产中，我使用docker swarm / stack。它允许在与gitlabRunner服务器不同的服务器上启动容器

deploy-production:
  when: manual
  stage: production
  script:
    - docker login registry.MYSITE.com -u USER -p PASSWORD
    - docker-compose -f docker-compose.release.yml build
    - docker-compose -f docker-compose.release.yml push
    - docker stack deploy preprod -c deploy/production/service.yml --with-registry-auth

由于我将图像存储在专用注册表中，因此我使用--with-registry-auth

Gitlab CI - 在dev-server上部署docker-compose.yml，测试并部署到PD

修改

2 个答案: