gitlab与jenkins
CI持续集成
CI（持续集成）流程是一个软件开发实践，用于将代码的集成、构建和测试过程自动化。GitLab和Jenkins是常用的工具，可以用于实现CI流程的不同方面。
GitLab是一个代码托管平台，提供了版本控制、代码管理和协作功能。在CI流程中，GitLab通常用于存储代码仓库，并与其他工具（如Jenkins）集成，以便在代码提交或其他事件发生时触发构建和测试过程。
Jenkins是一个开源的持续集成和持续交付（CI/CD）工具，它提供了丰富的功能和插件来自动化构建、测试和部署软件。在CI流程中，Jenkins通常用于配置和执行构建任务，例如在代码提交后自动构建、运行测试和生成构件等。
综上所述，GitLab用于代码管理和版本控制，而Jenkins用于构建和测试等CI任务。它们可以结合使用，以创建一个完整的CI流程，实现代码的自动化构建、测试和部署。当在GitLab上进行代码提交时，可以触发Jenkins任务来执行相应的构建和测试操作。这样的集成可以提高开发团队的效率和软件质量。
部署gitlab
gitlab代码仓库搭建
https://github.com/sameersbn/docker-gitlab
## 全量部署的组件
$ gitlab-ctl status
run: alertmanager: (pid 1987) 27s; run: log: (pid 1986) 27s
run: gitaly: (pid 1950) 28s; run: log: (pid 1949) 28s
run: gitlab-exporter: (pid 1985) 27s; run: log: (pid 1984) 27s
run: gitlab-workhorse: (pid 1956) 28s; run: log: (pid 1955) 28s
run: logrotate: (pid 1960) 28s; run: log: (pid 1959) 28s
run: nginx: (pid 2439) 1s; run: log: (pid 1990) 27s
run: node-exporter: (pid 1963) 28s; run: log: (pid 1962) 28s
run: postgres-exporter: (pid 1989) 27s; run: log: (pid 1988) 27s
run: postgresql: (pid 1945) 28s; run: log: (pid 1944) 28s
run: prometheus: (pid 1973) 28s; run: log: (pid 1972) 28s
run: puma: (pid 1968) 28s; run: log: (pid 1966) 28s
run: redis: (pid 1952) 28s; run: log: (pid 1951) 28s
run: redis-exporter: (pid 1971) 28s; run: log: (pid 1964) 28s
run: sidekiq: (pid 1969) 28s; run: log: (pid 1967) 28s
部署分析
- 依赖postgres
- 依赖redis
使用k8s部署
准备secret文件
$ cat gitlab-secret.txt
postgres.user.root=root
postgres.pwd.root=www.yuchaoit.cn
# 从文件创建
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins create secret generic gitlab-secret --from-env-file=gitlab-secret.txt
secret/gitlab-secret created
启动postgreSQL
$ cat postgres.yaml
apiVersion: v1
kind: Service
metadata:
name: postgres
labels:
app: postgres
namespace: jenkins
spec:
ports:
- name: server
port: 5432
targetPort: 5432
protocol: TCP
selector:
app: postgres
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: postgredb
namespace: jenkins
spec:
accessModes:
- ReadWriteOnce
storageClassName: nfs
resources:
requests:
storage: 200Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: jenkins
name: postgres
labels:
app: postgres
spec:
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
tolerations:
- operator: "Exists"
containers:
- name: postgres
image: postgres:11.4
imagePullPolicy: "IfNotPresent"
ports:
- containerPort: 5432
env:
- name: POSTGRES_USER #PostgreSQL 用户名
valueFrom:
secretKeyRef:
name: gitlab-secret
key: postgres.user.root
- name: POSTGRES_PASSWORD #PostgreSQL 密码
valueFrom:
secretKeyRef:
name: gitlab-secret
key: postgres.pwd.root
resources:
limits:
cpu: 1000m
memory: 2048Mi
requests:
cpu: 50m
memory: 100Mi
volumeMounts:
- mountPath: /var/lib/postgresql/data
name: postgredb
volumes:
- name: postgredb
persistentVolumeClaim:
claimName: postgredb
#创建postgres
[root@k8s-master ~/jenkins-all]#kubectl create -f postgresql.yaml
service/postgres created
persistentvolumeclaim/postgredb created
deployment.apps/postgres created
# 创建数据库gitlab,为后面部署gitlab组件使用
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins exec -it postgres-78dc4bd6bc-g94nd -- bash
root@postgres-78dc4bd6bc-g94nd:/#
root@postgres-78dc4bd6bc-g94nd:/# ps
ps psql pstree pstree.x11
root@postgres-78dc4bd6bc-g94nd:/# psql
psql (11.4 (Debian 11.4-1.pgdg90+1))
Type "help" for help.
root=# create database gitlab;
CREATE DATABASE
root=#
部署redis
$ cat redis.yaml
apiVersion: v1
kind: Service
metadata:
name: redis
labels:
app: redis
namespace: jenkins
spec:
ports:
- name: server
port: 6379
targetPort: 6379
protocol: TCP
selector:
app: redis
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: jenkins
name: redis
labels:
app: redis
spec:
replicas: 1
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
tolerations:
- operator: "Exists"
containers:
- name: redis
image: sameersbn/redis:4.0.9-2
imagePullPolicy: "IfNotPresent"
ports:
- containerPort: 6379
resources:
limits:
cpu: 1000m
memory: 2048Mi
requests:
cpu: 50m
memory: 100Mi
[root@k8s-master ~/jenkins-all]#kubectl create -f redis.yml
service/redis created
deployment.apps/redis created
部署gitlab
注意点：
- 使用ingress暴漏服务
- 添加annotation，指定nginx端上传大小限制，否则推送代码时会默认被限制1m大小，相当于给nginx设置client_max_body_size的限制大小
- 使用服务发现地址来访问postgres和redis
- 在secret中引用数据库账户和密码
- 数据库名称为gitlab
这些yaml怎么写，都是要根据gitlab镜像，需要传入的环境变量，存储等信息，改编而来。
$ cat gitlab.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: gitlab
namespace: jenkins
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
ingressClassName: nginx
rules:
- host: gitlab.yuchaoit.cn
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: gitlab
port:
number: 80
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: gitlab
namespace: jenkins
spec:
accessModes:
- ReadWriteOnce
storageClassName: nfs
resources:
requests:
storage: 200Gi
---
apiVersion: v1
kind: Service
metadata:
name: gitlab
labels:
app: gitlab
namespace: jenkins
spec:
ports:
- name: server
port: 80
targetPort: 80
protocol: TCP
selector:
app: gitlab
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: jenkins
name: gitlab
labels:
app: gitlab
spec:
replicas: 1
selector:
matchLabels:
app: gitlab
template:
metadata:
labels:
app: gitlab
spec:
tolerations:
- operator: "Exists"
containers:
- name: gitlab
image: sameersbn/gitlab:13.2.2
imagePullPolicy: "IfNotPresent"
env:
- name: GITLAB_HOST
value: "gitlab.yuchaoit.cn"
- name: GITLAB_PORT
value: "80"
- name: GITLAB_SECRETS_DB_KEY_BASE
value: "long-and-random-alpha-numeric-string"
- name: GITLAB_SECRETS_SECRET_KEY_BASE
value: "long-and-random-alpha-numeric-string"
- name: GITLAB_SECRETS_OTP_KEY_BASE
value: "long-and-random-alpha-numeric-string"
- name: DB_HOST
value: "postgres"
- name: DB_NAME
value: "gitlab"
- name: DB_USER
valueFrom:
secretKeyRef:
name: gitlab-secret
key: postgres.user.root
- name: DB_PASS
valueFrom:
secretKeyRef:
name: gitlab-secret
key: postgres.pwd.root
- name: REDIS_HOST
value: "redis"
- name: REDIS_PORT
value: "6379"
ports:
- containerPort: 80
resources:
limits:
cpu: 2000m
memory: 5048Mi
requests:
cpu: 100m
memory: 500Mi
volumeMounts:
- mountPath: /home/git/data
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: gitlab
# 创建
$ kubectl create -f gitlab.yaml
检查资源
[root@k8s-master ~/jenkins-all]#kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master 110m 2% 5291Mi 54%
k8s-slave1 26m 1% 400Mi 7%
k8s-slave2 1017m 50% 2552Mi 44%
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins get po -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gitlab-5bdddc77ff-qh4b8 1/1 Running 0 4m13s 10.244.1.114 k8s-slave2 <none> <none>
jenkins-master-75c78b968c-nzxw8 1/1 Running 1 (99s ago) 36m 10.244.1.111 k8s-slave2 <none> <none>
postgres-78dc4bd6bc-g94nd 1/1 Running 0 9m20s 10.244.1.112 k8s-slave2 <none> <none>
redis-56bb5f8cc9-84lb9 1/1 Running 0 7m2s 10.244.1.113 k8s-slave2 <none> <none>
[root@k8s-master ~/jenkins-all]#
# gitlab日志
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins logs gitlab-5bdddc77ff-qh4b8 --tail=20
2023-05-08 06:36:07,530 INFO Included extra file "/etc/supervisor/conf.d/puma.conf" during parsing
2023-05-08 06:36:07,530 INFO Included extra file "/etc/supervisor/conf.d/sidekiq.conf" during parsing
2023-05-08 06:36:07,530 INFO Included extra file "/etc/supervisor/conf.d/sshd.conf" during parsing
2023-05-08 06:36:07,535 INFO RPC interface 'supervisor' initialized
2023-05-08 06:36:07,535 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2023-05-08 06:36:07,535 INFO supervisord started with pid 1
2023-05-08 06:36:08,536 INFO spawned: 'gitaly' with pid 950
2023-05-08 06:36:08,537 INFO spawned: 'puma' with pid 951
2023-05-08 06:36:08,538 INFO spawned: 'gitlab-workhorse' with pid 952
2023-05-08 06:36:08,539 INFO spawned: 'sidekiq' with pid 957
2023-05-08 06:36:08,541 INFO spawned: 'nginx' with pid 958
2023-05-08 06:36:08,549 INFO spawned: 'sshd' with pid 959
2023-05-08 06:36:08,550 INFO spawned: 'cron' with pid 960
2023-05-08 06:36:10,491 INFO success: gitaly entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: puma entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: gitlab-workhorse entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-05-08 06:36:10,491 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
[root@k8s-master ~/jenkins-all]#
访问gitlab
# 做好hosts解析
10.0.0.80 gitlab.yuchaoit.cn
# 设置root密码
www.yuchaoit.cn
#
推送eladmin-api项目
# 本地做好hosts解析
[root@k8s-master ~/jenkins-all]#echo '10.0.0.80 gitlab.yuchaoit.cn' >> /etc/hosts
# 本地准备好代码
Sylar@DESKTOP-G6C412R MINGW64 ~/Desktop
$ git clone https://gitee.com/yuco/eladmin.git
Cloning into 'eladmin'...
remote: Enumerating objects: 11410, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 11410 (delta 1), reused 0 (delta 0), pack-reused 11389
Receiving objects: 100% (11410/11410), 6.79 MiB | 928.00 KiB/s, done.
Resolving deltas: 100% (5490/5490), done.
gitlab首页
创建group
在GitLab中，项目和组是组织和管理代码仓库的方式。
- 项目（Project）：
- 项目是GitLab中最基本的单位，它代表了一个具体的代码仓库。
- 每个项目都有一个唯一的名称和标识符，可以包含源代码、文档、问题跟踪、持续集成（CI）配置等内容。
- 项目可以与特定的团队、部门或个人相关联，用于协作开发、版本控制和持续集成等活动。
- 项目可以具有不同的访问权限设置，例如公开（Public）、内部（Internal）或私有（Private）。
- 组（Group）：
- 组是在GitLab中组织和管理多个相关项目的方式。
- 一个组可以包含多个项目，并将这些项目进行逻辑上的分组。
- 组可以代表一个部门、团队、产品线或任何您希望组织的实体。
- 组可以有不同的成员和权限设置，以便在项目之间共享和管理访问权限。
- 组内的成员可以访问组内所有项目，根据项目的具体权限设置进行操作。
通过项目和组，您可以实现以下功能和优势：
- 项目和组之间的层次结构和组织，可以更好地管理和分类不同的代码仓库。
- 组可以简化权限管理，允许团队成员在多个项目中共享相同的访问权限。
- 组内的成员可以更轻松地查看和访问属于组的所有项目。
- 项目和组的访问权限设置可以确保代码的安全性和保密性。
- 项目和组的管理功能可以支持团队协作、问题跟踪、持续集成等开发活动。
理解GitLab的项目和组的概念可以帮助您更好地组织和管理代码，促进团队协作和开发过程的流畅进行。
创建项目
绑定SSH-KEY
git仓库设置
git remote rename origin old-origin
git remote add origin http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git
$ git remote -v
old-origin https://gitee.com/yuco/eladmin.git (fetch)
old-origin https://gitee.com/yuco/eladmin.git (push)
origin http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git (fetch)
origin http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git (push)
# 输入你的账号密码
root
www.yuchaoit.cn
$ git push -u origin
fatal: Unencrypted HTTP is not supported for GitLab. Ensure the repository remote URL is using HTTPS.
Enumerating objects: 11410, done.
Counting objects: 100% (11410/11410), done.
Delta compression using up to 20 threads
Compressing objects: 100% (4012/4012), done.
Writing objects: 100% (11410/11410), 6.79 MiB | 48.60 MiB/s, done.
Total 11410 (delta 5490), reused 11410 (delta 5490), pack-reused 0
remote: Resolving deltas: 100% (5490/5490), done.
To http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git
* [new branch] master -> master
branch 'master' set up to track 'origin/master'.
推送到你的gitlab
jenkins如何去gitlab拉代码
在使用Kubernetes（k8s）中的Jenkins和GitLab进行通信时，有几个要注意的方面：
- 网络连接：确保Jenkins和GitLab在网络上是可访问的，并且可以相互通信。在Kubernetes集群中，确保Jenkins Pod和GitLab Pod之间可以建立网络连接，并且它们可以通过正确的网络地址和端口进行通信。
- 访问权限：在Kubernetes集群中，确保Jenkins Pod和GitLab Pod之间的访问权限设置正确。这可能涉及到在Kubernetes中配置适当的网络策略（Network Policy）以允许从Jenkins Pod到GitLab Pod的流量通过，并确保GitLab Pod上的相关端口是开放的。
- 凭据管理：确保Jenkins可以正确地使用GitLab的凭据进行身份验证和授权。在Jenkins中配置GitLab的凭据，以便可以访问GitLab仓库和执行相关操作。这可能涉及到配置Jenkins的"Credentials"系统，以便存储GitLab的访问令牌或用户名/密码等凭据。
- Webhook配置：为了实现持续集成/持续交付（CI/CD），通常会配置GitLab的Webhook来触发Jenkins中的构建和部署流程。确保在GitLab中正确配置Webhook，以便在代码提交、合并请求或其他相关事件发生时，向Jenkins发送通知。
- 插件和集成：使用适当的插件和集成工具可以简化Jenkins和GitLab之间的通信。例如，Jenkins提供了GitLab插件，可以更轻松地与GitLab进行集成和交互。确保安装和配置了适当的插件，并按照文档中的说明进行设置。
- 日志和监控：对于故障排除和性能监控，确保在Jenkins和GitLab上启用了适当的日志记录和监控机制。这可以帮助您追踪通信问题、错误和异常，并及时采取必要的措施。
以上是在使用Kubernetes中的Jenkins和GitLab进行通信时需要注意的一些方面。具体的设置和配置可能因您的环境和需求而有所不同，请参考官方文档和相关资源进行详细配置。
Gitlab-access-tokens
GitLab Access Tokens是用于与GitLab API进行身份验证和授权的令牌。当您需要在应用程序、脚本或工具中与GitLab进行交互时，可以使用Access Tokens代表您的身份进行访问。
理解GitLab Access Tokens的关键点如下：
- 访问权限：Access Tokens授予特定用户或应用程序对GitLab资源的访问权限。每个Access Token都关联着一个用户或服务账号，并在GitLab上设置了相应的权限范围。您可以授予Token有限的访问权限，例如只读权限、写入权限或更高级别的管理员权限。
- 生成和管理：Access Tokens可以通过GitLab的用户设置界面生成和管理。用户可以自行创建和撤销自己的Access Tokens，也可以由管理员为其他用户或应用程序生成。生成Access Token时，通常需要指定名称、过期时间和访问权限。
- 身份验证：使用Access Token进行身份验证是与GitLab API进行交互的常见方式。在与GitLab API进行通信时，您需要将Access Token包含在请求的标头中，以证明您具有相应的权限。通常，Access Token会作为"PRIVATE-TOKEN"标头的值进行传递。
- 安全性：GitLab Access Tokens是敏感信息，应妥善保护。确保不要将Access Tokens泄露给不信任的第三方，或者在公开的存储库或脚本中明文显示。如果有必要，可以定期更换Access Tokens以增加安全性。
通过使用GitLab Access Tokens，您可以实现与GitLab的安全交互，并根据所需的权限范围进行授权访问。这为应用程序、工具和脚本提供了便捷的方式来与GitLab进行集成和自动化操作。
jenkins-gitlab设置
注意hosts的坑
# 请注意，现在是2个pod，互相去通信了
jenkins.yuchaoit.cn
gitlab.yuchaoit.cn
这俩是我们通过修改本机hosts文件，结合ingress-nginx实现的通信。
但是容器内，并不认识这个域名
默认你jenkins是不认识这gitlab的域名的
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins exec -it jenkins-master-75c78b968c-nzxw8 -- curl gitlab.yuchaoit.cn
Defaulted container "jenkins" out of: jenkins, fix-permissions (init)
curl: (6) Could not resolve host: gitlab.yuchaoit.cn
command terminated with exit code 6
# 除非你去修改容器的hosts文件，但是如果你pod重建了呢？
确保GitLab和Jenkins服务可以相互解析对方的域名是确保它们能够进行通信的重要一步。下面是两种常见的方式来实现这一点：
在容器内配置hosts：您可以通过在Jenkins和GitLab的容器内部配置hosts文件，将对方的域名解析到正确的IP地址。这样，容器内的应用程序将能够通过域名进行通信。您可以通过在容器启动时挂载自定义hosts文件或通过Dockerfile或Kubernetes Pod配置中的命令来实现这一点。
配置CoreDNS的静态解析：如果您使用的是Kubernetes集群，并且已经部署了CoreDNS作为集群的DNS解析服务，您可以在CoreDNS配置中添加静态解析规则。编辑CoreDNS配置文件，将Jenkins和GitLab的域名与相应的IP地址进行映射。这样，Kubernetes集群中的所有Pod都将能够通过域名解析到正确的IP地址。
示例CoreDNS配置文件（Corefile）：
[root@k8s-master ~/jenkins-all]#kubectl -n kube-system edit cm coredns
8 apiVersion: v1
9 data:
10 Corefile: |
11 .:53 {
12 errors
13 health {
14 lameduck 5s
15 }
16 ready
17 kubernetes cluster.local in-addr.arpa ip6.arpa {
18 pods insecure
19 fallthrough in-addr.arpa ip6.arpa
20 ttl 30
21 }
22 hosts {
23 10.0.0.80 jenkins.yuchaoit.cn gitlab.yuchaoit.cn sonar.yuchaoit.cn
24 fallthrough
25 }
26 prometheus :9153
27 forward . /etc/resolv.conf {
28 max_concurrent 1000
29 }
再试试dns解析通了吗
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins exec -it jenkins-master-75c78b968c-nzxw8 -- curl gitlab.yuchaoit.cn
Defaulted container "jenkins" out of: jenkins, fix-permissions (init)
<html><body>You are being <a href="http://gitlab.yuchaoit.cn/users/sign_in">redirected</a>.</body></html>
[root@k8s-master ~/jenkins-all]#kubectl -n jenkins exec -it gitlab-5bdddc77ff-qh4b8 -- curl jenkins.yuchaoit.cn
<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body style='background-color:white; color:white;'>
Authentication required
<!--
-->
</body></html> # 可知，gitlab、jenkins两个容器内，都实现了静态dns域名的解析
记录一次pod应用故障
访问应用域名时，直接503，那就是后台pod故障了，去看pod日志，好像也没什么信息；
describe也只知道pod崩溃了。
直接去看应用节点上的kubelet日志，发现如下问题
May 8 16:59:13 k8s-slave2 kernel: [38616] 0 38616 11225 262 29 0 914 nginx
May 8 16:59:13 k8s-slave2 kernel: Out of memory: Kill process 37864 (java) score 1546 or sacrifice child
May 8 16:59:13 k8s-slave2 kernel: Killed process 37864 (java) total-vm:9073788kB, anon-rss:3234448kB, file-rss:0kB, shmem-rss:0kB
May 8 16:59:14 k8s-slave2 containerd: time="2023-05-08T16:59:14.192310184+08:00" level=info msg="shim disconnected" id=304d3b8eecad4a60b00129d9a4c034365df81a6d17027f1809669c32b7c341db
...
May 8 16:59:14 k8s-slave2 containerd: time="2023-05-08T16:59:14.202456547+08:00" level=warning msg="cleanup warnings time=\"2023-05-08T16:59:14+08:00\" level=info msg=\"starting signal loop\" namespace=k8s.io pid=38632 runtime=io.containerd.runc.v2\n"
McontainerID="304d3b8eecad4a60b00129d9a4c034365df81a6d17027f1809669c32b7c341db"
May 8 16:59:56 k8s-slave2 kubelet: E0508 16:59:56.749336 1674 pod_workers.go:951] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"jenkins\" with CrashLoopBackOff: \"back-off 2m40s restarting failed container=jenkins pod=jenkins-master-75c78b968c-cllc7_jenkins(07921082-3ca5-436a-ae7e-e267ba3d74f6)\"" pod="jenkins/jenkins-master-75c78b968c-cllc7" podUID=07921082-3ca5-436a-ae7e-e267ba3d74f6
容器崩溃的原因是内存不足导致的 Out of Memory 错误。您可以尝试以下解决方法：
- 调整容器资源限制：根据您提供的 free -m 输出，可见您的服务器内存（RAM）总共为 5789 MB，已使用 2319 MB，可用 3064 MB。您可以尝试增加容器的内存限制，确保容器有足够的内存可用。可以通过修改 Kubernetes Pod 的资源配置来调整容器的内存限制。
- 检查其他资源使用情况：除了内存，还应注意其他资源（如CPU、存储等）的使用情况。确保容器使用的所有资源都在合理的限制范围内，并且没有过度占用。
- 检查应用程序的内存消耗：如果您的应用程序有内存泄漏或者存在其他内存消耗过高的问题，这可能导致容器的内存不断增加，最终耗尽所有可用内存。您可以检查应用程序的内存使用情况，尝试优化代码或配置以减少内存占用。
- 考虑使用交换空间（Swap）：根据您提供的信息，服务器上似乎没有启用交换空间。您可以考虑启用交换空间来作为内存不足时的备用选项。请注意，使用交换空间可能会对性能产生一定影响，并且并不是解决内存问题的根本解决方案，只是提供一种缓解措施。
- 监测和调优：使用监测工具来监视容器和服务器的资源使用情况。这样可以更好地理解容器运行期间的资源需求和瓶颈，并进行相应的调优和优化。
建议node配置
10GB
4C
创建jenkins-job
让jenkins去连接gitlab
确保如下没错误即可
修改gitlab网络配置
Push构建触发器(gitlab)
http://jenkins.yuchaoit.cn/project/free-demo1
以及秘钥，随机生成一个
a572800b5ed5470d4b52bd316b9bbece
这个URL，交给gitlab，让它使用这个webhook
jenkins确认构建webhook
构建shell
首次构建
- 本地代码推送到gitlab、触发push事件
- gitlab触发jenkins的job构建任务
- 程序自动部署
- 查看jenkins任务日志输出
本地git
Sylar@DESKTOP-G6C412R MINGW64 ~/Desktop/eladmin (master)
$ git add hello_chaoge.txt
warning: in the working copy of 'hello_chaoge.txt', LF will be replaced by CRLF the next time Git touches it
Sylar@DESKTOP-G6C412R MINGW64 ~/Desktop/eladmin (master)
$ git commit -m 'add hello_chaoge.txt'
[master 12d70a7] add hello_chaoge.txt
1 file changed, 1 insertion(+)
create mode 100644 hello_chaoge.txt
Sylar@DESKTOP-G6C412R MINGW64 ~/Desktop/eladmin (master)
$ git push -u origin
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 20 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 310 bytes | 310.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
To http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git
7a2c252..12d70a7 master -> master
branch 'master' set up to track 'origin/master'.
查看gitlab
查看jenkins构建任务
自动会出现一个构建任务，查看日志
# 很明显是由于gitlab的push事件，触发的任务
Started by GitLab push by Administrator
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/free-demo1
The recommended git tool is: NONE
using credential gitlab-user
Cloning the remote Git repository
Cloning repository http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git
> git init /var/jenkins_home/workspace/free-demo1 # timeout=10
Fetching upstream changes from http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git
> git --version # timeout=10
> git --version # 'git version 2.30.2'
using GIT_ASKPASS to set credentials
> git fetch --tags --force --progress -- http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url http://gitlab.yuchaoit.cn/elamin-ops/eladmin-api.git # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
skipping resolution of commit remotes/origin/master, since it originates from another repository
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision 12d70a7e901c8aa2e46c2be146c6b9ff657481b3 (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 12d70a7e901c8aa2e46c2be146c6b9ff657481b3 # timeout=10
Commit message: "add hello_chaoge.txt"
First time build. Skipping changelog.
[free-demo1] $ /bin/sh -xe /tmp/jenkins212219370405520184.sh
+ echo 超哥带你学k8s-jenkins
超哥带你学k8s-jenkins
+ echo http://jenkins.yuchaoit.cn/job/free-demo1/ free-demo1
http://jenkins.yuchaoit.cn/job/free-demo1/ free-demo1
Finished: SUCCESS
确认jenkins、gitlab调通
接下来可以做更复杂的构建任务了。
查看jenkins节点
在Jenkins中，节点列表是指可用于构建和执行任务的计算机或服务器的集合。每个节点代表一个物理机器、虚拟机或容器，Jenkins可以通过网络与这些节点通信并在其上执行任务。
节点列表可以包含各种类型的节点，例如：
- 主节点（Master Node）：这是Jenkins服务器本身所在的节点。它负责管理整个Jenkins系统，分配任务给其他节点并监控构建过程。
- 代理节点（Agent Node）：这些节点是与主节点连接的计算机或服务器。代理节点可以是物理机器、虚拟机或容器，它们负责执行Jenkins任务。代理节点可以与主节点位于同一台计算机上，也可以是通过网络与主节点连接的远程计算机。
节点列表对于分布式构建和扩展Jenkins的能力非常重要。通过将任务分配给不同的节点，可以实现并行构建和利用集群中的多个计算资源，从而提高构建和部署的效率。
在Jenkins中，可以通过以下步骤查看和管理节点列表：
- 登录到Jenkins控制台。
- 导航到"系统管理"或"系统设置"页面。
- 在页面上找到"节点管理"或"节点列表"选项。
- 单击"节点管理"或"节点列表"，将显示当前配置的节点列表。
- 您可以查看节点的名称、连接状态以及其他相关信息。
- 您可以添加新节点、删除现有节点或编辑节点的配置。
理解和配置节点列表可以帮助您在Jenkins中管理和利用计算资源，以实现更高效的构建和部署流程。
# 查看jenkins pod
[root@k8s-master ~]#kubectl -n jenkins exec -it jenkins-master-75c78b968c-cllc7 -- bash
Defaulted container "jenkins" out of: jenkins, fix-permissions (init)
jenkins@jenkins-master-75c78b968c-cllc7:/$
jenkins@jenkins-master-75c78b968c-cllc7:/$ cd /var/jenkins_home/
jenkins@jenkins-master-75c78b968c-cllc7:~$
# 这里的数据，就是PVC持久化到NFS的数据
查看workspace
这就是每一个job，执行后，会在workspace里执行任务，包括git下载代码。
Workspace（工作空间）是每个节点上的一个目录，用于存储Jenkins任务的工作文件。当任务在节点上执行时，Jenkins会为该任务创建一个独立的工作空间，用于存放源代码、构建输出、日志文件等。每个任务都有自己的工作空间，不同任务的工作空间是相互隔离的，这样可以防止任务之间的相互干扰。
jenkins@jenkins-master-75c78b968c-cllc7:~/workspace$ ls
free-demo1 free-demo1@tmp
jenkins@jenkins-master-75c78b968c-cllc7:~/workspace$ cd free-demo1
jenkins@jenkins-master-75c78b968c-cllc7:~/workspace/free-demo1$ ls
LICENSE eladmin-common eladmin-logging eladmin-tools pom.xml
README.md eladmin-generator eladmin-system hello_chaoge.txt sql
master-slave节点优化
Jenkins的Slave节点（也称为Agent节点或Worker节点）在分布式构建和部署中起着关键作用。以下是一些使用Slave节点的主要原因：
- 扩展性和负载均衡：Slave节点允许将任务分发到多台计算机或服务器上。通过使用多个Slave节点，可以并行执行多个任务，提高整体构建和部署的吞吐量。同时，将任务分散到不同的节点上可以平衡主节点的负载，减轻主节点的压力，提高Jenkins系统的扩展性。
- 多平台和环境支持：Slave节点可以在不同的操作系统、不同的硬件配置或不同的容器中运行。这使得Jenkins可以同时构建和部署适用于不同平台和环境的应用程序。例如，可以在Windows、Linux和macOS上运行不同的Slave节点来处理相应平台的任务。
- 安全和隔离性：通过使用Slave节点，可以将构建和部署任务限制在特定的计算机或服务器上。这提供了一定程度的安全性和隔离性，因为每个Slave节点都可以配置独立的访问权限和环境设置。您可以根据需要为每个Slave节点设置适当的访问控制和权限级别。
- 分布式构建和测试：通过使用Slave节点，可以在不同的物理机器、虚拟机或容器上执行构建和测试任务。这对于大型项目或需要大量计算资源的任务非常有用。通过并行地在多个Slave节点上执行构建和测试，可以缩短构建周期并提高整体开发效率。
总之，Jenkins的Slave节点提供了可扩展性、灵活性和资源利用的优势。它们允许将任务分发到多个计算资源上，并提供了多平台支持、安全性和隔离性，以及分布式构建和测试的能力。通过合理配置和使用Slave节点，可以优化Jenkins的性能，加快构建和部署过程，提高持续集成和交付的效率。
创建固定节点
number of executors
Jenkins 可以在此节点上执行并发构建的最大数目。 在开始的时候，使用节点的 CPU 个数作为该值是一个不错的选择。一个较大的值将会使每个构建花费更多的时间， 但是却有可能增加系统整体的吞吐量。例如，一个构建可能是 CPU 密集型的，而在同一时刻另一个构建可能是 I/O 密集型的，因此，后者可以有效的利用空闲的 I/O。
代理节点（非 master 节点）必须至少拥有一个执行器。如需暂时阻止其执行构建，请使用其页面右上方的临时断开此节点按钮。
对于 master 节点，设置执行器的数目为零将会阻止构建在其上执行。注意：master 节点将总是能够执行轻量级的任务，包括顶级的流水线任务。
详细配置
tunnel是什么
在Jenkins的节点列表中，Tunnel（隧道）是一个选项，用于配置主节点和代理节点之间的网络连接。这个选项通常用于在不同的网络环境或防火墙后面连接主节点和代理节点。
当您在Jenkins配置节点时，可以选择设置Tunnel选项来建立主节点与代理节点之间的连接。要理解Tunnel的概念，以下是一些关键点：
- 网络隔离：在某些情况下，主节点和代理节点可能处于不同的网络环境中，例如主节点位于内部网络，而代理节点位于外部网络或云服务提供商的虚拟网络中。这种网络隔离可能导致主节点无法直接与代理节点进行通信。
- 隧道连接：为了解决网络隔离的问题，Jenkins提供了Tunnel选项。通过Tunnel，您可以在主节点和代理节点之间建立一个安全的通信通道，使它们能够互相通信。通常，Tunnel使用SSH隧道或其他加密通信协议来保证通信的安全性。
- 配置Tunnel：要配置Tunnel，您需要提供代理节点的主机名（或IP地址）和端口号，以便主节点可以建立到代理节点的连接。这些信息将用于在两个节点之间建立加密通道，使它们能够进行安全的通信。您需要确保代理节点的网络设置和防火墙规则允许主节点与代理节点之间的通信。
通过使用Tunnel选项，您可以克服网络隔离问题，使得主节点和代理节点能够安全地进行通信并协同工作。这样，Jenkins就能够在不同的网络环境中扩展，并利用分布式节点执行任务和构建。
K8s-slave1上启动agent
在命令行中启动节点
curl -sO http://jenkins.yuchaoit.cn/jnlpJars/agent.jar
java -jar agent.jar -jnlpUrl http://jenkins.yuchaoit.cn/manage/computer/10%2E0%2E0%2E81/jenkins-agent.jnlp -secret 620fff284f85d2478b3dc863ba57d684519a43793324a2ca3dcbe0de9e4a2bae -workDir "/opt/jenkins_jobs"
Or run from agent command line, with the secret stored in a file:
echo 620fff284f85d2478b3dc863ba57d684519a43793324a2ca3dcbe0de9e4a2bae > secret-file
curl -sO http://jenkins.yuchaoit.cn/jnlpJars/agent.jar
java -jar agent.jar -jnlpUrl http://jenkins.yuchaoit.cn/manage/computer/10%2E0%2E0%2E81/jenkins-agent.jnlp -secret @secret-file -workDir "/opt/jenkins_jobs"
启动命令
# 1.注意hosts解析
[root@k8s-slave1 ~]#cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.80 k8s-master harbor.yuchaoit.cn jenkins.yuchaoit.cn
10.0.0.81 k8s-slave1
10.0.0.82 k8s-slave2
# 2.启动脚本
[root@k8s-slave1 ~]#cat agent.sh
echo 620fff284f85d2478b3dc863ba57d684519a43793324a2ca3dcbe0de9e4a2bae > secret-file
curl -sO http://jenkins.yuchaoit.cn/jnlpJars/agent.jar
nohup java -jar agent.jar -jnlpUrl http://jenkins.yuchaoit.cn/manage/computer/10%2E0%2E0%2E81/jenkins-agent.jnlp -secret @secret-file -workDir "/opt/jenkins_jobs" & > /tmp/agent.log
[root@k8s-slave1 ~]#
# 注意jdk版本，错了无法运行，以你jenkisn启动的节点版本为准
[root@k8s-master ~]#kubectl -n jenkins exec -it jenkins-master-75c78b968c-cllc7 -- bash
Defaulted container "jenkins" out of: jenkins, fix-permissions (init)
jenkins@jenkins-master-75c78b968c-cllc7:/$ java -version
openjdk version "11.0.17" 2022-10-18
OpenJDK Runtime Environment Temurin-11.0.17+8 (build 11.0.17+8)
OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (build 11.0.17+8, mixed mode)
jenkins@jenkins-master-75c78b968c-cllc7:/$
# 安装jdk11
[root@k8s-slave1 ~]#yum install java-11-openjdk
[root@k8s-slave1 ~]#yum list installed |grep java
java-11-openjdk.x86_64 1:11.0.19.0.7-1.el7_9 @updates
java-11-openjdk-headless.x86_64 1:11.0.19.0.7-1.el7_9 @updates
javapackages-tools.noarch 3.4.1-11.el7 @base
python-javapackages.noarch 3.4.1-11.el7 @base
tzdata-java.noarch 2023c-1.el7 @updates
[root@k8s-slave1 ~]#
[root@k8s-slave1 ~]#java -version
openjdk version "11.0.19" 2023-04-18 LTS
OpenJDK Runtime Environment (Red_Hat-11.0.19.0.7-1.el7_9) (build 11.0.19+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.19.0.7-1.el7_9) (build 11.0.19+7-LTS, mixed mode, sharing)
[root@k8s-slave1 ~]#
#执行jenkins agent脚本
[root@k8s-slave1 ~]#sh agent.sh
[root@k8s-slave1 ~]#ps -ef|grep java
root 55011 1 15 14:15 pts/0 00:00:01 java -jar agent.jar -jnlpUrl http://jenkins.yuchaoit.cn/manage/computer/10%2E0%2E0%2E81/jenkins-agent.jnlp -secret @secret-file -workDir /opt/jenkins_jobs
root 55206 11835 0 14:15 pts/0 00:00:00 grep --color=auto java
确认节点可用
这个新的节点，就可以作为jenkins的构建节点了
修改job运行节点
需要用刚才的node节点标签
再次构建job
1.代码推送
git add
git commit
git push -u origin
2.查看构建
若是有错，修改即可
# 手工去k8s-slave1机器上
[root@k8s-slave1 ~]#grep yuchaoit.cn /etc/hosts
10.0.0.80 k8s-master harbor.yuchaoit.cn jenkins.yuchaoit.cn gitlab.yuchaoit.cn
[root@k8s-slave1 ~]#
[root@k8s-slave1 ~]#yum install git -y
成功构建
检查agent节点
[root@k8s-slave1 ~]#cd /opt/jenkins_jobs/
[root@k8s-slave1 /opt/jenkins_jobs]#ll
total 0
drwxr-xr-x 4 root root 34 May 9 14:08 remoting
drwxr-xr-x 4 root root 46 May 9 14:24 workspace
[root@k8s-slave1 /opt/jenkins_jobs]#ll workspace/
total 0
drwxr-xr-x 10 root root 246 May 9 14:25 free-demo1
drwxr-xr-x 2 root root 6 May 9 14:25 free-demo1@tmp
[root@k8s-slave1 /opt/jenkins_jobs]#
jenkins凭据管理
agent节点详细
