お客様のプラットフォーム上での継続的デプロイメントの実装

True Engineering では、顧客のサーバーに更新を継続的に配信するプロセスを確立しており、この経験を共有したいと考えています。

まず、お客様向けにオンラインシステムを開発し、自社のKubernetesクラスターに導入しました。現在、高負荷ソリューションをお客様のプラットフォームに移行し、完全自動化された継続的デプロイメントプロセスを構築しています。これにより、市場投入までの時間、つまり本番環境への変更の配信を短縮できました。

この記事では、継続的デプロイメント (CD) プロセス、つまり顧客のプラットフォームに更新を配信するすべての段階について説明します。

1. このプロセスはどのように始まるのか
2. 顧客のGitリポジトリとの同期、
3. バックエンドとフロントエンドのアセンブリ、
4. テスト環境へのアプリケーションの自動展開、
5. Prod への自動デプロイ。

セットアップの詳細は後ほど共有します。

1. CDを起動する

継続的デプロイメントは、開発者が Git リポジトリのリリース ブランチに変更をプッシュすることから始まります。

私たちのアプリケーションはマイクロサービスアーキテクチャに基づいており、すべてのコンポーネントは単一のリポジトリに保存されています。これにより、たとえマイクロサービスのいずれかが変更されたとしても、すべてのマイクロサービスが収集され、インストールされます。

私たちが作業を 1 つのリポジトリで整理した理由はいくつかあります。

• 開発の容易さ - アプリケーションは積極的に開発されているため、すべてのコードを同時に操作できます。
• アプリケーションが単一システムとしてすべてのテストに合格し、顧客の本番環境に配信されることを保証する単一の CI/CD パイプライン。
• バージョンの混乱をなくします。マイクロサービスのバージョンのマップを保存したり、Helm スクリプトで各マイクロサービスの構成を記述したりする必要がなくなります。

2. 顧客のGitソースコードリポジトリとの同期

変更内容はお客様のGitリポジトリと自動的に同期されます。そこでアプリケーションのビルドが設定され、ブランチの更新後に起動され、本番環境へのデプロイが行われます。これらのプロセスはいずれも、お客様の環境内でGitリポジトリから実行されます。

独自の開発・テスト環境が必要なため、お客様のリポジトリを直接操作することはできません。そのため、GitLabのGitリポジトリを使用しています。このリポジトリはお客様のGitリポジトリと同期されています。開発者がGitLabのリポジトリの対応するブランチに変更をプッシュすると、GitLabはすぐにその変更をお客様に送信します。

その後、ビルドを行う必要があります。ビルドは、バックエンドとフロントエンドの構築、テスト、そして本番環境への配信という複数の段階から構成されます。

3. バックエンドとフロントエンドの組み立て

バックエンドビルドとフロントエンドビルドは、GitLab Runnerシステムで実行される2つの並行タスクです。初期ビルド設定は同じリポジトリにあります。

GitLabでYAMLビルドスクリプトを書くためのチュートリアル.

GitLab Runnerは必要なリポジトリからコードを取得し、Javaアプリケーションのビルドコマンドを使用してアセンブルし、Dockerレジストリに送信します。ここでバックエンドとフロントエンドをアセンブルし、Dockerイメージを取得して、顧客側のリポジトリに配置します。Dockerイメージの管理には、以下を使用します。 Gradleプラグイン.

イメージのバージョンを、Dockerで公開されるリリースのバージョンと同期します。スムーズな動作のために、いくつかの設定を行いました。

1. テスト環境と本番環境間でコンテナは再構築されません。テスト環境と本番環境の両方で、同じコンテナがすべての設定、環境変数、サービスを使用して再構築なしで動作するように、パラメータ化されています。

2. Helm 経由でアプリケーションを更新するには、バージョンを指定する必要があります。私たちの場合、バックエンド、フロントエンドの構築、アプリケーションの更新はそれぞれ異なるタスクであるため、すべての環境で同じバージョンのアプリケーションを使用することが重要です。K8S クラスター構成とアプリケーションは同じ Git リポジトリにあるため、このタスクでは Git 履歴のデータを使用します。

コマンド実行の結果からアプリケーションのバージョンを取得します
git describe --tags --abbrev=7.

4. すべての変更をテスト環境（UAT）に自動的に展開する

このビルドスクリプトの次のステップは、K8Sクラスターを自動的に更新することです。これは、アプリケーション全体がビルドされ、すべてのアーティファクトがDockerレジストリに公開されていることを前提としています。その後、テスト環境の更新が開始されます。

クラスタの更新は次のように開始されます ヘルムアップデートその結果、何か問題が発生した場合、Helm はすべての変更を自動的かつ独立してロールバックします。その動作を監視する必要はありません。

ビルドには K8S クラスター構成が同梱されているので、次のステップではこれを更新します（configMaps、デプロイメント、サービス、シークレット、および変更したその他の K8S 構成）。

その後、Helm はテスト環境でアプリケーション自体の RollOut アップデートを実行します。これは、アプリケーションが本番環境にデプロイされる前に、ユーザーがテスト環境にリリースされたビジネス機能を手動で確認できるようにするためです。

5. すべての変更を本番環境に自動的にデプロイする

アップデートを本番環境にデプロイするには、GitLab でボタンを 1 つクリックするだけで、コンテナがすぐに本番環境に配信されます。

同じアプリケーションを、テスト環境と本番環境など、異なる環境で再構築することなく動作させることができます。アプリケーション自体には一切変更を加えず、同じ成果物を使用し、パラメータは外部から設定します。

アプリケーション設定の柔軟なパラメータ化は、アプリケーションが実行される環境によって異なります。すべての環境設定は外部化されており、K8S構成とHelmパラメータを介してパラメータ化されます。Helmがビルドをテスト環境にデプロイすると、テストパラメータが適用され、本番環境パラメータが本番環境に適用されます。

最も困難だったのは、環境に依存するすべてのサービスと変数をパラメーター化し、それらを環境変数と Helm の環境パラメーターの記述構成に変換することでした。

環境変数はアプリケーションのパラメータで使用されます。環境変数の値は、Goテンプレートでテンプレート化されたK8S configmapを使用してコンテナに設定されます。例えば、ドメイン名を環境変数に設定するには、次のようにします。

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – この変数には環境の名前 (prod、stage、UAT) が格納されます。
.Values.app.properties.app_external_domain – この変数では、.Values.yamlファイルで必要なドメインを設定します

アプリケーションを更新する際、Helm はテンプレートから configmap.yaml ファイルを作成し、アプリケーションの更新が開始される環境に応じて APP_EXTERNAL_DOMAIN 値に必要な値を設定します。この変数はコンテナ内で既に設定されています。アプリケーションからアクセスできるため、アプリケーション環境ごとにこの変数の値は異なります。

比較的最近、Spring Cloud は configMaps のサポートを含む K8S のサポートを追加しました。 Spring Cloud Kubernetesプロジェクトは現在開発中で劇的な変化が見られるため、本番環境では使用できません。ただし、状態を積極的に監視し、開発環境の設定で使用しています。安定次第、環境変数の使用から本番環境への切り替えを予定しています。

合計で

これで、継続的デプロイメントがセットアップされ、稼働状態になりました。すべてのアップデートはキー操作ひとつで完了します。本番環境への変更の配信は自動的に行われます。そして重要なのは、アップデートによってシステムの動作が停止されないことです。

将来の計画: 自動データベース移行

データベースのアップグレードと、これらの変更をロールバックする機能について検討しました。結局のところ、アプリケーションの2つの異なるバージョンが同時に実行されています。古いバージョンが実行中で、新しいバージョンが起動中です。そして、新しいバージョンが正常に動作していることが確実になったら、古いバージョンを停止します。データベースの移行は、アプリケーションの両方のバージョンで動作できるようにする必要があります。

そのため、列名やその他のデータを単純に変更することはできません。しかし、新しい列を作成し、古い列のデータをその列にコピーし、別の列を更新すると同時に別の列のデータもコピーして更新するトリガーを記述することは可能です。そして、新バージョンのアプリケーションが正常にデプロイされ、リリース後のサポート期間が終了したら、不要になった古い列とトリガーを削除できます。

新しいバージョンのアプリケーションが正常に動作しない場合は、データベースの以前のバージョンを含め、以前のバージョンにロールバックできます。つまり、今回の変更により、アプリケーションの複数のバージョンを同時に使用できるようになります。

K8Sジョブによるデータベース移行を自動化し、CDプロセスに統合する予定です。この経験はHabrでも必ず共有します。

出所： habr.com