gitlab-ci.yml CI / CD最佳实践和运行程序配置是什么？

Question

这有点理论性，但是我将尽我所能解释我的设置：

• 1个具有自托管gitlab的服务器（实例）
• 1个用于开发的服务器（实例）
• 1个用于生产的服务器（实例）

比方说，在我的gitlab中，我有一个ReactJs项目，并且我按如下方式配置了gitlab-ci.yml：

• 作业deploy_dev推送到dev分支后，更新将与rsync复制到/var/www/html/${CI_PROJECT_NAME}（作为开发服务器的部署）

• 拾取作业deploy_dev的运行程序是安装在我部署到的同一dev服务器上的共享运行程序，它拾取带有标签reactjs的作业< / p>

问题是： 如果要部署到生产环境，应该遵循什么最佳实践？

我设法提出了一些我想到的选择，但是我不知道哪个是最佳实践（如果有）。这是我想出的：

1. 修改gitlab-ci.yml以添加具有相同标签deploy_prod的作业reactjs，但是脚本应rsync与生产服务器的/var/www/html/${CI_PROJECT_NAME}使用SSH吗？

2. 在生产服务器上设置另一个运行程序，并让其运行带有标签reactjs-prod的作业，并修改gitlab-ci.yml以使具有标签deploy_prod的{​​{1}}吗？

3. 除了上述2种方法之外，您还有更好的方法吗？

最后一个问题（相关）： 哪里可以安装跑步机？我在做什么（让跑步者在reactjs-prod服务器上）真的可以吗？

请您向我解释最好的方法（您会选择），并给出正反两方面的理由。

Answer 1

最佳做法是将CI / CD基础结构与托管应用程序的基础结构分开。 这样做是为了尽量减少可能导致您的应用程序或运行程序出现问题的变量数量。

在运行应用程序的同一台计算机上有运行程序时，请考虑以下情形：（即使运行程序和应用程序在单独的Docker容器中运行，也可能发生以下情况。基础计算机仍然是单点运行失败。）

1. 运行程序执行CPU / RAM繁重的工作并占用计算机上的大部分资源。您的应用程序开始遇到性能问题。

2. Gitlab运行程序崩溃，并使主机处于无法操作的状态。 （码头工人恐慌或其他）。 您的生产应用程序停止运行。

3. 您的应用会制动主机（无关紧要。可能会发生），CI / CD停止工作，并且无法将修复部署到生产中。

请考虑使用一台单独的运行器机器（或多台机器。Gitlab运行器可以水平缩放），该机器用于将部署作业运行到开发服务器和生产服务器。