GitLab CI+GitLab Runner+k8s

external_url ‘http://自己服务器IP’，#这个是gitlab url，就是以后访问要使用的，所以一定要设置好，严格按照格式设置，"http://"不能省略，生产环境建议使用域名。出现以上证明启动成功，使用上面设置的external_url ‘http://自己服务器IP’，访问一下，生产环境建议设置一个域名，使用nginx代理一下。在上面的示例中，安装GitLab Runner

一番番

1203人浏览 · 2023-06-25 16:06:31

一番番 · 2023-06-25 16:06:31 发布

持续集成/交付（CI/CD）是现代软件开发不可或缺的一部分，可以显著提高开发效率和代码质量。
在本文中，我们将介绍如何使用GitLab CI在Kubernetes集群上运行Java项目，并实现自动化的构建、镜像推送和应用部署。

和Jenkins相比，GitLab本身，就相当于Jenkins的Master。 GitLab Runner类似Jenkins的Agent（Slave），可以理解为运行Job的容器或管理者

前置条件
在开始之前，你需要满足以下条件：

创建一个Kubernetes集群
手动安装创建一个GitLab源码库
手动安装一个GitLab Runner
了解GitLab CI/CD的基本概念和使用方法

准备安装包：
1.安装gitlab
gitlab-ce-12.0.0-ce.0.el7.x86_64.rpm
gitlab-runner-12.0.0-1.x86_64.rpm
如果确实依赖包，可以选择yum安装
即：

yum - y install gitlab-ce-12.0.0-ce.0.el7.x86_64.rpm

修改中文
默认语言使用的英文，如果想修改为中文的话。操作步骤：右上角头像 -> Settings -> Preferences -> Language -> 简体中文 -> save changes。

初始化；
启动，首先要修改初始化文件，一般是在/etc/gitlab/gitlab.rb，主要是修改如下几项：
external_url ‘http://自己服务器IP’，#这个是gitlab url，就是以后访问要使用的，所以一定要设置好，严格按照格式设置，"http://"不能省略，生产环境建议使用域名。

邮件设置：
# 启用 smtp 服务
gitlab_rails['smtp_enable'] = true
# 配置 smtp 服务地址，这里需要填写邮件服务里面的“SMTP服务器地址”(如下是网易163邮箱的smtp服务器地址)
gitlab_rails['smtp_address'] = "smtp.163.com"
# 配置 smtp 服务的端口号(默认)
gitlab_rails['smtp_port'] = 465
# 配置发送邮件的电子邮箱名称(即刚才注册的邮箱名称)
gitlab_rails['smtp_user_name'] = "xxx@163.com"
# 配置发送邮件的电子邮箱授权密码，刚才在邮箱里面开启 SMTP 服务的时候弹框提示的那一串【授权密码】（切记：这里不是邮箱的登录密码，是SMTP的授权密码）
gitlab_rails['smtp_password'] = "xxAxxSxxDx"
# 配置 SMTP 服务的域名，和上面的smtp服务器地址一致(如下是网易163邮箱的smtp域名)
gitlab_rails['smtp_domain'] = "smtp.163.com"
# 配置 SMTP 鉴定类别(默认 login 即可)
gitlab_rails['smtp_authentication'] = "login"
# 开启纯文本通信协议扩展
gitlab_rails['smtp_enable_starttls_auto'] = true
# 开启 smtp_tls (传输安全)
gitlab_rails['smtp_tls'] = true

# gitlab 服务邮件发送来源邮箱(即发出邮件的发送方邮箱)，填写刚才注册的邮箱即可
gitlab_rails['gitlab_email_from'] = 'git_xxx@163.com'
gitlab_rails['time_zone'] = 'Asia/Shanghai'

还有就是数据目录存放，默认存放到/var/lib/gitlab下面，可以修改为其他较大空间的目录。

#重新加载配置信息
gitlab-ctl reconfigure
#重新启动服务
gitlab-ctl restart
启动完成后，查看一下状态：
出现以上证明启动成功，使用上面设置的external_url ‘http://自己服务器IP’，访问一下，生产环境建议设置一个域名，使用nginx代理一下。
首次访问会提示更新密码，设置一个新的密码就可以了，默认用户名root。

其他命令
#启动 gitlab 服务gitlab-ctl start
#停止 gitlab 服务gitlab-ctl stop
查看版本：
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

管理员配置：
http://127.0.0.0/admin 管理员配置
在这里插入图片描述

在这里插入图片描述

2、安装gitlab-runner
yum -y install gitlab-runner-12.0.0-1.x86_64.rpm
2. 安装GitLab Runner
为了在Kubernetes集群中执行GitLab CI Pipeline，我们需要在该集群中安装GitLab Runner并配置相应的Runner Executor。具体步骤如下：
2.1 获取GitLab Runner的注册信息
在GitLab源码库中获取GitLab Runner的注册信息，包括URL和registration token等。
2.2 配置GitLab Runner
使用以下命令注册Runner：

gitlab-runner register \
  --non-interactive \
  --url "http://YOUR_GITLAB_URL/" \
  --registration-token "YOUR_REGISTRATION_TOKEN" \
  --executor "shell" \
  --description "k8s-runner" \
  --tag-list "build,k8s,java" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

向GitLab-CI注册一个Runner必须有：GitLab-CI的url和注册token。
token用于确定Runner是所有工程都能够使用的Shared Runner还是具体某一个工程才能使用的Specific Runner。

如果要注册Shared Runner，需要到管理界面的Runners页面里面查找注册token。使用管理员登录，点击Admin Area菜单，右侧导航栏Runners，
在这里插入图片描述通过gitlab-ci-multi-runner register注册的Runner配置会存储在/etc/gitlab-runner/config.toml中，如果需要修改可直接编辑该文件。GitLab-CI会为每个Runner生成一个唯一的token，以后Runner就通过token与GitLab-CI进行通信。

变量配置：
在这里，你需要将YOUR_GITLAB_URL和YOUR_REGISTRATION_TOKEN替换为你的GitLab URL和注册令牌。
图形化配置查看
获取GitLab Runner的注册信息。
获取项目专用Runner的注册信息。
登录GitLab。
在顶部导航栏中，选择Projects > Your projects。
在Your projects页签下，选择相应的Project。
在左侧导航栏中，选择Settings > CI / CD。
单击Runners右侧的Expand。
在这里插入图片描述
命令查询

gitlab-runner list
列出注册的Runner,显示Runner的状态、标签、运行器等信息。
gitlab-runner stop 28923
停止指定Runner,28923为Runner的ID。停止Runner后,其状态变为stopped,不会再执行新任务。
gitlab-runner verify
验证Runner的配置是否正确。

2.3 缓存配置
GitLab Runner对缓存方案的支持有限，所以我们需要使用挂载Volume的方式做缓存。在上面的示例中，安装GitLab Runner时默认使用/opt/cache目录作为缓存空间。你也可以通过修改values.yaml文件中的runners.cachePath字段修改缓存目录。
例如，如需建立Maven缓存，你可以在variables下添加MAVEN_OPTS变量并指定本地缓存目录：
variables:
KUBECONFIG: /etc/deploy/config
MAVEN_OPTS: “-Dmaven.repo.local=/opt/cache/.m2/repository”

2.4 设置全局变量
在GitLab源码库中设置全局变量，包括Registry用户名、密码和KubeConfig的编码字符串。

REGISTRY_USERNAME：镜像仓库用户名。
REGISTRY_PASSWORD：镜像仓库密码。
kube_config：KubeConfig的编码字符串。

执行以下命令生成KubeConfig的编码字符串：

echo $(cat ~/.kube/config | base64) | tr -d " "

编写.gitlab-ci.yml
创建.gitlab-ci.yml文件来定义Pipeline，该Pipeline将完成Java项目的编译构建、镜像推送和应用部署。示例.gitlab-ci.yml文件如下所示：

image: docker:stable  # Pipeline中各个步骤阶段的构建镜像没有指定时， 默认使用docker:stable镜像
stages:
  - package                # 源码打包阶段
  - docker_build         # 镜像构建和打包推送阶段
  - deploy_k8s           # 应用部署阶段
variables:
  KUBECONFIG: /etc/deploy/config   # 定义全局变量KUBECONFIG
maven源码打包阶段。
mvn_build_job:     # job名称
  image: maven:3.6.2-jdk-14  # 本阶段构建使用的构建镜像
  stage: package      # 关联的阶段名称
  tags:                     # GitLab Runner的tag
    - k8s-runner
  script:
    - mvn package -B -DskipTests  # 执行构建脚本
    - cp target/demo.war /opt/cache   # 构建物保存至缓存区
镜像构建和打包推送阶段。
docker_build_job:  # job名称
  image: docker:latest # 本阶段构建使用的构建镜像
  stage: docker_build  # 关联的阶段名称
  tags:                      # GitLab Runner的tag
    - k8s-runner
  script:
    - docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD registry.cn-beijing.aliyuncs.com   # 登录镜像仓库
    - mkdir target
    - cp /opt/cache/demo.war target/demo.war
    - docker build -t registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID .     # 打包Docker镜像，使用的tag为本次Pipeline的ID
    - docker push registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID      # 推送Docker镜像
应用部署阶段。
deploy_k8s_job:   # job名称
  image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/kubectl:1.16.6   # 本阶段构建使用的构建镜像
  stage: deploy_k8s   # 关联的阶段名称
  tags:                      # GitLab Runner的tag
    - k8s-runner
  script:
    - mkdir -p /etc/deploy
    - echo $kube_config |base64 -d > $KUBECONFIG   # 配置连接Kubernetes集群的config文件
    - sed -i "s/IMAGE_TAG/$CI_PIPELINE_ID/g" deployment.yaml  # 动态替换部署文件中的镜像tag
    - cat deployment.yaml
    - kubectl apply -f deployment.yaml

需要修改的地方有自己的config文件，已经变量账户名密码
包含模板文件

上述Pipeline包括三个阶段：

package：使用maven构建Java项目，并将构建结果复制到缓存目录；
docker_build：使用Docker构建镜像，并推送到k8s集群Registry；
deploy_k8s：使用kubectl部署应用到Kubernetes集群中。

在这个Pipeline中，我们使用了一些GitLab CI的特性，例如：

使用stages设置流水线的阶段，定义了任务执行的顺序；
使用variables设置变量，这些变量会在整个Pipeline中生效；
使用script脚本指定具体的任务执行命令。

设置tags
Runner的设置可以在GitLab的网页上，进行二次调整，比如tags。
这是对Runner进行分类，以便不同项目的不同业务选择

启动Pipeline
当编辑完成.gitlab-ci.yml文件之后，在GitLab源码库中点击“CI/CD”菜单，手动启动Pipeline。
此时，GitLab Runner将根据.gitlab-ci.yml文件中的定义，自动执行Pipeline并完成Java项目的构建、镜像推送和应用部署。
执行Pipeline
提交.gitlab-ci.yml文件后，Project gitlab-java-demo会自动检测到这个文件并执行Pipeline，如下图所示。
访问服务
如果部署文件中没有指定Namespace，则默认会部署到GitLab命名空间下：
kubectl -n gitlab get svc
预期输出：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
java-demo LoadBalancer 172.19.9.252 xx.xx.xx.xx 80:32349/TCP 1m
浏览器访问xx.xx.xx.xx/demo进行验证。

tips:

stages:
  - test
  - deploy

build:
  stage: test
  tags:
    - linux
  script:
    - make
    - make test
  only:
    - master
    - merge_requests
    - tags

install:
  stage: deploy
  tags:
    - linux
    - production
  script:
    - make
    - make install
  only:
    - tags

示例，上面定义的两个Job，展示了GitLab CI的常见用法。 build属于test阶段，而install属于后面的deploy阶段，build会先于install执行。如果build执行失败，install则不会执行。 build这个Job会在master分支、MR以及打tag三种情况下触发，而install只会在打tag情况下触发。 build会在仅有标签linux的Runner下执行，而install只会在包含linux和production两个标签的Runner下执行。

参考文档：
https://help.aliyun.com/document_detail/106968.html?spm=a2c4g.106712.0.0.2cf75e45IuhKl2

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub