Red Hat Advanced Cluster Management and Application Management、Part 2. Blue / Green Deployment、Migration..。

このブログの皆さん、こんにちは!前回の投稿では、Red Hat Advanced Cluster Management(ACM)のアプリケーションライフサイクルの基本概念を取り上げ、2つのクラスターにアプリケーションを展開してそれらを適用する方法を示しました。今日は、青緑色の展開、クロスクラスターアプリケーションの移行、および災害復旧にACMを使用する方法を紹介します。







下の図に示すモデル構成を使用していることを思い出してください。例では積極的に使用するため、そこで使用可能なラベルに注意してください。



ソフトウェアコンポーネント バージョン
Red HatOpenShiftコンテナプラットフォーム 4.5.7
Red Hat Advanced Cluster Management 2.0フィックスパック2.0.2


Gitリポジトリ



前回の記事のGitリポジトリも使用します。



ブランチ 説明
構成 すべての環境で使用されるアプリケーションのベースファイルを格納します。
製品 実稼働環境で使用されるアプリケーションのオーバーレイファイルを格納します。
ステージ テスト環境で使用されるアプリケーションのオーバーレイファイルを格納します


Red HatACMを使用した青/緑の展開



前回の記事では、リバースワードアプリケーションを開発と本番の2つの環境にデプロイしました。たとえば、開発版にはバージョン0.0.3があり、本番環境には0.0.2があります。



ここで、開発者がバージョン0.0.4をリリースし、ACMのGitOps機能を使用して開発クラスターと本番クラスターに青緑色の展開を実行したいとします。



前回の記事では、必要なChannel、PlacementRules、Subscriptions、およびApplicationsリソースをACMで作成したため、新しいバージョンをデプロイすると、Gitのみが両方のクラスターで機能します。



開発環境でのアプリケーションの更新



必要なリソースはすべてすでに作成されているため、対応する環境のバージョンを更新するには、Gitでアプリケーションの説明を変更するだけで済みます。



注意。ここではACMのGitOps機能のみを示しているため、変更をリポジトリのブランチに直接プッシュしますが、これは適切ではありません。実際には、さまざまな環境に変更を加えるための明確に定義されたプロセスが必要ですこれについて詳しくは、こちらをご覧ください



1.クローン化されたGitリポジトリに移動します。



注:前の記事の例を複製した場合は、このリポジトリのクローン化されたブランチがすでにここにあります



cd /path/to/acm-app-lifecycle-blog/forked/repository/


2.まず、開発環境でアプリケーションのバージョンを更新して、変更を本番環境にプッシュする前にテストできるようにします。したがって、ステージブランチを使用します。



git checkout stage


3.次に、アプリケーションデプロイメントのオーバーレイを更新して、このデプロイメントが新しいバージョンのイメージ(0.0.4)を使用するようにする必要があります。



これまでのところ、リリース0.0.3は開発クラスターで実行されています。



sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml


4.変更をコミットする前に、開発クラスター内のアプリケーションの現在の状態を確認してください。



curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080


ご覧のとおり、バージョン0.0.3は現在開発環境で実行されています。



Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3


5.ファイルをコミットして、ステージブランチにプッシュします。



注意。繰り返しになりますが、実際の生活ではすべきではありません。これには、明確に定義されたプロセスが必要です。



git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage


6.すでにサブスクリプションがあるため、リポジトリとブランチへの新しいコミットを検出すると、ACMは、Gitで記述されているように、状態を現在の状態から目的の状態に変更するアクションを実行します。



oc --context dev -n reverse-words-stage get pods


ご覧のとおり、変更が検出され、新しいバージョンのポッドが新しいバージョンのアプリケーションとともにデプロイされています。



NAME                             READY   STATUS              RESTARTS   AGE
reverse-words-5ff744d4bd-kkfvn   0/1     ContainerCreating   0          3s
reverse-words-68b9b894dd-jfgpf   1/1     Running             0          109m


7.次に、アプリケーションへのリクエストを実行し、0.0.4リリースがデプロイされていることを確認します。



curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4


8.製品リリースはそのまま残ります。



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Production release v0.0.2. App version: v0.0.2


9.これで、検証テストを実行できます。すべて問題がなければ、新しいバージョンのアプリケーションを本番環境にロールアウトできます。



実稼働環境でのアプリケーションの更新



1.クローン化されたGitリポジトリに移動します。



cd /path/to/acm-app-lifecycle-blog/forked/repository/


2.開発クラスターで新しいバージョンのアプリケーションのテストに成功したと考えており、適切な変更を加えて本番クラスターにデプロイするときが来たので、次にprodブランチを使用します。



git checkout prod


3.この展開で新しいバージョンのイメージ(0.0.4)が使用されるように、アプリケーション展開のオーバーレイを更新する必要があります。



これまでのところ、リリース0.0.2は本番クラスターで実行されています



sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml


4.変更をコミットする前に、実稼働クラスター内のアプリケーションの現在の状態を確認してください。



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080


ご覧のとおり、バージョン0.0.2は現在本番環境で実行されています。



Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2


5.ファイルをコミットして、prodブランチにプッシュします。



注意。繰り返しになりますが、実際にはそうすべきではありません。これには、明確に定義されたプロセスが必要です。



git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod


6.すでにサブスクリプションがあるため、リポジトリとブランチへの新しいコミットを検出すると、ACMは、Gitで記述されているように、状態を現在の状態から目的の状態に変更するアクションを実行します。



oc --context pro -n reverse-words-prod get pods


ご覧のとおり、変更が検出され、新しいバージョンのポッドが新しいバージョンのアプリケーションとともにデプロイされています。



NAME                             READY   STATUS              RESTARTS   AGE
reverse-words-68795d69ff-6t4c7   0/1     ContainerCreating   0          5s
reverse-words-7dd94446c-vkzr8    1/1     Running             0          115m


7.次に、アプリケーションへのリクエストを実行し、0.0.4リリースがデプロイされていることを確認します。



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Production Release v0.0.4. App version: v0.0.4


8.これで、開発と本番の両方の環境でアプリケーションをバージョン0.0.4に更新しました。



結論



最初の部分このシリーズは、我々はGitOpsのカテゴリに分類さACMの側面をカバーしました。今日は、青緑色の展開、クラスター間のアプリケーションの移行、および災害復旧にACMを使用する方法を学びました。次の投稿では、ACMを使用してクラスター間でリバースワードアプリケーションをシームレスに移行する方法を紹介します。



All Articles