目录
前言
一、Gitops是什么以及Gitlab Runer是什么？
1.1 CI阶段
1.2 Gitops简单介绍
二、本文章演示内容
三、演示步骤
1.gitlab安装
1.1安装docker-compuse
1.2 在设置其他所有内容之前，请配置一个新的环境变量 $GITLAB_HOME，指向配置、日志和数据文件所在的目录。 确保该目录存在并且已授予适当的权限。
1.3 在用户目录下创建gitlab目录，并且创建docker-compose.yml文件
1.4 将下面的代码写入docker-compose.yml文件
1.5 启动gitlab
1.6 获取初使root密码
1.7 浏览器访问gitlab登录，记得加本地dns解析
2.Python示例代码
2.1 Python（示例）
3.Dockerfile示例展示
3.1 Dockfile
3.2 构建容器镜像:
3.3 本地Run一下测试
4. Gitlab创建项目并且将我们的.py文件以及Dockerfile发布
4.1登录gitlab创建新项目
4.2 测试配置如下：
4.3 访问Gitlab仓库
4.4.SSH方式
4.4.1 创建SSH密钥。
4.4.3 SSH密钥访问测试验证
4.4.4 配置特定的Gitlab的域名SSH端口为23
4.4.4.1 正式发布之前解决push的时候SSH端口的问题，因为我们的gitlab的容器SSH端口为23
4.5 正式推送
4.5.1 安装Git
4.5.2 配置Git
4.5.3 正式推送当面目录的文件到Gitlab仓库
4.5.4 验证推送
5. 安装Gitlab-Runner(Cli工具)
5.1 Liunx主机安装（推荐）
5.2 创建Gitlab-Runner容器
5.3 验证GItlab-Runner安装
5.4 配置与注册Gitlab-Runner执行器
5.5 获取Gitlab-Runner执行器注册Token
5.6 gitlab-runner register命令交互式注册Gitlab执行器
5.7 直接编写config.tomol来实现注册Gitlab执行器。
5.8 验证你的Gitlab-Runner执行器配置
5.9 使用注册的执行器进行一个简单的Ci.yml测试验证
5.9.1 使用默认的.Ci yml进行Gitlab-Runer测试
5.10 Ci流水线构建Python容器镜像并且推送到仓库
5.10.1 编写Git-ci.yml
5.10.2 运行推送测试
6 . 配置项目的Gitlab-CI流水线集成代码审核静态审查（STAT）转为SonarQube
6.1 使用docker-compose部署一个SonarQube
6.2 创建持久话docker存储卷
6.3 启动 SonarQube和PostgreSQL 服务
6.4 会启动失败，这里会有一个虚拟内存报错
6.5 解决内存映射区域的问题
6.6 重启SonarQube和PostgreSQL 服务
6.7 访问宿主机➕900端口,访问SonarQube
6.8 SonarQube修改默认admin密码
6.9 SonarQube添加本地个人令牌
6.10 添加Gitlab项目集成到gitlab-ci.yml中，按图一部一走即可
6.11 回到我们的Gitlab的clone目录
6.12 根据提示，新增sonar-project.properties以及修改.gitlab.ci.yml
6.13 推送到flask_demo仓库
6.14 将我们上传的.gitlab.ci编辑正式的 .gitlab-ci.yml 流水线文件
6.15 制作sonar-scanner容器镜像
6.15.1 下载sonar-scanner-cli工具与jre17
6.15.2 编写dockerfile
6.15.3 执行我们的Ci流水线
6.16 Sonar查看结果
6.16.1 Sonar_qube配置中文
4.16.2 Sonar_web查看扫描结果
四.故障处理
1.1 Gitlab_Ci流水线故障处理
1.1.1 invalid IP address in add-host
1.1.2 报错：处理lookup gitlab.example.com on 114.114.114.114:53: no such host
1.2 Gitlab-Https访问方式
1.2.1 解决Gitclone self signed certificate证书问题
1.3 解决docker中注册Gitlab-Runner（执行器）SSL证书问题
1.3.1 报错：x509: certificate relies on legacy Common Name field, use SANs instead
1.3.1.1 创建符合X509标准的CA证书以及证书请求以及对于的私钥。
1.3.1.2 将Gitlab Server容器内的SSL目录替换成你的证书，因为我们加- V参数了所以在主机上就可以直接操作。
1.3.1.3 Gitlab容器应用配置与重启
1.3.1.4 将CA证书复制进Gitlab-Runner容器的证书目录下
1.3.1.5 Gitlab-Runner容器信任CA证书
总结
举个例子：你或你的公司在数据中心搭建了私有云或购买了公有云的主机或Kubernetes集群，当在你的本地电脑上编写Kubernetes的Cluster.yml以及相关K8s集群的网络、配置文件、策略、安全等都是使用代码的形式-这种称之为Ias(基础设施基代码)。这么做非常好。但也有一些问题：
1、你本地编写代码没办法与其它工程师协同分享，再优秀的工程师也没办法同时维护几个版本的代码以及精确代码回退。
2、假设你有一个Git仓库，你只有一个主分支，其他人更改代码提交后，我只能看到谁提交了，但你并没有办法知道他提交的代码是否安全以及编写正确。
3、你提交了基础设施代码，只有当他部署成开发环境的实际基础设施的时候才能得到验证是否按照预想的的运行。
4、部署环境到测试环境整个流程是手动的。
5、同时你和你的同事本地电脑都可能编写基础设施基代码，那么你和你同事谁才是正儿八经的正确来源呢？
那么Gitops主要解决的就是上述几个问题。
1、唯一代码事实来源，方便管理和维护。
2、整个Ci-CD流程全自动化。
3、在任何人提交代码时都需要开发、高级工程师审核才能实际应用。
4、版本控制
实现Gitops的软件一般有有两个工作模式：Pull or Push.
1、Pull 即我们传统的推模式，把代码推送到主机、集群上进行部署。
2、Push即主机和集群中有我们的Agent,由Agent 每隔一段时间与Gitrepo你的仓库中的代码进行对比，如果有变更则进行同步。实现只要我们Gitrepo的代码变更了你的基础设施即跟着改。你回退也只需要回退你的Gitrepo中的代码即可回退基础设施以及App的代码。
这边文章主要讲的是Push模式的Argo以及Ci_CD的自动化流程。
结合我们开发和运维实践中，在CI阶段，我们一般会做什么事情？
1、编写Code
2、Code打包前上传到gitlab静态扫描
3、通过Dockerfile将code编译后的制品打包成容器镜像。
4、容器镜像扫描
5、将打包后的Dockerfile上传至私有镜像仓库。
6、编排manifests清单文件
上面的这些步骤，如果在jenkins中，我们不仅要看jenkins的集成还要编写很长很长一段流水线来实现，那么有没有一个软件和工具。不仅支持存储代码也支持存储容器镜像，还提供安全扫描功能，还能支持流水线？
我学习了gitops,上述的1、2、4、5点都可以直接利用gitlab的原生功能实现。
3、5、6点可以使用gitlab的流水线功能实现。几乎做到了all in one.
在jenkins中我们需要单独部署一台虚拟机或者物理机，来做为编译、打包、上传的工作节点。
在gitops中gitlab原生提供gitlab runer担任工作节点，负责处理你的流水线。
GitOps 是一种用于持续交付（CD）的实践，它将 Git 作为单一的真理来源和配置的中心。这种方法强调开发人员和运维团队使用 Git 进行版本控制、代码审查和自动化部署的能力，以提高软件开发和部署的速度、安全性和可靠性。
也可以参考下面我的另外一篇博客。
Gitlab CI/CD笔记-第一天-GitOps和以前的和jenkins的集成的区别_jenkins gitops-CSDN博客
1、一台虚拟机通过docker跑一个gitlab,充当私服gitlab.
2、一个3节点的RKE2 k8s集群
3、一个示例的应用demo,使用Python编写的最简单web,就展示hello-world.
4、我本地开发代码上传到gitlab测试仓库并且使用静态代码扫描，
5、编写gitlab的流水线，使gitlab runer使用代码库中的dockerfile镜像构建容器镜像，并上传至gitlab的镜像仓库。
6、镜像扫描后。
7、编写manifests清单文件
6、利用ArgoCD进行持续部署到集群中。
1.1安装docker-compuse
https://docs.docker.com/compose/install/
1.2 在设置其他所有内容之前，请配置一个新的环境变量 ，指向配置、日志和数据文件所在的目录。 确保该目录存在并且已授予适当的权限。
1.3 在用户目录下创建gitlab目录，并且创建docker-compose.yml文件
1.4 将下面的代码写入docker-compose.yml文件
**请注意我们修改了 SSH的侦听端口为23
1.5 启动gitlab
1.6 获取初使root密码
1.7 浏览器访问gitlab登录，记得加本地dns解析
2.1 Python（示例）
就是最简单的web框架、展示Hello,World!带一个版本V1.
固定侦听的端口为5000
3.2 构建容器镜像:
3.3 本地Run一下测试
回显：Hello Word!V1 即正确。
4.1登录gitlab创建新项目
4.2 测试配置如下：
**这里是项目名称是flase,我后面修改是flask.
Project_name 设置为你的自己的项目名称
ProjectURL 为Clone/Push 选择用户的namespace
可视权限 选择公开
不添加 REMADE文件
4.3 访问Gitlab仓库
访问Gitlab仓库有两种一种Https一种为SSH，官网推荐为SSH。文章最下面也提供访问Https的疑难解答。
4.4.SSH方式
4.4.1 创建SSH密钥。
默认保存在～/.ssh/id_rsa.pub.
4.4.3 SSH密钥访问测试验证
**这里的-p 23是因为我们Gitlab侦听的SSH端口为23 映射到主机的22端口. 下面也需要修改git push时的SSH端口。
返回入下面所示，即成功。
4.4.4 配置特定的Gitlab的域名SSH端口为23
4.4.4.1 正式发布之前解决push的时候SSH端口的问题，因为我们的gitlab的容器SSH端口为23
其中gitlab.example.com替换为你的gitlab域名。
4.5 正式推送
4.5.1 安装Git
红帽或者Open Suse的软件包仓库均自带git,安装即可。这里不做演示。
4.5.2 配置Git
4.5.3 正式推送当面目录的文件到Gitlab仓库
4.5.4 验证推送
5.1 Liunx主机安装（推荐）
-
授权执行：
-
创建极狐GitLab CI 用户：
-
安装并作为服务运行：
确保您在 中拥有 进行 root 操作，否则可能会出现 错误。 或者，您可以在其他位置安装 ，比如 。
本文章演示参与此方式：
-
添加官方极狐GitLab 仓库：
对于 Debian/Ubuntu/Mint：
对于 RHEL/CentOS/Fedora：
Debian 用户应该使用 APT Pinning。为了方便用户安装使用极狐GitLab Runner，我们在中国国内设置了极狐GitLab 镜像站点。
-
安装最新版本的极狐GitLab Runner，或跳到下一步，安装特定版本。
从 14.0 开始，默认禁用 目录使用，以避免 作业错误。
对于 Debian/Ubuntu/Mint：
对于 RHEL/CentOS/Fedora：
在 14.7 及更高版本中，符合 FIPS 140-2 的极狐GitLab Runner 版本可用于 RHEL 发行版。 您可以将 用作包名称以安装这个版本，而不是使用 。
**下面演示的是Docker部署Gitlab-Runner（不推荐哈，容器嵌套排错非常麻烦。）
5.2 创建Gitlab-Runner容器
5.3 验证GItlab-Runner安装
5.4 配置与注册Gitlab-Runner执行器
配置与注册Gitlab-Runner执行器有多种方式，你可以通过
5.5 获取Gitlab-Runner执行器注册Token
进入Gitlab-设置-CI/CD-Runners
**国内版本的获取方式 ，Gitlab容器镜像为gitlab-jh结尾的是国内版本
**国外版本获取到注册Runner的Token，Gitlab容器镜像结尾为gitlab-ce为国外版本
***填写你希望这个Runer来干什么。因为项目可能存在多个Runer来执行不同阶段需要进行区分。
***最重要的是拿到注册的令牌！即。glrt开头的这个。
GitLab Runner 命令 | 极狐GitLab
5.7 直接编写
在/etc/gitlab-runner/config.toml编写对应执行器的配置文件，下面是一个使用Docker执行器并且挂载主机套接字配置文件例子：
Docker部署的Gitlab-Runner
直接修改挂载主机上的/srv/gitlab-runnner/config/config.toml
替换其中的TOKEN，URL,以及你的extra_hosts映射的内部地址。
5.8 验证你的Gitlab-Runner执行器配置
回显：Verifying runner... is alive 即存活。
同时登陆通过Gitlab-Settings-CI/CD-Runner可以看到你有一个注册的Runner并且前面的状态表示为绿色。
5.9 使用注册的执行器进行一个简单的Ci.yml测试验证
5.9.1 使用默认的.Ci yml进行Gitlab-Runer测试
点击-Buid-Pipeline editor ，你可以在后面看到一个create new Gitlab-Runer测试,他会自动在你仓库的根目录生成一个.ci 的yml文件，里面就是gitlab的Ci Pipeline流水线文件。
回到Buid-Pipeline editor，点击下面的Commit change 就可以触发流水线。
点击Pipelines-右边的Stages-点击build-job就查看当前阶段的构建日志和状态。
只要Runner以及执行器配置正确，那么这里3个阶段就会是3个绿色。如果有问题，请查看文章后面的疑难解答。
5.10 Ci流水线构建Python容器镜像并且推送到仓库
5.10.1 编写Git-ci.yml
1、替换其中CI_REGISTRY_USER、CI_REGISTRY以及
2、替换docker tag 后跟你的仓库。
5.10.2 运行推送测试
点击下面的Commit.然后查看流水线状态。
登陆你的仓库验证即可。
到这一步有那么一丢丢问题，因为需要Gitlab企业版才能使用代码审核静态审查（STAT），故放弃。
这里选择用docker-compose部署一个SonarQube,使用SonarQube来提供静态代码扫描的能力。
6.1 使用docker-compose部署一个SonarQube
代码解释：
这段 YAML 文件描述了一个 Docker Compose 的配置文件，用于部署 SonarQube 和 PostgreSQL 服务，并定义了它们的数据卷（volumes）。
1. **services** 下的 `sonarqube` 服务：
- 使用 `sonarqube:community` 镜像。
- 依赖于 `db` 服务。
- 指定了环境变量用于 SonarQube 连接到 PostgreSQL 数据库。
- 定义了三个数据卷：
- `/srv/sonarqube/sonarqube_data:/opt/sonarqube/data`：用于存储 SonarQube 的数据。
- `/srv/sonarqube/sonarqube_extensions:/opt/sonarqube/extensions`：用于存储 SonarQube 的扩展。
- `/srv/sonarqube/sonarqube_logs:/opt/sonarqube/logs`：用于存储 SonarQube 的日志。
- 将容器内部的 9000 端口映射到宿主机的 9000 端口。
2. **services** 下的 `db` 服务：
- 使用 `postgres:12` 镜像。
- 指定了 PostgreSQL 数据库的用户名和密码。
- 定义了两个数据卷：
- `/srv/sonarqube/postgresql:/var/lib/postgresql`：用于存储 PostgreSQL 的数据库文件。
- `/srv/sonarqube/postgresql_data:/var/lib/postgresql/data`：用于存储 PostgreSQL 的数据。
3. **volumes** 部分定义了这些数据卷的名称，这些名称与上述服务中的 volumes 部分对应，用于持久化存储服务的数据。
总结：这段配置文件通过 Docker Compose 部署了 SonarQube 和 PostgreSQL 服务，并使用数据卷来持久化存储它们的数据、扩展和日志。通过这种方式，即使容器重新启动，也能保留数据和配置的持久性。
6.2 创建持久话docker存储卷
6.3 启动 SonarQube和PostgreSQL 服务
6.4 会启动失败，这里会有一个虚拟内存报错
6.5 解决内存映射区域的问题
官网提示：
Maximum map count check | Elasticsearch Guide [8.13] | Elastic
6.6 重启SonarQube和PostgreSQL 服务
6.7 访问宿主机➕900端口,访问SonarQube
默认用户和密码均为：admin
6.8 SonarQube修改默认admin密码
不做演示，根据密码策略修改
6.9 SonarQube添加本地个人令牌
- 选择创建新项目。
- 为您的项目提供项目密钥和显示名称，然后选择设置。
- 在“提供令牌”下，选择“生成令牌”。为您的令牌命名，选择生成，然后单击继续。
6.10 添加Gitlab项目集成到gitlab-ci.yml中，按图一部一走即可
按照提示，Gitlab中的操作：
Settings-CI/CD-Add variable
6.11 回到我们的Gitlab的clone目录
此时我们clone的目录下存在下面这些文件：
demo.web.py-我们的示例Python代码
dockerfile-我们的dockerfile
README.md 自述文件
.git git仓库自述文件
6.12 根据提示，新增sonar-project.properties以及修改.gitlab.ci.yml
.gitlab.ci.yml与sonar-project.properties 这两个文件复制即可。
一个是CI的流水线示例配置文件，
一个是sonar-project.properties 定义Sonarqube的变量，这是sonar_cli工具要使用到的配置文件请注意，下面CI流水线会使用到。
**请注意我们推送的是.gitlab.ci.yml文件不是.gitlab-ci.yml。因为我们这里的.gitlab.ci.yml只是Sonarqube给我们的示例ci文件，我们需要进入GItlab的Pepilines editer进行编辑，验证语法。
6.13 推送到flask_demo仓库
Gitlab仓库验证：
6.14 将我们上传的.gitlab.ci编辑正式的 .gitlab-ci.yml 流水线文件
现在我们仓库有了.gitlab.ci以及.gitlab-ci.yml （正儿八经的流水线文件）
需要将Sonarqube给我们的示例ci文件编辑到.gitlab-ci.yml中。
正式编辑之前我们先来拆分解释一下示例.gitlab.ci文件。
这部分流水线分为全局配置、阶段配置
其中全局配置内容为：image,
image定义全局使用的镜像，
使用 指定要在作业之间缓存的文件和目录列表,阶段中要使用其他阶段的产物或者文件可以通过cashe来解决。
这里单独说一下，这个阶段会生产一个报告，这个报告依旧需要订阅Gitlab的Ultimate的服务。
Sourqube的给的提示是，如果你没有订阅服务，可以安全的删除，我们把这个阶段删除就可以了。
点击文件右上方-edit-Edit single file,删除完毕然后下面Commit即可。
将我们编辑好的.gitlab.ci.yml整合到我们的正儿八经的流水线文件中.gitlab-ci.yml文件.
复制下面的内容到.gitlab-ci.yml文件，先不做提交。
1、可以看到我删除了-deploy阶段，并且将
-
6.15 制作sonar-scanner容器镜像
6.15.1 下载sonar-scanner-cli工具与jre17
SonarScanner CLI
回到你的主机上执行：
此时你得到了下面这个目录：
bin为sonarcli工具的二进制文件
conf为 sonarcli工具的配置文件存放位置
jre为sonarcli工具的运行环境-jre17
lib为依赖的工具包
可以看到sonar_cli工具已经帮我们解决了sonarcli与jre的环境问题。
6.15.2 编写dockerfile
下面为示例dockerfile
COPY 命令后面替换为你实际解压的文件名称
将dockerfile与你解压的文件放置在一个目录下，并且删除zip的压缩包。
构建容器镜像。
6.15.3 执行我们的Ci流水线
你现在应该有一个和我一摸一样的流水线内容。
点击下面的commit触发流水线更新。
我们的流水线就搞定静态扫描这个阶段了。
6.16 Sonar查看结果
6.16.1 Sonar_qube配置中文
为了方便查看结果，我们配置Sonar_qube为中文。
1、需要插件安装协议点击同意即可。
2、下面的插件右边你可以看到一个install的按钮，点击安装即可。需要重启一下很快。
4.16.2 Sonar_web查看扫描结果
回到Sonar_web你可以看到如下内容：
我们静态扫描阶段就正式结束了，下面开始到CD阶段，利用Gitlab提交更新促发Fleet进行部署。
4.1 Gitlab_Ci流水线故障处理
4.1.1 invalid IP address in add-host
上述问题是因为host解析的问题，我们的gitlab是内网网络，需要使用本地hosts文件来解析。
官网文档中有一个解决办法：
可以在gitlab-runner中自定义主机名
上面是官网给出的例子,这个 extra_hosts的参数需要添加到gitlab-runer的配置文件中。
我们需要修改我们配置的gitlab-runner的文件，他在 /etc/gitlab-runner/config.toml（这个目录我们通过-v 参数挂载到主机上了，可以在主机上修改），在runners.docker下面添加。
注意：这里添加的是运行gitlab的主机IP即可。
只要不是修改Gitlab-Runner对应执行器的url，即gitlab的地址，不用重新注册执行器，回到Gitlab重新点击执行：
3个都通过说明你的Gitlab-Runner对于这个执行器本身配置层面和网络层面没有问题。
同时也说明你的执行器具备具备单任务和并发任务（第二个阶段Test是两个并发Job）的能力。
4.1.2 报错：处理lookup gitlab.example.com on 114.114.114.114:53: no such host
在gtilab-runner 容器中执行 gitlab-runner verify 激活执行器时报错：
因为是私有的域名，公网的DNS没办法解析到，需要修改/etc/hosts或者你的DNS-Server存在代理关系。
4.2 Gitlab-Https访问方式
Https因为自签名证书的问题需要对GItlab服务器证书执行信任和对CA根证书的信任，公司内部选择SSH管理更加方便，如果自己公司内部有自己的自签名证书管理机制就可以选择Https。
下面分享几个HTTPs证书处理的一些流程和步骤。
4.2.1 解决Gitclone self signed certificate证书问题
从gitlab的容器中拿到内部的自签名证书文件
4.3 解决docker中注册Gitlab-Runner（执行器）SSL证书问题
4.3.1 报错：x509: certificate relies on legacy Common Name field, use SANs instead
Runner本身是不信任Gitlab默认的内部的CA机构以及CA机构颁发的证书的。
所以你要自己创建一个CA机构并且使用自签名的CA架构颁发Gitlab的证书以及让Runner信任这个CA机构，这样Gitlab-Runner才能使用令牌注册上去。
4.3.1.1 创建符合X509标准的CA证书以及证书请求以及对于的私钥。
注意！
**需要替换命令中的example.com为你的域名。
**并且你的Gitlab-Runer容器中需要添加你自定义域名和IP地址的对应关系，不然没法解析.
4.3.1.2 将Gitlab Server容器内的SSL目录替换成你的证书，因为我们加- V参数了所以在主机上就可以直接操作。
4.3.1.3 Gitlab容器应用配置与重启
4.3.1.4 将CA证书复制进Gitlab-Runner容器的证书目录下
4.3.1.5 Gitlab-Runner容器信任CA证书
截止到现在，Ci阶段到构建镜像、推送镜像、检查代码-Ci阶段就完成了。