日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

アストラ制御を使用すると、事後分析やアプリケーションのリストアが容易になります

05/22/2023 寄稿者

概要

を参照してください "最初のユースケース"では、ネットアップのAstra Control Centerを使用してKubernetesでアプリケーションを保護する方法を紹介しました。このセクションでは、NetApp AstraツールキットのPython SDKを使用して、Astra Controlを介したアプリケーションバックアップを開発ワークフローに直接統合する方法について説明します。このアプローチにより、継続的統合/継続的導入（CI / CD）プロセスでオンデマンドバックアップを自動化することで、開発環境と本番環境の保護が可能になります。アプリケーションと整合性のあるデータ保護のこの追加レイヤーがCI / CDパイプラインと本番アプリケーションに追加されたことで、プロセスに何か問題が発生しても開発プロセスは安全になり、ビジネス継続性のプラクティスが促進されます。

従来のワークフローでは、アプリケーションを新しいバージョンにアップグレードするときにエラーが発生した場合、開発チームはお客様から提供されたバグレポートに基づいて問題のトラブルシューティングをリアルタイムで試みます。また、最初に問題が発生したときに、チームはアプリケーションを並列デバッグ環境に再配置して、そのプロセスをオフラインにすることもできます。以前のバージョンの古いコードベースを本番環境に再導入することで、アプリケーションを作業順序に復元できます。

このアプローチは機能しますが、問題が発生したときに本番環境で使用されていたバージョンと破損した本番アプリケーションの状態が一致していることを確認する必要があります。また、リポジトリからコードを取得し、マシンイメージを再展開してアプリケーションを良好な稼働状態に復元することで、動作確認済みビルドを本番環境にプロモートするための時間も必要になります。また、このシナリオでは、本番環境のデータベース自体が、障害のあるコードによって破損していないかどうかを考慮しませんでした。データベースデータのバックアッププロセスが別に用意されているのは理想的ですが、公開時にアプリケーションの状態と整合性があると仮定する必要があります。ここでは、Astra Controlを使用して、ステートフルでアプリケーションと整合性のあるバックアップ、リストア、クローンを作成することのメリットが、まさにその価値を示しています。

まず、アストラ制御を使用して、アプリケーションの状態に関する事後分析を容易に行うことができます。そのためには、アプリケーションと整合性のある方法で、バグのある本番バージョンを並行テスト環境にクローニングします。この環境をバグ非表示状態にしておくと、リアルタイムで問題のトラブルシューティングを行うことができます。

さらに、Astra Controlでは、インプレースリストア機能がサポートされているため、本番アプリケーションを最後の許容可能なバックアップ（コードのバージョンが古い場合）にリストアできます。復元されたバージョンは、以前に割り当てられた入力IPを含む、アプリケーションと一貫性のあるステートフルな方法で、以前のバグのある本番アプリケーションの位置を想定しています。そのため、フロントエンドにアクセスするお客様は、バックアップバージョンへの移行を認識しません。

ユースケースの検証の前提条件

前提条件として、次のツールまたはプラットフォームを導入および設定しました。

Red Hat OpenShift Container Platform：
NetApp ONTAP システムにバックエンドを設定して、OpenShiftにNetApp Astra Tridentをインストールします。
NetApp ONTAP バックエンドをポイントするデフォルトのストレージクラスが設定されている
OpenShiftクラスタにNetApp Astraコントロールセンターをインストール。
OpenShiftクラスタをAstra Control Centerにマネージドクラスタとして追加。
OpenShiftクラスタにJenkinsをインストールしました。
本番環境にインストールされたMagentoアプリケーション。このユースケースの本番環境は、Red Hat OpenShiftクラスタで「ジェント本番環境」という名前のネームスペースです。
本番アプリケーションはAstra Control Centerによって管理されます。
Astra Controlでキャプチャされた、本番アプリケーションの正常なバックアップ。

クローニングとリストアのパイプライン

アプリケーションが新しいバージョンにアップグレードされたことを考慮して、本番環境のアプリケーション（「Magent-prod」）はアップグレード後に意図したとおりに動作しません。フロントエンドクエリから返されるデータがリクエストと一致しないか、データベースが実際に破損しているとします。パイプラインをクローニングしてリストアするには、次の手順を実行します。

Jenkinsにログインし、[新しいアイテム]、[パイプライン]の順にクリックしてパイプラインを作成します。
Jenkinsfileからパイプラインをコピーします "こちらをご覧ください"。
パイプラインをJenkinsパイプラインセクションに貼り付け、保存をクリックします。
Jenkinsパイプラインのパラメータに、本番環境の現在のMagentoアプリケーションバージョン、Astra Control Center FQDN、APIトークン、本番環境とデバッグ環境のインスタンスIDとアプリケーション名またはネームスペース、ソースクラスタ名とデスティネーションクラスタ名など、それぞれの詳細を入力します。このユースケースのために、本番環境は「メント本番」と呼ばれるネームスペースであり、デバッグ環境はRed Hat OpenShiftクラスタで構成される「メントデバッグ」と呼ばれるネームスペースです。
```
MAGENTO_VERSION = '2.4.1-debian-10-r14'
ASTRA_TOOLKIT_VERSION = '2.0.2'
ASTRA_API_TOKEN = 'xxxxx'
ASTRA_INSTANCE_ID = 'xxx-xxx-xxx-xxx-xxx'
ASTRA_FQDN = 'netapp-astra-control-center.org.example.com'
PROD_APP_NAME = 'magento-prod'
DEBUG_APP_NAME = 'magento-debug'
DEBUG_NAMESPACE = 'magento-debug'
PROD_KUBERNETES_CLUSTER = 'ocp-vmw'
DEBUG_KUBERNETES_CLUSTER = 'ocp-vmw'
```
[今すぐ構築]をクリックしますパイプラインが実行を開始し’ステップを進めますアプリケーションは、最初に現在の状態でデバッグ環境にクローニングされ、その後、動作確認済みのバックアップにリストアされます。
クローニングしたアプリケーションのバージョンがバグを含むことを確認します。
本番環境が稼働中のバックアップにリストアされ、本番環境のアプリケーションが想定どおりに動作することを確認します。