首页 > 其他分享 >gitlab-runner配合k8s完成代码自动打包部署上线

gitlab-runner配合k8s完成代码自动打包部署上线

时间:2023-08-13 20:01:14浏览次数:48  
标签:CI runner gitlab ci 镜像 k8s

前期搭建了云服务器私有的gitlab和k8s环境,但是都是独立运行的,每次代码更新需要手动去打包好镜像,推送到镜像仓库,然后在deployment里面更新image,这样平时不太有问题,但是会给运维我这边产生很多琐事(反正就是想偷懒,能自动化的为什么要手动,懒惰才是提高生产力的动力!)。在这种情况下我就考虑上自动化CI/CD,因为有了gitlab-runner我以为很容易就能完成,结果花了3天时间暂时跑通了整个流程,其中有些部分还是需要后期再优化,下面罗列一下其中遇到的坑:

一、安装注册gitlab-runner

先要确定gitlab-runner是要安装到哪里,我用的gitlab版本是16.0.1,点开你的项目-“设置”-“CI/CD”-“Runner”-“Expand”,在这里新建项目的runner(当然如果你是管理员,你可以在首页的“设置”-“CI/CD”里面新建),这里你可以看到几种安装环境以及官方给出的安装方法:

gitlab-runner配合k8s完成代码自动打包部署上线_docker

这里我选择的Kubernetes(中途也想换成linux算了,直接shell处理不用这么麻烦,本来也不是什么大的项目,最后还是好奇心驱动自己一步步的走下去)。安装Kubernetes executor,我们需要用到helm,helm的安装可以参考官方文档https://helm.sh/zh/docs/intro/install/很简单。

安装完之后我们添加gitlab helm仓库:

helm repo add gitlab https://charts.gitlab.io

更新一下

helm repo update gitlab

查看有哪些版本的gitlab-runner

helm search repo -l gitlab/gitlab-runner

现在我们准备2个yaml文件,values.yaml是最重要的,其中有很多参数需要我们调整,我会提出其中重要的部分,标准文件可以在官网下载

gitlabUrl: https://git.test.com/	#这里需要更改为你自己的gitlab地址

rbac:		
  create: true	#rbac这里需要开启,默认是没有开启的,这样pod会起不来,这里的rules是可以细化的而且会影响到后面的
  							#每一步的执行权限,很重要,下一步的我会研究rbac这块
             
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:20.04"	#executor运行的image
        privileged = true				#一定要是true,否则起不来
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs/client"
        medium = "Memory"
  secret: secrets	#存放runner-registration-token的secret文件,很重要,runner注册的关键

下面我们来创建secret.yaml,就是对应上面runners里面的secret的

apiVersion: v1
kind: Secret
metadata:
  name: projected-secrets
  namespace: gitlab-ci
type: Opaque
stringData:
  runner-registration-token: "glrt-***************" #gitlab里Runner生成的token
  runner-token: ""			#默认是REDACTED,一定要删除,不是runner启动不了,大坑

这样我们就准备好在k8s里运行runner了,之后就能在设置里的Runner里看到连接成功,绿灯

#运行secret
kubectl create -f secret.yaml

#运行runner,这里是在k8s中namespace gitlab-ci下创建名字为gitlab-runner版本0.53.1的depolyment
helm install --namespace gitlab-ci gitlab-runner -f values.yaml gitlab/gitlab-runner --version 0.53.1

这里我是遇到了pipeline报错的情况

ERROR: Job failed (system failure): prepare environment: setting up credentials: secrets is forbidden: 
User "system:serviceaccount:gitlab-ci:default" cannot create resource "secrets" in API group "" in the namespace
"gitlab-ci". Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information

该报错意思是gitlab-ci命名空间下的名为gitlab-runner的serviceaccount没有在kube-system中创建secrets的权限。该问题通常是因为RBAC权限不足引起。通过添加相关的RBAC权限解决,我用的简单粗暴的

kubectl create clusterrolebinding gitlab-admin --clusterrole=cluster-admin --serviceaccount=gitlab-ci:gitlab-runner

二、编辑流水线pipeline

这里我们主要编辑的是项目根目录下的.gitlab-ci.yml文件,这个文件定义了我们是怎么样去打包、测试、部署现有项目(不限于我说的这3步,可以自定义流程),我这里做的是需要更新代码后自动打包成镜像,推送到指定仓库,最后在k8s里更新镜像。

variables: # 声明环境变量
  IMAGE: cn-guangzhou.cr.volces.com/test/web:$CI_COMMIT_SHORT_SHA

stages:          # List of stages for jobs, and their order of execution
  - build
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  tags:
    - k8s
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
      --context $CI_PROJECT_DIR
      --dockerfile $CI_PROJECT_DIR/Dockerfile
      --destination $IMAGE    

deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  tags:
    - k8s
  image:
    name: bitnami/kubectl:latest
    entrypoint: ['']  
  script:
    - kubectl set image -n default deployment/xcx xcx=$IMAGE

语法的话,可以看一下官方文档https://docs.gitlab.com/ee/ci/yaml/,这里我主要说一下我遇到的一些坑。因为用的是私有的镜像仓库,所以我们需要在gitlab项目中设置的变量里定义CI_REGISTRY(镜像仓库地址)CI_REGISTRY_USER(登录账号)CI_REGISTRY_PASSWORD(密码)。

最开始我准备用docker命令去执行build、push,但是写出来pipeline执行就报错:

ERROR: Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?

什么方法都试过了不行,直接放弃,用kaniko。用kaniko需要注意的是由于他的镜像地址是在google的国内拉不下来会报错,用其他地址代替;另外一个就是镜像必须用kaniko:debug的,只有这个才是带shell可以执行命令的。

镜像打包推送完了之后就需要在k8s里面更新镜像,这里需要注意就是加载kubectl的镜像。

通过上述操作就完成了从代码push到gitlab后自动build image, push image, 最后k8s的更新,后续会再研究一下rbac。

标签:CI,runner,gitlab,ci,镜像,k8s
From: https://blog.51cto.com/shevastar/7069454

相关文章

  • ​​Linux搭建GitLab私有仓库
    @[TOC]转载自远控源码文章:Linux搭建GitLab私有仓库,并内网穿透实现公网访问前言GitLab是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的Web服务。Gitlab是被广泛使用的基于git的开源代码管理平台,基于RubyonRails构建,主要针对软件开发过程中产......
  • k8s笔记10
    摘要:组播;;1、docker加入组播(docker加入组播(docker组播))(docker与组播(docker组播)),Docker容器默认不支持UDP/组播流量,在使用容器进行网络应用的开发过程中,需要使用第三方软件支持组播。下面介绍使用Docker加入组播的方法。#创建一个新的网络dockernetworkcreate--driver=......
  • Jenkinsfile使用k8s agent构建失败:Container jnlp was terminated (Exit Code: 1, Rea
    问题描述Jenkinsfile使用k8sagent构建失败jenkins报错截图:查看pod app-system-23-wmx8b-5lnl2-lxvlr的jnlp容器日志:分析处理一般构建失败大都是jnlp容器问题。经以下日志分析发现jenkins主节点和slave节点的jdk版本不一致导致该提示JavaJDK版本不对:hudson/slaves/SlaveComputer......
  • gitlab--services、environment、inherit
    servicesservices 关键字定义了一个Docker镜像,该镜像在链接到image关键字定义的Docker镜像的 job 期间运行。这允许您在构建期间访问服务镜像。服务镜像可以运行任何应用程序,但最常见的用例是运行数据库容器,例如:MySQLPostgreSQLRedis例如,每次构建项目时,使用现有......
  • k8s etcd operator
    在k8s生态中,Operator是灵活管理有状态应用的解决方案。operator通过crd来描述部署的有状态应用和自定义控制器来完成部署和运维工作。EtcdOperator部署Etcd集群,采用的是静态集群的方式。好处是不必依赖一个额外的服务发现机制来组建集群,适合本地容器化部署。难点在于部署时规划好......
  • k8s finalizers和owner references
    finalizers终结器,存放键的列表,列表内的键为空时资源才可被删除。删除指定了Finalizer的对象时,填充.metadata.deletionTimestamp来标记要删除的对象,返回已接受202状态码使其进入只读状态。#创建包含finalizers的configmapcat<<EOF|kubectlcreate-f-apiVersion:v1kind:......
  • k8s 网络模型
    容器网络通信模式在Host模式中,各容器共享宿主机的根网络名称空间,它们使用同一个接口设备和网络协议栈,因此,用户必须精心管理共享同一网络端口空间容器的应用与宿主机应用,以避免端口冲突。Bridge模式对host模式进行了一定程度的改进,在该模式中,容器从一个或多个专用网络(地址池)中获取IP......
  • k8s 容器安全上下文
    容器安全上下文介绍kubernetes为安全运行pod及容器运行设计了安全上下文机制,该机制允许用户和管理员定义pod或容器的特权与访问控制,已配置容器与主机以及主机之上的其它容器间的隔离级别。安全上下文就是一组用来决定容器时如何创建和运行的约束条件,这些条件代表创建和运行容器时使......
  • k8s 准入控制器之ResourceQuota
    资源配额概述尽管LimitRange资源能在名称空间上限制单个容器、Pod或PVC相关的系统资源用量,但用户依然可以创建出无数的资源对象,进而侵占集群上所有的可用系统资源。ResourceQuota资源能够定义名称空间级别的资源配额,从而在名称空间上限制聚合资源消耗的边界,它支持以资源类型来限制......
  • k8s 准入控制器之LimitRanger
    LimitRanger概述尽管用户可以为容器或Pod资源指定资源需求及资源限制,但这并非强制性要求,那些未明确定义资源限制的容器应用很可能会因程序Bug或真实需求而吞掉本地工作节点上的所有可用计算资源。因此妥当的做法是,使用LimitRange资源在每个名称空间中限制每个容器的最小及最大计算......