gitlab是用rust开发的

对于这个问题，我需要回答一个问题原因类的问题。据我所知，GitLab并不是用Rust开发的，而是用Ruby on Rails开发的。可能是因为Rust语言有着高性能、内存安全和并发能力等特点，因此有些人误以为GitLab是用Rust开发的。
但是，Rust在软件开发领域中确实具有很好的表现。它是一种安全且快速的系统编程语言，可以避免大多数常见的安全漏洞，还具有内存安全和并发性等特点，这些特点使得它非常适合用于开发高性能、高可靠性和安全性的软件系统。
因此，Rust可以用于开发各种类型的软件，包括 *** 作系统、网络服务器、Web应用程序、数据处理工具等等。而对于GitLab这样的软件开发平台，如果想要实现高性能、高可用性和高安全性，使用Rust作为一种辅助语言也是非常可行的选择。

从 Gitlab 80 开始，Gitlab CI 就已经集成在 Gitlab 中，只要在项目中添加一个 gitlab-ciyml 文件，然后添加一个 Runner ，即可进行持续集成。在介绍 Gitlab CI 之前，先看看一些 Gitlab CI 的一些相关概念。

Jobs->Stages->Pipeline

一次 Pipeline 其实相当于一次构建任务，里面可以包含很多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发 Pipeline 构建，如下图所示：

Stages 表示一个构建阶段，也就是上面提到的一个流程。可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

Stages 和 Pipeline 的关系如下所示：

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

Jobs 和 Stage 的关系如下所示：

如果理解了上面的基本概念之后，可能我们就会发现一个问题，我们的构建任务在什么地方来执行呢，以前用 Jenkins 在 Master 和 Slave 节点都可以用来运行构建任务，而来执行我们的 Gitlab CI 构建任务的就是 Gitlab Runner。

我们知道大多数情况下构建任务都是会占用大量的系统资源的，如果直接让 Gitlab 本身来运行构建任务的话，显然 Gitlab 的性能会大幅度下降的。GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情交给一个独立的 Gitlab Runner 来做就会好很多，更重要的是 Gitlab Runner 可以安装到不同的机器上，甚至是我们本机，这样完全就不会影响到 Gitlab 本身了。

安装 Gitlab Runner 非常简单，我们可以完全安装官方文档： >访问>使用私有化部署的GitLab社区版的风险主要包括以下几点：
1 安全风险：在私有化部署GitLab社区版时，需要自己负责服务器的安全管理工作，包括系统、应用程序和数据的安全管理。一旦服务器受到攻击或出现漏洞，可能会导致数据泄露、系统崩溃、信息丢失等严重后果。
2 维护困难：私有化部署需要自己负责系统更新、备份、恢复等各种工作，需要花费大量时间和精力来保持系统的可靠性和稳定性。如果无法及时维护，将会影响开发和部署进度。
3 兼容性问题：在自己的服务器上搭建GitLab社区版可能会面临兼容性问题，包括与其他软件的兼容性、与第三方服务的兼容性、与开发框架的兼容性等。这些问题可能会导致系统无法运行或者运行不正常。
4 成本问题：私有化部署GitLab社区版需要购买服务器、软件和其他硬件设备等，还需要支付人力成本和维护费用。这些成本可能会超出预算并且难以掌控。
因此，使用私有化部署的GitLab社区版需要承担一定的风险和责任。如果您没有足够的经验或技能来管理和维护系统，可以考虑使用GitLab提供的托管服务或者其他第三方托管服务。

Gitlab是套功能完善的源码管理系统，平时用于公司内部各研发组的源码同步、问题跟踪、开发协同。Gitlab自带的CI/CD功能与Gitlab更简单、灵活的协同工作，也减小了日常维护的压力，因此，本文针对Gitlab的CI/CD功能做的要点分享。

基于GitLab的CI/CD系统由Gitlab与Gitlab-runner两个主要部分构成。

Gitlab源码库管理系统，提供基于Git的源码库管理、协作、权限等丰富的功能。

在Gitlab源码库的根目录中如果创建有`gitlab-ciyml`文件，相当于为当前源码库启用了CI/CD功能。

该文件用于控制CI/CD流程与行为，每次源码的提交、合并动作都会触发Gitlab执行当前 *** 作分支上的该文件。

该文件中通过gitlab提供的关键字、预定义变量、脚本代码等等来规划pipeline和定义Job，实现依据条件控制不同Gitlab-Runner中的执行器进行需要动作，共同完成代码的编译、打包、发布等 *** 作。

Gitlab-Runner运行在本地或远程目标机上的一个程序，作用是接收执行Gitlab的指令，比如编译、打包部署等等。

一个Gitlab可接入多个Gitlab-Runner，每个Runner可以注册多种相同或不同形式的“执行器”。

Runner与Gitlab联接需要通过Gitlab生成的Token，每个Runner对应且仅对应到一个唯一的Token。

Gitlab-Runner基于Go语言开发，可运行在多种系统平台。Gitlab-runner在Gitlab中有三种使用权限范围，第一种是全局共享，第二种是群组共享，第三种是项目特定。

Gitlab-Runner的作用是接收Gitlab指令，并控制与管理“执行器”的程序。具体动作执行则是由Runner派生出的“执行器”这个逻辑模块来完成，Runner支持多种“执行器”形式，有Shell，有Docker等等。

Gitlab-Runner的安装有两种方式，一种是直接安装到原生系统，另一种是以Docker容器方式进行安装。Runner安装完成后，需要执行Runner中的注册命令，建立与Gitlab的关联。

在注册过程中需要填入Gitlab服务器地址、Gitlab提供的Token、执行器形式，以及不同执行器的配置等等。

将Runner以原生系统方式进行安装（也可以以Docker形式安装），并在Runner注册时选择Docker执行器形式。

在注册过程中会要求指定一个Docker Image，该Docker Image是默认用于执行指令的实体（即在`gitlab-ciyml`中未指定Image时默认使用，也可以在Job中明确指定其它的Docker Image）。Runner注册完成后会在`/etc/gitlab-runner`中生成一个`configtoml`文件，如要修改Runner配置，可重新注册（重新注册原配置不会删除，原注册的执行器还保持有效，需要在Gitlab端删除）或修改该文件。另外，一个Runner实例可以配置多个同类型或不同类型的执行器。

执行器是用于Job执行不同的指令，因此执行器的环境需要依据Job的具体要求进行配置，比如用于Java构建，则执行器环境中需要支持jdk、maven等指令。由于本篇用的是Docker形式的执行器，因此在指定的DockerImage中要安装好JDK与MAVEN包（注：为了更好的利用自建的DockerImage，需要创建一个Docker私服，可以用Harbor或Nexus3来实现自定义的Docker Image的管理）。

每个Job都会重新启动一个新的容器，并且会自动完成源码库的下载（放在启动容器的`/build`目录中），并且这个不要求执行器镜像支持Git（原理不清楚，有清楚的欢迎评论区指教！），如何在Job中禁止下载原码还需要再学习（有清楚的欢迎评论区指教！）。

以下是`configtoml`文件及主要字段说明:

`gitlab-ciyml`文件必须在源码库的根目录中，该文件用于控制源码何时、何地、如何加工处理代码的配置脚本，并且需要符合`YAML`的格式与语法。

在该脚本中，通过`stages`关键字定义代码处理阶段，定义的上下顺序则是阶段执行次序。

然后就是各种各样的JOB定义，在Job中需要指明哪个阶段执行，在哪个执行器运行，什么条件下执行，以及执行的具体动作。多个不同的JOB可以关联到同一个阶段，实现并发处理不同的事务。

Gitlab为CI/CD提供了平台与机制，在微服务、异构系统开发时代CI/CD已成为必不可少的效率工具，也可以说是软件自动化生产线，但要用好和维护好一套CI/CD，需要有丰富的研发经验与广泛的系统知识。

---