Gitlab CI/CD笔记-第一天-GitOps和以前的和jenkins的集成的区别

一、GitOps-CI/CD的流程图与Jenkins的流程图

从上图可以看到：
GitOps与基于Jennkins技术栈的CI/CD流程，无法从Jenkins集成其他第三方开源的项目来实现换成了Gitlab来进行集成。

好处在于：CI 一个工具Gitlab就行了，但CD部分依旧是传统的云主机（虚拟机），物理及，docker单机容器或者k8s的pod。

二、gitlab的实现

 

2.1、Gitlab-执行器

Gitlab-server端

Gitlab-Runner-为Agent

Executor-为执行器        在Gitlab-Runner所在节点上执行job任务，有不同的执行器来执行不同的任务，但取决于Gitlab-Runner部署的方式，如果是linux那这个执行器就只能在OS层面执行，如果是docker那就是docker单机来执行任务,如果是k8s那就是启动pod来执行。

我理解的大概流程就是因为Gitlab作为server端和GitRuner本身注册就要使用gitlab使用的token来验证身份，Runer在Gitlab上注册好之后，Runer就具备从Gitlab-server端获取到job的信息，但Runer只是一个Agent，他并不能干活，干活就需要找一个执行器来做，并且这个执行器是根据Runer部署的方式来提供相应的服务，不同执行器的部署方式也不一样。

 2.2、Runer

                1.这个就是jenkins里的worker-slave的角色，
                2.git-lab  server 下发任务，Runner执行。
                3.这个Runer具备在环境中的执行job需要的权限。

 2.3、.gitlab-ci.yml

                1.就是定义的流水线，这是核心，和jenkins除了关键词不同，其他的格式都是yaml非常简单好写

三、GitOps和以前的和jenkins的集成的区别

        1.GitOps直接把jenkins代替了，开发和云原生运维人员不用付出学习成本来学习jenkins了，而且jenkins很多插件真多用起来脑壳大,无法下载，无法加速等等问题。

        2.Git直接把什么第三方的代码扫描，代码授权，代码规范都做了，同时Runer的广泛适配性从范围从物理到云原生都支持，啥都可以跑。

        3.总结：以前是jenkins对接集成第三方工具，GitOps那就是Gitlab把所有涉及到CI/CD工具都自带了，非常无敌，也好用。

        4.本身开发人员用gitlab就比较熟悉，让开发写一个yaml就更玩似得，而且常用的关键词就10几个。

        5.极狐gitlab中国特有，有本地支持，这点完爆jenkins.很关键的，因为很多公司做CI/CD都希望有一家国内有公司可以提供技术支持.