Skip to main content
Deploy CLI は、マルチテナント・マルチ環境での運用をサポートしています。これを CI/CD の開発ワークフローに組み込むことで、機能開発から本番環境に至るまで、Auth0 の変更を反映できます。 一般的な推奨ワークフローは次のとおりです。
  1. 環境 (開発、ステージング、本番) ごとに個別の Auth0 テナントを作成します。
  2. すべての環境のリソース設定ファイルを 1 つのリポジトリで管理します。
  3. 環境へのデプロイ時に、適切な Auth0 テナントへ Auth0 リソース構成を適用するステップを CI/CD パイプラインに追加します。

テナントと環境の対応

環境ごとに個別の Auth0 テナント/アカウントを用意することを推奨します。たとえば、次のようになります。

リソース設定リポジトリ

エクスポートすると、Auth0 テナントの状態は、YAML またはディレクトリ形式のいずれかのリソース設定ファイル一式として表されます。マルチ環境では、すべての環境に適用する単一のリソース設定リポジトリを用意することが想定されます。実際には、これはプロジェクトのコードベース内のディレクトリとして存在することもあれば、完全に別のコードベースに存在することもあります。 リポジトリには、テナントごとに少なくとも 1 つのブランチを用意する必要があります。これにより、変更内容をすぐにデプロイせずに作業できます。この方法では、作業ブランチをプライマリブランチ (mainmaster など) にマージしたときにのみ、変更がデプロイされます。この構成により、各環境に対応する継続的インテグレーションのタスクを用意でき、プライマリブランチが更新されるたびに、対象の環境へ変更を自動的にデプロイできます。 ワークフローの例としては、次のようになります。
  1. 開発環境に変更を加えます。
  2. 変更をテスト環境 (または uat) にマージします。
  3. uat で変更をテストします。準備ができたら、その変更を staging に移してマージします。
  4. staging をテストします。準備ができたら、その変更を production に移してマージします。
予防策として、production 環境では手動でトリガーした場合にのみデプロイするように設定しておくとよいでしょう。

単方向フロー

マルチ環境のワークフローは、変更を単一方向に「上位」へ伝播させる場合に最も効果的です。リソース設定ファイルへの変更は、まず最下位の環境 (開発環境など) に適用し、その後、すべての環境を経由して段階的に上位へ適用し、最終的に本番環境へ反映する必要があります。この単方向の運用により、テナントへの変更について十分なテストと承認を確保できます。いったんこの運用を確立したら、その変更が後続の Deploy CLI エクスポートで取り込まれない限り、 などの別の手段で構成を本番環境に直接適用しないことを推奨します。そうしないと、それらの変更は上書きされる可能性があります。

環境固有の値

すべての環境で同じ一連のリソース設定ファイルを共有することを前提としていますが、環境固有の値は、個別のツール設定ファイルと動的なキーワード置換を使用して指定できます。

個別の設定ファイル

環境ごとに個別のツール設定ファイルを指定することで、各環境の要件に対応しながら、リソース設定ファイルを環境に依存しない形で維持できます。最低限、環境ごとに個別の認証情報を指定する必要がありますが、そのほかにも、特定のリソースの除外、削除の有効化、動的なキーワード置換を環境ごとに行うことができます。

ファイル構成の例

キーワード置換による動的な値

環境ごとに個別の設定ファイルを採用したら、AUTH0_KEYWORD_REPLACE_MAPPINGS 設定プロパティを介したキーワード置換を使用して、環境に応じた動的な置換値を表現できます。たとえば、クライアントごとに許可するオリジンのセットを別々に用意する必要がある場合があります。詳細については、キーワード置換 を参照してください。

config-dev.json の例

config-prod.json の例