Chez True Engineering, nous avons mis en place un processus de livraison continue de mises à jour aux serveurs des clients et souhaitons partager cette expérience.
Pour commencer, nous avons développé un système en ligne pour le client et l'avons déployé dans notre propre cluster Kubernetes. Notre solution à forte charge a désormais migré vers la plateforme du client, pour laquelle nous avons mis en place un processus de déploiement continu entièrement automatique. Grâce à cela, nous avons accéléré le délai de mise sur le marché, c'est-à-dire la mise en œuvre des modifications apportées à l'environnement du produit.
Dans cet article nous parlerons de toutes les étapes du processus de Déploiement Continu (CD) ou de livraison des mises à jour sur la plateforme client :
- Comment démarre ce processus ?
- synchronisation avec le dépôt Git du client,
- assemblage du backend et du frontend,
- déploiement automatique d'applications dans un environnement de test,
- déploiement automatique vers Prod.
Nous partagerons les détails de configuration en cours de route.
1. Démarrer le CD
Le déploiement continu commence lorsque le développeur apporte des modifications à la branche release de notre référentiel Git.
Notre application fonctionne sur une architecture de microservices et tous ses composants sont stockés dans un seul référentiel. Grâce à cela, tous les microservices sont collectés et installés, même si l'un d'entre eux a changé.
Nous avons organisé le travail via un seul référentiel pour plusieurs raisons :
- Facilité de développement - l'application se développe activement, vous pouvez donc travailler avec tout le code à la fois.
- Un pipeline CI/CD unique qui garantit que l'application en tant que système unique réussit tous les tests et est livrée dans l'environnement de production du client.
- Nous éliminons la confusion dans les versions - nous n'avons pas besoin de stocker une carte des versions du microservice et de décrire sa configuration pour chaque microservice dans les scripts Helm.
2. Synchronisation avec le dépôt Git du code source du client
Les modifications apportées sont automatiquement synchronisées avec le référentiel Git du client. Là, l'assembly d'application est configuré, qui est lancé après la mise à jour de la branche et le déploiement dans la suite. Les deux processus proviennent de leur environnement à partir d'un référentiel Git.
Nous ne pouvons pas travailler directement avec le référentiel du client car nous avons besoin de nos propres environnements pour le développement et les tests. Nous utilisons notre référentiel Git à ces fins - il est synchronisé avec leur référentiel Git. Dès qu'un développeur publie des modifications dans la branche appropriée de notre référentiel, GitLab transmet immédiatement ces modifications au client.
Après cela, vous devez faire l'assemblage. Il se compose de plusieurs étapes : assemblage backend et frontend, tests et livraison en production.
3. Assemblage du backend et du frontend
La construction du backend et du frontend sont deux tâches parallèles effectuées dans le système GitLab Runner. Sa configuration d'assemblage d'origine se trouve dans le même référentiel.
.
GitLab Runner récupère le code du référentiel requis, l'assemble avec la commande de construction d'application Java et l'envoie au registre Docker. Ici, nous assemblons le backend et le frontend, obtenons des images Docker, que nous mettons dans un référentiel du côté du client. Pour gérer les images Docker que nous utilisons .
Nous synchronisons les versions de nos images avec la version release qui sera publiée dans Docker. Pour un fonctionnement fluide, nous avons effectué plusieurs ajustements :
1. Les conteneurs ne sont pas reconstruits entre l'environnement de test et l'environnement de production. Nous avons effectué des paramétrages afin que le même conteneur puisse fonctionner avec tous les paramètres, variables d'environnement et services à la fois dans l'environnement de test et en production sans reconstruction.
2. Pour mettre à jour une application via Helm, vous devez préciser sa version. Nous construisons le backend, le frontend et mettons à jour l'application - ce sont trois tâches différentes, il est donc important d'utiliser la même version de l'application partout. Pour cette tâche, nous utilisons les données de l'historique Git, puisque notre configuration de cluster K8S et nos applications se trouvent dans le même référentiel Git.
Nous obtenons la version de l'application à partir des résultats de l'exécution de la commande
git describe --tags --abbrev=7.
4. Déploiement automatique de toutes les modifications apportées à l'environnement de test (UAT)
L'étape suivante de ce script de build consiste à mettre à jour automatiquement le cluster K8S. Cela se produit à condition que l'intégralité de l'application ait été créée et que tous les artefacts aient été publiés dans le registre Docker. Après cela, la mise à jour de l'environnement de test démarre.
La mise à jour du cluster est démarrée en utilisant . Si, par conséquent, quelque chose ne s'est pas déroulé comme prévu, Helm annulera automatiquement et indépendamment toutes ses modifications. Son travail n'a pas besoin d'être contrôlé.
Nous fournissons la configuration du cluster K8S avec l'assemblage. Par conséquent, l'étape suivante consiste à le mettre à jour : configMaps, déploiements, services, secrets et toute autre configuration K8S que nous avons modifiée.
Helm exécute ensuite une mise à jour RollOut de l'application elle-même dans l'environnement de test. Avant que l'application ne soit déployée en production. Ceci est fait afin que les utilisateurs puissent tester manuellement les fonctionnalités commerciales que nous mettons dans l'environnement de test.
5. Déploiement automatique de toutes les modifications vers Prod
Pour déployer une mise à jour dans l'environnement de production, il vous suffit de cliquer sur un bouton dans GitLab - et les conteneurs sont immédiatement livrés à l'environnement de production.
La même application peut fonctionner dans différents environnements (test et production) sans reconstruction. Nous utilisons les mêmes artefacts sans rien changer dans l'application, et nous définissons les paramètres en externe.
Le paramétrage flexible des paramètres de l'application dépend de l'environnement dans lequel l'application sera exécutée. Nous avons déplacé tous les paramètres d'environnement en externe : tout est paramétré via la configuration K8S et les paramètres Helm. Lorsque Helm déploie un assembly dans l'environnement de test, les paramètres de test lui sont appliqués et les paramètres du produit sont appliqués à l'environnement de production.
Le plus difficile a été de paramétrer tous les services et variables utilisés qui dépendent de l'environnement, et de les traduire en variables d'environnement et en descriptions-configurations des paramètres d'environnement pour Helm.
Les paramètres de l'application utilisent des variables d'environnement. Leurs valeurs sont définies dans des conteneurs à l'aide de la carte de configuration K8S, modélisée à l'aide de modèles Go. Par exemple, définir une variable d'environnement sur le nom de domaine peut être effectué comme ceci :
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – cette variable stocke le nom de l'environnement (prod, stage, UAT).
.Values.app.properties.app_external_domain – dans cette variable nous définissons le domaine souhaité dans le fichier .Values.yaml
Lors de la mise à jour d'une application, Helm crée un fichier configmap.yaml à partir de modèles et remplit la valeur APP_EXTERNAL_DOMAIN avec la valeur souhaitée en fonction de l'environnement dans lequel la mise à jour de l'application démarre. Cette variable est déjà définie dans le conteneur. Il est accessible depuis l'application, chaque environnement d'application aura donc une valeur différente pour cette variable.
Relativement récemment, la prise en charge de K8S est apparue dans Spring Cloud, notamment l'utilisation de configMaps : . Bien que le projet se développe activement et change radicalement, nous ne pouvons pas l'utiliser en production. Mais nous surveillons activement son état et l'utilisons dans les configurations DEV. Dès qu'il se stabilisera, nous passerons de l'utilisation de variables d'environnement à celui-ci.
En tout
Ainsi, le déploiement continu est configuré et fonctionne. Toutes les mises à jour s'effectuent en une seule frappe. La livraison des modifications à l’environnement du produit est automatique. Et surtout, les mises à jour n’arrêtent pas le système.
Projets futurs : migration automatique des bases de données
Nous avons réfléchi à la mise à niveau de la base de données et à la possibilité d'annuler ces modifications. Après tout, deux versions différentes de l’application s’exécutent en même temps : l’ancienne est en cours d’exécution et la nouvelle est opérationnelle. Et nous ne désactiverons l'ancienne que lorsque nous serons sûrs que la nouvelle version fonctionne. La migration de la base de données doit vous permettre de travailler avec les deux versions de l'application.
Par conséquent, nous ne pouvons pas simplement modifier le nom de la colonne ou d’autres données. Mais nous pouvons créer une nouvelle colonne, y copier les données de l'ancienne colonne et écrire des déclencheurs qui, lors de la mise à jour des données, les copieront et les mettront simultanément à jour dans une autre colonne. Et après le déploiement réussi de la nouvelle version de l'application, après la période de support post lancement, nous pourrons supprimer l'ancienne colonne et le déclencheur devenu inutile.
Si la nouvelle version de l'application ne fonctionne pas correctement, nous pouvons revenir à la version précédente, y compris la version précédente de la base de données. Bref, nos modifications vous permettront de travailler simultanément avec plusieurs versions de l'application.
Nous prévoyons d'automatiser la migration de la base de données via le travail K8S, en l'intégrant dans le processus CD. Et nous partagerons certainement cette expérience sur Habré.
Source: habr.com