DevOps on F嘉阳

ArgoCD落地GitOps

Sat, 23 Aug 2025 22:49:50 +0800

背景

在过去的DevOps实践中，跨环境的基础设施部署和迁移经常存在遗漏，导致环境差异，部署一个新环境往往需要几天。传统CICD流水线采用“推”模式，将变更推送到不同的环境，推送后也不对目标环境状态进行管理和监控，容易导致推送后部署失败。随着云原生容器化已经成为行业事实标准，GitOps成为一种更可靠的应用部署和基础设置运维的范式。

技术选型

ArgoCD遵循GitOps的核心原则，已经成为落地GitOps的默认技术选型，因此此处不探讨其他选型方案。

原理

Git 作为唯一事实来源（GitOps思想）
自动化和持续同步：Argo CD会持续监控 Git 仓库的状态，并自动将集群的实际状态与 Git 中声明的目标状态进行同步。
- 利用K8s的Kustomize能力完成对集群apply操作

实践

环境

安装ArgoCD

$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

检查安装结果

查看argo cd登录密码

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

设计代码库结构

落地ArgoCD通常有以下几种仓库设计范式

单仓库模式
多仓库模式
App of Apps模式

本次采用App of Apps的单仓库模式，仓库结构如下

.
├── apps
│ ├── app-one
│ ├── app-two
├── cluster-infra
│ ├── argocd
│ │ ├── base
│ │ └── overlays
│ ├── ingress
│ │ ├── base
│ │ └── overlays
│ │ └── dev
│ └── prometheus-stack
│ ├── base
│ └── overlays
│ └── dev
└── environments
 └── dev
 └── root.yaml

该结构特点如下

基础设施和应用部署分离（apps和cluster-infra）
环境基础配置和环境定制配置分离（base和overlays）
环境根节点配置（environments控制git仓库配置、应用apps注册）

本次将该代码库存放到阿里云代码仓库中。

环境配置迁移

目前的k3s环境中已经手动运维安装了argocd，现在需要将已安装的配置迁移到git库中

将官方安装配置https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml写入到cluster-infra/argocd/base/argocd.yaml中

配置``cluster-infra/argocd/base/kustomization.yaml`文件，注册同目录的安装文件

resources:
 - argocd.yaml

本次依赖阿里云代码仓库，通过ssh连接，需要覆盖默认的argocd配置，编写cluster-infra/argocd/overlays/with-known-hosts/ssh-known-hosts.patch.yaml

apiVersion: v1 
kind: ConfigMap 
metadata: 
 name: argocd-ssh-known-hosts-cm 
data: 
 ssh_known_hosts: |- 
 # BEGIN >>> 自定义条目（全局生效） 
 codeup.aliyun.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD6WbValczSDKC4ktjRzDNC1qINDAViw/oGA8ud7qH5F9XFZ4QAWhZmFBsp+cppBIOM63exjc4O9vbzMrd7AUItXigymGfTqrGt5VykIiaNhjttxSwbZf3N9eDcAvX4gGm3fcm6D1ACvPxvxMsCwOpdz5tDHqDxGOLPAXN+FSAvjdcN4uMz0MXghGh9Q3zSpy8z1TLkAKT2QBnr4q2tsdZKwWON8bBHIPwP3RSAdSUL6bAyotyncMDAvG53kwRKJ3wJ5ZezXqZNNV7EzHds+pvwThtuWtWsBuuRpL/oZiviWlXy6hILoWbkRfgONPwT0faaOn1GLzjHLuqHHfALGOen 
 # END <<< 自定义条目 
 
 # This file was automatically generated by hack/update-ssh-known-hosts.sh. DO NOT EDIT 
 [ssh.github.com]:443 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg= 
 [ssh.github.com]:443 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl 
 [ssh.github.com]:443 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk= 
 bitbucket.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPIQmuzMBuKdWeF4+a2sjSSpBK0iqitSQ+5BM9KhpexuGt20JpTVM7u5BDZngncgrqDMbWdxMWWOGtZ9UgbqgZE= 
 bitbucket.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIazEu89wgQZ4bqs3d63QSMzYVa0MuJ2e2gKTKqu+UUO 
 bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDQeJzhupRu0u0cdegZIa8e86EG2qOCsIsD1Xw0xSeiPDlCr7kq97NLmMbpKTX6Esc30NuoqEEHCuc7yWtwp8dI76EEEB1VqY9QJq6vk+aySyboD5QF61I/1WeTwu+deCbgKMGbUijeXhtfbxSxm6JwGrXrhBdofTsbKRUsrN1WoNgUa8uqN1Vx6WAJw1JHPhglEGGHea6QICwJOAr/6mrui/oB7pkaWKHj3z7d1IC4KWLtY47elvjbaTlkN04Kc/5LFEirorGYVbt15kAUlqGM65pk6ZBxtaO3+30LVlORZkxOh+LKL/BvbZ/iRNhItLqNyieoQj/uh/7Iv4uyH/cV/0b4WDSd3DptigWq84lJubb9t/DnZlrJazxyDCulTmKdOR7vs9gMTo+uoIrPSb8ScTtvw65+odKAlBj59dhnVp9zd7QUojOpXlL62Aw56U4oO+FALuevvMjiWeavKhJqlR7i5n9srYcrNV7ttmDw7kf/97P5zauIhxcjX+xHv4M= 
 github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg= 
 github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl 
 github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk= 
 gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY= 
 gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf 
 gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9 
 ssh.dev.azure.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7Hr1oTWqNqOlzGJOfGJ4NakVyIzf1rXYd4d7wo6jBlkLvCA4odBlL0mDUyZ0/QUfTTqeu+tm22gOsv+VrVTMk6vwRU75gY/y9ut5Mb3bR5BV58dKXyq9A9UeB5Cakehn5Zgm6x1mKoVyf+FFn26iYqXJRgzIZZcZ5V6hrE0Qg39kZm4az48o0AUbf6Sp4SLdvnuMa2sVNwHBboS7EJkm57XQPVU3/QpyNLHbWDdzwtrlS+ez30S3AdYhLKEOxAG8weOnyrtLJAUen9mTkol8oII1edf7mWWbWVf0nBmly21+nZcmCTISQBtdcyPaEno7fFQMDD26/s0lfKob4Kw8H 
 vs-ssh.visualstudio.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7Hr1oTWqNqOlzGJOfGJ4NakVyIzf1rXYd4d7wo6jBlkLvCA4odBlL0mDUyZ0/QUfTTqeu+tm22gOsv+VrVTMk6vwRU75gY/y9ut5Mb3bR5BV58dKXyq9A9UeB5Cakehn5Zgm6x1mKoVyf+FFn26iYqXJRgzIZZcZ5V6hrE0Qg39kZm4az48o0AUbf6Sp4SLdvnuMa2sVNwHBboS7EJkm57XQPVU3/QpyNLHbWDdzwtrlS+ez30S3AdYhLKEOxAG8weOnyrtLJAUen9mTkol8oII1edf7mWWbWVf0nBmly21+nZcmCTISQBtdcyPaEno7fFQMDD26/s0lfKob4Kw8H

配置``cluster-infra/argocd/overlays/with-known-hosts/kustomization.yaml`文件，注册hosts patch文件

resources: 
 - ../../base 
 
patchesStrategicMerge: 
 - ssh-known-hosts.patch.yaml

按这样配置后，argocd会先执行base的安装文件apply基础环境，再使用ssh-known-hosts.patch.yaml覆盖ssh的配置，保证环境与git配置一致。

接下来，继续在apps根目录注册应用，配置environments/dev/kustomization.yaml

resources:
 - ../../cluster-infra/argocd/overlays/with-known-hosts

编写根目录git配置

apiVersion: argoproj.io/v1alpha1 
kind: Application 
metadata: 
 name: dev-root 
 namespace: argocd 
spec: 
 project: default 
 source: 
 repoURL: git@codeup.aliyun.com:xxxx/fjy8018/pve-k3s-gitops.git 
 targetRevision: master 
 path: environments/dev 
 kustomize: 
 enableHelm: true 
 destination: 
 server: https://kubernetes.default.svc 
 namespace: argocd 
 syncPolicy: 
 automated: 
 prune: true 
 selfHeal: true

到此，所有配置迁移完成，将git仓库提交到远程后，在master节点添加私钥

argocd repo add git@codeup.aliyun.com:xxxx/fjy8018/pve-k3s-gitops.git --ssh-private-key-path /root/.ssh/gitops_ed25519

同步dev根应用

kubectl apply -f dev-root.yaml

本地使用kubectl暴露临时端口，再使用argocd cli连接集群查看状态

kubectl port-forward svc/argocd-server -n argocd --address 0.0.0.0 30443:443
argocd login xxxx:30443 --username admin
argocd app list

部署ingress

一直使用临时端口+命令行查看应用状态也不方便，官方提供webui界面查看部署状态，考虑使用ingress暴露固定域名访问

ingress的部署也遵循相同步骤

配置官方安装文件
配置环境个性化
1. 端口暴露
根应用添加配置

将官方https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml安装文件配置到cluster-infra/ingress/base/ingress-nginx.yaml

配置端口暴露cluster-infra/ingress/overlays/dev/ingress-nginx-controller-nodeport.yaml

apiVersion: v1 
kind: Service 
metadata: 
 name: ingress-nginx-controller 
 namespace: ingress-nginx 
spec: 
 type: NodePort 
 ports: 
 - name: http 
 port: 80 
 targetPort: http 
 protocol: TCP 
 nodePort: 30080 
 - name: https 
 port: 443 
 targetPort: https 
 protocol: TCP 
 nodePort: 30443

根应用添加配置

resources: 
 - ../../cluster-infra/ingress/overlays/dev 
 - ../../cluster-infra/argocd/overlays/with-known-hosts

在argocd环境目录下添加ingress域名配置

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
 name: argocd-ingress 
 namespace: argocd 
 annotations: 
 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" 
spec: 
 ingressClassName: nginx 
 rules: 
 - host: xxxx 
 http: 
 paths: 
 - path: / 
 pathType: Prefix 
 backend: 
 service: 
 name: argocd-server 
 port: 
 number: 443

git提交后即可自动同步并创建ingress

访问域名查看argocd webui

部署Prometheus+Grafana

为了完善集群监控，argocd 支持通过helm charts部署应用

配置cluster-infra/prometheus-stack/base/prometheus-stack.yaml

apiVersion: argoproj.io/v1alpha1 
kind: Application 
metadata: 
 name: prometheus-stack 
 namespace: argocd 
 annotations: 
 argocd.argoproj.io/sync-options: ServerSideApply=true 
spec: 
 project: default 
 source: 
 repoURL: https://prometheus-community.github.io/helm-charts 
 chart: kube-prometheus-stack 
 targetRevision: 75.16.1 
 helm: 
 valueFiles: 
 - values.yaml 
 destination: 
 server: https://kubernetes.default.svc 
 namespace: monitoring 
 syncPolicy: 
 automated: 
 prune: true 
 selfHeal: true

注意，由于Helm仓库部署prometheus时伴随大量CRD资源文件apply，需要开启ServerSideApply模式避免通过接口apply导致字符超长报错。参考：https://argocd.devops.gold/user-guide/sync-options/#_9

使用helm模式安装的应用无法使用patchesStrategicMerge策略覆盖，目前覆盖个性化配置只能将所有内容写到一个资源文件内，因此dev环境的个性化配置values如下

prometheus: 
 prometheusSpec: 
 retention: 3d 
 retentionSize: "2Gi" 
 resources: 
 requests: 
 memory: 128Mi 
 limits: 
 memory: 1Gi 
 storageSpec: 
 volumeClaimTemplate: 
 spec: 
 resources: 
 requests: 
 storage: 5Gi 
 ingress: 
 enabled: true 
 ingressClassName: nginx 
 annotations: {} 
 hosts: 
 - prometheus.fjy8018.top 
 paths: 
 - / 
 tls: 
 - hosts: 
 - xxx.xxx
 secretName: prometheus-tls 
 prometheusSpec: 
 externalUrl: https://xxx.xxx 
 routePrefix: / 
 
grafana: 
 adminPassword: "2EvwJJ0NOLzhYa" 
 resources: 
 requests: 
 memory: 64Mi 
 limits: 
 memory: 512Mi 
 ingress: 
 enabled: true 
 ingressClassName: nginx 
 annotations: {} 
 hosts: 
 - xxx.xxx 
 tls: 
 - hosts: 
 - xxx.xxx
 secretName: grafana-tls

需要在dev中覆盖base的资源文件，通过multi repo模式合并helm配置

apiVersion: argoproj.io/v1alpha1 
kind: Application 
metadata: 
 name: prometheus-stack 
 namespace: argocd 
 annotations: 
 argocd.argoproj.io/sync-options: ServerSideApply=true 
spec: 
 project: default 
 sources: 
 - repoURL: https://prometheus-community.github.io/helm-charts 
 chart: kube-prometheus-stack 
 targetRevision: 75.16.1 
 helm: 
 valueFiles: 
 - $values/cluster-infra/prometheus-stack/overlays/dev/values-dev.yaml 
 - repoURL: 'git@codeup.aliyun.com:xxxx/fjy8018/pve-k3s-gitops.git' 
 targetRevision: master 
 ref: values 
 destination: 
 server: https://kubernetes.default.svc 
 namespace: monitoring 
 syncPolicy: 
 automated: 
 prune: true 
 selfHeal: true

prometheus依赖CRD提前部署的namespace需要注册为独立应用提前配置好

apiVersion: v1 
kind: Namespace 
metadata: 
 name: monitoring

命名空间的配置和普通应用一致

apiVersion: argoproj.io/v1alpha1 
kind: Application 
metadata: 
 name: common-ns 
 namespace: argocd 
spec: 
 project: default 
 source: 
 repoURL: git@codeup.aliyun.com:xxxx/fjy8018/pve-k3s-gitops.git 
 targetRevision: master 
 path: cluster-infra/common-ns 
 destination: 
 server: https://kubernetes.default.svc 
 namespace: argocd 
 syncPolicy: 
 automated: 
 prune: true 
 selfHeal: true

最终根目录应用配置如下

resources: 
 - ../../cluster-infra/ingress/overlays/dev 
 - ../../cluster-infra/argocd/overlays/with-known-hosts 
 - ../../cluster-infra/prometheus-stack/overlays/dev 
 - common-ns-app.yaml

同步后效果如下

查看监控部署拓扑

通过域名访问grafana

Kubesphere落地DevOps

Sat, 19 Jun 2021 22:16:00 +0800

创建企业空间

创建一个企业空间和一个帐户 (project-admin)，必须邀请该帐户至该企业空间并赋予 workspace-self-provisioner 角色。

进入企业空间，切换到DevOps工程，点击创建

创建工程

安装helm

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

找不到环境变量报错

安装helm遇到报错

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
 % Total % Received % Xferd Average Speed Time Time Time Current
unset -f pathmunge
 Dload Upload Total Spent Left Speed
100 11248 100 11248 0 0 61543 0 --:--:-- --:--:-- --:--:-- 61802
Helm v3.6.0 is available. Changing from version v3.2.1.
Downloading https://get.helm.sh/helm-v3.6.0-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm
helm not found. Is /usr/local/bin on your $PATH?
Failed to install helm
 For support, go to https://github.com/helm/helm.

则需要配置环境变量

$ vi /etc/profile
# 添加配置
export PATH=/usr/local/bin:$PATH

$ source /etc/profile

验证

$ helm version
version.BuildInfo{Version:"v3.6.0", GitCommit:"7f2df6467771a75f5646b7f12afb408590ed1755", GitTreeState:"clean", GoVersion:"go1.16.3"}

安装SonarQube

执行以下命令安装 SonarQube 服务器

$ helm upgrade --install sonarqube sonarqube --repo https://charts.kubesphere.io/main -n kubesphere-devops-system --create-namespace --set service.type=NodePort

输出

执行以下命令以获取 SonarQube NodePort

$ export NODE_PORT=$(kubectl get --namespace kubesphere-devops-system -o jsonpath="{.spec.ports[0].nodePort}" services sonarqube-sonarqube)
$ export NODE_IP=$(kubectl get nodes --namespace kubesphere-devops-system -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo http://$NODE_IP:$NODE_PORT

输出

此时可在kubesphere控制台中看到sonar服务

配置 SonarQube 服务器

访问地址，点击右上角的 Log in，然后使用默认帐户 admin/admin 登录。

创建 SonarQube 管理员令牌 (Token)

点击右上角字母 A，然后从菜单中选择 My Account 以转到 Profile 页面。

生成token

创建 Webhook 服务器

执行以下命令获取 SonarQube Webhook 的地址。

$ export NODE_PORT=$(kubectl get --namespace kubesphere-devops-system -o jsonpath="{.spec.ports[0].nodePort}" services ks-jenkins)
$ export NODE_IP=$(kubectl get nodes --namespace kubesphere-devops-system -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo http://$NODE_IP:$NODE_PORT/sonarqube-webhook/

输出

依次点击 Administration、Configuration 和 Webhooks 创建一个 Webhook。

点击 Create

由于webhook都通过内部网络调用，故可以使用内部网络地址

将 SonarQube 配置添加到 ks-installer

执行以下命令编辑 ks-installer

$ kubectl edit cc -n kubesphere-system ks-installer

搜寻至 devops。添加字段 sonarqube 并在其下方指定 externalSonarUrl 和 externalSonarToken。

 devops:
 enabled: true
 jenkinsJavaOpts_MaxRAM: 2g
 jenkinsJavaOpts_Xms: 512m
 jenkinsJavaOpts_Xmx: 512m
 jenkinsMemoryLim: 2Gi
 jenkinsMemoryReq: 1500Mi
 jenkinsVolumeSize: 8Gi
 sonarqube:
 externalSonarUrl: http://10.170.0.5:32108
 externalSonarToken: c6a6e2e15a9d52e30b744df0eef4c639bbea88a1

完成操作后保存此文件。

将 SonarQube 服务器添加至 Jenkins

执行以下命令获取 Jenkins 的地址。

$ export NODE_PORT=$(kubectl get --namespace kubesphere-devops-system -o jsonpath="{.spec.ports[0].nodePort}" services ks-jenkins)
$ export NODE_IP=$(kubectl get nodes --namespace kubesphere-devops-system -o jsonpath="{.items[0].status.addresses[0].address}")
$ echo http://$NODE_IP:$NODE_PORT

输出

使用地址 http://{$Public IP}:30180 访问 Jenkins。安装 KubeSphere 时，默认情况下也会安装 Jenkins 仪表板。此外，Jenkins 还配置有 KubeSphere LDAP，这意味着您可以直接使用 KubeSphere 帐户（例如 admin/P@88w0rd）登录 Jenkins。

使用kubesphere admin账户登录

前往系统管理下的 Manage Credentials 并点击 Stores scoped to Jenkins 下的 Jenkins，再点击全局凭据 (unrestricted)

点击左侧导航栏的添加凭据，用 SonarQube 管理员令牌添加凭证

点击左侧的系统管理，向下翻页找到并点击系统配置。

搜寻到 SonarQube servers，然后点击 Add SonarQube。

添加sonar服务器地址和名称，点击应用完成操作。

将 sonarqubeURL 添加到 KubeSphere 控制台

指定 sonarqubeURL，以便可以直接从 KubeSphere 控制台访问 SonarQube。

执行以下命令：

$ kubectl edit cm -n kubesphere-system ks-console-config

搜寻到 client，添加 devops 字段并指定 sonarqubeURL。

 client:
 version:
 kubesphere: v3.1.0
 kubernetes: v1.20.4
 openpitrix: v0.3.5
 enableKubeConfig: true
 devops:
 sonarqubeURL: http://34.92.90.181:32108

结果

重启服务

执行以下命令。

$ kubectl -n kubesphere-system rollout restart deploy ks-apiserver
$ kubectl -n kubesphere-system rollout restart deploy ks-console

为新工程创建 SonarQube Token

创建一个 SonarQube 令牌，以便您的流水线可以在运行时与 SonarQube 通信。

在 SonarQube 控制台上，点击 Create new project。

设置工程名称

生成token

创建令牌后，点击 Continue。

分别选择 Java 和 Maven。复制下图所示绿色框中的序列号，如果要在流水线中使用，则需要在凭证中添加此序列号。

创建流水线工程

创建凭证

凭证 ID	类型	用途
dockerhub-id	帐户凭证	Docker Hub
demo-kubeconfig	kubeconfig	Kubernetes

demo-kubeconfig

dockerhub-id

创建一个凭证 ID (sonar-token)

列表中看到已创建的三个凭证。

创建流水线

在流水线页面点击创建，为了使用图形化流水线搭建，不在此处引用代码仓库，直接点击下一步

保持默认配置，点击创建

创建成功

进入流水线，点击编辑

此时选择CICD模板

可视化编辑流水线

编辑后运行

流水线支持交互式操作

在 KubeSphere 控制台查看结果

流水线执行成功后，即可查看到代码质量标签

sonar控制台也可以查看对应结果

jenkins视图

blue ocean

GitHub DevOps工作流构建Java项目并上传到DockerHub

Sun, 07 Feb 2021 11:58:43 +0800

工程准备

此处使用fork自alibaba/Sentinel的FJiayang/Sentinel项目实践

工程地址

Sentinel — Sentinel仓库源码

准备Dockerfile

该工程为标准Java项目，故准备好的Dockerfile文件如下

FROM anapsix/alpine-java:8_server-jre_unlimited

MAINTAINER fjy8018@gmail.com

ENV PARAM ""
ENV VERSION 1.8.0

RUN mkdir -p /sentinel

WORKDIR /sentinel

ADD ./sentinel-dashboard/target/sentinel-dashboard.jar ./app-${VERSION}.jar

# 设置时区，默认为UTC
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
RUN echo 'Asia/Shanghai' > /etc/timezone

ENTRYPOINT ["java", "${PARAM}", "-jar", "app-${VERSION}.jar"]

编写GitHub工作流

GitHub DevOps工作流又叫GitHub Actions 是2019年末推出的自动化CICD持续集成工作流，有详细的样例文档

此处参考以下文档编写

使用 Maven 构建和测试 Java — GitHub Actions 指南

安全配置

由于需要建构建后的制品推送到DockerHub中，但又不能在工作流中直接使用用户名和密码登陆，故还需要配置环境变量

在DockerHub中新增秘钥

在构建工程的设置中新增用户名和密码变量

编写后的工作流如下

name: Publish Docker image

on: [push]

jobs:
 build:

 runs-on: ubuntu-latest

 steps:
 - uses: actions/checkout@v2
 - name: Set up Maven Central Repository
 uses: actions/setup-java@v1
 with:
 java-version: 1.8

 - name: Publish package
 run: mvn --batch-mode clean package -Dmaven.test.skip=true

 - name: Push to Docker Hub
 uses: docker/build-push-action@v1
 with:
 username: ${{ secrets.DOCKER_USERNAME }}
 password: ${{ secrets.DOCKER_PASSWORD }}
 repository: fjy8018/sentinel
 tag_with_ref: true

触发构建

当前的触发方式配置为PUSH，修改好文件后会自动触发流水线工作

Maven打包，速度很快

打包完成

检查结果

登录到DockerHub中检查推送结果，可见成功推送

总结

整体来看，GitHub工作流效率高，文档齐全，编码上手速度快，相比GitLab CICD和DockerHub CICD来说，GitHub CICD配置更加简单、友好和高效。

DevOps实践心得二

Sun, 27 Dec 2020 12:25:47 +0800

背景

上一篇DevOps实践心得编写于2019年08月16日

文章最后提到未来探索方向是

全面容器化服务治理方向

国内对容器化有非常多的实践

kubernetes作为容器调度成为大多数服务治理的选择

容器隔离、迁移和伸缩带来的巨大优势

容器与传统应用部署结合方式

以半全自动方式落地DevOps，采用Mesos+marathon方式同时兼容传统服务部署和容器化部署

兼容分布式服务治理

国外有大量的实践案例

日志收集体系完备

经过一年半的时间，完成对完整DevOps的探索

Mesos+Marathon的DevOps分布式环境探索

参考文章

该架构更加适合还未进行容器化改造的项目，其支持较为通用，但各组件都是由开源组件协调而成，故搭建较为繁琐，而且后续版本升级并不方便

全面容器化服务探索

探索历程

最终完成了DevOps容器化自动部署实践

采用kuberneties方案，其统一性更加一致，依赖的基础设施也多支持容器化部署，机器利用率较高，版本升级、维护较为方便，适用于云原生项目部署

遇到的坑

最终生产环境采用kuberneties集群方案，5个节点，但由于实施经验不足，依然遇到不少坑

后续发展展望

云原生技术还在不断发展中，不少公司也研发并开源关于kuberneties集群管理方案，例如kubesphere

kubesphere — The Kubernetes platform tailored for hybrid multicloud

经过测试，其2.x版本资源占用较高，还处于刚起步阶段，暂时不适用于小规模集群

基于Mesos+Marathon的DevOps分布式环境搭建

Sun, 18 Aug 2019 22:01:00 +0800

基础环境

本地准备了4台虚拟机配置如下

虚拟机名称	IP	CPU	内存	磁盘
129	192.168.133.129	1	2G	20G
130	192.168.133.130	1	2G	20G
131	192.168.133.131	1	2G	20G
132	192.168.133.132	1	2G	20G

部署架构

部署架构图如下

各服务详细部署情况

Zookeeper

服务器	节点	端口	版本
129	zk-1-docker	2181	3.4.14
131	zk-2-docker	2181	3.4.14
132	zk-3-docker	2181	3.4.14

MesosMaster

服务器	节点	端口	版本
132	master	5050	1.7.0
130	master	5050	1.7.0
131	master	5050	1.7.0

MesosSlave

服务器	节点	端口	版本
131	slave2	5051	1.7.0
130	slave1	5051	1.7.0

marathon

服务器	服务	端口	版本
132	marathonMaster	8080	v1.6.496

marathon-lb

服务器	服务	端口	版本
129	marathon-lb	9090	v1.14.0

环境准备

开放防火墙

本次服务各主机将可能使用到以下端口

8080
9090
2181
2888
3888
5050
5051

逐台登陆服务器执行放行防火墙脚本

firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --zone=public --add-port=2181/tcp --permanent
firewall-cmd --zone=public --add-port=5050/tcp --permanent
firewall-cmd --zone=public --add-port=5051/tcp --permanent
firewall-cmd --zone=public --add-port=9090/tcp --permanent
firewall-cmd --zone=public --add-port=2888/tcp --permanent
firewall-cmd --zone=public --add-port=3888/tcp --permanent
firewall-cmd --reload

安装Docker

本次所有服务均采用Docker方式部署，服务调度通过Docker in Docker的方式进行

由于Docker有可能出现版本影响环境问题，参考文章相关文章

故建议安装时指定版本

$ yum-config-manager \
 --add-repo \
 https://download.docker.com/linux/centos/docker-ce.repo
$ yum install docker-ce-19.03.1 docker-ce-cli-19.03.1 containerd.io

设置开机启动并运行服务

$ systemctl enable docker
$ systemctl start docker

安装docker-compose，脚本参考官方文档

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

安装Zookeeper

鉴于zk 3.4和3.5版本的配置有一定差别，编写脚本时注意版本，此处使用的是3.4.14，以下配置文件注意hosts的微小差别

docker-compose-zoo-129.yml

version: '3.1'

services:
 zoo1:
 image: zookeeper:3.4.14
 restart: always
 network_mode: host
 extra_hosts:
 - "zoo2: 192.168.133.131"
 - "zoo3: 192.168.133.132"
 ports:
 - 2181:2181
 - 2888:2888
 - 3888:3888
 environment:
 ZOO_MY_ID: 1
 ZOO_SERVERS: server.1=0.0.0.0:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

docker-compose-zoo-131.yml

version: '3.1'

services:

 zoo2:
 image: zookeeper:3.4.14
 restart: always
 network_mode: host
 extra_hosts:
 - "zoo1: 192.168.133.129"
 - "zoo3: 192.168.133.132"
 ports:
 - 2181:2181
 - 2888:2888
 - 3888:3888
 environment:
 ZOO_MY_ID: 2
 ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=0.0.0.0:2888:3888 server.3=zoo3:2888:3888

docker-compose-zoo-132.yml

version: '3.1'

services:

 zoo3:
 image: zookeeper:3.4.14
 restart: always
 network_mode: host
 extra_hosts:
 - "zoo1: 192.168.133.129"
 - "zoo2: 192.168.133.131"
 ports:
 - 2181:2181
 - 2888:2888
 - 3888:3888
 environment:
 ZOO_MY_ID: 3
 ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=0.0.0.0:2888:3888

安装MesosMaster

MesosMaster也采用3节点高可用方案，由于要在各台机器上配置hosts过于麻烦，此处选择使用非hosts注册方式，故需要配置各自的IP地址

docker-compose-mesos-master-130.yml

version: '3.1'

services:

 mesos-master:
 image: mesosphere/mesos-master:1.7.0
 restart: always
 network_mode: host
 hostname: master
 command: --no-hostname_lookup --ip=192.168.133.130
 ports:
 - 5050:5050
 environment:
 MESOS_PORT: 5050
 MESOS_ZK: zk://192.168.133.129:2181/mesos
 MESOS_QUORUM: 1
 MESOS_REGISTRY: in_memory
 MESOS_LOG_DIR: /var/log/mesos
 MESOS_WORK_DIR: /var/tmp/mesos

docker-compose-mesos-master-131.yml

version: '3.1'

services:

 mesos-master:
 image: mesosphere/mesos-master:1.7.0
 restart: always
 network_mode: host
 hostname: master
 command: --no-hostname_lookup --ip=192.168.133.131
 ports:
 - 5050:5050
 environment:
 MESOS_PORT: 5050
 MESOS_ZK: zk://192.168.133.129:2181/mesos
 MESOS_QUORUM: 1
 MESOS_REGISTRY: in_memory
 MESOS_LOG_DIR: /var/log/mesos
 MESOS_WORK_DIR: /var/tmp/mesos

docker-compose-mesos-master-132.yml

version: '3.1'

services:

 mesos-master:
 image: mesosphere/mesos-master:1.7.0
 restart: always
 network_mode: host
 hostname: master
 command: --no-hostname_lookup --ip=192.168.133.132
 ports:
 - 5050:5050
 environment:
 MESOS_PORT: 5050
 MESOS_ZK: zk://192.168.133.129:2181/mesos
 MESOS_QUORUM: 1
 MESOS_REGISTRY: in_memory
 MESOS_LOG_DIR: /var/log/mesos
 MESOS_WORK_DIR: /var/tmp/mesos

安装MesosSlave

需要选择与master对应的版本号，同时也使用IP注册的方式

docker-compose-mesos-slave1.yml

version: '3.1'

services:

 mesos-slave1:
 image: mesosphere/mesos-slave:1.7.0
 restart: always
 network_mode: host
 hostname: slave1
 command: --no-systemd_enable_support --no-hostname_lookup --ip=192.168.133.131
 ports:
 - 5051:5051
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /cgroup:/cgroup
 - /sys:/sys
 - /usr/bin/docker:/usr/local/bin/docker
 environment:
 MESOS_PORT: 5051
 MESOS_MASTER: zk://192.168.133.129:2181/mesos
 MESOS_SWITCH_USER: 0
 MESOS_CONTAINERIZERS: docker,mesos
 MESOS_LOG_DIR: /var/log/mesos
 MESOS_WORK_DIR: /var/tmp/mesos
 privileged: true

docker-compose-mesos-slave2.yml

version: '3.1'

services:

 mesos-slave2:
 image: mesosphere/mesos-slave:1.7.0
 restart: always
 network_mode: host
 hostname: slave2
 command: --no-systemd_enable_support --no-hostname_lookup --ip=192.168.133.130
 ports:
 - 5051:5051
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /cgroup:/cgroup
 - /sys:/sys
 - /usr/bin/docker:/usr/local/bin/docker
 environment:
 MESOS_PORT: 5051
 MESOS_MASTER: zk://192.168.133.129:2181/mesos
 MESOS_SWITCH_USER: 0
 MESOS_CONTAINERIZERS: docker,mesos
 MESOS_LOG_DIR: /var/log/mesos
 MESOS_WORK_DIR: /var/tmp/mesos
 privileged: true

Marathon

marathon在高版本会出现收不到mesos心跳自动停止的问题，暂时没找到可以配置的方式，故使用1.6的版本，问题链接如下

Missing heartbeats from Mesos, eventually disconnecting and dying

docker-compose-marathon.yml

version: '3.1'

services:

 marathon:
 image: mesosphere/marathon:v1.6.496
 hostname: marathon
 restart: always
 command: --master zk://192.168.133.129:2181/mesos --zk zk://192.168.133.129:2181/marathon
 ports:
 - 8080:8080

安装marathon-lb

marathon-lb 与marathon没有版本的对应关系，故使用当前最新的版本1.14，新版和旧版的配置也有所不同，在早期版本无需指定端口的环境变量，翻阅官网也指出其应该是自动配置的，但如果使用Docker默认运行脚本则需要手动指定

if you use the built-in run script, you’ll need to pass an env var that contains a comma separated list of the ports HAProxy binds to

参考ISSUES：

unbound variable PORTS v1.1.0

docker-compose-marathon-lb.yml

version: '3.1'

services:

 marathon-lb:
 image: mesosphere/marathon-lb:v1.14.0
 network_mode: host
 hostname: marathon-lb
 restart: always
 command: sse --group external --marathon http://192.168.133.132:8080
 environment:
 PORTS: 9090
 ports:
 - 9090:9090

启动

启动顺序：

zookeeper
mesosMaster
mesosSlave
marathon
marathon-lb

由于全使用docker-compose脚本编写，启动时只需指定文件名即可

$ docker-compose -f xx.yml up -d

查看日志命令，-f表示跟踪最新的日志

$ docker-compose -f xx.yml logs [-f]

效果

随便打开一个节点的mesos端口，可看到当前的服务注册数量和当前的leader，其采用与ZK类似的选举算法来选出leader实现高可用

slave信息

查看框架注册情况

查看marathon-lb情况

marathon面板

marathon支持通过面板创建任务和通过rest接口创建任务

使用postman创建任务测试

请求路径http://192.168.133.132:8080/v2/apps

内容

{
 "id": "basic-0", 
 "cmd": "while [ true ] ; do echo 'Hello Marathon' ; sleep 5 ; done",
 "cpus": 0.1,
 "mem": 10.0,
 "instances": 1
}

结果

面板同步显示

运行状态正常

查看详情可知其运行在130服务器上

通过面板创建

切换为json格式可以编辑更多内容

{
 "id": "demo-springboot",
 "cmd": null,
 "cpus": 0.3,
 "mem": 128,
 "disk": 0,
 "instances": 1,
 "container": {
 "docker": {
 "image": "fjy8018/demo-springboot:2.1.6.RELEASE",
 "forcePullImage": true
 },
 "type": "DOCKER",
 "portMappings": [
 {
 "containerPort": 8080,
 "protocol": "tcp",
 "servicePort": 18080
 }
 ]
 },
 "networks": [
 {
 "mode": "container/bridge"
 }
 ]
}

运行成功

访问成功

查看资源调度情况

配置扩缩容

配置成功

两个实例被分别调度到不同的机器上

配置健康检查

自动轮询接口

错误告警

DevOps实践心得一

Fri, 16 Aug 2019 19:32:00 +0800

初遇DevOps

最早接触到DevOps是在2018年8月26日，那时首先接触到的就是大名鼎鼎的Jenkins，当时看了多篇关于持续集成和持续部署的文章，蠢蠢欲动，便开始了第一套DevOps环境的搭建

Jenkins

第一套DevOps是用Jenkins+Ansible+GitLab搭建的，那时只是了解Docker的好处，并没有使用Docker搭建整套环境，还是基于传统虚拟服务器搭建的整套流程。

Jenkins不仅可以编写groove脚本、pipeline 流水线等，还能与maven集成自动构建，深深感受到了Jenkins的强大，同时大量的用户为其贡献了许多插件，有很多实践问题都可以在网上搜索到解决方案

搭建过程：

最后顺利实现了静态网站持续集成、持续部署，详见：相关文章

Docker+GitLab

随着容器化技术在国内越来越流行，容器普及度越来越高，其带来的环境隔离极大推动了DevOps的落地，使得无需使用python环境隔离，可以直接利用容器技术实现跨平台和环境隔离，并且利于迁移和部署

于是在2019年4月开始研究GitLab官方文档，发现其早已原生支持流水线，并依托其GitLab-runner可以直接实现整套DevOps环境

因此，经过不断摸索，完整的搭建的基于Docker和GitLab的DevOps环境，搭建过程见：

由于国内当时对GitLab流水线使用的并不多，因此遇到的很多坑都需要翻查官方文档和国外的实践记录，比如：

DevOps 带来的好处

2019年7月将手上的一个小型项目尝试使用完整的DevOps流程开发，开发小组选择敏捷开发方法，所有的开发工具都尽量的适应快速的需求变化，同时投入非常少量的开发人员，分工明确，从一开始一周发布一次到最后一天可以发布多次

开发人员已经完全从运维中脱离，全团队没有专门的运维人员，极大的提高了开发效率，精简了人员构成，一旦构建失败，开发人员可以根据邮件通知的内容排查上线失败问题，调整代码和配置后重新提交

面板提供了流水线统计图，如果出现频繁的失败还是需要人工介入，查看问题原因

当前的问题

尽管使用了基于Docker+GitLab的流水线实现了完整的DevOps流程，但对于监控和日志部分仍然处在很多问题

尽管上线的是单体应用，服务器和应用的健康状态都无法得知，也没有相应的告警
应用的日志没有被外部服务收集，无法进行快速分析
没有实现完整的测试流程，生成测试覆盖率报告等
没有实现0停机上线，在容器切换时仍需停机1-2分钟
没有实现灰度上线、蓝绿部署等，上线失败需要手动回滚

未来探索方向

全面容器化服务治理方向
- 国内对容器化有非常多的实践
- kubernetes作为容器调度成为大多数服务治理的选择
- 容器隔离、迁移和伸缩带来的巨大优势
容器与传统应用部署结合方式
- 以半全自动方式落地DevOps，采用Mesos+marathon方式同时兼容传统服务部署和容器化部署
- 兼容分布式服务治理
- 国外有大量的实践案例
- 日志收集体系完备

DevOps GitLab CICD 实践3——CI文件编写

Wed, 03 Apr 2019 16:32:00 +0800

前置步骤：

Docker 版 GitLab CICD 实践1——GitLab 部署 [[Docker 版 GitLab CICD 实践]]
Docker 版 GitLab CICD 实践2——Runner 部署 [[Docker 版 GitLab CICD 实践——Runner 部署]]

官方文档

编写结构类似Jenkins pineline流水线

GitLab CI/CD Pipeline Configuration Reference

GitLab CI/CD Pipeline Configuration Reference
GitLab CI/CD pipelines are configured using a YAML file called .gitlab-ci.yml within each project.

The .gitlab-ci.yml file defines the structure and order of the pipelines and determines:

What to execute using GitLab Runner.

What decisions to make when specific conditions are encountered. For example, when a process succeeds or fails.

This topic covers CI/CD pipeline configuration. For other CI/CD configuration information, see:

GitLab CI/CD Variables, for configuring the environment the pipelines run in.

GitLab Runner advanced configuration, for configuring GitLab Runner.

We have complete examples of configuring pipelines:

For a quick introduction to GitLab CI, follow our quick start guide.

For a collection of examples, see GitLab CI/CD Examples.

To see a large .gitlab-ci.yml file used in an enterprise, see the .gitlab-ci.yml file for gitlab-ce.

目标

maven项目自动打包
~~自动测试~~
自动镜像构建并上传

官方参数表列出了作业的可用参数：

关键词	描述
`script`	由Runner执行的Shell脚本。
`image`	使用泊坞窗图像。也可用：`image:name`和`image:entrypoint`。
`services`	使用docker services图像。也可用：`services:name`，`services:alias`，`services:entrypoint`，和`services:command`。
`before_script`	覆盖在作业之前执行的一组命令。
`after_script`	覆盖作业后执行的一组命令。
`stages`	定义管道中的阶段。
`stage`	定义作业阶段（默认值:) `test`。
`only`	创建作业时限制。也可用：`only:refs`，`only:kubernetes`，`only:variables`，和`only:changes`。
`except`	在未创建作业时限制。也可用：`except:refs`，`except:kubernetes`，`except:variables`，和`except:changes`。
`tags`	用于选择Runner的标签列表。
`allow_failure`	让工作失败。失败的作业无助于提交状态。
`when`	什么时候开始工作。也可用：`when:manual`和`when:delayed`。
`environment`	作业部署到的环境的名称。也可用：`environment:name`，`environment:url`，`environment:on_stop`，和`environment:action`。
`cache`	后续运行之间应缓存的文件列表。也可用：`cache:paths`，`cache:key`，`cache:untracked`，和`cache:policy`。
`artifacts`	成功附加到作业的文件和目录列表。也可用：`artifacts:paths`，`artifacts:name`，`artifacts:untracked`，`artifacts:when`，`artifacts:expire_in`，`artifacts:reports`，和`artifacts:reports:junit`。在GitLab 企业版，这些都是可供选择：`artifacts:reports:codequality`，`artifacts:reports:sast`，`artifacts:reports:dependency_scanning`，`artifacts:reports:container_scanning`，`artifacts:reports:dast`，`artifacts:reports:license_management`，和`artifacts:reports:performance`。
`dependencies`	作业所依赖的其他作业，以便您可以在它们之间传递工件。
`coverage`	给定作业的代码覆盖率设置。
`retry`	在发生故障的情况下，可以自动重试作业的次数和次数。
`parallel`	应该并行运行多少个作业实例。
`trigger`	定义下游管道触发器。
`include`	允许此作业包含外部YAML文件。也可用：`include:local`，`include:file`，`include:template`，和`include:remote`。
`extends`	此作业将继承的配置条目。
`pages`	上传作业结果以用于GitLab Pages。
`variables`	在作业级别定义作业变量。

注：参数types和type被弃用。

参考

官方构建案例

Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD

参考其脚本

Configure GitLab CI/CD to deploy your application
Now we need to add the GitLab CI/CD configuration file (.gitlab-ci.yml) to our project’s root. This is how GitLab figures out what commands need to be run whenever code is pushed to our repository. We will add the following .gitlab-ci.yml file to the root directory of the repository, GitLab will detect it automatically and run the steps defined once we push our code:
image: java:8

stages:
 - build
 - deploy

build:
 stage: build
 script: ./mvnw package
 artifacts:
 paths:
 - target/demo-0.0.1-SNAPSHOT.jar

production:
 stage: deploy
 script:
 - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
 - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
 - ./cf push
 only:
 - master

配置

全局变量

进入工程CI设置配置全局变量脚本，包含镜像仓库登陆名称、密码、打包名称等

配置全局变量目的在于配置脚本中不应该包含密码等敏感信息

若希望使用GitLab内置环境变量，可参考官方表格

GitLab CI/CD environment variables

CI脚本

结合可用参数和样例配置，根据已经存在的SpringBoot项目编写响应的CI脚本.gitlab-ci.yml

image: docker:stable
services:
 - docker:dind

variables:
 DOCKER_DRIVER: overlay
 SPRING_PROFILES_ACTIVE: gitlab-ci

stages:
 - build
 - package

maven-build:
 image: maven:3-jdk-8
 stage: build
 script: "mvn package -B"
 artifacts:
 paths:
 - target/*.jar

docker-build:
 stage: package
 script:
 - docker build -t $CONTAINER_IMAGE:latest .
 - docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS
 - docker push $CONTAINER_IMAGE:latest

该脚本对于满足脚本目标的工程都可复用，若需要测试，则增加相关的测试步骤即可

此处由于工程包含外部依赖关系，不在构建时测试

自动构建

默认的触发构建事件为commit等

触发后会自动执行任务

Maven自动触发构建，自动镜像打包

自动上传（推送）镜像

执行结果

若执行失败则会发送邮件给开发人员

CICD全套流程目标实现！

总结

不管使用GitLab CICD或者是使用Jenkins+Ansible的方式，目标都在于践行DevOps，打通开发与运维流程，一旦配置好CICD流程，往后开发人员便不再操心打包、构建等操作，可以专注开发

DevOps GitLab CICD 实践2——Runner 部署

Wed, 03 Apr 2019 16:31:00 +0800

前置步骤：DevOps GitLab CICD 实践1——GitLab 部署

官方文档

文档地址

虽然有官方指引，但个人感觉指引的不够清晰，导致初次配置可能频繁失败

Run GitLab Runner in a container
This is how you can run GitLab Runner inside a Docker container.

General GitLab Runner Docker image usage
GitLab Runner Docker images (based on Ubuntu or Alpine Linux) are designed as wrappers around the standard gitlab-runner command, like if GitLab Runner was installed directly on the host.

The general rule is that every GitLab Runner command that normally would be executed as:
gitlab-runner [Runner command and options...]
can be executed with:
docker run [chosen docker options...] gitlab/gitlab-runner [Runner command and options...]
For example, getting the top-level help information for GitLab Runner command could be executed as:
docker run --rm -t -i gitlab/gitlab-runner --help

NAME:
 gitlab-runner - a GitLab Runner

USAGE:
 gitlab-runner [global options] command [command options] [arguments...]

VERSION:
 10.7.0 (7c273476)

(...)
In short, the gitlab-runner part of the command is replaced with docker run [docker options] gitlab/gitlab-runner, while the rest of Runner’s command stays as it is described in the register documentation. The only difference is that the gitlab-runner command is executed inside of a Docker container.

Docker image installation and configuration
Install Docker first:
 curl -sSL https://get.docker.com/ | sh
You need to mount a config volume into the gitlab-runner container to be used for configs and other resources:
 docker run -d --name gitlab-runner --restart always \
 -v /srv/gitlab-runner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest
Tip: On macOS, use /Users/Shared instead of /srv.

Or, you can use a config container to mount your custom data volume:
 docker run -d --name gitlab-runner-config \
 -v /etc/gitlab-runner \
 busybox:latest \
 /bin/true
And then, run the Runner:
 docker run -d --name gitlab-runner --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 --volumes-from gitlab-runner-config \
 gitlab/gitlab-runner:latest
Register the runner you just launched by following the instructions in the Docker section of Registering Runners. The runner won’t pick up any jobs until it’s registered.

安装步骤

获取Gitlab Runner秘钥

可以通过Gitlab管理员账号获取，也可以让每一个用户自行配置

普通用户查看秘钥

进入任意一个仓库的设置中，查看CICD配置

准备注册专用Runner令牌

管理员查看令牌

进入总设置页面，配置全局Runner令牌

Runner注册

由于Runner一般运行复杂构建、打包任务，推荐配置在性能、带宽更大的机房

准备Docker环境

$ curl -sSL https://get.docker.com/ | sh
$ systemctl start docker

注册

可以根据需要选择注册Runner类型

同时，为了方便配置，使用单行注册并且关闭交互

单行注册官方文档

命令说明：

-v挂载的目的是为了将注册后的配置文件持久化，用于运行容器
--rm指定容器运行结束后自动删除停止的容器
-it指定使用命令行交互方式运行，便于查看注册结果

$ docker run --rm -it \
 -v /www/wwwroot/gitlab/srv/gitlab-runner/config:/etc/gitlab-runner \
 gitlab/gitlab-runner:alpine-v11.8.0 register \
 --non-interactive \
 --executor "docker" \
 --docker-image docker:stable \
 --url "Gitlab URL" \
 --registration-token "令牌" \
 --description "描述" \
 --tag-list "标签1,标签2" \
 --run-untagged \
 --docker-privileged \
 --locked="false"

注册成功提示

此时管理面板显示新的Runner已经注册

Runner 启动

挂载本地配置信息并启动Runner

$ docker run -d --name gitlab-runner --restart always \
 	-v /www/wwwroot/gitlab/srv/gitlab-runner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:alpine-v11.8.0

此时可见Runner已经保持和Gitlab的联系

DevOps GitLab CICD 实践1——GitLab 部署

Wed, 03 Apr 2019 16:30:00 +0800

配置目标

邮件提示
GitHub第三方授权登陆
GitLab Runner
Docker私服注册

官方介绍

目前微服务盛行环境下，服务部署优先考虑Docker方式，便于迁移和弹性伸缩

官方镜像介绍 GitLab Docker images

GitLab Docker images
Both GitLab CE and EE are in Docker Hub:

GitLab CE Docker image

GitLab EE Docker image

The GitLab Docker images are monolithic images of GitLab running all the necessary services on a single container.

In the following examples we are using the image of GitLab CE. To use GitLab EE instead of GitLab CE, replace the image name to gitlab/gitlab-ee:latest.

If you want to use the latest RC image, use gitlab/gitlab-ce:rc or gitlab/gitlab-ee:rc for GitLab CE and GitLab EE respectively.

The GitLab Docker images can be run in multiple ways:

Run the image in Docker Engine

Install GitLab into a cluster

Install GitLab using docker-compose

docker-compose 脚本

此处选择社区版(CE)安装，同时为了便于参数配置，使用docker-compose方式编写脚本文件

Install GitLab using docker-compose
With Docker compose you can easily configure, install, and upgrade your Docker-based GitLab installation.
Install Docker Compose
Create a docker-compose.yml file (or download an example):
 web:
 image: 'gitlab/gitlab-ce:latest'
 restart: always
 hostname: 'gitlab.example.com'
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url 'https://gitlab.example.com'
 # Add any other gitlab.rb configuration here, each on its own line
 ports:
 - '80:80'
 - '443:443'
 - '22:22'
 volumes:
 - '/srv/gitlab/config:/etc/gitlab'
 - '/srv/gitlab/logs:/var/log/gitlab'
 - '/srv/gitlab/data:/var/opt/gitlab'
Make sure you are in the same directory as docker-compose.yml and run docker-compose up -d to start GitLab
Read “Pre-configure Docker container” to see how the GITLAB_OMNIBUS_CONFIG variable works.

Below is another docker-compose.yml example with GitLab running on a custom HTTP and SSH port. Notice how the GITLAB_OMNIBUS_CONFIG variables match the ports section:
web:
 image: 'gitlab/gitlab-ce:latest'
 restart: always
 hostname: 'gitlab.example.com'
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url 'http://gitlab.example.com:9090'
 gitlab_rails['gitlab_shell_ssh_port'] = 2224
 ports:
 - '9090:9090'
 - '2224:22'
 volumes:
 - '/srv/gitlab/config:/etc/gitlab'
 - '/srv/gitlab/logs:/var/log/gitlab'
 - '/srv/gitlab/data:/var/opt/gitlab'
This is the same as using --publish 9090:9090 --publish 2224:22.

官方提示说明Docker CE版基于Omnibus版本，故环境配置也可参考相关文档

Omnibus文档目录

Installation and Configuration using omnibus package
Note: This section describes the commonly used configuration settings. Check configuration section of the documentation for complete configuration settings.

Installing GitLab

Manually downloading and installing a GitLab package

Setting up a domain name/URL for the GitLab Instance so that it can be accessed easily

Enabling HTTPS

Enabling notification EMails

Enabling replying via email

Installing and configuring postfix

Enabling container registry on GitLab

You will require SSL certificates for the domain used for container registry

Enabling GitLab Pages

If you want HTTPS enabled, you will have to get wildcard certificates

Enabling Elasticsearch

GitLab Mattermost Set up the Mattermost messaging app that ships with Omnibus GitLab package.

GitLab Prometheus Set up the Prometheus monitoring included in the Omnibus GitLab package.

GitLab High Availability Roles

结合配置目标编写yaml文件

注意：

此处邮件使用163邮箱（官方没有提供163邮箱支持案例）
Docker私服公钥执行从私服上获取
由于特殊原因，目标配置未启动SSL安全连接，但GitLab可以通过简单配置支持SSL并自动更新证书

配置文档

Let’s Encrypt Integration
Primary GitLab Instance

Note: Introduced in GitLab version 10.5 and disabled by default. Enabled by default in GitLab version 10.7 and later if external_url is set with the httpsprotocol and no certificates are configured.

Note: In order for Let’s Encrypt verification to work correctly, ports 80 and 443 will need to be accessible to the Let’s Encrypt servers that run the validation. Also note that the validation currently does not work with non-standard ports.
Caution Administrators installing or upgrading to GitLab version 10.7 or later and do not plan on using Let’s Encrypt should set the following in /etc/gitlab/gitlab.rb to disable:
letsencrypt['enable'] = false
Add the following entries to /etc/gitlab/gitlab.rb to enable Let’s Encrypt support for the primary domain:
letsencrypt['enable'] = true # GitLab 10.5 and 10.6 require this option
external_url "https://gitlab.example.com"	 # Must use https protocol
letsencrypt['contact_emails'] = ['foo@email.com'] # Optional

生成163邮箱授权密码

生成GitHub授权秘钥

最终配置

version: '3.1'

services:

 gitlab:
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 external_url '外部访问地址'
 gitlab_rails['gitlab_shell_ssh_port'] = 外部SSH端口
 registry_external_url 'Docker私服地址'
 registry_nginx['ssl_certificate'] = "Docker 私服CA证书 crt文件"
 registry_nginx['ssl_certificate_key'] = "Docker 私服公钥 pem文件"
 gitlab_rails['smtp_enable'] = true
 gitlab_rails['smtp_address'] = "smtp.163.com"
 gitlab_rails['smtp_port'] = 465
 gitlab_rails['smtp_user_name'] = "邮件发送者名称"
 gitlab_rails['gitlab_email_from'] = '邮件发送地址'
 gitlab_rails['smtp_password'] = "授权密码"
 gitlab_rails['smtp_domain'] = "163.com"
 gitlab_rails['smtp_authentication'] = "login"
 gitlab_rails['smtp_enable_starttls_auto'] = true
 gitlab_rails['smtp_tls'] = true
 gitlab_rails['omniauth_enabled'] = true
 gitlab_rails['omniauth_allow_single_sign_on'] = true
 gitlab_rails['omniauth_block_auto_created_users'] = true
 gitlab_rails['omniauth_providers'] = [
 {
 "name" => "github",
 "app_id" => "Client ID",
 "app_secret" => "Client Secret",
 "url" => "https://github.com/",
 "args" => { "scope" => "user:email" }
 }
 ]
 image: gitlab/gitlab-ce:latest
 hostname: gitlab.fjy8018.top
 restart: always
 networks:
 - devops-service-bridge
 ports:
 - '8443:443'
 - '8099:8099'
 - '8022:22'
 volumes:
 - ./srv/gitlab/config:/etc/gitlab
 - ./srv/gitlab/logs:/var/log/gitlab
 - ./srv/gitlab/data:/var/opt/gitlab
 - /etc/docker/certs.d:/etc/docker/certs.d


networks:
 devops-service-bridge:
 driver: bridge