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

Question

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

dockerdocker-composegitlabdevopsgitlab-ci

3

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

我在Gitlab存储库中有一个docker-compose文件和几个Dockerfiles。docker-compose文件由许多相互依赖的镜像组成。我们有两个docker服务器，一个生产服务器和一个开发服务器。我们想要实现以下目标：

1.通过触发器（手动或提交），我们希望关闭dev server上的容器（通过docker-compose down）。 2.检出存储库的最新/当前版本（包含docker-compose.yml和Dockerfiles）。 3.在dev server上启动所有容器（通过docker-compose up -d）。 4.[稍后需要定义]开始测试。 5.如果测试成功或通过手动交互（单击按钮），则应将环境部署到prod server上（即在prod server上执行步骤1、2和3）。

这种方法有什么问题吗？我目前遇到的主要问题是，我不知道如何“使用”/“引用”我的现有服务器。因此，我不想采用通常的方法（创建一个新的隔离的docker容器，测试软件并丢弃），而是想按照上述描述进行操作。

感谢您的帮助！

编辑

经过一些额外的研究，我觉得有必要添加一些内容：从我的理解来看，通常在CI/CD流水线中会启动一个Docker容器来测试您的应用程序。由于我实际上正在测试整个容器堆栈/ docker-compose文件，这需要对docker主机系统进行某些要求，因此我需要使用类似于docker in docker的东西并在那里部署我的堆栈。但是，在第一阶段中，我想使用现有的docker服务器，因为我的“堆栈”需要进行调整，以便从头开始动态创建。

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

希望这可以帮助您。如果有不清楚的地方，请随时问我。

- mcode

2个回答

0

我是这样做的：

1）使用连接到主机上的Docker的GitLab Runner

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 Runner工作的同一服务器上启动容器

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。它允许在与GitLab Runner不同的服务器上启动容器。

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，因为我将镜像存储在私有仓库中

- Ryabchenko Alexander

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rumen Kyusakov · Accepted Answer

您所描述的设置在运行集成测试时非常典型，其中您需要启动更多或更少完整的系统以进行测试。有不同的解决方法，但这是我的看法：

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

2）在CI流水线中，在所有代码构建、单元测试等之后，添加一个手动作业（https://docs.gitlab.com/ee/ci/yaml/README.html#when-manual），以启动开发/暂存服务器上的集成测试。

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 到生产服务器并执行 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 方法是最简单的。