スターターアーキテクチャ
Adobe Commerce on cloud infrastructure スターターアーキテクチャでは、初期プロジェクトコード、ステージング環境、および最大2つの統合環境を含むmaster環境を含む、最大 4 環境をサポートします。
すべての環境はPaaS （Platform as a Service）コンテナ内にあります。 これらのコンテナは、サーバーのグリッド上の非常に制限されたコンテナ内にデプロイされます。 これらの環境は読み取り専用で、ローカルワークスペースからプッシュされたブランチからデプロイされたコード変更を受け入れます。 各環境には、データベースとweb サーバーが用意されています。
master環境からstaging環境を作成します。 次に、stagingから分岐してintegration環境を作成します。スターター環境のアーキテクチャ
次の図は、スターター環境の階層関係を示しています。
本番環境
実稼動環境は、Adobe Commerceをパブリッシュ対応の単一およびマルチサイトストアフロントを実行するクラウドインフラストラクチャにデプロイするためのソースコードを提供します。 実稼動環境では、master ブランチのコードを使用して、web サーバー、データベース、設定済みサービス、およびアプリケーションコードを設定および有効にします。
production環境は読み取り専用なので、integration環境を使用してコードを変更し、integrationからstagingまでのアーキテクチャ全体にデプロイし、最後にproduction環境にデプロイします。 ストアのデプロイ および サイトの立ち上げを参照してください。
Adobeでは、production環境にデプロイされるmaster ブランチにプッシュする前に、staging ブランチで完全にテストすることをお勧めします。
ステージング環境
Adobeでは、masterからstagingという名前のブランチを作成することをお勧めします。 staging ブランチは、コードをステージング環境にデプロイして、コード、モジュールと拡張機能、支払いゲートウェイ、配送、製品データなどをテストするための実稼働前の環境を提供します。 この環境では、Fastly、New Relic APM、検索など、実稼動環境に一致するすべてのサービスの設定が提供されます。
このガイドの追加セクションでは、最終的なコードのデプロイと、セキュアなステージング環境での実稼動レベルのインタラクションのテストについて説明します。 最高のパフォーマンスと機能テストを実行するには、データベースをステージング環境にレプリケートします。
統合環境
開発者は、integration環境を使用して、開発、デプロイ、およびテストを行います。
-
Adobe Commerce アプリケーションコード
-
カスタムコード
-
拡張機能
-
サービス
推奨されるユースケース：
統合環境は、限定的なテストと開発のために設計されています。 例えば、統合環境を使用して次のタスクを実行できます。
-
継続的インテグレーション（CI）プロセスへの変更がクラウド互換であることを確認します
-
ホーム、カテゴリー、商品詳細ページ（PDP）、チェックアウト、管理者など、主要なページで重要なワークフローをテストします
統合環境で最高のパフォーマンスを発揮するには、次のベストプラクティスに従います。
-
カタログサイズの制限 – 参考までに、サンプルデータには約2,048の製品が含まれています。カタログサイズを4,000～5,000個程度に減らしてみてください。
カタログ内の製品数を確認するには、次のMySQL クエリを実行します。code language-sql select distinct count(entity_id) from catalog_product_entity; -
顧客グループの数を減らします。顧客グループが多すぎると、インデックス作成のパフォーマンスと全体的なパフォーマンスに影響を与える可能性があります。
-
同時ユーザー数を1人または2人に制限
-
cron ジョブを無効にし、必要に応じて手動で実行します
アクティブな統合環境は、最大 2 個まで設定できます。 統合環境を作成するには、staging ブランチからブランチを作成します。 統合環境を作成する場合、環境名はブランチ名と一致します。 統合環境は、ウェブサーバとデータベースとを含む。 Fastly CDNやNew Relicなど、すべてのサービスが含まれているわけではありません。
コードを保存するための非アクティブなブランチの数は無制限にできます。 非アクティブなブランチにアクセスし、表示し、テストするには、ブランチをアクティブ化する必要があります
制作およびステージングのテクノロジースタック
実稼動環境とステージング環境には、次のテクノロジーが含まれます。 これらのテクノロジーは、.magento.app.yaml ファイルを使用して変更および設定できます。
- HTTP キャッシュとCDN向けFastly
- 複数のワーカーを持つ1つのインスタンスであるPHP-FPMに話しかけるNginx web サーバー
- Redis サーバー
- Adobe Commerce 2.2から2.4.3-p2までのカタログ検索のためのElasticsearch
- OpenSearch Adobe Commerce 2.3.7-p3、2.4.3-p2、および2.4.4以降のカタログ検索
- 出力フィルタリング（アウトバウンドファイアウォール）
サービス
Adobe Commerce on cloud infrastructureは、現在、PHP、MySQL （MariaDB）、Elasticsearch（Adobe Commerce 2.2 ～ 2.4.3-p2）、OpenSearch （2.3.7-p3、2.4.3-p2、2.4.4以降）、Redis、およびRabbitMQのサービスをサポートしています。
各サービスは、個別の安全なコンテナで実行されます。 コンテナは、プロジェクト内で一緒に管理されます。 次のような一部のサービスが標準です。
-
HTTP ルーター（受信リクエストの処理だけでなく、キャッシュとリダイレクトも処理）
-
PHP アプリケーションサーバー
-
Git
-
セキュアシェル（SSH）
ソフトウェア版
Adobe Commerce on cloud infrastructureは、Debian GNU/Linux オペレーティングシステムとNGINX web サーバーを使用します。 このソフトウェアはアップグレードできませんが、次のバージョンを設定できます。
ステージング環境と本番環境では、CDNとキャッシュにFastlyを使用します。 最新バージョンのFastly CDN拡張機能は、プロジェクトの最初のプロビジョニング中にインストールされます。 拡張機能をアップグレードして、最新のバグ修正と機能強化を取得できます。 Magento 2🔗のFastly CDN モジュールを参照してください。 また、パフォーマンス モニタリング用にNew Relicにアクセスできます。
以下のファイルを使用して、実装で使用するソフトウェアのバージョンを設定します。
バックアップと災害復旧
データベースとファイルシステムのバックアップは、Cloud ConsoleまたはCLIを使用して作成できます。 バックアップ管理を参照してください。
開発のための準備
次のワークフローでは、コードのブランチ、ストアの開発およびデプロイのプロセスを要約します。
-
ローカル環境の設定
-
masterブランチをローカル環境に複製します -
masterからstagingブランチを作成 -
stagingからの開発用ブランチの作成 -
ビルドしてテスト用の環境にデプロイするコードをGitにプッシュします
ストアの開発、テスト、デプロイについて詳しい手順と手順については、次の節を参照してください。
-
Docker development （Cloud Docker for Commerceでローカル開発環境を有効にする）