への応募作品のいくつかで、優れたハイレベルな作品をたくさん見てきました。ただし、毎日の作業中に一般的なスタンバイ (開発、ステージ、本番など) でデータベースを最新の状態に保つ方法を検討している人はほとんどいません。この記事は初心者の開発者を対象としています。 Spring を例として使用し、データベース移行システムを CI/CD プロセスに導入する簡単な手法を示しました。 DevOps Writing Contest このデプロイには 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 はここで見つけることができます) のランナーをインストールする方法に役立ちます。 https://docs.gitlab.com/runner/install/?embedable=true # 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 これで、 ボタンをクリックして、UI を通じてランナー自体を作成できるようになりました。 New project runner 各ランナーは、プラットフォーム、青色で表示されるタグ、およびその他のランタイム構成を持つことができます。プログラムからコマンドを実行できるかどうかを設定する必要がある場合、タグが役に立ちます。当分の間、私たちは他のことには興味がありません。 をクリックした後は、ランナーを登録するだけです。 Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU リキベース データベース移行を管理するための無料のオープンソース プラットフォームです。要約すると、Liquibase では、変更セット ファイルを使用してロールアップおよびロールバックの手順を記述することができます。スクリプト自体は、従来の SQL コマンドである場合もあれば、データベースに依存しない変更の記述であり、データベースに合わせて調整されたスクリプトに変換される場合もあります。 。 Liquibase は、 サポートされているデータベースのリストは、ここから入手できます Spring アプリケーションで移行を実行する方法を示します。これは、すべての変更セットの実行を別のステップとして制御できるようにするために必要です。 プロジェクト Spring アプリケーションを迅速に開発するには、 。 ここにアクセスしてください それでは、 有効なオプションと変更ログのオプションには特に注意を払う必要があります。最初のオプションはアプリケーション レベルで Liquibase を有効または無効にし、2 番目のオプションは変更ログへのパスを設定します。 application.yml. 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 変数をどうするか? これらを GitLab に配置することをお勧めします。これにより、開発/運用スタンド間でアプリケーションを柔軟にカスタマイズできます。 私たちのプロジェクトでは 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 使用可能なすべてのコマンドは、 に記載されています。ここで必要なのは だけです。これにより、changelog-master.xml ファイルから現在のバージョンに更新できるようになります。 Liquibase のドキュメント update 次のステップでは、CI/CD プロセスの続行方法に関する指示を含む .gitlab-ci.yml ファイルをプロジェクト ルートに作成します。 まず、 ファイルの してください。このリンカーは、プロジェクトの相対パス にあります。設定をいじる前に、これを使用することをお勧めします。また、YAML ファイルの操作方法を理解していることも前提としています。 gitlab-ci.yml 組み込みリンカーに注目 ci/lint ステージとジョブ 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 にはテストがありませんが、たとえば間違ったファイル パスが入力された場合に誤動作する可能性があります。 CI/CD の構成後にチェックボックスがオンになっていない場合、すべてのマージは許可されません。 最後の仕上げ 移行ファイルを作成して有効にしましょう。これを行うには、入力ポイントとして ファイルを作成する必要があります。 changelog-master.xml より柔軟な管理のために、複数のchangelog.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 プロセスに統合する方法について説明しました。このガイドが、このガイドの実践に役立つことを願っています。
