企业级Gitlab-ci实践
前言
吐槽一波
2020年6月2号刚入职公司时，第一感觉是集群环境是个大坑！内网一套，公网一套。内网采用单节点Kubernetes，公网采用aliyun托管的X节点Kubernetes(还有节点是2C的...)。内网Kubernetes环境几乎无人使用(可能后端开发工程师在偶尔使用吧)。公网的X节点Kubernetes集群，也可以是称之为生产Kubernetes集群，也可以称之为测试Kubernetes集群，天才的设想--通过名称空间区分集群环境！
引出话题
研发人员向部署在公网的Kubernetes集群的gitlab代码管理仓库推送代码，然后由部署在香港服务器的gitlab-runner做ci，容器镜像是存在gitlab上的，也就是公网kubernetes集群上，emmm，好吧，反正是集群重构势在必行了。
集群重构说的也直接点也就是针对ci的重构，用起内网环境，增加预发环境，将公网Kubernetes的测试环境给剔除掉。
架构图
企业级集群架构图
由上图可知，分三种环境：研发环境（内网环境）；预发环境（和生产环境处于同一VPC）；生产环境（原公网环境【升配】）。
研发环境
研发人员：开发的日常开发工作都在这个环境进行。大部分的基础开发工作都会在该环境进行。
测试人员：主要用于测试验证当前的需求开发是否符合预期。
预发环境
其实就是真实的线上环境，几乎全部的环境配置都是一模一样的，包括但不限于，操作系统版本以及软件配置，开发语言的运行环境，数据库配置等。 最后上线前的验证环境，除了不对用户开放外，这个环境的数据和线上是一致的。产品、运营、测试、开发都可以尝试做最后的线上验证，提前发现问题。
环境对比
| 分类 | 使用场景 | 使用者 | 使用时机 | 备注 |
|---|---|---|---|---|
| 研发环境 | 日常开发测试验证 | 开发测试工程师 | 需求开发开发完成 | |
| 预发环境 | 线上验证 | 开发、测试、产品、运营等 | 上线之前 |
gitlab-ci架构图
如上图所示，开发者将代码提交到GitLab后，可以触发CI脚本在GitLab Runner上执行，通过编写CI脚本可以完成很多使用的功能：编译、测试、构建docker镜像、推送到Aliyun镜像仓库等；
- 部署在公网环境的Gitlab 如何管控部署在内网环境的Kubernetes集群呢？
- 部署在Kubernetes上的Gitlab-runner如何实现缓存呢？
部署环境
部署Kubernetes
公网直接使用阿里云的ACK版Kubernetes集群
- ingress nginx lb 域名？？？
内网部署如下：
清理Kubernetes环境
rm -rf ~/.kube/
rm -rf /etc/kubernetes/
rm -rf /etc/systemd/system/kubelet.service.d
rm -rf /etc/systemd/system/kubelet.service
rm -rf /usr/bin/kube*
rm -rf /etc/cni
rm -rf /opt/cni
rm -rf /var/lib/etcd
rm -rf /var/etcd
部署Kubernetes单节点
docker info
cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
yum list kubelet kubeadm kubectl --showduplicates | sort -r
yum install -y kubelet-1.17.5 kubeadm--1.17.5 kubectl-1.17.5
systemctl enable kubelet && systemctl start kubelet
kubelet status kubelet
kubeadm init --apiserver-advertise-address=10.17.1.44 --image-repository registry.aliyuncs.com/google_containers --kubernetes-version=1.17.5 --pod-network-cidr=10.244.0.0/16
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get cs
cd linkun/
cd zujian/
kubectl apply -f calico.yaml
kubectl get pods -A
kubectl apply -f metrice-server.yaml
kubectl apply -f nginx-ingress.yaml
kubectl get pods -A
部署gitlab
4C8G的ECS服务器
yum install vim gcc gcc-c++ wget net-tools lrzsz iotop lsof iotop bash-completion -y
yum install curl policycoreutils openssh-server openssh-clients postfix -y
systemctl disable firewalld
sed -i '/SELINUX/s/enforcing/disabled/' /etc/sysconfig/selinux
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-13.1.4-ce.0.el7.x86_64.rpm
yum localinstall gitlab-ce-13.1.4-ce.0.el7.x86_64.rpm
cp /etc/gitlab/gitlab.rb{,.bak}
vim /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure
ss -lntup
不允许用户注册
部署gitlab-runner
GitLab-CI 是一套 GitLab 提供给用户使用的持续集成系统，GitLab 8.0 版本以后是默认集成并且默认启用。GitLab-Runner 是配合 GitLab-CI 进行使用的，GitLab 里面每个工程都会定义一些该工程的持续集成脚本，该脚本可配置一个或多个 Stage 例如构建、编译、检测、测试、部署等等。当工程有代码更新时，GitLab 会自动触发 GitLab-CI，此时 CitLab-CI 会找到事先注册好的 GitLab-Runner 通知并触发该 Runner 来执行预先定义好的脚本。
传统的 GitLab-Runner 我们一般会选择某个或某几个机器上，可以 Docker 安装启动亦或是直接源码安装启动，都会存在一些痛点问题，比如发生单点故障，那么该机器的所有 Runner 就不可用了；每个 Runner 所在机器环境不一样，以便来完成不同类型的 Stage 操作，但是这种差异化配置导致管理起来很麻烦；资源分配不平衡，有的 Runner 运行工程脚本出现拥塞时，而有的 Runner 缺处于空闲状态；资源有浪费，当 Runner 处于空闲状态时，也没有安全释放掉资源。因此，为了解决这些痛点，我们可以采用在 Kubernetes 集群中运行 GitLab-Runner 来动态执行 GitLab-CI 脚本任务，它整个流程如下图：
这种方式带来的好处有：
- 服务高可用，当某个节点出现故障时，Kubernetes 会自动创建一个新的 GitLab-Runner 容器，并挂载同样的 Runner 配置，使服务达到高可用。
- 动态伸缩，合理使用资源，每次运行脚本任务时，Gitlab-Runner 会自动创建一个或多个新的临时 Runner，当任务执行完毕后，临时 Runner 会自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个节点资源的使用情况，动态分配临时 Runner 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。
- 扩展性好，当 Kubernetes 集群的资源严重不足而导致临时 Runner 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现横向扩展。
helm部署
https://www.cnblogs.com/bolingcavalry/p/13200977.html
wget https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz
tar xf helm-v3.1.2-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/
chmod +x /usr/local/bin/helm
helm version
helm repo add gitlab https://charts.gitlab.io
helm fetch gitlab/gitlab-runner
helm install --name-template gitlab-runner -f values.yaml . --namespace gitlab-runner
helm uninstall gitlab-runner --namespace gitlab-runner
statefulset部署
名称空间
# cat gitlab-runner-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: gitlab-runner
# kubectl apply -f gitlab-runner-namespace.yaml
namespace/gitlab-runner created
用于注册、运行和取消注册Gitlab ci runner 的Token
# echo "WyJEPLXYJ3uuLxbs62NT" | base64
V3lKRVBMWFlKM3V1THhiczYyTlQK
# cat gitlab-runner-token-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: gitlab-ci-token
namespace: gitlab-runner
labels:
app: gitlab-ci-token
data:
GITLAB_CI_TOKEN: V3lKRVBMWFlKM3V1THhiczYyTlQK
# kubectl apply -f gitlab-runner-token-secret.yaml
secret/gitlab-ci-token created
在k8s里configmap里存储一个用于注册、运行和取消注册 Gitlab ci runner 的小脚本
# cat gitlab-runner-scripts-cm.yaml
apiVersion: v1
data:
run.sh: |
#!/bin/bash
unregister() {
kill %1
echo "Unregistering runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner unregister -t "$(/usr/bin/gitlab-ci-multi-runner list 2>&1 | tail -n1 | awk '{print $4}' | cut -d'=' -f2)" -n ${RUNNER_NAME}
exit $?
}
trap 'unregister' EXIT HUP INT QUIT PIPE TERM
echo "Registering runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner register -r ${GITLAB_CI_TOKEN}
sed -i 's/^concurrent.*/concurrent = '"${RUNNER_REQUEST_CONCURRENCY}"'/' /home/gitlab-runner/.gitlab-runner/config.toml
echo "Starting runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner run -n ${RUNNER_NAME} &
wait
kind: ConfigMap
metadata:
labels:
app: gitlab-ci-runner
name: gitlab-ci-runner-scripts
namespace: gitlab-runner
# kubectl apply -f gitlab-runner-scripts-cm.yaml
configmap/gitlab-ci-runner-scripts created
使用k8s的configmap资源来传递runner镜像所需的环境变量
# cat gitlab-runner-cm.yaml
apiVersion: v1
data:
REGISTER_NON_INTERACTIVE: "true"
REGISTER_LOCKED: "false"
METRICS_SERVER: "0.0.0.0:9100"
CI_SERVER_URL: "http://gitlab.st.realibox.com/ci"
RUNNER_REQUEST_CONCURRENCY: "4"
RUNNER_EXECUTOR: "kubernetes"
KUBERNETES_NAMESPACE: "gitlab-runner"
KUBERNETES_PRIVILEGED: "true"
KUBERNETES_CPU_LIMIT: "1"
KUBERNETES_CPU_REQUEST: "500m"
KUBERNETES_MEMORY_LIMIT: "1Gi"
KUBERNETES_SERVICE_CPU_LIMIT: "1"
KUBERNETES_SERVICE_MEMORY_LIMIT: "1Gi"
KUBERNETES_HELPER_CPU_LIMIT: "500m"
KUBERNETES_HELPER_MEMORY_LIMIT: "100Mi"
KUBERNETES_PULL_POLICY: "if-not-present"
KUBERNETES_TERMINATIONGRACEPERIODSECONDS: "10"
KUBERNETES_POLL_INTERVAL: "5"
KUBERNETES_POLL_TIMEOUT: "360"
kind: ConfigMap
metadata:
labels:
app: gitlab-ci-runner
name: gitlab-ci-runner-cm
namespace: gitlab-runner
# kubectl apply -f gitlab-runner-cm.yaml
configmap/gitlab-ci-runner-cm created
需要用于k8s权限控制的rbac文件
# cat gitlab-runner-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-ci
namespace: gitlab-runner
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab-ci
namespace: gitlab-runner
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab-ci
namespace: gitlab-runner
subjects:
- kind: ServiceAccount
name: gitlab-ci
namespace: gitlab-runner
roleRef:
kind: Role
name: gitlab-ci
apiGroup: rbac.authorization.k8s.io
# kubectl apply -f gitlab-runner-rbac.yaml
serviceaccount/gitlab-ci created
role.rbac.authorization.k8s.io/gitlab-ci created
rolebinding.rbac.authorization.k8s.io/gitlab-ci created
zisefeizhu:gitlab-runner root
在k8s集群生成gitlab runner的statefulset文件
# cat gitlab-runner-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: gitlab-ci-runner
namespace: gitlab-runner
labels:
app: gitlab-ci-runner
spec:
updateStrategy:
type: RollingUpdate
replicas: 2
selector:
matchLabels:
app: gitlab-ci-runner
serviceName: gitlab-ci-runner
template:
metadata:
labels:
app: gitlab-ci-runner
spec:
volumes:
- name: gitlab-ci-runner-scripts
projected:
sources:
- configMap:
name: gitlab-ci-runner-scripts
items:
- key: run.sh
path: run.sh
mode: 0755
serviceAccountName: gitlab-ci
securityContext:
runAsNonRoot: true
runAsUser: 999
supplementalGroups: [999]
containers:
- image: gitlab/gitlab-runner:latest
name: gitlab-ci-runner
command:
- /scripts/run.sh
envFrom:
- configMapRef:
name: gitlab-ci-runner-cm
- secretRef:
name: gitlab-ci-token
env:
- name: RUNNER_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
ports:
- containerPort: 9100
name: http-metrics
protocol: TCP
volumeMounts:
- name: gitlab-ci-runner-scripts
mountPath: "/scripts"
readOnly: true
restartPolicy: Always
# kubectl apply -f gitlab-runner-statefulset.yaml
statefulset.apps/gitlab-ci-runner created
zisefeizhu:gitlab-runner root# kubectl get pods -n gitlab-runner -w
NAME READY STATUS RESTARTS AGE
gitlab-ci-runner-0 0/1 ContainerCreating 0 10s
gitlab-ci-runner-0 1/1 Running 0 26s
测试环境同样的配置
测试环境
预发布环境
# tar cvf gitlab-runner.tar.gz ./*
a ./gitlab-runner-cm.yaml
a ./gitlab-runner-namespace.yaml
a ./gitlab-runner-rbac.yaml
a ./gitlab-runner-scripts-cm.yaml
a ./gitlab-runner-statefulset.yaml
a ./gitlab-runner-token-secret.yaml
[root@localhost gitlab-runner]# tar xf gitlab-runner.tar.gz
[root@localhost gitlab-runner]# ll
总用量 36
-rw-r--r--. 1 root wheel 831 7月 20 23:27 gitlab-runner-cm.yaml
-rw-r--r--. 1 root wheel 63 7月 20 23:05 gitlab-runner-namespace.yaml
-rw-r--r--. 1 root wheel 547 7月 20 23:31 gitlab-runner-rbac.yaml
-rw-r--r--. 1 root wheel 853 7月 20 23:17 gitlab-runner-scripts-cm.yaml
-rw-r--r--. 1 root wheel 1315 7月 20 23:54 gitlab-runner-statefulset.yaml
-rw-r--r--. 1 root root 9728 7月 21 03:24 gitlab-runner.tar.gz
-rw-r--r--. 1 root wheel 178 7月 20 23:14 gitlab-runner-token-secret.yaml
[root@localhost gitlab-runner]# kubectl apply -f .
namespace/gitlab-runner created
serviceaccount/gitlab-ci created
role.rbac.authorization.k8s.io/gitlab-ci created
rolebinding.rbac.authorization.k8s.io/gitlab-ci created
configmap/gitlab-ci-runner-scripts created
statefulset.apps/gitlab-ci-runner created
secret/gitlab-ci-token created
configmap/gitlab-ci-runner-cm created
[root@localhost gitlab-runner]# kubectl get pods -n gitlab-runner -w
NAME READY STATUS RESTARTS AGE
gitlab-ci-runner-0 1/1 Running 0 36s
gitlab-ci-runner-1 1/1 Running 0 1s
gitlab-ci和阿里云镜像仓库 & 不同kubernetes集群调试
gitlab-ci使用有关文档
1、GitLab的CI自动编译的实现（基础） ： https://www.jianshu.com/p/b69304279c5f
2、gitlab-ci.yml 配置Gitlab pipeline以达到持续集成的方法 （参数讲解）： https://www.jianshu.com/p/617f035f01b8
3、持续集成之gitlab-ci.yml（命令及示例讲解）：https://segmentfault.com/a/1190000019540360
4、gitlab 官方文档地址（官）：https://docs.gitlab.com/ee/ci/yaml/README.html
gitlab-ci和阿里云镜像仓库联调
注：此处有docker in docker的问题
# cat gitlab-ci
# 设置执行镜像
image: busybox:latest
before_script:
- export REGISTRY_IMAGE="${ALI_IMAGE_REGISTRY}"/gitlab-test/"${CI_PROJECT_NAME}":"${CI_COMMIT_REF_NAME//\.}"-"${CI_PIPELINE_ID}"
stages:
- build
- deploy
docker_build_job:
stage: build
tags:
- advance
image: docker:latest
stage: build
stage: build
script:
- docker login -u "${ALI_IMAGE_USER}" -p "${ALI_IMAGE_PASSWORD}" "${ALI_IMAGE_REGISTRY}"
- docker build . -t $REGISTRY_IMAGE --build-arg CI_COMMIT_SHORT_SHA=$CI_COMMIT_SHORT_SHA --build-arg NODE_DEPLOY_ENV=$NODE_DEPLOY_ENV --build-arg DEPLOY_VERSION=$DEPLOY_VERSION --build-arg API_SERVER_HOST=$API_SERVER_HOST --build-arg COOKIE_DOMAIN=$COOKIE_DOMAIN --build-arg LOGIN_HOST=$LOGIN_HOST
- docker push "${REGISTRY_IMAGE}"
tags:
- advance
gitlab-ci和kubernetes集群联调
注：因为测试环境是在内网，测试环境的k8s集群无法通过外网连接，如果gitlab-runner是部署在外部的裸机上，将无法和测试环境k8s对接，如果gitlab-runner是部署在k8s集群上，那么如何实现runner job跑在对应的分支上呢？
我的方案是通过制作三个kubectl 镜像分别控制三个集群，在gitlab-ci脚本中引用。
制作kubectl镜像，以测试环境为例 在香港服务器上制作镜像
# pwd
/root/linkun/gitlab-runner/test
# ll
total 20
drwxr-xr-x 2 root root 4096 Jul 23 16:38 ./
drwxr-xr-x 4 root root 4096 Jul 23 15:55 ../
-rw-r--r-- 1 root root 5451 Jul 23 16:31 config
-rw-r--r-- 1 root root 545 Jul 23 16:38 Dockerfile
此处的config是k8s集群的/root/.kube/config 保密期间，再次不引开
# cat Dockerfile
FROM alpine:3.8
MAINTAINER cnych <icnych@gmail.com>
ENV KUBE_LATEST_VERSION="v1.17.5"
RUN apk add --update ca-certificates \
&& apk add --update -t deps curl \
&& apk add --update gettext \
&& apk add --update git \
&& curl -L https://storage.googleapis.com/kubernetes-release/release/${KUBE_LATEST_VERSION}/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl \
&& chmod +x /usr/local/bin/kubectl \
&& apk del --purge deps \
&& rm /var/cache/apk/*
RUN mkdir /root/.kube
COPY config /root/.kube/
ENTRYPOINT ["kubectl"]
CMD ["--help"]
# docker build -t registry.cn-shenzhen.aliyuncs.com/zisefeizhu/kubectl:test .
# docker push registry.cn-shenzhen.aliyuncs.com/zisefeizhu/kubectl:test
阿里云镜像仓库
gitlab-ci脚本
stages:
- kubectl
kubernetes_kuectl:
tags:
- test
stage: kubectl
image: "${KUBECTL_ADVANCE}"
script:
- kubectl get node
- kubectl get pods -A
# - sleep 500
- echo "success"
观察job
观察ku job
至此说明：gitlab-ci和阿里云镜像仓库 & 不同kubernetes集群调试
环境变量
内置环境变量
.gitlab-ci.yml预设环境变量【系统级】
| 名称 | 说明 |
|---|---|
| $CI_PROJECT_NAME | 项目名称 |
| $CI_PROJECT_NAMESPACE | 组名称 |
| $CI_PROJECT_PATH | 项目相对路径 |
| $CI_PROJECT_URL | 项目URL地址 |
| $GITLAB_USER_NAME | 用户名称 |
| $GITLAB_USER_EMAIL | 用户邮箱 |
| $CI_PROJECT_DIR | 项目绝对路径 |
| $CI_PIPELINE_ID | 流水线ID |
| $CI_COMMIT_REF_NAME | 当前分支 |
案例演示
自设环境变量
案例演示
stages:
- neizhi
- release
- kubectl
neizhibianliang:
tags:
- advance
stage: neizhi
script:
- echo "$CI_PROJECT_NAME $CI_PROJECT_NAMESPACE $CI_PROJECT_PATH $CI_PROJECT_URL $GITLAB_USER_NAME $GITLAB_USER_EMAIL $CI_PROJECT_DIR $CI_PIPELINE_ID $CI_COMMIT_REF_NAME" > test.txt
- cat test.txt
image_build:
tags:
- advance
stage: release
image: docker:latest
variables:
DOCKER_DRIVER: overlay
DOCKER_HOST: tcp://localhost:2375
services:
- name: docker:18.03-dind
command: ["--insecure-registry=registry.cn-shenzhen.aliyuncs.com"]
script:
- docker info
- docker login -u $ALI_IMAGE_USER -p $ALI_IMAGE_PASSWORD $ALI_IMAGE_REGISTRY
- docker pull alpine:latest
- docker tag alpine:latest ${ALI_IMAGE_REGISTRY}/gitlab-test/test:${CI_COMMIT_REF_NAME//\.}-$CI_PIPELINE_ID
- docker image ls
kubernetes_kuectl:
tags:
- advance
stage: kubectl
image: $KUBECTL_ADVANCE
script:
- kubectl get node
- kubectl get pods -A
- echo "success"
通过自设环境变量可以避免因为敏感信息外泄！
gitlab-ci指令集
Gitlab CI 使用高级技巧：https://www.jianshu.com/p/3c0cbb6c2936
案例项目
gitlab-ci.yml
image:
name: golang:1.13.2-stretch
entrypoint: ["/bin/sh", "-c"]
# The problem is that to be able to use go get, one needs to put
# the repository in the $GOPATH. So for example if your gitlab domain
# is mydomainperso.com, and that your repository is repos/projectname, and
# the default GOPATH being /go, then you'd need to have your
# repository in /go/src/mydomainperso.com/repos/projectname
# Thus, making a symbolic link corrects this.
before_script:
- pwd
- ls -al
- mkdir -p "/go/src/git.qikqiak.com/${CI_PROJECT_NAMESPACE}"
- ls -al "/go/src/git.qikqiak.com/"
- ln -sf "${CI_PROJECT_DIR}" "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}"
- ls -la "${CI_PROJECT_DIR}"
- pwd
- cd "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}/"
- pwd
- export REGISTRY_IMAGE="${ALI_IMAGE_REGISTRY}"/gitlab-test/"${CI_PROJECT_NAME}":"${CI_COMMIT_REF_NAME//\.}"-"${CI_PIPELINE_ID}"
variables:
NAMESPACE: gitlab-runner
PORT: 8000
stages:
- test
- build
- release
- review
test:
tags:
- advance
stage: test
script:
- make test
test2:
tags:
- advance
stage: test
script:
- echo "We did it! Something else runs in parallel!"
compile:
tags:
- advance
stage: build
script:
# Add here all the dependencies, or use glide/govendor/...
# to get them automatically.
- make build
artifacts:
paths:
- app
image_build:
tags:
- advance
stage: release
image: docker:latest
script:
- docker info
- docker login -u "${ALI_IMAGE_USER}" -p "${ALI_IMAGE_PASSWORD}" "${ALI_IMAGE_REGISTRY}"
- docker build -t "${REGISTRY_IMAGE}" .
- docker push "${REGISTRY_IMAGE}"
deploy_review:
tags:
- advance
image: "${KUBECTL_ADVANCE}"
stage: review
environment:
name: stage-studio
url: http://studio.advance.realibox.com/api-ews/
script:
- kubectl version
- cd manifests/
- sed -i "s/__ALI_IMAGE_REGISTRY__/${ALI_IMAGE_REGISTRY}/" secret-namespace-advance.sh
- sed -i "s/__ALI_IMAGE_USER__/${ALI_IMAGE_USER}/" secret-namespace-advance.sh
- sed -i "s/__ALI_IMAGE_PASSWORD__/${ALI_IMAGE_PASSWORD}/" secret-namespace-advance.sh
- sed -i "s/__NAMESPACE__/${NAMESPACE}/g" secret-namespace-advance.sh deployment.yaml svc.yaml ingress.yaml realibox-namespace.yaml
- sed -i "s/__CI_PROJECT_NAME__/${CI_PROJECT_NAME}/g" deployment.yaml svc.yaml ingress.yaml
- sed -i "s/__VERSION__/"${CI_COMMIT_REF_NAME//\.}"-"${CI_PIPELINE_ID}"/" deployment.yaml
- sed -i "s/__PORT__/${PORT}/g" deployment.yaml svc.yaml ingress.yaml
- cat secret-namespace-advance.sh
- cat deployment.yaml
- cat svc.yaml
- cat ingress.yaml
- |
if kubectl apply -f realibox-namespace.yaml | grep -q unchanged; then
echo "=> The namespace already exists."
else
echo "=> The namespace is created"
fi
- |
if sh -x secret-namespace-advance.sh || echo $? != 0; then
echo "=> The secret already exists."
else
echo "=> The secret is created"
fi
- |
if kubectl apply -f deployment.yaml | grep -q unchanged; then
echo "=> Patching deployment to force image update."
kubectl patch -f deployment.yaml -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"ci-last-updated\":\"$(date +'%s')\"}}}}}"
else
echo "=> Deployment apply has changed the object, no need to force image update."
fi
- kubectl apply -f svc.yaml
- kubectl apply -f ingress.yaml
- kubectl rollout status -f deployment.yaml
- kubectl get all -l name=${CI_PROJECT_NAME} -n ${NAMESPACE}
项目流水线
项目资源查看
项目界面访问
！
企业级Gitlab-ci实践的更多相关文章
- Gitlab CI 持续集成的完整实践
Gitlab CI 持续集成的完整实践 本着公司团队初创,又在空档期想搞点事情,搭建了私有Gitlab的契机,顺便把持续集成搭建起,实现了对Python服务端代码的单元测试.静态代码分析和接口测试的持 ...
- .NetCore 配合 Gitlab CI&CD 实践 - 单体项目
前言 上一篇博文 .NetCore 配合 Gitlab CI&CD 实践 - 开篇,主要简单的介绍了一下 GitLab CI 的持续集成以及持续部署,这篇将通过 GitLab CI 发布一个 ...
- 实践分享！GitLab CI/CD 快速入门
用过 GitLab 的同学肯定也对 GitLab CI/CD 不陌生,GitLab CI/CD 是一个内置在 GitLab 中的工具,它可以帮助我们在每次代码推送时运行一系列脚本来构建.测试和验证代码 ...
- .NetCore 配合 Gitlab CI&CD 实践 - 开篇
引言 这是一个系列的文章,讲述的是一个中小型开发团队如何从零开始使用搭建基建 GitLab 代码托管平台,以及使用 GitLab Runner 实现 CI/CD 的故事.本系列通过部署一个完整的 .n ...
- 【转】gitlab CI流水线配置文件.gitlab-ci.yml详解
目录 GitLab CI流水线配置文件.gitlab-ci.yml详解 实验环境 GitLab CI介绍 .gitlab-ci.yml 配置参数 参数详解 script image services ...
- GitLab CI持续集成配置方案
目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 GitLab持续集成所需环境 2.4 需要了解 ...
- GitLab CI
GitLab CI持续集成配置方案 目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 Git ...
- Gitlab CI 自动部署 asp.net core web api 到Docker容器
为什么要写这个? 在一个系统长大的过程中会经历不断重构升级来满足商业的需求,而一个严谨的商业系统需要高效.稳定.可扩展,有时候还不得不考虑成本的问题.我希望能找到比较完整的开源解决方案来解决持续集成. ...
- 当谈到 GitLab CI 的时候，我们都该聊些什么（下篇）
上篇主要介绍了 GitLab WorkFlow 以及 CI/CD 做的事情,并且详细分析 GitLab CI 跟 Runner 信息交互是如何进行的.接下来将为大家讲解 Executor 的实现,再通 ...
- Git Hooks、GitLab CI持续集成以及使用Jenkins实现自动化任务
Git Hooks.GitLab CI持续集成以及使用Jenkins实现自动化任务 前言 在一个共享项目(或者说多人协同开发的项目)的开发过程中,为有效确保团队成员编码风格的统一,确保部署方式的统一, ...
随机推荐
- 014.Nginx跨域配置
一 跨域概述 1.1 同源策略 同源策略是一个安全策略.同源,指的是协议,域名,端口相同.浏览器处于安全方面的考虑,只允许本域名下的接口交互,不同源的客户端脚本,在没有明确授权的情况下,不能读写对方的 ...
- k8s极简史：K8s多集群技术发展的历史、现状与未来
引子 随着云原生技术的普及,越来越多的企业使用Kubernetes来管理应用,并且集群规模也呈爆发式增长,企业也亟需应对随集群规模增长而带来的各种挑战.同时,为了更好地提供高可用.弹性伸缩的应用,企业 ...
- 浅谈Python中的深浅拷贝的区别
深.浅拷贝总结 深拷贝 拷贝可变数据类型,如列表容器: a = [1, 2, [3, 4]] b = copy.deepcopy(a) a 与 b 所指的列表容器的空间地址不一致,即 id(a) != ...
- VS code 的集成终端Integrated terminal 的颜色问题
其实是默认终端的配色问题在使用vs code时,运行代码时,控制台是这样子的,搞得我很难受 一块一块的 其实是默认终端的配色问题 默认终端一般是powershell,还可以是cmd,或者git bas ...
- CSS过渡时间
CSS过渡时间 基础知识 在了解CSS过渡时间之前,你应该先了解一下CSS的变形动画,可以参考之前的一篇博客. 我们的元素在属性发生变化时,如果没有特地的为它设置过渡时间,整个变化过程其实是以毫秒级别 ...
- 附002.Nginx代理相关模块解析
一 ngx_http_proxy_module模块 1.1 proxy_pass配置 proxy_pass URL; Context: location, if in location, limit_ ...
- JDBC 连接 MySQL 8.0.15+ 常见错误记录
课后复习 1. No suitable driver found for mysql:jdbc://localhost:3306/test 错误原因: mysql:jdbc://localhost:3 ...
- Markdown画图(mermaid)学习
简介 目前博客园支持mermaid的graph,subgraph,sequenceDiagram,gantt,classDiagram mermaid(美人鱼), 是一个类似markdown,用文本语 ...
- 前端 /deep/ 深入样式(很深入的那种哦) 简单收藏
简单介绍:使用vue脚手架和elemen-ui开发的前端项目 遇到这样的场景: 对div下的el-select下拉组件 设置样式,直接在标签上用style属性是完全可以的,但我们的开发规范是前端样式 ...
- MySQL之高级操作
新增数据: 基本语法: insert into 表名 [(字段列表)] values(列表值) 在数据插入的时候,假设主键对应的值已经存在,插入一定会失败 主键冲突: 当主键存在冲突的时候(Dupl ...