サービス間参照
参照を使うと、あるサービスが、認証情報をコピー&ペーストせずに別のサービスやアドオンの値を読み取れます。各値を1か所にまとめて保持でき、コンシューマーは次回のデプロイ時に変更を取得します。
構文
${{<name>.<KEY>}}<name>— 対象のサービスまたはアドオン名(ダッシュボードに表示され、lizard add -nで使われるもの)。<KEY>— 対象が公開するキー。アドオンは接続用の値を公開します。サービスは、プロジェクトとサービスの変数とシークレット、さらにLIZARD_*とPORTの値を公開します。Lizard がアドオンから注入するDATABASE_URLやREDIS_URLは公開しません。それらはアドオンを参照してください。
値を受け付ける場所ならどこでも使えます。最も一般的なのはシークレットです:
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api解決の仕組み
- 参照は、対象が公開する値に対してデプロイ時に解決されます。
- シークレットに設定した参照(
lizard secrets setまたはダッシュボード)は、対象の現在の名前と照合されます。対象の名前を変更すると参照は壊れるため、名前の変更後はすべての${{oldname.KEY}}を更新してください。lizard add -vで初期設定した参照は、名前を変更しても対象を追従します。 - 存在しない対象またはキーへの参照は、空文字列に解決されます。デプロイは失敗しません。ビルドログには、空になった参照ごとに理由付きの警告が表示されます。
- エラーになるのは循環参照だけです。
参照を設定したあとは、ビルドログで空の参照がないか確認してください:
lizard logs --build --service api
参照が期待どおりに反映されない場合は、トラブルシューティング → シークレットまたは参照が表示されない を参照してください。
よくあるパターン
1つのアドオンを複数のサービスに接続する — 各コンシューマー側でバインドします。プロジェクト内ではプライベート URL を使ってください:
lizard secrets set REDIS_URL='${{redis.REDIS_PRIVATE_URL}}' --service api
lizard secrets set REDIS_URL='${{redis.REDIS_PRIVATE_URL}}' --service worker別のサービスの値を参照する — たとえば、計算された URL やトークンを共有する場合。LIZARD_PUBLIC_DOMAIN はスキームを含まないホスト名で、サービスにドメインができると利用できます。LIZARD_PRIVATE_DOMAIN(<name>.lizard.internal)を使うと、プロジェクト内からサービスに接続できます:
lizard secrets set UPSTREAM_URL='https://${{api.LIZARD_PUBLIC_DOMAIN}}' --service web
lizard secrets set INTERNAL_API='http://${{api.LIZARD_PRIVATE_DOMAIN}}:8080' --service web同じ種類の2つ目のアドオンを参照する — その自動生成された名前を使います:
lizard secrets set CACHE_URL='${{redis-winter-otter.REDIS_URL}}' --service apiなぜ --global を使わないのですか?
共有の値をプロジェクト(--global)スコープに置くと、必要のないものも含めてすべてのサービスに公開されます。参照なら値を1か所にまとめて保持し、設定した場所にだけバインドできます。なお、各サービスには、プロジェクトの Postgres アドオンと Redis アドオンから DATABASE_URL と REDIS_URL がすでに 1 つずつ、最も低い優先順位で渡されています。同じ種類のアドオンが複数ある場合、どれが渡されるかは決まっていません。参照はこれらを上書きします。シークレットのスコープ を参照してください。
関連項目
- 変数とシークレット — スコープと優先順位。
lizard secrets— 完全なコマンドリファレンス。
更新日