前言

吐槽一波

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部署

gitlab-runner.tar.gz

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

案例项目

项目:go-daemon.tar.gz

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实践的更多相关文章

  1. Gitlab CI 持续集成的完整实践

    Gitlab CI 持续集成的完整实践 本着公司团队初创,又在空档期想搞点事情,搭建了私有Gitlab的契机,顺便把持续集成搭建起,实现了对Python服务端代码的单元测试.静态代码分析和接口测试的持 ...

  2. .NetCore 配合 Gitlab CI&CD 实践 - 单体项目

    前言 上一篇博文 .NetCore 配合 Gitlab CI&CD 实践 - 开篇,主要简单的介绍了一下 GitLab CI 的持续集成以及持续部署,这篇将通过 GitLab CI 发布一个 ...

  3. 实践分享!GitLab CI/CD 快速入门

    用过 GitLab 的同学肯定也对 GitLab CI/CD 不陌生,GitLab CI/CD 是一个内置在 GitLab 中的工具,它可以帮助我们在每次代码推送时运行一系列脚本来构建.测试和验证代码 ...

  4. .NetCore 配合 Gitlab CI&CD 实践 - 开篇

    引言 这是一个系列的文章,讲述的是一个中小型开发团队如何从零开始使用搭建基建 GitLab 代码托管平台,以及使用 GitLab Runner 实现 CI/CD 的故事.本系列通过部署一个完整的 .n ...

  5. 【转】gitlab CI流水线配置文件.gitlab-ci.yml详解

    目录 GitLab CI流水线配置文件.gitlab-ci.yml详解 实验环境 GitLab CI介绍 .gitlab-ci.yml 配置参数 参数详解 script image services ...

  6. GitLab CI持续集成配置方案

    目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 GitLab持续集成所需环境 2.4 需要了解 ...

  7. GitLab CI

    GitLab CI持续集成配置方案   目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 Git ...

  8. Gitlab CI 自动部署 asp.net core web api 到Docker容器

    为什么要写这个? 在一个系统长大的过程中会经历不断重构升级来满足商业的需求,而一个严谨的商业系统需要高效.稳定.可扩展,有时候还不得不考虑成本的问题.我希望能找到比较完整的开源解决方案来解决持续集成. ...

  9. 当谈到 GitLab CI 的时候,我们都该聊些什么(下篇)

    上篇主要介绍了 GitLab WorkFlow 以及 CI/CD 做的事情,并且详细分析 GitLab CI 跟 Runner 信息交互是如何进行的.接下来将为大家讲解 Executor 的实现,再通 ...

  10. Git Hooks、GitLab CI持续集成以及使用Jenkins实现自动化任务

    Git Hooks.GitLab CI持续集成以及使用Jenkins实现自动化任务 前言 在一个共享项目(或者说多人协同开发的项目)的开发过程中,为有效确保团队成员编码风格的统一,确保部署方式的统一, ...

随机推荐

  1. 从零开始学Electron笔记(五)

    在之前的文章我们介绍了一下Electron的右键菜单的制作,接下来我们继续说一下Electron如何通过链接打开浏览器和嵌入网页. 现在有这样一个需求,我们要在我们的软件中加一个链接,然后点击该链接打 ...

  2. Gradle系列之构建脚本基础

    原文发于微信公众号 jzman-blog,欢迎关注交流. 前面两篇文章分别介绍了 Gradle 基础知识以及 Groovy 相关基础知识,这也是学习 Gradle 所必需了解的,文章链接如下:: Gr ...

  3. 【C#】NET截屏网页,生成网页快照开发——IECapt、CutyCapt

    软件介绍 IECapt.CutyCapt 生成网页快照 http://iecapt.sourceforge.net/ http://cutycapt.sourceforge.net/ ### 操作代码 ...

  4. centos 构建dns服务 dnsmasq

    1 安装yum -y install dnsmasq开放udp tcp 53 端口2,修改配置文件 dnsmasq.conf# grep -Ev "^$|^[#;]" /etc/d ...

  5. 【转载】基于dom的一些前端漏洞

    最直接的xss --dom xss function trackSearch(query) { document.write('<img src="/resources/images/ ...

  6. Dart函数

    函数 Dart是一种真正的面向对象的语言,所以即使是函数也是对象,并且有一个类型Function.这意味着函数可以赋值给变量或作为参数传递给其他函数,这是函数式编程的典型特征.同时意味着在Dart语言 ...

  7. $0.\dot{9}=1,是指以1为极限,而非初等数学的相等“=”$

    $注:文中的讨论,没有使用严格的 \epsilon 极限定义,而是简单假设$ 按照中小学的定义,整数,有限小数,无限循环小数是有理数.无限不循环小数是无理数. $\frac{1}{3}=0.\dot{ ...

  8. control+B进入layout文件的xml文本编辑模式

    control+B进入layout文件的xml文本编辑模式

  9. 感性认识JWT

    常见的认证机制 今天我么聊一聊JWT. 关于JWT,相信很多人都已经看过用过,他是基于json数据结构的认证规范,简单的说就是验证用户登没登陆的玩意.这时候你可能回想,哎哟,不是又那个session么 ...

  10. 大家是怎么做APP接口的版本控制的?欢迎进来看看我的方案。升级版的Versioning

    背景 APP不同于网站,网站程序一发版,所有用户看到的都是最新的页面.调用最新的接口,没有新老版本一说.APP一旦下载到用户手机上,用户不更新你拿他一点办法都没有,但是随着业务的调整,同一个接口的请求 ...