Chez True Engineering, nous avons mis en place le processus de mise à jour continue des serveurs des clients et souhaitons partager cette expérience.
Tout d'abord, nous avons développé un système en ligne pour le client et l'avons déployé dans notre propre cluster Kubernetes. Maintenant, notre solution hautement chargée est passée à la plate-forme du client, pour laquelle nous avons mis en place le processus de déploiement continu entièrement automatique. Grâce à cela, nous avons accéléré le délai de mise sur le marché - la livraison des modifications de l'environnement du produit.
Dans cet article, nous parlerons de toutes les étapes du processus de déploiement continu (CD) ou de la mise à jour de la plateforme du client:
- comment commence ce processus
- synchronisation avec le référentiel Git du client,
- assemblage backend et frontend
- déploiement automatique de l'application dans un environnement de test,
- déploiement automatique sur Prod.
Dans le processus, nous partagerons les détails des paramètres.
1. Démarrer le CD
Le déploiement continu commence par le fait que le développeur publie les modifications dans la branche de publication de notre référentiel Git.
Notre application fonctionne sur la base d'une architecture de microservices et tous ses composants sont stockés dans un référentiel. Grâce à cela, tous les microservices sont assemblés et installés, même si l'un d'eux a changé.
Nous avons organisé le travail via un référentiel pour plusieurs raisons:
- Facilité de développement - l'application se développe activement, vous pouvez donc travailler immédiatement avec tout le code.
- Un pipeline CI / CD unique qui garantit que l'application en tant que système unique passe tous les tests et est livrée à l'environnement de production du client.
- Nous excluons la confusion dans les versions - nous n'avons pas besoin de stocker une carte des versions de microservice et de décrire notre configuration pour chaque microservice dans les scripts Helm.
2. Synchronisation avec le référentiel Git du code source du client
Les modifications apportées sont automatiquement synchronisées avec le référentiel Git du client. Là, l'assemblage de l'application est configuré, qui démarre après la mise à jour de la branche, et le déploiement vers prod. Les deux processus se produisent dans leur environnement à partir du 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 de développement et de test. Nous utilisons notre référentiel Git à ces fins - il est synchronisé avec leur référentiel Git. Dès que le développeur publie les modifications dans la branche appropriée de notre référentiel, GitLab envoie immédiatement ces modifications au client.
Après cela, vous devez faire un assemblage. Il se compose de plusieurs étapes: assemblage du backend et du frontend, test et livraison au prod.
3. Construisez le backend et le frontend
Le backend et le frontend assembly sont deux tâches parallèles qui sont effectuées dans le système GitLab Runner. Sa configuration de l'assemblage d'origine réside dans le même référentiel.
Tutoriel pour écrire un script YAML à construire dans GitLab .
GitLab Runner récupère le code du référentiel souhaité, collecte la commande de génération d'application Java et l'envoie au registre Docker. Ici, nous collectons le backend et le frontend, obtenons les images Docker, que nous mettons dans le référentiel côté client. Pour gérer les images Doker, utilisez le
plugin Gradle .
Nous synchronisons les versions de nos images avec la version de la version, qui sera publiée dans Docker. Pour un fonctionnement fluide, nous avons effectué plusieurs réglages:
1. Entre l'environnement de test et les conteneurs d'épicerie ne sont pas remontés. Nous avons fait le paramétrage pour que le même conteneur puisse fonctionner sans reconstruire avec tous les paramètres, variables d'environnement et services à la fois dans l'environnement de test et dans le prod.
2. Pour mettre à jour l'application via Helm, vous devez spécifier sa version. Nous avons l'assemblage backend, le frontend et la mise à jour de 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 des données de l'historique Git, car nous avons une configuration de cluster K8S et les applications sont dans le même référentiel Git.
Nous obtenons la version de l'application à partir des résultats de la commande
git describe --tags --abbrev=7 .
4. Déploiement automatique de toutes les modifications dans un environnement de test (UAT)
L'étape suivante de ce script de génération consiste à mettre à jour automatiquement le cluster K8S. Cela se produit à condition que l'application entière soit assemblée et que tous les artefacts soient publiés dans le Docker Registry. Après cela, la mise à jour de l'environnement de test démarre.
La mise à jour du cluster est lancée à l'aide de
Helm Update . Si, par conséquent, quelque chose s'est mal passé, Helm annulera automatiquement et indépendamment tous ses changements. Son travail n'a pas besoin d'être contrôlé.
Avec l'assemblage, nous livrons la configuration du cluster K8S. 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.
Après cela, Helm lance RollOut mettre à jour l'application elle-même dans un environnement de test. Avant que l'application ne soit déployée sur le prod. Cette opération permet aux utilisateurs de vérifier manuellement les fonctionnalités métier que nous avons publiées dans l'environnement de test.
5. Déployez automatiquement toutes les modifications dans Prod
Pour déployer la mise à jour dans l'environnement du produit, il ne reste plus qu'à cliquer sur un bouton dans GitLab - et les conteneurs sont immédiatement livrés à l'environnement du produit.
Une seule et même application peut fonctionner sans reconstruction dans différents environnements - test et production. Nous utilisons les mêmes artefacts sans rien changer dans l'application, et nous définissons les paramètres de l'extérieur.
Le paramétrage flexible des paramètres d'application dépend de l'environnement dans lequel cette application sera exécutée. Nous avons supprimé tous les paramètres d'environnement: tout est paramétré via la configuration K8S et les paramètres Helm. Lorsque Helm déploie un assemblage dans un environnement de test, les paramètres de test s'appliquent à lui et les paramètres de produit s'appliquent à l'environnement de produit.
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 description-configuration des paramètres d'environnement pour Helm.
Les paramètres d'application utilisent des variables d'environnement. Leurs valeurs sont définies dans des conteneurs à l'aide de la configmap K8S, qui est basée sur des modèles Go. Par exemple, définir une variable d'environnement sur un nom de domaine peut se faire comme ceci:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env - le nom de l'environnement (prod, stage, UAT) est stocké dans cette variable.
.Values.app.properties.app_external_domain - dans cette variable nous dans le fichier .Values.yaml définissons le domaine souhaité
Lors de la mise à jour de l'application, Helm crée le fichier configmap.yaml à partir des modèles et remplit la valeur APP_EXTERNAL_DOMAIN avec la valeur requise 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. L'accès se fait depuis l'application, respectivement, dans chaque environnement de l'application il y aura une valeur différente de cette variable.
Relativement récent, Spring Cloud a introduit le support K8S, y compris le travail avec configMaps:
Spring Cloud Kubernetes . 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 stabilise, nous passerons de l'utilisation de variables d'environnement à celui-ci.
Total
Ainsi, le déploiement continu est opérationnel. Toutes les mises à jour se produisent au clic d'un bouton. La livraison des modifications de l'environnement alimentaire est automatique. Et, surtout, les mises à jour n'arrêtent pas le système.
Plans futurs: migration automatique de la base
Nous avons pensé à mettre à niveau la base de données et à pouvoir annuler ces modifications. Après tout, deux versions différentes de l'application fonctionnent simultanément: l'ancienne fonctionne et la nouvelle monte. Et nous ne désactiverons l'ancienne que lorsque nous serons convaincus que la nouvelle version fonctionne. La migration de la base de données doit permettre de travailler avec les deux versions de l'application.
Par conséquent, nous ne pouvons pas simplement changer 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 y écrire des déclencheurs qui, lorsque les données seront mises à jour, les copieront et les mettront à jour simultanément 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 pouvons 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. En un mot, nos modifications 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 du CD. Et nous partagerons sûrement cette expérience sur Habré.