Scripts de migration de base de données simples sur votre étape CI/CD

J'ai vu beaucoup de travaux exceptionnels et de haut niveau dans plusieurs des soumissions au concours d'écriture DevOps . Cependant, peu de personnes réfléchissent à la manière de maintenir la base de données à jour dans les tâches courantes (développement, scène, production, etc.) tout en travaillant quotidiennement. Cet article est destiné aux développeurs novices. J'ai utilisé Spring comme exemple pour démontrer une technique simple permettant d'introduire un système de migration de base de données dans le processus CI/CD.

Nous aurons besoin des outils CI/CD Liquibase et GitLab pour ce déploiement. Supposons pour le moment qu'une base de données soit opérationnelle. J'utiliserai PostgreSQL.

GitLab CI/CD

Si GitLab est déjà déployé, vous pouvez ignorer complètement cette étape.

Pour déployer Gitlab, nous utiliserons la méthode Docker. Il est important de noter que nous devons créer la variable $GITLAB_HOME .

 sudo docker run --detach \ --hostname gitlab.devopscontest.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ee:16.4.1-ee.0

L'étape suivante consiste à installer et configurer les coureurs.

Si vous avez déjà un projet de longue durée et que tout a été configuré depuis longtemps, vous pouvez ignorer la création d'un nouveau coureur.

Je vais montrer la création d'un runner en utilisant la version 16.4.1 comme exemple. Tout ce qui est après 17.0 est enregistré en utilisant RUNNER_AUTHENTICATION_TOKEN , mais l'approche est proche de celle actuelle.

Tout d’abord, vous devez installer la source du coureur. Afin de l'installer via bash sur votre GitLab déployé, cet exemple vous explique comment installer runner pour les systèmes basés sur Apple Silicon (autres systèmes d'exploitation que vous pouvez trouver ici) :

 # Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 # Give it permission to execute sudo chmod +x /usr/local/bin/gitlab-runner # Create a GitLab Runner user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash # Install and run as a service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start

Nous pouvons maintenant créer le coureur lui-même via l'interface utilisateur en cliquant sur le bouton New project runner .

Chaque coureur peut avoir une plate-forme, des balises qui apparaissent en bleu et d'autres configurations d'exécution. Lorsque nous devons définir la possibilité d'exécuter des commandes à partir du programme, les balises sont utiles. Pour l’instant, tout le reste ne nous intéresse pas.

Après avoir cliqué sur Create runner , il ne vous reste plus qu'à inscrire votre coureur.

 # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU

Liquibase

Liquibase est une plateforme gratuite et open source pour gérer les migrations de bases de données. En résumé, Liquibase vous permet de décrire les procédures de rollup et de rollback à l'aide de fichiers changset. Les scripts eux-mêmes peuvent être des commandes SQL conventionnelles ainsi que des descriptions de modifications indépendantes de la base de données qui seront transformées en un script adapté à votre base de données. La liste des bases de données prises en charge est disponible ici .

Je vais vous montrer un moyen d'effectuer des migrations dans une application Spring. Cela est nécessaire pour que vous puissiez contrôler l'exécution de tous les ensembles de modifications en tant qu'étape distincte.

Projet

Pour développer rapidement une application Spring, rendez-vous ici .

Créons maintenant rapidement application.yml. Une attention particulière doit être accordée aux options activées et de journal des modifications. La première option active et désactive Liquibase au niveau de l'application, tandis que la seconde définit le chemin d'accès au journal des modifications.

 server: port: 80 spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} url: ${DB_HOST} liquibase: enabled: true change-log: classpath:db/changelog/db.changelog-master.xml

Que faire des variables ?

Nous utilisons Kubernetes dans notre projet, et ces paramètres doivent être définis par les équipes elles-mêmes lors de la construction de l'application à l'aide de fichiers de valeurs préconfigurés pour différents schémas.

 env: - name: SPRING_PROFILES_ACTIVE value: "dev" - name: DB_HOST value: "jdbc:postgresql://127.0.0.1:5436/your_db" - name: DB_USERNAME value: "user" - name: DB_PASSWORD value: "pass"

Revenons à la personnalisation. Créer des applications complètement autonomes et prêtes à être déployées immédiatement est, à mon avis, une pratique judicieuse. Afin de construire davantage une étape distincte dans CI/CD, construisons un fichier de migration. Nous pouvons utiliser différents outils pour différentes équipes, et nous ne sommes pas limités au système de migration avec ce fichier.

 #!/bin/sh cd /opt/app /opt/app/liquibase \ --changeLogFile=./db/changelog/changelog-master.xml \ --url="$DB_HOST" \ --username="$DB_USERNAME" \ --password="$DB_PASSWORD" \ --logLevel=info \ --headless=true \ update

Toutes les commandes possibles peuvent être trouvées dans la documentation Liquibase . Maintenant, nous n'avons besoin que update , ce qui nous permet de mettre à jour vers la version actuelle à partir du fichier changelog-master.xml.

L'étape suivante consiste à créer un fichier.gitlab-ci.yml à la racine du projet qui contient des instructions sur la façon de poursuivre le processus CI/CD.

Tout d'abord, je voudrais attirer l'attention sur l'éditeur de liens intégré pour le fichier gitlab-ci.yml , qui se trouve dans le projet au chemin relatif ci/lint . Avant de modifier la configuration, je suggère de l'utiliser. Il est également supposé que vous savez comment travailler avec les fichiers YAML.

Étapes et travaux

 stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev

La balise migration demande à notre exécuteur généré précédemment de réagir à cette tâche et d'exécuter des scripts dans la section script . La chaîne stage identifie l'étape à laquelle appartient ce travail. Si nécessaire, un même coureur peut travailler sur plusieurs projets à la fois. Le bloc environnement fait référence à l' environnement . Il s'agit d'un type de tableau de bord où vous pouvez visualiser l'état de vos stands (développement, pré-prod, prod, etc.) et prendre des actions telles que des déploiements manuels. De plus, des variables liées à l'environnement peuvent être configurées ; cependant, je n'ai pas eu l'occasion de tester cette fonctionnalité premium.

Rejet des mesures comportant des erreurs

Vous pouvez arrêter la fusion correspondante en cas de problème avec la procédure de déploiement. Cela est particulièrement utile si les tests sont intégrés dans CI/CD en tant que phase indépendante. Bien que Liquibase ne dispose pas de tests dans notre exemple, il peut mal fonctionner si des chemins de fichiers incorrects sont saisis, par exemple.

Touches finales

Créons un fichier de migration et activons-le. Pour ce faire, nous devons créer le fichier changelog-master.xml comme point d'entrée.

 <?xml version="1.1" encoding="UTF-8" standalone="no"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:pro="http://www.liquibase.org/xml/ns/pro" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd"> <include file="db/changelog/changeset-202310151300-create-table.sql"/> </databaseChangeLog>

 --liquibase formatted sql --changeset a.tyryshkin:create-table create table if not exists table ( id bigserial primary key, name varchar(255) ); create sequence if not exists table_id_seq;

Vous pouvez utiliser différents formats XML, YAML ou JSON pour décrire les migrations, mais SQL est le plus simple à lire à mon goût.

Nous essayons d’exécuter et tout réussit. Consultez notre base de données et voyez l’entrée dans databasechangelog.

Conclusion

Dans cet article, nous avons expliqué comment déployer GitLab vous-même, télécharger et configurer les exécuteurs et, plus important encore, intégrer un système de migration de base de données dans votre processus CI/CD. J'espère que ce guide vous aidera à mettre ce guide en action.