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

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

まず、顧客向けにオンライン システムを開発し、独自の Kubernetes クラスターにデプロイしました。 現在、当社の高負荷ソリューションはお客様のプラットフォームに移行しており、そのプラットフォームに対して完全に自動化された継続的展開プロセスがセットアップされています。 このおかげで、市場投入までの時間が短縮され、製品環境に変更を加えることができました。

この記事では、継続的展開 (CD) プロセスまたは顧客のプラットフォームへの更新の配信のすべての段階について説明します。

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

途中で設定の詳細を共有します。

1.CDを起動する

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

私たちのアプリケーションはマイクロサービス アーキテクチャ上で実行され、そのすべてのコンポーネントは XNUMX つのリポジトリに保存されます。 このおかげで、マイクロサービスの XNUMX つが変更された場合でも、すべてのマイクロサービスが収集されてインストールされます。

いくつかの理由から、XNUMX つのリポジトリを通じて作業を整理しました。

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

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

加えられた変更は、顧客の Git リポジトリと自動的に同期されます。 そこでアプリケーション アセンブリが構成され、ブランチの更新後に起動され、継続へのデプロイが行われます。 どちらのプロセスも、環境内の Git リポジトリから始まります。

開発とテストには独自の環境が必要であるため、顧客のリポジトリを直接操作することはできません。 当社はこれらの目的で Git リポジトリを使用しており、Git リポジトリと同期されています。 開発者がリポジトリの適切なブランチに変更を投稿すると、GitLab は直ちにこれらの変更を顧客にプッシュします。

この後、組み立てを行う必要があります。 これは、バックエンドとフロントエンドのアセンブリ、テスト、本番環境への配信という複数の段階で構成されます。

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

バックエンドとフロントエンドの構築は、GitLab Runner システムで実行される XNUMX つの並行タスクです。 元のアセンブリ構成は同じリポジトリにあります。

GitLab でビルドするための YAML スクリプトを作成するためのチュートリアル.

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

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

1. コンテナはテスト環境と実稼働環境の間で再構築されません。 パラメータ化を行って、同じコンテナーが再構築せずにテスト環境と運用環境の両方ですべての設定、環境変数、サービスを使用できるようにしました。

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

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

4. テスト環境へのすべての変更の自動展開 (UAT)

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

クラスターの更新は次を使用して開始されます ヘルムのアップデート。 その結果、何かが計画どおりに進まなかった場合、Helm はすべての変更を自動的かつ個別にロールバックします。 彼の仕事をコントロールする必要はない。

K8S クラスター構成をアセンブリとともに提供します。 したがって、次のステップは、configMap、デプロイメント、サービス、シークレット、および変更したその他の K8S 構成を更新することです。

次に、Helm はテスト環境でアプリケーション自体の RollOut 更新を実行します。 アプリケーションが運用環境にデプロイされる前。 これは、テスト環境に導入したビジネス機能をユーザーが手動でテストできるようにするために行われます。

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

更新を運用環境にデプロイするには、GitLab でボタンを XNUMX つクリックするだけで、コンテナがすぐに運用環境に配信されます。

同じアプリケーションは、再構築することなく、テスト環境と運用環境の異なる環境で動作できます。 アプリケーションでは何も変更せずに同じ成果物を使用し、パラメーターを外部で設定します。

アプリケーション設定の柔軟なパラメータ化は、アプリケーションが実行される環境に応じて異なります。 すべての環境設定を外部に移動しました。すべてが 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 値に必要な値を入力します。 この変数はコンテナ内にすでに設定されています。 アプリケーションからアクセスできるため、アプリケーション環境ごとにこの変数の値が異なります。

比較的最近、configMaps との連携を含む K8S サポートが Spring Cloud に登場しました。 Spring Cloud Kubernetes。 プロジェクトは積極的に開発され、根本的に変化していますが、実稼働環境で使用することはできません。 しかし、私たちはその状態を積極的に監視し、DEV 構成で使用します。 安定し次第、環境変数の使用から移行する予定です。

合計で

したがって、継続的デプロイメントは構成され、機能しています。 すべての更新は XNUMX 回のキーストロークで行われます。 製品環境への変更は自動的に反映されます。 そして重要なのは、アップデートによってシステムが停止するわけではありません。

今後の計画: データベースの自動移行

私たちはデータベースをアップグレードし、これらの変更をロールバックする可能性を検討しました。 結局のところ、アプリケーションの XNUMX つの異なるバージョンが同時に実行されています。古いバージョンが実行中で、新しいバージョンが起動しています。 そして、新しいバージョンが動作することが確実な場合にのみ、古いバージョンをオフにします。 データベースを移行すると、両方のバージョンのアプリケーションで作業できるようになります。

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

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

K8S ジョブを介してデータベースの移行を自動化し、CD プロセスに統合する予定です。 そして、私たちはこの経験をハブレで必ず共有します。

出所： habr.com