devbox
喵喵爱编程
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Gitops-万字保姆级教程-小白也可以轻松学会! (Part 1)-Gitlab与Gitlab-Ci_fleet gitops

作者：喵喵爱编程 | 2024-08-15 11:36:49

赞

踩

fleet gitops

系列文章目录

本文章分为4个部分：​​​​​​​

Gitops-万字保姆级教程-小白也可以轻松学会! (Part 1)-Gitlab与Gitlab-Ci-CSDN博客文章浏览阅读839次，点赞21次，收藏14次。本文章分为2个部分：Part 1主要涉及Gitlab、Gitlab-Runner、Git-Ci、Sonar-qube。Part 2主要涉及Rancher、Fleet、Git-Ci。GitOps 是一种用于持续交付（CD）的实践，它将 Git 作为单一的真理来源和配置的中心。这种方法强调开发人员和运维团队使用 Git 进行版本控制、代码审查和自动化部署的能力，以提高软件开发和部署的速度、安全性和可靠性。也可以参考下面我的另外一篇博客。https://blog.csdn.net/weixin_46510209/article/details/139827315?spm=1001.2014.3001.5502Gitops-万字保姆级教程-小白也可以轻松学会! (Part 2)-ArgoCD_git actions argo-CSDN博客文章浏览阅读896次，点赞8次，收藏21次。在Part 1中我们安装了Gitlab、配置了Gitlab-Runner、并且测试了最基本的Ci流水线。接着结合Sonar_qube对代码进行静态扫描并集成在Gitlab_Ci中。我们初步的完成了Ci阶段。这篇Part 2 主要涉及到CD阶段，通过Argo结合Gitops部署到我们的环境中。在Part 1 篇中我们使用的Python代码只用于演示Ci阶段，本次演示代码使用博主的Github开源仓库。开源万岁！一、Argo-CD是什么？总结。_git actions argohttps://blog.csdn.net/weixin_46510209/article/details/140342523?spm=1001.2014.3001.5501Gitops-万字保姆级教程-小白也可以轻松学会! (Part 3）-关于git你需要知道的事情_git 常用命令分析-CSDN博客文章浏览阅读554次，点赞5次，收藏6次。这是Devops系列文章的第三篇，从git命令学习。_git 常用命令分析https://blog.csdn.net/weixin_46510209/article/details/136997876?spm=1001.2014.3001.5502

Gitops-万字保姆级教程-小白也可以轻松学会! (Part 4)-Argo-Cli安装与使用-CSDN博客文章浏览阅读423次，点赞5次，收藏8次。*选择合适的符合你操作系统以及CPU架构的二进制文件。https://blog.csdn.net/weixin_46510209/article/details/140674710?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22140674710%22%2C%22source%22%3A%22weixin_46510209%22%7D

​​​​​​​

目录

前言

一、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证书

总结

一、Gitops是什么以及Gitlab Runer是什么？

        举个例子：你或你的公司在数据中心搭建了私有云或购买了公有云的主机或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的自动化流程。

1.1 CI阶段

      结合我们开发和运维实践中，在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担任工作节点，负责处理你的流水线。

1.2 Gitops简单介绍

        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.gitlab安装

1.1安装docker-compuse

https://docs.docker.com/compose/install/​​​​​​​

1.2 在设置其他所有内容之前，请配置一个新的环境变量 $GITLAB_HOME，指向配置、日志和数据文件所在的目录。 确保该目录存在并且已授予适当的权限。 

echo 'export GITLAB_HOME=/srv/gitlab' >> ~/.bash_profile

1.3 在用户目录下创建gitlab目录，并且创建docker-compose.yml文件 

  1. cd ~
  2. mkdir gitlab
  3. vim docker-compose.yml

1.4 将下面的代码写入docker-compose.yml文件 

  1. version: '3.6'
  2. services:
  3.   web:
  4.     image: 'registry.gitlab.cn/omnibus/gitlab-jh:latest'
  5.     restart: always
  6.     hostname: 'gitlab.example.com'
  7.     environment:
  8.       GITLAB_OMNIBUS_CONFIG: |
  9.         external_url 'https://gitlab.example.com'
  10.         # Add any other gitlab.rb configuration here, each on its own line
  11.     ports:
  12.       - '80:80'
  13.       - '443:443'
  14.       - '23:22'
  15.     volumes:
  16.       - '$GITLAB_HOME/config:/etc/gitlab'
  17.       - '$GITLAB_HOME/logs:/var/log/gitlab'
  18.       - '$GITLAB_HOME/data:/var/opt/gitlab'
  19.     shm_size: '256m'

        **请注意我们修改了 SSH的侦听端口为23 

1.5 启动gitlab 

docker-compose up -d

1.6 获取初使root密码

docker exec -it gitlab-web-1 cat /etc/gitlab/initial_root_password

1.7 浏览器访问gitlab登录，记得加本地dns解析

echo ‘IP地址 你的gitlab域名’ >> /etc/hosts

2.Python示例代码

2.1 Python（示例）

        就是最简单的web框架、展示Hello,World!带一个版本V1.

        固定侦听的端口为5000

  1. from flask import Flask
  2.  
  3. app = Flask(__name__)
  4.  
  5. @app.route('/')
  6. def hello():
  7.     return 'Hello, World! V1'
  8.  
  9. if __name__ == '__main__':
  10.     app.run(port=5000)

3.Dockerfile示例展示

3.1 Dockfile

  1. # 使用官方的Python镜像作为基础镜像
  2. FROM m.daocloud.io/docker.io/python:3.8-slim-buster
  3.  
  4. # 设置工作目录
  5. WORKDIR /app
  6.  
  7. # 将当前目录的内容复制到工作目录中
  8. COPY . /app
  9.  
  10. # 更改pip源为清华大学的镜像源
  11. RUN mkdir -p /root/.pip && echo "[global]\ntrusted-host =  pypi.tuna.tsinghua.edu.cn\nindex-url = https://pypi.tuna.tsinghua.edu.cn/simple" > /root/.pip/pip.conf
  12.  
  13. # 安装Flask
  14. RUN pip install --no-cache-dir flask
  15.  
  16. # 暴露端口5000供应用使用
  17. EXPOSE 5000
  18.  
  19. # 定义环境变量
  20. ENV FLASK_APP=demo_web.py
  21.  
  22. # 当容器启动时运行 Flask 应用
  23. CMD ["flask", "run", "--host=0.0.0.0", "--port=5000"]

3.2 构建容器镜像:

docker build -t my-flask-app .

3.3 本地Run一下测试

docker run -p -d  5000:5000 my-flask-app
curl localhost:5000

        回显：Hello Word!V1 即正确。 

4. Gitlab创建项目并且将我们的.py文件以及Dockerfile发布

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密钥。
  1. #创建SSH密钥，- C 后面写你的邮箱
  2. ssh-keygen -t ecdsa-sk -C "<comment>"

                默认保存在～/.ssh/id_rsa.pub.

        4.4.2 将公钥放入Gitlab中。 

        4.4.3 SSH密钥访问测试验证
ssh -T git@gitlab.example.com -p 23

        **这里的-p 23是因为我们Gitlab侦听的SSH端口为23 映射到主机的22端口. 下面也需要修改git push时的SSH端口。

  1. #示例回显：
  2. The authenticity of host 'gitlab.example.com (35.231.145.151)' can't be established.
  3. ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
  4. Are you sure you want to continue connecting (yes/no)? yes
  5. Warning: Permanently added 'gitlab.example.com' (ECDSA) to the list of known hosts.

        返回入下面所示，即成功。

Welcome to Gitlab,@root! 
        4.4.4 配置特定的Gitlab的域名SSH端口为23
        4.4.4.1 正式发布之前解决push的时候SSH端口的问题，因为我们的gitlab的容器SSH端口为23
vim ~/.ssh/config
  1. Host gitlab.example.com
  2.     HostName gitlab.example.com
  3.     Port 23

        其中gitlab.example.com替换为你的gitlab域名。 

4.5 正式推送         

        4.5.1 安装Git

        红帽或者Open Suse的软件包仓库均自带git,安装即可。这里不做演示。

        4.5.2 配置Git
  1. 1、在 shell 中，添加您的用户名：
  2. git config --global user.name "your_username"
  1. 2、添加您的邮件地址
  2. git config --global user.email "your_email_address@example.com"
        4.5.3 正式推送当面目录的文件到Gitlab仓库
  1. cd /root/flask_demo
  2. git init --initial-branch=main
  3. git remote add origin git@gitlab.example.com:root/flase_demo.git
  4. git add .
  5. git commit -m "Initial commit"
  6. git push --set-upstream origin main
        4.5.4 验证推送

5. 安装Gitlab-Runner(Cli工具)

5.1 Liunx主机安装（推荐）

  1. # Linux x86-64
  2. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-amd64"
  3.  
  4. # Linux x86
  5. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-386"
  6.  
  7. # Linux arm
  8. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-arm"
  9.  
  10. # Linux arm64
  11. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-arm64"
  12.  
  13. # Linux s390x
  14. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-s390x"
  15.  
  16. # Linux ppc64le
  17. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-ppc64le"
  18.    
  19. # Linux x86-64 FIPS Compliant
  20. sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.gitlab.cn/latest/binaries/gitlab-runner-linux-amd64-fips"

  1. 授权执行：

    sudo chmod +x /usr/local/bin/gitlab-runner

  2. 创建极狐GitLab CI 用户：

    sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

  3. 安装并作为服务运行：

    1. sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
    2. sudo gitlab-runner start

    确保您在 $PATH 中拥有 /usr/local/bin/ 进行 root 操作，否则可能会出现 command not found 错误。 或者，您可以在其他位置安装 gitlab-runner，比如 /usr/bin/。

本文章演示参与此方式：

  1. 添加官方极狐GitLab 仓库：

    对于 Debian/Ubuntu/Mint：

    curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

    对于 RHEL/CentOS/Fedora：

    curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

    Debian 用户应该使用 APT Pinning。为了方便用户安装使用极狐GitLab Runner，我们在中国国内设置了极狐GitLab 镜像站点。

  2. 安装最新版本的极狐GitLab Runner，或跳到下一步，安装特定版本。

    从 14.0 开始，默认禁用 skel 目录使用，以避免 No such file or directory 作业错误。

    对于 Debian/Ubuntu/Mint：

    sudo apt-get install gitlab-runner

    对于 RHEL/CentOS/Fedora：

    sudo yum install gitlab-runner

在 14.7 及更高版本中，符合 FIPS 140-2 的极狐GitLab Runner 版本可用于 RHEL 发行版。 您可以将 gitlab-runner-fips 用作包名称以安装这个版本，而不是使用 gitlab-runner。

 **下面演示的是Docker部署Gitlab-Runner（不推荐哈，容器嵌套排错非常麻烦。）

5.2 创建Gitlab-Runner容器

  1. #创建你的配置文件管理目录
  2. mkdir -p /srv/gitlab-runner/config
  3.  
  4. #通过Docker容器运行包含Gitlab-runner的容器，并且挂载主机的Docker套接字
  5. docker run -d --name gitlab-runner --restart always \
  6.   -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  7.   -v /var/run/docker.sock:/var/run/docker.sock \
  8.   gitlab/gitlab-runner:latest

5.3 验证GItlab-Runner安装

  1. #Linux主机安装验证
  2. gitlab-runner help
  3. #Docker容器安装验证
  4. docker ps -a | grep gitlab-runner

5.4 配置与注册Gitlab-Runner执行器

        配置与注册Gitlab-Runner执行器有多种方式，你可以通过gitlab-runner register命令交互式注册，也可以直接编写config.tomol来实现。当然目的就是生成config.toml，使得对应的执行器能找到配置文件。

        下面两种方式均适用Linux主机或者Docker部署的Gitlab-runner

5.5 获取Gitlab-Runner执行器注册Token

                 进入Gitlab-设置-CI/CD-Runners

                                                                       

                **国内版本的获取方式 ，Gitlab容器镜像为gitlab-jh结尾的是国内版本

                **国外版本获取到注册Runner的Token，Gitlab容器镜像结尾为gitlab-ce为国外版本

              ***填写你希望这个Runer来干什么。因为项目可能存在多个Runer来执行不同阶段需要进行区分。 

              ***最重要的是拿到注册的令牌！即。glrt开头的这个。

5.6 gitlab-runner register命令交互式注册Gitlab执行器

GitLab Runner 命令 | 极狐GitLab

5.7 直接编写config.tomol来实现注册Gitlab执行器。

        在/etc/gitlab-runner/config.toml编写对应执行器的配置文件，下面是一个使用Docker执行器并且挂载主机套接字配置文件例子：

        Docker部署的Gitlab-Runner

        直接修改挂载主机上的/srv/gitlab-runnner/config/config.toml

  1. [[runners]]
  2.   name = "My Docker Runner"
  3.   url = "https://gitlab.example.com/" #替换成你的Gitlab域名
  4.   token = "T4Hdd1hz2NzHzmS3jm3u" #替换为你获取到的执行器的Token,查看步骤
  5.   executor = "docker"
  6.   [runners.custom_build_dir]
  7.   [runners.cache]
  8.     [runners.cache.s3]
  9.     [runners.cache.gcs]
  10.     [runners.cache.azure]
  11.   [runners.docker]
  12.     tls_verify = false
  13.     image = "docker:20.10.16"
  14.     privileged = true
  15.     pull_policy = "if-not-present"
  16.     disable_entrypoint_overwrite = false
  17.     oom_kill_disable = false
  18.     disable_cache = false
  19.     volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
  20.     extra_hosts = ["gitlab.example.com:192.168.91.103"] #替换为你的Gitlab域名，不然Docker容器中的执行器解析不到gitlab的地址
  21.     shm_size = 0

                替换其中的TOKEN，URL,以及你的extra_hosts映射的内部地址。 

5.8 验证你的Gitlab-Runner执行器配置

gitlab-runner verify

回显：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.  
  2. variables:
  3.   CI_REGISTRY_USER: "Your_User"
  4.   CI_REGISTRY_PASSWORD: "Your_Password"
  5.   CI_REGISTRY: "Your_REGISTRY "
  6.   tag: "v2"
  7.  
  8. stages:         
  9.   - build
  10.   - sonarqube-check
  11.  
  12. build:       # This job runs in the build stage, which runs first.
  13.   stage: build
  14.   script:
  15.     - ls
  16.     - docker build -t python-demo:$tag .
  17.     - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  18.     - docker tag python-demo:$tag xxxx:$tag
  19.     - docker push xxx:$tag
  20.  
  21.

        1、替换其中CI_REGISTRY_USER、CI_REGISTRY以及CI_REGISTRY_PASSWORD变量为你仓库的用户名和密码来访问容器镜像仓库。

        2、替换docker tag 后跟你的仓库。

        5.10.2 运行推送测试

点击下面的Commit.然后查看流水线状态。

登陆你的仓库验证即可。 

   

6 . 配置项目的Gitlab-CI流水线集成代码审核静态审查（STAT）转为SonarQube

         到这一步有那么一丢丢问题，因为需要Gitlab企业版才能使用代码审核静态审查（STAT），故放弃。

         这里选择用docker-compose部署一个SonarQube,使用SonarQube来提供静态代码扫描的能力。

6.1 使用docker-compose部署一个SonarQube

  1. version: "3"
  2.  
  3. services:
  4.   sonarqube:
  5.     image: sonarqube:community
  6.     depends_on:
  7.       - db
  8.     environment:
  9.       SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
  10.       SONAR_JDBC_USERNAME: sonar
  11.       SONAR_JDBC_PASSWORD: sonar
  12.     volumes:
  13.       - /srv/sonarqube/sonarqube_data:/opt/sonarqube/data
  14.       - /srv/sonarqube/sonarqube_extensions:/opt/sonarqube/extensions
  15.       - /srv/sonarqube/sonarqube_logs:/opt/sonarqube/logs
  16.     ports:
  17.       - "9000:9000"
  18.  
  19.   db:
  20.     image: postgres:12
  21.     environment:
  22.       POSTGRES_USER: sonar
  23.       POSTGRES_PASSWORD: sonar
  24.     volumes:
  25.       - /srv/sonarqube/postgresql:/var/lib/postgresql
  26.       - /srv/sonarqube/postgresql_data:/var/lib/postgresql/data
  27.

        代码解释：

这段 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存储卷

  1. $> docker volume create --name sonarqube_data
  2. $> docker volume create --name sonarqube_logs
  3. $> docker volume create --name sonarqube_extensions

6.3 启动 SonarQube和PostgreSQL 服务

docker-compose up -d

6.4 会启动失败，这里会有一个虚拟内存报错

6.5 解决内存映射区域的问题

官网提示：

Maximum map count check | Elasticsearch Guide [8.13] | Elastic

sysctl -w vm.max_map_count=262144
  1. #查看当前进程可以拥有的最大内存映射区域数量
  2. sysctl -n vm.max_map_count
  3. #写入进程可以拥有的最大内存映射区域数量为262144
  4. sysctl -w vm.max_map_count=262144
  5. #验证#查看当前进程可以拥有的最大内存映射区域数量
  6. sysctl -n vm.max_map_count

6.6 重启SonarQube和PostgreSQL 服务 

docker-compose restart

6.7 访问宿主机➕900端口,访问SonarQube

        默认用户和密码均为：admin

6.8 SonarQube修改默认admin密码

        不做演示，根据密码策略修改

6.9  SonarQube添加本地个人令牌

  1. 选择创建新项目。
  2. 为您的项目提供项目密钥和显示名称，然后选择设置。
  3. 在“提供令牌”下，选择“生成令牌”。为您的令牌命名，选择生成，然后单击继续。

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仓库

  1. git add .
  2. git commit -m "sec commit"
  3. git push --set-upstream origin main

        Gitlab仓库验证：

6.14 将我们上传的.gitlab.ci编辑正式的 .gitlab-ci.yml 流水线文件

                现在我们仓库有了.gitlab.ci以及.gitlab-ci.yml （正儿八经的流水线文件）

                需要将Sonarqube给我们的示例ci文件编辑到.gitlab-ci.yml中。

                正式编辑之前我们先来拆分解释一下示例.gitlab.ci文件。

  1. image: 
  2.     name: sonarsource/sonar-scanner-cli:latest
  3.     entrypoint: [""]
  4.  
  5. variables:
  6.   SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
  7.   GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  8.  
  9. stages:
  10.   - sonarqube-check
  11.   - sonarqube-vulnerability-report
  12.  
  13. sonarqube-check:
  14.   stage: sonarqube-check
  15.   dependencies:
  16.     - get-binaries
  17.     - build
  18.   cache:
  19.     policy: pull
  20.     key: "${CI_COMMIT_SHORT_SHA}"
  21.     paths:
  22.       - sonar-scanner/
  23. script: 
  24.     - sonar-scanner
  25.   allow_failure: true
  26.   rules:
  27.     - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  28.     - if: $CI_COMMIT_BRANCH == 'master'
  29.     - if: $CI_COMMIT_BRANCH == 'main'
  30.     - if: $CI_COMMIT_BRANCH == 'develop'
  31.  
  32. sonarqube-vulnerability-report:
  33.   stage: sonarqube-vulnerability-report
  34.   script:
  35.     - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=gitops_with_fleet&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  36.   allow_failure: true
  37.   rules:
  38.     - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  39.     - if: $CI_COMMIT_BRANCH == 'master'
  40.     - if: $CI_COMMIT_BRANCH == 'main'
  41.     - if: $CI_COMMIT_BRANCH == 'develop'
  42.   artifacts:
  43.     expire_in: 1 day
  44.     reports:
  45.       sast: gl-sast-sonar-report.json
  46.

这部分流水线分为全局配置、阶段配置

其中全局配置内容为：image,variables,stages,script

                  image定义全局使用的镜像，

        variables定义全局可以使用的变量。

        stages定义构建阶段。

两个阶段配置内容为：sonarqube-check,sonarqube-vulnerability-report。

sonarqube-check阶段

        dependencies获取构建阶段的产物，比如在你的java代码在build阶段会有一个xxx.jar的产物，那么在这个阶段dependencies就可以获取到这个产物。

        cashe:使用 cache 指定要在作业之间缓存的文件和目录列表,阶段中要使用其他阶段的产物或者文件可以通过cashe来解决。

        script：定义执行shell命令

        allow_failure:True,下面为官方解释很通俗了，就是阶段可以失败，但流水线不会停。

sonarqube-vulnerability-report。

这里单独说一下，这个阶段会生产一个报告，这个报告依旧需要订阅Gitlab的Ultimate的服务。

Sourqube的给的提示是，如果你没有订阅服务，可以安全的删除，我们把这个阶段删除就可以了。 

点击文件右上方-edit-Edit single file,删除完毕然后下面Commit即可。

将我们编辑好的.gitlab.ci.yml整合到我们的正儿八经的流水线文件中.gitlab-ci.yml文件.

复制下面的内容到.gitlab-ci.yml文件，先不做提交。

  1.  
  2. variables:
  3.   CI_REGISTRY_USER: "Your_User"
  4.   CI_REGISTRY_PASSWORD: "Your_Password"
  5.   CI_REGISTRY: "Your_REGISTRY "
  6.   tag: "v2"
  7.  
  8. stages:         
  9.   - build
  10.   - sonarqube-check
  11.  
  12. build:       # This job runs in the build stage, which runs first.
  13.   stage: build
  14.   script:
  15.     - ls
  16.     - docker build -t python-demo:$tag .
  17.     - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  18.     - docker tag python-demo:$tag xxxx:$tag
  19.     - docker push xxx:$tag
  20.  
  21.  
  22. sonarqube-check:
  23.   stage: sonarqube-check
  24.   image: 
  25.     name: sonar-scanner:v1
  26.     entrypoint: [""]
  27.   dependencies:
  28.     - build  
  29.   script: 
  30.     - ls
  31.     - sonar-scanner -Dsonar.sources=. -Dproject.settings=sonar-project.properties
  32.   allow_failure: true

1、可以看到我删除了-deploy阶段，并且将sonarqube-vulnerability-report给删除了。

2、我使用的镜像不是官网给的镜像，因为官网给的镜像的jre版本为11，需要jre17。需要自己制作一个容器镜像（下面有教程和dockerfile）.

3、进入容器后执行的命令为sonar-scanner -Dsonar.sources=. -Dproject.settings=sonar-project.properties。

这句命令的意思是

        -Dsonar.sources=. #扫描的文件目录

                  -Dproject.settings=sonar-project.properties #告诉sonar-cli工具你的sonar-project.properties的配置文件在哪里。

4、把全局的image替换到了阶段的image.

6.15 制作sonar-scanner容器镜像

        6.15.1 下载sonar-scanner-cli工具与jre17

SonarScanner CLI

点击上面的链接-选择合适的芯片架构-复制链接 

回到你的主机上执行：
 

  1. #创建目录
  2. mkdir sonar_cli
  3. #进入目录
  4. cd sonar_cli
  5. #下载文件
  6. wget <你的链接>
  7. #解压文件
  8. unzip <你下载的zip包>

此时你得到了下面这个目录：

        bin为sonarcli工具的二进制文件

        conf为 sonarcli工具的配置文件存放位置

        jre为sonarcli工具的运行环境-jre17

        lib为依赖的工具包

可以看到sonar_cli工具已经帮我们解决了sonarcli与jre的环境问题。

        6.15.2 编写dockerfile

下面为示例dockerfile

  1. # 使用 Alpine Linux 作为基础镜像
  2. FROM centos7.9.2009
  3.  
  4.  
  5. # 设置工作目录
  6. WORKDIR /sonar-scanner
  7.  
  8. # 将 sonar-scanner-cli 二进制文件复制到镜像中
  9. COPY sonar-scanner-6.1.0.4477-linux-x64 /sonar-scanner/
  10.  
  11.  
  12.  
  13. # 设置环境变量
  14. ENV SONAR_SCANNER_HOME=/sonar-scanner
  15. ENV PATH=$SONAR_SCANNER_HOME/bin:$PATH
  16.  
  17. # 设置默认命令
  18. ENTRYPOINT [""]

COPY 命令后面替换为你实际解压的文件名称

 将dockerfile与你解压的文件放置在一个目录下，并且删除zip的压缩包。

构建容器镜像。

docker build -t sonar-scanner:v1 .
        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的容器中拿到内部的自签名证书文件

docker cp gitlab-web-1:/etc/gitlab/ssl/ /root/gitlab/

git config --global http.sslCAInfo /root/gitlab/ssl/gitlab.example.com.crt

 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证书以及证书请求以及对于的私钥。
  1. openssl genrsa -out ca.key 2048
  2. openssl req -new -x509 -days 365 -key ca.key -subj "/C=CN/ST=GD/L=SZ/O=Acme, Inc./CN=Acme Root CA" -out ca.crt
  3. openssl req -newkey rsa:2048 -nodes -keyout example.com.key -subj "/C=CN/ST=GD/L=SZ/O=Acme, Inc./CN=*.example.com" -out example.com.csr
  4. openssl x509 -req -extfile <(printf "subjectAltName=DNS:example.com,DNS:www.example.com") -days 365 -in example.com.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out example.com.crt

                注意！

                **需要替换命令中的example.com为你的域名。

                **并且你的Gitlab-Runer容器中需要添加你自定义域名和IP地址的对应关系，不然没法解析.


        4.3.1.2 将Gitlab Server容器内的SSL目录替换成你的证书，因为我们加- V参数了所以在主机上就可以直接操作。
cp ./* /srv/gitlab/config/ssl/
        4.3.1.3 Gitlab容器应用配置与重启
docker exec -it gitlab-web-1 /bin/bash
gitlab-cli reconfigure & gitlab-cli restart
        4.3.1.4 将CA证书复制进Gitlab-Runner容器的证书目录下
docker cp ./ca.crt gitlab-runner:/usr/local/share/ca-certificates/
        4.3.1.5 Gitlab-Runner容器信任CA证书
update-ca-certificates

总结

        截止到现在，Ci阶段到构建镜像、推送镜像、检查代码-Ci阶段就完成了。

        此文章很长，内容比较多、希望可以帮助到小白。加油！

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：【wpsshop博客】
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号