热门标签
当前位置: article > 正文
纯 k8s 部署实现 gitlab CICD 保姆级教程
作者：AllinToyou | 2024-06-02 02:04:53
赞
踩
纯 k8s 部署实现 gitlab CICD 保姆级教程
gitlab CICD
k8s 安装 GitLab
GitLab 具有三个需要进行持久化的目录，它们分别是 /etc/gitlab、/var/log/gitlab、/var/opt/gitlab，它们分别为 Gitlab 的运行提供配置、日志、数据的持久化。我们使用 nfs 来作为 GitLab 的持久化方式（当然，你也可以选择其他方式），为此，我们需要先安装 NFS，并且在 NFS 的配置文件中进行如下修改：
vim /etc/exports
# 注意，用户的访问权限一定要设置为 no_root_squash，因为 gitlab 需要 root 权限来操作这些文件。
/data/nfs/gitlab/config 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/gitlab/logs 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
/data/nfs/gitlab/data 172.17.33.152(rw,insecure,sync,no_root_squash,subtree_check)
# 启用新的配置文件
exportfs -r
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
随后在 k8s 中安装 gitlab 及其各个组件
kubectl apply -f - << EOF apiVersion: v1 kind: Service metadata: name: gitlab-svc namespace: gitlab spec: type: NodePort ports: - port: 443 targetPort: 443 nodePort: 31443 name: https - port: 80 nodePort: 31080 targetPort: 80 name: http selector: app: gitlab --- apiVersion: apps/v1 kind: Deployment metadata: name: gitlab-dep namespace: gitlab spec: selector: matchLabels: app: gitlab revisionHistoryLimit: 2 template: metadata: labels: app: gitlab spec: containers: - image: gitlab/gitlab-ce name: gitlab imagePullPolicy: IfNotPresent ports: - containerPort: 443 name: https - containerPort: 80 name: http - containerPort: 22 name: ssh volumeMounts: - name: gitlab-config mountPath: /etc/gitlab - name: gitlab-logs mountPath: /var/log/gitlab - name: gitlab-data mountPath: /var/opt/gitlab volumes: - name: gitlab-config nfs: server: 172.17.33.149 path: /data/nfs/gitlab/config - name: gitlab-logs nfs: server: 172.17.33.149 path: /data/nfs/gitlab/logs - name: gitlab-data nfs: server: 172.17.33.149 path: /data/nfs/gitlab/data
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
完成后，查看 gitlab 网页暴露在哪个端口：
kubectl get svc -n gitlab
########################################## 返回结果 #########################################
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE #
# gitlab-svc NodePort 10.102.48.248 <none> 443:31443/TCP,80:31080/TCP 153m #
###########################################################################################
- 1
- 2
- 3
- 4
- 5
访问 gitlab 页面，进入登录界面
管理员用户为 root，其登录密码在容器目录 /etc/gitlab/initial_root_password 文件中，即 nfs 服务器的 /data/nfs/gitlab/config/initial_root_password 文件。获取初始密码：
kubectl exec -it -n gitlab $(kubectl get pods -n gitlab | grep gitlab | awk '{print$1}') -- cat /etc/gitlab/initial_root_password | grep Password:
- 1
登录进入系统，修改初始密码（一定要修改，因为这个临时密码的有效时间只有 24 小时）。页面路径为：右上角头像->Edit profile->左边导航栏->Password
随后可以创建一个普通用户，测试是否能正常使用 git 进行操作。
修改外部 URL
通常情况下，gitlab 会根据机器内部的 FQCN 来标记一个仓库的 url。这就导致了在 gitlab 中复制 clone url 时，其使用的不是 IP 而是一个域名。如果在局域网内部署 gitlab，这个 DNS 显然是不可以使用的。如果我们希望 gitlab 中的 url 直接使用 IP 地址，那么就需要修改配置文件 gitlab.rb
# 由于我们之前将 gitlab 的配置文件挂载到了 /data/nfs/gitlab/config 上，因此通过修改宿主机的配置文件即可
vim gitlab.rb
# 在其中添加一行：
external_url 'http://<ip>:<port>'
# 例如： external_url 'http://172.17.33.149:31080'
# 修改完配置文件后，删除原本的 gitlab pod，让其自动重启，加载配置文件
kubectl delete pod -n gitlab gitlab-5xjfiosd2jn
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
执行完上述操作后，我们尝试登录在外网登录 gitlab，发现无法登录。这是因为 external_url 修改后，导致 Pod 内部，gitlab 的端口也发生了变化。在没有设置之前，gitlab 是暴露在 80 端口，修改之后，gitlab 就暴露在我们设置的那个端口。因此，还需要修改 service 的 tagetPort 字段，才能让外部正常访问到 gitlab：
kubectl edit svc -n gitlab gitlab-svc
# 将 targetPort 设置为之前修改的端口
- 1
- 2
此时，我们已经可以正常访问 gitlab，查看 clone 中的 url，如下图所示：
安装 Harbor
由于 Harbor 的组件实在是太多，因此，使用 helm 作为安装手段来简化安装过程。具体过程参照文档：https://goharbor.io/docs/2.7.0/install-config/harbor-ha-helm/
helm 是一种 k8s 安装工具，它通过模板化的方式，一次性构造出一个大型项目。
# 下载 harbor chart
helm repo add harbor https://helm.goharbor.io
# 将 chart 下载至本地，执行完这一步后，当前路径会出现一个 harbor 文件夹，里面是各种安装文件
helm fetch harbor/harbor --untar
- 1
- 2
- 3
- 4
为了简化过程，我们不对其中的任何一个组件进行外部定制，只为这些组件提供必要的持久化手段。
我们先自行创建 pv 和 pvc：
# 此处使用 nfs 支持持久卷，为此需要创建多个目录以供挂载 for i in chartmuseum database jobservice redis registry trivy;do mkdir -p /data/nfs/harbor/$i; done cat >> /etc/exports << EOF /data/nfs/harbor/registry *(rw,insecure,sync,no_root_squash,subtree_check) /data/nfs/harbor/chartmuseum *(rw,insecure,sync,no_root_squash,subtree_check) /data/nfs/harbor/jobservice *(rw,insecure,sync,no_root_squash,subtree_check) /data/nfs/harbor/database *(rw,insecure,sync,no_root_squash,subtree_check) /data/nfs/harbor/trivy *(rw,insecure,sync,no_root_squash,subtree_check) /data/nfs/harbor/redis *(rw,insecure,sync,no_root_squash,subtree_check) EOF # 更新 nfs exportfs -r # 查看 nfs 当前提供的挂载点 showmount -e # 创建 pv + pvc cat >> pvc-pv-chartmuseum.yaml << EOF apiVersion: v1 kind: PersistentVolume # pv 没有命名空间的限制 metadata: name: harbor-chartmuseum-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteMany nfs: server: 172.17.33.149 path: /data/nfs/harbor/chartmuseum --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: harbor-chartmuseum-pvc namespace: harbor spec: accessModes: - ReadWriteMany volumeMode: Filesystem resources: requests: storage: 5Gi EOF for i in database jobservice redis registry trivy;do cat pvc-pv-chartmuseum.yaml | sed "s/chartmuseum/$i/g" > pvc-pv-$i.yaml; done kubectl apply -f . # 查看 pvc、pv kubectl get pv kubectl get pvc -n harbor
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
现在，我们需要让 helm 创建的 harbor 组件使用我们的 pvc，因此，我们需要定制化这一部分功能。helm 的 chart 安装包，通常的文件结构如下：
<chart>--- conf # 通常不需要关心
|
|- template # 模板文件，就是 k8s 的 yaml 文件，在调用 helm install 指令时，helm 会根据这些模板，生成真正的 yaml 文件，并调用 kubectl apply 来启动
|
|- values.yaml # 重点关心的文件，这个文件里面存放了所有可以定制化的参数。所谓的定制化，实际上就是将模板中的一些默认参数修改为我们希望的值，而这些值，就存放在 values.yaml 文件中。
- 1
- 2
- 3
- 4
- 5
我们进入到 harbor 安装包，修改 value.yaml 文件，让 harbor 的组件使用我们自己的持久卷——不要被 value.yaml 文件的内容吓到了，我们关心的只有很小的一部分。
-
修改服务暴露方式。在自行搭建的小集群内，通常使用的暴露方式是
NodePort，因此我们修改expose.type: nodePort，如下图：
-
修改外部 URL，即
externalURL:http://<your_k8s_ip>:30002。如果不修改，成功部署 harbor 之后，无法登录到 harbor 管理界面，因为 harbor 只信任以这个 URL 访问的 http 请求。这也意味着，之后你也只能使用这个 url 才能登录到 harbor 中。
- 修改持久化方式。重点是修改
persistence字段下的各个existingClaim字段为我们之前创建的 PVC 名称
修改完成后，保存退出。最后安装即可：
# helm install 命令的格式是这样的：
# helm install <name> -n <namespace> <chart_path>
# name: 名称，不重要，给人看的
# namespace: 命名空间，指定后，所有组件都会被安装到这个命名空间下
# chart_path: 安装包的路径
helm install harbor -n harbor harbor/
- 1
- 2
- 3
- 4
- 5
- 6
你可能遇到的问题：
- 执行完安装程序后，过了很久后，pod 一直处在
CrashLoopxxx状态：创建 harbor 是一个很久的过程，你需要耐心等待，如果 10 分钟后还有大量 Pod 没有安装成功，建议从网络、集群状态方向入手解决问题。如果只有个别 Pod 没有启动成功，你可以尝试把这些 Pod 删除，让它们自动重建。
安装 gitlab runner
config.toml 文件中的配置项及其功能可以查看官方文档： https://docs.gitlab.com/runner/executors/kubernetes.html#default-annotations-for-job-pods
概述
gitlab-runner 是 gitlab 提供的一种执行 CICD pipline 的组件。它有多种执行器，每一个执行器都提供一种实现 pipline 的方式，例如：shell 执行器是使用 shell 指令实现，docker 执行器是使用 docker api 实现。其中，最有难度的一种是 kubernetes 执行器。这种执行器会使用 k8s api 来实现 CICD pipline。
runner 的 k8s 执行器是这样执行 pipline 的：
- 首先，runner 会通过 RBAC 认证获取到调用 k8s 集群 API 的权限。
- runner 会监听 gitlab，当有合适的
job时，runner 会自动抓取任务执行。请注意，一个流水线中可以有很多个stage，这些stage是串行执行的，而一个stage中又可以有多个并行的job，runner 抓取的任务是以job为单位，而不是stage，更不是pipline。 - 随后，runner 会调用 k8s API，创建一个用于执行该 job 的 pod。通常来说，runner 创建的所有 pod 有一个通用模板，我们需要在 runner 的
config.toml配置文件中配置这个模板。但 pod 中具体使用什么镜像、在 pod 中执行什么命令，这些都是在后续的.gitlab-ci.yml文件中配置，并且随着 job 的不同而不同。 - 在完成了 job 内的工作后，runner 会将这个临时 pod 删除。
配置 ConfigMap
将主节点 kubeconfig 内容添加到 secret 中。这个文件的内容是 kubectl 访问 k8s 集群的准入 Token，只有在指定了该 Token 后，才能使用 kubectl 指令来对集群内的各种资源进行增删改查。由于 runner 在 CICD 过程中需要对 k8s 集群进行操作，因此，每一个 runner 中都必须具备 Token以供 gitrunner 的 k8s 执行器使用。
使用 secrete 将这个 Token 以卷挂载的方式加入到 runner 创建的 pod 中。
温馨提示：请务必保证 config 文件中包含的证书与密钥没有过期
kubectl create secrete generic -n gitlab --from-file ~/.kube/config
- 1
接下来配置 runner 的 config.toml 文件
apiVersion: v1 kind: ConfigMap metadata: name: gitlab-runner-config namespace: gitlab data: # 以下是 gitlab-runner 的配置文件模板，gitlab-runner 会实时读取 config.toml 配置文件并热加载，因此，在 gitlab-runner 部署后，可以直接通过修改 config.toml 文件来更新配置 config-template.toml: |- [[runners]] # cache 不是必要的。它的作用是缓存项目的依赖包，从而大大减少项目构建的时间 [runners.cache] # Type 可以选择 s3 和 gc3 两种对象存储协议 Type = "s3" # Shared 字段控制不同 runner 之间的缓存是否共享，默认是 false Shared = false [runners.cache.s3] ServerAddress = <s3_host:s3_port> # 相当于用户名 AccessKey = <key> # 相当于密码 SecretKey = <secret> # 桶名 BucketName = <bucket_name> Insecure = true # 重要，用于配置 kubernetes 执行器。 [runners.kubernetes] # 容器镜像拉取规则 pull_policy = "if-not-present" # CICD 产生的 Pod 所在的命名空间，这个 namespace 需要和后续创建的所有资源所在 namespace 保持一致，否则会导致角色和它需要创建的资源不在同一个 namespace 从而失败 namespace = "gitlab" poll_time = 600 cpu_request = "1" service_cpu_request = "200m" dns_policy = "none" # 用于配置该 Executor 生成的 Pod 中的 /etc/hosts 文件 [[runners.kubernetes.host_aliases]] ip = "127.0.0.1" hostnames = ["localhost"] # 用于配置 Pod 的 DNS 配置 [runners.kubernetes.dns_config] nameserver = [ <DNS_1> <DNS_2> ... ] searches = [ <searches_1> <searches_2> ... ] # 共用宿主机的 docker [runners.kubernetes.volumes] [[runners.kubernetes.volumes.host_path]] name = "docker" mount_path = "/var/run/docker.sock" read_only = true host_path = "/var/run/docker.sock" # 将 kubeconfig 内容挂载在 [[runners.kubernetes.volumes.secret]] name = "kube-config" mount_path = "/home/" read_only = true # 以下这些配置是用于后续注册 runner 时使用 group_runner_concurrent: "10" group_runner_executor: "kubernetes" group_runner_name: "gitlab-runner" group_runner_tag: "gitlab-runner" # 这个地方需要修改为 gitlab 的地址 group_runner_url: "http://bdcgit.cuc.edu.cn:8089/" # 修改为 gitrunner 注册的 token group_runner_token: "UwYRJp8vw4S-MbbJxgoT"
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
获取上述配置中的 token 如下：
-
如果要将 runner 注册在全局下（所有项目都能使用）：
a. 登录 root 管理员账户
b. Admin --> CI/CD --> Register an instance runner
如下图所示：
-
如果要将 runner 注册在一个组下：
a. 只要你是组管理员即可，进入组管理界面
b. CI/CD --> Register a group runner
如下图所示：
配置 gitlab-runner 注册脚本
将 runner 部署到 k8s 上之后还需要将 runner 注册到 gitlab 上才能使用，为此，我们需要写一个脚本，让 runner 部署完成后自行执行，从而完成注册。我们通过 configmap 来将这个脚本挂载到 runner 所在的 Pod 中，这样，只要在之后创建容器时使用启动脚本就能自动执行。
apiVersion: v1
kind: ConfigMap
metadata:
name: gitlab-runner-register
namespace: gitlab
data:
run.sh: |
# !/bin/bash
# 这里的 --non-interactive 是指使用非交互模式注册，如果不用该限定符，就会使用交互式注册，那需要我们手动键入所有必要的配置，这显然不符合自动化的宗旨
# 下面所涉及到的所有环境变量都是在后续的 Deployment 中配置的
gitlab-runner register --non-interactive --name $GROUP_RUNNER_NAME --url $GROUP_RUNNER_URL --registration-token $GROUP_RUNNER_TOKEN --executor $GROUP_RUNNER_EXECUTOR --template-config /config/config-template.toml --tag-list $GROUP_RUNNER_TAG --locked
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
Deployment
apiVersion: apps/v1 kind: Deployment metadata: name: gitlab-runner namespace: gitlab spec: replicas: 1 selector: matchLabels: name: gitlab-runner template: metadata: labels: name: gitlab-runner spec: #nodeName: bdcenter-k8s-worker9 serviceAccountName: gitlab-runner-admin imagePullSecrets: - name: harbor-secret containers: - image: gitlab/gitlab-runner:latest imagePullPolicy: IfNotPresent name: gitlab-runner env: # 将我们之前在 configmap 中设置的项通过环境变量的方式注入到容器中 - name: GROUP_RUNNER_CONCURRENT valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_concurrent - name: GROUP_RUNNER_NAME valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_name - name: GROUP_RUNNER_TAG valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_tag - name: GROUP_RUNNER_TOKEN valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_token - name: GROUP_RUNNER_URL valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_url - name: GROUP_RUNNER_EXECUTOR valueFrom: configMapKeyRef: name: gitlab-runner-config key: group_runner_executor lifecycle: # 在容器启动之后，执行注册脚本 postStart: exec: command: ["/bin/sh", "-c", "sh /foo/run.sh && sed -i 's/concurrent = 1/concurrent = '$GROUP_RUNNER_CONCURRENT'/g' /etc/gitlab-runner/config.toml"] resources: requests: cpu: "100m" limits: cpu: "100m" volumeMounts: - name: gitlab-runner-config mountPath: /config - name: script-volume mountPath: /foo volumes: - name: gitlab-runner-config configMap: name: gitlab-runner-config items: - key: config-template.toml path: config-template.toml - name: script-volume configMap: name: gitlab-runner-register items: - key: run.sh path: run.sh mode: 0755 --- # 创建角色，runner 生成的 pod 会使用下述角色信息通过 k8s 的 RBAC，从而能够创建 k8s 的相应资源 apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-runner-admin namespace: gitlab --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: gitlab name: gitlab-admin rules: - apiGroups: [""] resources: ["*"] verbs: ["*"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: gitlab-admin namespace: gitlabE subjects: - kind: ServiceAccount name: gitlab-runner-admin namespace: gitlab roleRef: kind: Role name: gitlab-admin apiGroup: rbac.authorization.k8s.io
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
最后，将上述所有资源应用到 k8s 集群中，等待 runner 启动完成。
如果能够在 gitlab 管理员界面查看到 runner，说明 runner 安装注册成功。
使用 gitlab CICD
配置 gitlab 环境变量
在 Group——>Your Group——>Settings——>CI/CD——>Variables 中填入相关环境变量
这些环境变量可以在后续的 .gitlab-ci.yml 文件中使用。
# 镜像仓库密码
REGISTRY_PASSWORD: Harbor12345
# 镜像仓库 url，例如：172.17.33.146:1180
REGISTRY_URL: <your_harbor_url>
# 镜像仓库用户名
REGISTRY_USERNAME: admin
- 1
- 2
- 3
- 4
- 5
- 6
请注意，添加变量时默认会将其设置为 “Protected”，这会让该变量只能被保护分支使用（保护分支通常是 default 分支），如果我们想要所有分支都能使用这个变量，应当将取消其 Protected 属性，如下图：
配置 .gitlab-ci.yml Pipeline 文件
下例为 npm 前端项目部署的 .gitlab-ci.yml 演示，对该文件有以下几点需要说明：
- 每个 stage 都会选择一个 runner 来执行，这意味着可以根据 stage 的不同，选择具有特定功能的 runner
- 在 kubernetes executor 模式中，每一个 stage，runner 都会使用 k8s api 在指定的命名空间中创建一个专用于 pipline 的临时 Pod，在这个 Pod 中执行完当前 stage 的所有 script，随后自动销毁
- CI 过程中，可以简单的认为，runner 将当前 git 代码仓库整个拷贝到了容器当中，而工作目录则是项目的根目录，因此，如果有什么文件需要进行拷贝、修改、删除，请尤其注意这一点。
# .gitlab-ci.yaml # 选取全局基础镜像为node:latest image: $REGISTRY_URL/library/node:latest # 表示 pipeline 分几个阶段进行，下例中表示 pipeline 分 package - build - depoly 三个阶段依次执行 stages: - package - build - deploy # 表示package阶段的开始 package: stage: package # 表示此阶段的基础镜像为node image: $REGISTRY_URL/library/node:latest # （可选）使用cache进行缓存 # cache: # 缓存git中没有被跟踪的文件 # untracked: true # key表示指定分支的指定Job使用此cache # key: "$CI_COMMIT_REF_SLUG" # 表示要缓存的目录,这里的node_modules目录是安装的依赖包目录 # paths: # - node_modules/ # 表示缓存的拉取策略 # policy: pull-push # 表示要执行的脚本 script: - npm install --registry=https://registry.npm.taobao.org # 将项目打包 - npm run build # tag 表示执行此阶段的 gitlab-runner tags: - [group_runner_name] # 使用 artifacts 来传递 stage 间的文件，这里需要将 build 生成的 dist 文件夹传至下一阶段进行镜像的制作 artifacts: paths: - dist build: # 使用docker作为基础镜像，使用 docker 的目的是生成镜像，并推送到本地镜像仓库 image: $REGISTRY_URL/library/docker:19.03.0-dind # 声明一些参数 services: - name: docker:19.03.0-dind command: ["--registry-mirror=https://dockerhub.azk8s.cn/"] command: ["--insecure-registry=$REGISTRY_URL"] stage: build script: # 查看docker信息 - docker info # 登录Harbor私有仓库 - docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD $REGISTRY_URL # docker build命令制作镜像，注意-t后面为镜像名称，此镜像名称需和deployment.yaml文件中的镜像名称对应。 # 确保项目根目录中已经存在一个 Dockerfile - docker build -t $REGISTRY_URL/$CI_PROJECT_NAMESPACE-$CI_PROJECT_NAME:v$CI_PIPELINE_ID . # 将制作的镜像push到远程私有仓库 - docker push $REGISTRY_URL/$CI_PROJECT_NAMESPACE-$CI_PROJECT_NAME:v$CI_PIPELINE_ID tags: - [group_runner_name] deploy: stage: deploy tags: - [group_runner_name] # 使用kubectl基础镜像，dockerhub 的 kubectl 基础镜像由于遵循最简化的原则，往往不符合我们的要求，因此，这个 kubectl 镜像是我们自己构建的，Dockerfile 在后文中会展示 image: $REGISTRY_URL/kubectl:latest script: - kubectl version # 使用 kubectl apply命令部署应用，至于 kubectl 的构建文件，此处不再展示，只是 - kubectl apply -f deployments/
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
当做好这一切的工作之后，就可以在 gitlab 上运行流水线了，如下图所示：
kubectl 镜像 Dockerfile
# alpine 镜像是一个轻量级的调试容器，它具有比 busybox 更完善的工具
FROM alpine:latest
# 这里的 KUBECONFIG 环境变量为 kubectl 指示出证书、密钥文件的路径
ENV KUBECONFIG=/home/config
# 将 kubectl 可执行文件拷贝到镜像中。这里是在主节点中执行的，你也可以在网上下载 kubectl 再复制到镜像中
COPY kubectl /usr/local/bin/
# 将 kubectl 设置为可执行权限
RUN chmod +x /usr/local/bin/kubectl
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/AllinToyou/article/detail/660461
推荐阅读
相关标签
