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

テナントと環境の対応

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

リソース設定リポジトリ

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

単方向フロー

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

環境固有の値

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

環境ごとに設定ファイルを分ける

環境ごとにツール用の設定ファイルを分けて指定すると、リソースの設定ファイルは環境に依存しないまま保ちつつ、各環境の要件にも対応できます。少なくとも、環境ごとに別々の認証情報を用意する必要がありますが、特定のリソースを除外したり、削除を有効にしたり、環境ごとに動的なキーワード置換を行ったりすることもできます。

ファイル構成の例

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

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

config-dev.json の設定例

config-prod.json の設定例