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

问题描述 投票：3回答：2

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

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

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

有什么可以反对这种方法吗？我目前的主要问题是，我不知道如何“使用”/“引用”我现有的服务器。所以我不想采用通常的方法（创建一个新的隔离的docker容器，测试软件并扔掉）但我想按照上面的描述去做。

谢谢你的帮助！

Edit

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

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

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

docker docker-compose gitlab devops gitlab-ci
2个回答
2
投票

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

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方法是最简单的。

0
投票

我已经以下一个方式做到了这一点：

1）gitlab runner与主机上的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 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，因为我将图像存储在私人注册表中

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.