CI/CD ステップでの簡単なデータベース移行スクリプト

DevOps Writing Contestへの応募作品のいくつかで、優れたハイレベルな作品をたくさん見てきました。ただし、毎日の作業中に一般的なスタンバイ (開発、ステージ、本番など) でデータベースを最新の状態に保つ方法を検討している人はほとんどいません。この記事は初心者の開発者を対象としています。 Spring を例として使用し、データベース移行システムを CI/CD プロセスに導入する簡単な手法を示しました。

このデプロイには Liquibase および GitLab CI/CD ツールが必要です。ここでは、データベースが稼働していると仮定します。 PostgreSQLを使用することになります。

GitLab CI/CD

すでに GitLab をデプロイしている場合は、この手順を完全にスキップできます。

Gitlab をデプロイするには、Docker メソッドを使用します。 $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

次のステップは、ランナーをインストールして構成することです。

すでに長期にわたるプロジェクトがあり、すべてが長期間にわたってセットアップされている場合は、新しいランナーの作成をスキップできます。

例としてバージョン 16.4.1 を使用してランナーの作成を示します。 17.0 以降はすべてRUNNER_AUTHENTICATION_TOKENを使用して登録されますが、アプローチは現在のものに近いです。

まず、ランナー ソースをインストールする必要があります。デプロイされた GitLab に bash 経由でインストールするために、この例は、Apple Silicon ベースのシステム (他の OS はここで見つけることができます) のランナーをインストールする方法に役立ちます。

 # 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

これで、 New project runnerボタンをクリックして、UI を通じてランナー自体を作成できるようになりました。

各ランナーは、プラットフォーム、青色で表示されるタグ、およびその他のランタイム構成を持つことができます。プログラムからコマンドを実行できるかどうかを設定する必要がある場合、タグが役に立ちます。当分の間、私たちは他のことには興味がありません。

Create runnerをクリックした後は、ランナーを登録するだけです。

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

リキベース

Liquibase は、データベース移行を管理するための無料のオープンソース プラットフォームです。要約すると、Liquibase では、変更セット ファイルを使用してロールアップおよびロールバックの手順を記述することができます。スクリプト自体は、従来の SQL コマンドである場合もあれば、データベースに依存しない変更の記述であり、データベースに合わせて調整されたスクリプトに変換される場合もあります。サポートされているデータベースのリストは、ここから入手できます。

Spring アプリケーションで移行を実行する方法を示します。これは、すべての変更セットの実行を別のステップとして制御できるようにするために必要です。

プロジェクト

Spring アプリケーションを迅速に開発するには、ここにアクセスしてください。

それでは、 application.yml.有効なオプションと変更ログのオプションには特に注意を払う必要があります。最初のオプションはアプリケーション レベルで Liquibase を有効または無効にし、2 番目のオプションは変更ログへのパスを設定します。

 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

変数をどうするか?

私たちのプロジェクトでは Kubernetes を使用しています。これらのパラメーターは、さまざまなスキーム用に事前構成された値ファイルを使用してアプリケーションを構築するときにチーム自身が設定する必要があります。

 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"

カスタマイズの話に戻りましょう。私の意見では、すぐに展開できる完全に自立したアプリを作成するのが賢明な方法です。 CI/CD で個別のステージをさらに構築するために、移行ファイルを構築しましょう。チームごとに異なるツールを使用でき、このファイルを使用する移行システムに制限されません。

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

使用可能なすべてのコマンドは、 Liquibase のドキュメントに記載されています。ここで必要なのはupdateだけです。これにより、changelog-master.xml ファイルから現在のバージョンに更新できるようになります。

次のステップでは、CI/CD プロセスの続行方法に関する指示を含む .gitlab-ci.yml ファイルをプロジェクト ルートに作成します。

まず、 gitlab-ci.ymlファイルの組み込みリンカーに注目してください。このリンカーは、プロジェクトの相対パスci/lintにあります。設定をいじる前に、これを使用することをお勧めします。また、YAML ファイルの操作方法を理解していることも前提としています。

ステージとジョブ

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

migrationタグは、以前に生成されたランナーに、このタスクに反応してscriptセクションのスクリプトを実行するように指示します。 stage文字列は、このジョブが属するステージを識別します。必要に応じて、同じランナーが複数のプロジェクトに同時に取り組むことができます。環境ブロックは環境を指します。これは、スタンド (開発、本番前、本番など) のステータスを表示し、手動デプロイなどのアクションを実行できるダッシュボードの一種です。さらに、環境バインド変数を構成できます。ただし、このプレミアム機能をテストする機会はありませんでした。

エラーのある措置の拒否

デプロイメント手順で問題が発生した場合は、対応するマージを停止できます。これは、テストが独立したフェーズとして CI/CD に統合されている場合に特に役立ちます。この例では Liquibase にはテストがありませんが、たとえば間違ったファイル パスが入力された場合に誤動作する可能性があります。

最後の仕上げ

移行ファイルを作成して有効にしましょう。これを行うには、入力ポイントとしてchangelog-master.xmlファイルを作成する必要があります。

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

さまざまな XML、YAML、または JSON 形式を使用して移行を記述することができますが、私の好みでは SQL が最も読みやすいです。

実行しようとしましたが、すべてが成功しました。データベースを確認し、databasechangelog のエントリを確認してください。

結論

この記事では、GitLab を自分でデプロイする方法、ランナーをダウンロードして構成する方法、そして最も重要なこととして、データベース移行システムを CI/CD プロセスに統合する方法について説明しました。このガイドが、このガイドの実践に役立つことを願っています。