Einfache Datenbankmigrationsskripte auf Ihrem CI/CD-Schritt

Ich habe in mehreren Einsendungen zum DevOps Writing Contest viele herausragende Arbeiten auf hohem Niveau gesehen. Allerdings denken nur wenige Menschen darüber nach, wie sie die Datenbank bei der täglichen Arbeit auf gemeinsamen Standbys (Entwickler, Bühne, Produkt usw.) auf dem neuesten Stand halten können. Dieser Artikel richtet sich an unerfahrene Entwickler. Ich habe Spring als Beispiel verwendet, um eine einfache Technik zur Einführung eines Datenbankmigrationssystems in den CI/CD-Prozess zu demonstrieren.

Für diese Bereitstellung benötigen wir die CI/CD-Tools Liquibase und GitLab. Gehen Sie zunächst davon aus, dass eine Datenbank betriebsbereit ist. Ich werde PostgreSQL verwenden.

GitLab CI/CD

Wenn Sie GitLab bereits bereitgestellt haben, können Sie diesen Schritt vollständig überspringen.

Um Gitlab bereitzustellen, verwenden wir die Docker-Methode. Es ist wichtig zu beachten, dass wir die Variable $GITLAB_HOME erstellen müssen.

 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

Der nächste Schritt besteht darin, Runner zu installieren und zu konfigurieren.

Wenn Sie bereits ein Projekt mit langer Laufzeit haben und alles schon seit langem eingerichtet ist, können Sie das Erstellen eines neuen Runners überspringen.

Ich zeige die Erstellung eines Runners am Beispiel der Version 16.4.1. Alles nach 17.0 erfolgt über die Registrierung mit RUNNER_AUTHENTICATION_TOKEN , aber der Ansatz ähnelt dem aktuellen.

Zuerst müssen Sie die Runner-Quelle installieren. Um es per Bash auf Ihrem bereitgestellten GitLab zu installieren, hilft dieses Beispiel, wie Sie Runner für Apple Silicon-basierte Systeme installieren können (andere Betriebssysteme finden Sie hier):

 # 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

Jetzt können wir den Runner selbst über die Benutzeroberfläche erstellen, indem wir auf die Schaltfläche New project runner klicken.

Jeder Runner kann eine Plattform, blau angezeigte Tags und andere Laufzeitkonfigurationen haben. Wenn wir die Möglichkeit festlegen müssen, Befehle aus dem Programm auszuführen, sind Tags hilfreich. An allem anderen sind wir vorerst desinteressiert.

Nachdem Sie auf Create runner geklickt haben, müssen Sie nur noch Ihren Läufer registrieren.

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

Flüssigkeitsbasis

Liquibase ist eine kostenlose Open-Source-Plattform zur Verwaltung von Datenbankmigrationen. Zusammenfassend lässt sich sagen, dass Sie mit Liquibase Rollup- und Rollback-Prozeduren mithilfe von Changeset-Dateien beschreiben können. Bei den Skripten selbst kann es sich sowohl um herkömmliche SQL-Befehle als auch um datenbankunabhängige Beschreibungen von Änderungen handeln, die in ein auf Ihre Datenbank zugeschnittenes Skript umgewandelt werden. Die Liste der unterstützten Datenbanken finden Sie hier .

Ich zeige Ihnen eine Möglichkeit, Migrationen in einer Spring-Anwendung durchzuführen. Dies ist notwendig, damit Sie die Ausführung aller Änderungssätze als separaten Schritt steuern können.

Projekt

Um schnell eine Spring-Anwendung zu entwickeln, klicken Sie hier .

Lassen Sie uns jetzt schnell application.yml. Besonderes Augenmerk sollte auf die Optionen „Aktiviert“ und „Änderungsprotokoll“ gelegt werden. Die erste Option aktiviert und deaktiviert Liquibase auf Anwendungsebene, während die zweite den Pfad zum Änderungsprotokoll festlegt.

 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

Was tun mit den Variablen?

Wir verwenden Kubernetes in unserem Projekt und diese Parameter müssen von den Teams selbst festgelegt werden, wenn sie die Anwendung mithilfe von Wertedateien erstellen, die für verschiedene Schemata vorkonfiguriert sind

 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"

Kommen wir zurück zur Anpassung. Meiner Meinung nach ist es eine kluge Vorgehensweise, völlig autarke Apps zu erstellen, die sofort einsatzbereit sind. Um eine eindeutige Phase in CI/CD weiter aufzubauen, erstellen wir eine Migrationsdatei. Wir können unterschiedliche Tools für unterschiedliche Teams verwenden und sind mit dieser Datei nicht auf das Migrationssystem beschränkt.

 #!/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

Alle möglichen Befehle finden Sie in der Liquibase-Dokumentation . Jetzt brauchen wir nur noch update , was uns ermöglicht, aus der Datei changelog-master.xml auf die aktuelle Version zu aktualisieren.

Der nächste Schritt besteht darin, eine.gitlab-ci.yml-Datei im Projektstammverzeichnis zu erstellen, die Anweisungen zum Fortfahren mit dem CI/CD-Prozess enthält.

Zunächst möchte ich auf den integrierten Linker für die Datei gitlab-ci.yml aufmerksam machen, der im Projekt unter dem relativen Pfad ci/lint zu finden ist. Bevor ich die Konfiguration durcheinander bringe, empfehle ich, sie zu verwenden. Es wird außerdem davon ausgegangen, dass Sie wissen, wie man mit YAML-Dateien arbeitet.

Etappen und Jobs

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

Das migration -Tag weist unseren zuvor generierten Runner an, auf diese Aufgabe zu reagieren und Skripte im script auszuführen. Die stage identifiziert die Stufe, zu der dieser Job gehört. Bei Bedarf kann derselbe Runner an mehreren Projekten gleichzeitig arbeiten. Der Umgebungsblock bezieht sich auf die Umgebung . Hierbei handelt es sich um eine Art Dashboard, in dem Sie den Status Ihrer Stände (Entwicklung, Vorproduktion, Produktion usw.) anzeigen und Aktionen wie manuelle Bereitstellungen durchführen können. Darüber hinaus können umgebungsgebundene Variablen konfiguriert werden; Allerdings hatte ich keine Gelegenheit, diese Premium-Funktion zu testen.

Ablehnung fehlerhafter Maßnahmen

Sie können die entsprechende Zusammenführung stoppen, falls beim Bereitstellungsvorgang etwas schief geht. Dies ist insbesondere dann hilfreich, wenn Tests als eigenständige Phase in CI/CD integriert werden. Obwohl Liquibase in unserem Beispiel keine Tests hat, kann es zu Fehlfunktionen kommen, wenn beispielsweise falsche Dateipfade eingegeben werden.

Letzter Schliff

Lassen Sie uns eine Migrationsdatei erstellen und aktivieren. Dazu müssen wir die Datei changelog-master.xml als Eingabepunkt erstellen.

 <?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;

Sie können verschiedene XML-, YAML- oder JSON-Formate verwenden, um Migrationen zu beschreiben, aber SQL ist für meinen Geschmack am einfachsten zu lesen.

Wir versuchen es umzusetzen und alles ist erfolgreich. Überprüfen Sie unsere Datenbank und sehen Sie sich den Eintrag im Datenbank-Changelog an.

Abschluss

In diesem Artikel haben wir besprochen, wie Sie GitLab selbst bereitstellen, Runner herunterladen und konfigurieren und, was am wichtigsten ist, ein Datenbankmigrationssystem in Ihren CI/CD-Prozess integrieren. Ich hoffe, dass dieser Leitfaden Ihnen dabei hilft, diesen Leitfaden in die Tat umzusetzen.