Cloud Automation Patching Service (CAPS) ワークフローの仕組み
このトピックでは、CAPS (Cloud Automation Patching Service)を使用したパッチ操作の仕組みの概要を説明します。
用語
-
操作 - CAPSによって実行された主なアクション：
- 適用
- 元に戻す
-
フェーズ - ワークフローの3つのフェーズ：
- 事前チェック
- パッチ
- 検証
-
環境 - パッチが適用されるAdobe Commerce Cloud環境。
業務運営
CAPSでは、Adobe Commerce Cloud環境でパッチを管理するために、次の2つのメイン 操作をサポートしています。
-
操作を適用 – 安全で検証済みのプロセスを通じて、コードベースにパッチ変更を追加します。 パッチは、「m2-hotfixes」フォルダーにパッチファイルを配置することで適用されます。
-
操作を元に戻す - 'm2-hotfixes' フォルダーからパッチ ファイルを削除して、以前に適用したパッチをコードベースから削除します。
フェーズ
CAPS ワークフローでは、パッチが安全かつ確実に適用されるように、常にこの順序で実行される3つの フェーズ を使用します。
- 予備チェック - パッチの互換性と環境の準備状況を検証します。
- パッチ適用 – 統合環境でパッチを適用または元に戻します。
- 検証 - パッチアプリケーションを検証し、ヘルスチェックを実行します。
フェーズの詳細
フェーズ 1：事前チェック
事前チェック フェーズでは、パッチを環境に安全に適用できることを検証します。
何が起こるか：
-
実稼動環境のセーフガード （実稼動環境のみ）:
- ストアがメンテナンスモードになっているかどうかを確認します
- cron ジョブが無効になっていることを確認します
- 条件が満たされない場合、パッチ適用をブロック
- 条件が満たされた場合、確認ダイアログを表示します
-
パッチ検証 - パッチファイルが有効で互換性があることを確認します
-
環境評価 – 環境の準備状況とリソースを確認します
-
競合の検出 – 既存のコードとの潜在的な競合を特定します
-
依存関係チェック - Adobe Commerce バージョンの互換性を検証します
フェーズ 2：パッチ適用
パッチフェーズでは、テスト用に一時的な統合環境でパッチを適用または元に戻します。 この段階で、CAPSは実際の環境に変更を加える前に、パッチを安全に適用してテストするための一時的なテスト環境を作成します。
このアプローチでは、次のことが可能になります。
- 安全性 - パッチが検証されるまで、ターゲット環境は変更されません
- 実稼動環境に影響を与える前に、テスト – を実環境で実行します
- ロールバック機能 – 問題が検出された場合
- 分離 – 各パッチ操作について
ステージ 2a：統合環境の作成
分岐の作成 - CAPSは、{target-environment}-CAPS-{patch-id}という名前の一時的な統合環境ブランチを作成します
環境セットアップ – 統合環境はターゲット環境の子として作成されます
コード同期 – 統合環境は、ターゲット環境の正確な状態を継承します
リソース要件 - CAPSは、ターゲット環境のコードベースを使用して一時的な環境を作成します。 Adobe Commerce Cloudのドキュメントによると、各環境（統合環境を含む）には、契約したストレージプランに基づいて個別のストレージ割り当てがあります。 契約したストレージの量は、各環境の合計ストレージを表します。 多くの場合、リソースの制限に関する問題は発生しません。 リソースの制限に関するエラーが発生した場合は、プランのアプリケーションサイズと契約済みストレージを確認してください。
ステージ 2b：統合環境でのパッチアプリケーション
安全なテスト - パッチは、ターゲット環境に直接ではなく、統合環境に適用されます
ファイル管理 - パッチファイルはm2-hotfixes/ ディレクトリに配置されます
Git操作 – 変更がコミットされ、統合環境ブランチにプッシュされます
環境のアクティブ化 - パッチを適用したコードをデプロイするために統合環境がアクティブ化されます
ステージ 2c：ターゲット環境にマージ・バック
環境チェックアウト - CAPSは、ターゲット環境をローカルでチェックアウトします
結合操作 – 統合環境ブランチがターゲット環境に結合されます
競合解決 – 競合が発生した場合、可能な限り自動的に解決されます
デプロイメント – 結合された変更がターゲット環境にデプロイされます
検証 - CAPSは、結合が成功し、環境が同期していることを確認します
環境のクリーンアップ - リソースを解放するために、一時的な統合環境が削除されます
統合環境ライフサイクル
統合環境には、パッチ適用段階で特定のライフサイクルがあります。
- 作成 - パッチ適用段階の開始時に作成
- アクティブ期間 - パッチの適用中およびテスト中もアクティブのままです
- クリーンアップ – 結合が成功した後、または操作が失敗した場合に自動的に削除されます
フェーズ 3：検証
検証フェーズでは、パッチを適用したアプリケーションが正しく動作し、ヘルスチェックを実行します。
何が起こるか：
- アプリケーションの正常性チェック - アプリケーションが正常に開始および実行されていることを確認します
- クリーンアップ – 一時的な環境の削除、ログの更新、完了の通知
成功指標
操作の適用：
- 「ジョブが正常に完了しました」 – 問題なくパッチが適用されました
- 「パッチが適用されました」 – パッチは既に存在します（操作は必要ありません）
- パッチファイルが「m2-hotfixes」フォルダーに正常に配置されました
- すべての検証チェックが合格する
- アプリケーションのヘルスチェックに成功しました
操作を元に戻す：
- 「ジョブが正常に完了しました」 – パッチが問題なく元に戻されました
- 「パッチが元に戻されました」 – パッチは既に元に戻されました（操作は必要ありません）
- パッチファイルが「m2-hotfixes」フォルダーから正常に削除されました
- すべての検証チェックが合格する
- アプリケーションのヘルスチェックに成功しました
本番環境のセーフガード
CAPSには、誤って中断されるのを防ぎ、パッチが事前に安全に検証されていることを確認するための、実稼動環境に対する特定のセーフガードが含まれています。
本番環境へのパッチ適用の前提条件
実稼動環境にパッチを適用する前に、CAPSは2つの重要な条件をチェックします。
- メンテナンスモード - ストアはメンテナンスモードである必要があります
- Cron ジョブが無効 - Cron ジョブは無効にする必要があります
いずれかの条件が満たされない場合、パッチアプリケーションはブロックされ、ユーザーに通知されます。