Explorez les CI / CD Gitea-Drone sur K3

Au cours du week-end, j'ai exploré l'implémentation de CI / CD avec Gitea et Drone.io s'exécutant sur des K3. L'objectif est de mettre en place une implémentation légère de CI / CD pouvant être hébergée sur un ordinateur portable afin de simuler l'environnement sur site. Ce document documente la configuration pour référence future.

Il est supposé que le K3 est opérationnel sur votre ordinateur portable. Reportez-vous à mon papier “Exécution de K3 avec Multipass sur Macbook”Pour savoir comment exécuter les K3 sur votre Macbook.

Configuration Gitea

Gitea sera le référentiel de code source. Bien qu’il n’y ait pas de graphique dans le référentiel de Kubernetes Helm, grâce à jfelten, il en existe un sur https://github.com/jfelten/gitea-helm-chart.

Git clone le référentiel, créez le paquetage helm en lançant

helm package gitea

Télécharger le package créé, gitea-1.6.1.tgz, à la machine virtuelle multipass qui héberge les K3. Déposez le fichier dans le répertoire de /var/lib/rancher/k3s/server/static/charts

Maintenant, créez le CRD de déploiement Helmchart,

apiVersion: k3s.cattle.io/v1
kind: HelmChart
metadata:
name: gitea
namespace: kube-system
spec:
chart: https://%{KUBERNETES_API}%/static/charts/gitea-1.6.1.tgz
targetNamespace: gitea
valuesContent: |-
service:
http:
serviceType: NodePort
externalPort:
externalHost:
persistence:
enabled: true
accessMode: ReadWriteOnce
config:
secretKey: password
disableInstaller: true

Sélectionnez le serviceType comme NodePort. Définissez externalPort et externalHost sur vider pour utiliser l'adresse IP du cluster; Activez la persistance en définissant le paramètre accessMode sur ReadWriteOnce, car le mode ReadWriteMany n'est pas pris en charge sur hostPath. Définissez secretKey pour que la fenêtre contextuelle du programme d'installation initial soit désactivée.

Une fois que les pods sont en cours d’exécution, recherchez le NodePort du service, allez à l’URL puis enregistrez l’utilisateur,

Configuration du drone

Il y a un diagramme de drone Helm stable. Téléchargez le tableau de Helm pour éviter le problème du problème de synchronisation non synchronisé. Déployez-le avec ce qui suit,

apiVersion: k3s.cattle.io/v1
kind: HelmChart
metadata:
name: drone
namespace: kube-system
spec:
chart: https://%{KUBERNETES_API}%/static/charts/drone-2.0.0-rc.12.tgz
targetNamespace: drone
valuesContent: |-
service:
type: NodePort
sourceControl:
provider: "gitea"
gitea:
server: "http://gitea-gitea-http.gitea:3000"
server:
adminUser: "wenzm"

Définissez le fournisseur sur «gitea» et indiquez au serveur le nom de service de gitea à l'intérieur du cluster. Attribué à adminUser celui enregistré dans Gitea.

Trouvez le noeudport du drone, allez à la console Web. Connectez-vous à l'aide du nom d'utilisateur et du mot de passe dans Gitea. Aucun répertoire ne sera affiché dans Drone pour le moment.

Configuration de Gitea Webhook

Créez un référentiel dans Gitea. De retour à la console du drone, cliquez sur le bouton “SYNC” pour synchroniser le référentiel. Le référentiel Gitea apparaît dans Drone.

Cliquez sur Activer. Ensuite, vérifiez les paramètres / webhook du référentiel dans Gitea,

Le Webhook est créé. Cependant, étant donné que le drone ne se trouve pas dans le même espace de noms que Gitea, nous devons mettre à jour l'URL pour inclure l'espace de noms. Mettez à jour le Webhook comme ci-dessous.

http://drone-drone.drone/hook?secret=xxxxxxxxxxxxxxxxxxxxxxxx

Maintenant, nous avons intégré Gitea et Drone. S'il y a un événement push dans Gitea, Drone lancera l'exécution du pipeline.

Pipeline CI / CD

Comme d’autres, le pipeline CI / CD est défini dans le code source. Il est nommé comme .drone.yml Par défaut, il définit un pipeline composé de différentes étapes. Chaque étape consiste à exécuter un conteneur et à exécuter les tâches / commandes conçues en conséquence.

Le pipeline pour cette exploration est répertorié ci-dessous.

kind: pipeline
name: mypipeline
steps:
- name: build
image: golang
environment:
CGO_ENABLED: 0
commands:
- go build -o hello src/*.go
- name: build-push-dockerhub
image: plugins/docker
settings:
username:
from_secret: dockerUser
password:
from_secret: dockerPass
repo: zhiminwen/hello-by-drone
tags:
- "${DRONE_COMMIT_SHA:0:8}"
- name: deploy-to-k3s
image: zhiminwen/kubectl:v1.14
environment:
K3SSERVER:
from_secret: k3sServer
K3SCERT:
from_secret: k3sCert
K3SPASS:
from_secret: k3sPass
IMAGETAG: "${DRONE_COMMIT_SHA:0:8}"

commands:
- envsubst < k3s.env.yaml > k3s.yaml
- envsubst < deploy/kustomization.env.yaml > deploy/kustomization.yaml
- export KUBECONFIG=$${DRONE_WORKSPACE_BASE}/k3s.yaml
- cd deploy; kubectl apply -k .

1. Étape: construire

L'application est juste un simple gestionnaire HTTP golang hello world. Nous utilisons l'image golang pour construire l'application. Définir la variable d'environnement CGO_ENABLED à 0 car nous allons construire l'image du menu fixe en utilisant la base alpine.

2. Étape: construire-push-dockerhub

Lors de la création des images du menu fixe, nous utilisons le plug-in Drone pour créer l'image du menu fixe et l'insérer dans Dockerhub.

Un fichier Docker est créé dans le référentiel source comme indiqué ci-dessous,

FROM alpineRUN mkdir -p /app
ADD hello /app
RUN chmod a+rx /app/hello
CMD ("/app/hello")

Dans le pas, le repo paramètre définit le nom de l'image par défaut sur dockerhub repo. Si un autre dépôt est requis, définissez son nom complet, par exemple, mycluster.icp:8500/zhiminwen/hello-by-drone

Nous définissons la balise image en utilisant les 8 premiers caractères de la valeur SHA de validation pour cette construction.

Pour pouvoir accéder au dockerhub, un identifiant de connexion est requis. Créez les secrets du référentiel Drone à l'aide de l'outil de ligne de commande drone.

export DRONE_SERVER=http://192.168.64.5:30093
export DRONE_TOKEN=zlz8c26jRy0Vc14wXkSlv8ripVHkmdHT
drone secret add --name dockerUser --data xxxxxx --repository wenzm/cicd
drone secret add --name dockerPass --data yyyyyy --repository wenzm/cicd

3. Étape: déployer-à-k3s

Nous allons déployer l'application dans K3 avec la construction de l'image.

Construire l'image kubectl

Créez une image de menu fixe avec le fichier Docker suivant pour exécuter la commande kubectl. Notez que j'utilise la version 1.14 afin que la fonctionnalité Kustomize puisse être utilisée.

FROM alpineRUN apk update && 
apk add curl gettext &&
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl &&
mv kubectl /usr/local/bin &&
chmod a+rx /usr/local/bin/kubectl

Pendant ce temps, le paquet gettext est ajouté car je dois exécuter le envsubst commande pour substituer les variables d'environnement.

Préparez le fichier KUBECONFIG

Avec l'outil prêt, je dois parler au serveur K3. Ajoutez le fichier k3s.env.yaml suivant dans le référentiel,

apiVersion: v1
clusters:
- cluster:
certificate-authority-data: $K3SCERT
server: $K3SSERVER
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
password: $K3SPASS
username: admin

Créez le secret du drone pour l'autorité de certification, le serveur K3, le mot de passe K3. Au cours de l’étape du pipeline, créez les variables d’environnement avec ces données secrètes.

Dans la commande pipeline, nous créons d’abord le fichier k3s.yaml en remplaçant la variable d’environnement, puis exportons KUBECONFIG dans le fichier nouvellement créé. Nous sommes prêts à exécuter la commande kubectl sur le serveur K3.

- envsubst < k3s.env.yaml > k3s.yaml
- export KUBECONFIG=$${DRONE_WORKSPACE_BASE}/k3s.yaml

J'utilise $$ pour échapper à la variable en expansion lorsque Drone tente d'exécuter la commande.

Déployer avec Kustomize

Pour éviter de créer des modèles excessifs, j'ai utilisé la dernière fonctionnalité Kustomize intégrée à la version 1.14 de Kubectl.

Dans le référentiel source, créez un dossier de déploiement, enregistrez les fichiers deploy.yaml et service.yaml suivants, qui ne sont pas censés être modifiés.

---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: hello
name: hello
namespace: demo
spec:
replicas: 1
selector:
matchLabels:
app: hello
template:
metadata:
labels:
app: hello
spec:
containers:
- name: hello
image: zhiminwen/hello-by-drone

Le fichier service yaml,

---
apiVersion: v1
kind: Service
metadata:
labels:
app: hello
name: hello
namespace: demo
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 8080
selector:
app: hello
type: NodePort

Créez le fichier Kustomization.env.yaml suivant qui personnalisera les paramètres d'image du déploiement.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
- name: zhiminwen/hello-by-drone
newName: zhiminwen/hello-by-drone
newTag: $IMAGETAG
resources:
- resources/deploy.yaml
- resources/service.yaml

Dans la commande pipeline, je vais d’abord créer le fichier Kustomization.yaml avec le fichier envsubst commande pour remplacer le $IMAGETAG variable d’environnement définie comme “${DRONE_COMMIT_SHA:0:8}”. Cela obligera le déploiement à utiliser la balise image dans la version actuelle.

- envsubst < deploy/kustomization.env.yaml > deploy/kustomization.yaml- cd deploy; kubectl apply -k .

Ensuite, appliquez la personnalisation avec l'option -k.

Essai

Mettez à jour le code, validez la modification, appuyez sur le référentiel. Le pipeline est lancé et fonctionne correctement.

L'application est accessible sans problème.

Nous serions ravis de connaître votre avis

      Laisser un commentaire