Gestion des Déploiements

Il y a deux cas possibles de déploiement selon les demandes étudiantes :

1. Application déjà conteneurisée

Par « application déjà conteneurisée », on inclut toutes applications/solutions utilisée sur le marché (ex: VaultWarden, NextCloud, Authentilk, ArgoCD, Gitlab …) qui est déjà conteneurisée et accessible sur un registre comme DockerHub ou GitHub Container Registry et potentiellement disponible via un helm chart.


Une application qui existe déjà et qui peut être hébergée (self-hosted), puisqu’une image Docker est disponible en ligne.

Cela demande d’automatiser le déploiement (CD) en écrivant des fichiers YAML qui représentent le déploiement dans Kubernetes (k8s).

Idéalement, les fichiers YAML sont testés en sandbox, manuellement avec l’utilitaire kubectl. Lorsque le déploiement semble fonctionner sur le cluster sandbox, le code peut être ajouté au dépôt GitOps de production afin qu’ArgoCD gère son déploiement et ses ressources.

Parfois, une application peut avoir des préconfigurations de déploiement avec Helm. Il est important de choisir des charts Helm fréquemment mis à jour pour assurer la longévité du déploiement.

Étapes pour déployer une application déjà conteneurisée

  • Choisir l’image Docker ou le chart Helm (préconfiguration de déploiement). Le choix doit se faire selon la fréquence des mises à jour, la date de la dernière mise à jour et les versions disponibles.

  • Écrire les fichiers (souvent en s’inspirant de déploiements similaires dans nos dépôts GitOps k8s-<clusterName> sur GitHub).

    https://github.com/ClubCedille/k8s-shared/tree/main

  • Tester les fichiers en les appliquant avec kubectl sur le cluster sandbox (https://github.com/ClubCedille/k8s-cedille-sandbox)

  • Lorsque le déploiement fonctionne, copier les fichiers dans le dépôt GitOps de production(https://github.com/ClubCedille/k8s-cedille-production-v2), dans une branche bien nommée, puis pousser la branche pour créer une merge request vers main.

  • Après révision et fusion (merge), ArgoCD pourra déployer l’application. Par la suite, il pourra la redéployer après chaque changement futur.


Il est important de pinner les versions, c’est-à-dire de spécifier une version précise plutôt que d’utiliser latest, afin d’éviter les breaking changes et les mises à jour automatiques non contrôlées.

exemple :
apps/outline/base/outline-statefulset.yaml

      image: outlinewiki/outline:1.1.0


Pour les images Docker hébergées sur notre GHCR à partir de code provenant de dépôts Git, l’utilisation de latest est acceptable. Cela permet aux étudiants de mettre à jour automatiquement leurs applications : en modifiant leur code puis en poussant/mergeant sur main, le pipeline reconstruit l’image, la pousse sur le registre, puis ArgoCD détecte la nouvelle version et met à jour le déploiement.

exemple :
apps/dronolab/webApp/base/deployment.yaml

      image: ghcr.io/dronolab/dronolab-website:latest

2. Code sur un dépôt Git

Par « code sur un dépôt git », on inclut tout code sur un répertoire Git. Que ce soit pour un site web ou un backend à la demande d’un club. Nous préférons que les répertoires soient publics quoique non-obligatoire.

Du code hébergé sur un dépôt Git doit d’abords être conteneurisé pour après le déployer comme dans le cas d’une application déjà conteneurisée (cas 1).

Cela demande d’automatiser l’intégration (CI) du code pour produire un artefact (image conteneurisée) qui pourra être déployé.

Concrètement, cela implique de créer un fichier Dockerfile (s’il n’existe pas déjà) ainsi qu’un fichier .github/workflows/build_and_push.yaml. Lorsqu’un changement est effectué sur la branche main/master, un pipeline est déclenché pour reconstruire l’image et la pousser vers un registre d’images (nous utilisons GitHub Container Registry — GHCR — de notre organisation).

Étapes pour déployer à partir de code

  • Demander que le compte GitHub cedille@etsmtl.net ainsi que votre utilisateur GitHub soient ajoutés au projet.

  • Créer, si nécessaire, les fichiers Dockerfile et .github/workflows/build_and_push.yaml.

  • Ajouter le secret dans le dépôt pour permettre au pipeline de pousser l’image vers notre GHCR (secret utilisé par le pipeline). Au lien de le regénérer à chaque nouveau déploiement, une copie du secret est dans vaultwarden (nommé GHCR external token)

  • Déployer ensuite l’application en utilisant l’image Docker générée sur notre GHCR, comme pour une application déjà conteneurisée.

Visualisation


Exemple : cedille.etsmtl.ca

Voici une des vues des composantes Kubernetes dans ArgoCD. On peut voir le nuage qui représente Internet, d’où proviennent les requêtes.

Ensuite, l’IP 142.137.247.79 est l’adresse publique du cluster sur lequel roule le déploiement.

Les deux composantes « ing » sont des Ingress (reverse proxies) qui acheminent les requêtes lorsqu’elles ciblent un nom de domaine. Ici, pour le site, il s’agit de cedille.etsmtl.ca et cedille.club, car nous voulons que ces deux domaines pointent vers le site du club.

Les requêtes sont ensuite acheminées vers le « svc » (Service), qui définit à quel port et à quels pods l’application est associée.

Finalement, les pods exécutent l’image Docker définie dans les fichiers de déploiement — concrètement, notre site web.


Le code du déploiement de notre site web se trouve dans le repo GitOps k8s-cedille-production-v2. Les fichiers sont définis comme suit :

  • cedille.argoapp.yaml : définit une application dans ArgoCD nommée « cedille », avec les champs nécessaires à la gestion et au déploiement automatique des ressources Kubernetes.

  • prod/kustomization.yaml : les fichiers kustomization.yaml servent principalement à lier les fichiers YAML à déployer.

  • prod/ingress.yaml : définit les Ingress, c’est-à-dire les noms de domaine qui pointent vers le service.

  • base/service.yaml : définit le Service qui pointe vers les déploiements (pods).

  • base/deployment.yaml : définit le déploiement, ce qui crée les pods exécutant les images Docker de notre site web.