Internal Routing

最終更新日 2022年09月19日(月)

作成時に、Private Space​ 内のアプリで Internal Routing​ を有効にすることができます。他のアプリと異なり、Internal Routing を有効にしたアプリは、アプリの web​ プロセスタイプ宛ての外部 Web トラフィックを受信できません。代わりに、アプリの web​ プロセスタイプは以下からトラフィックを受信できます。

  • Private Space ネットワーク内で実行されている他のアプリ
  • VPC ピアリング​または VPN 接続​されたネットワーク内で実行されているソフトウェア

それ以外のすべての面では、Internal Routing を有効にしたアプリの動作は、他の Private Space アプリの動作とまったく同じです。

Internal Routing は以下に対して役立ちます。

  • 他の Private Space アプリと、ピアリングされた AWS VPC で実行中のソフトウェアでしか使用されない API およびその他のセキュアなマイクロサービスコンポーネント。
  • VPN 接続されたオンプレミスネットワーク上のユーザーしかアクセスできないアプリ。アプリにリクエストを送信できるのはプライベートネットワーク上のホストだけであり、リクエストと応答は IPSEC 接続のみを通過できます。

Internal Routing は、Space 内ネットワークや、アプリアクセスのロックダウンのための他の Heroku 機能を補完します。

  • Private Space DNS Service Discovery​ を使用すると、dyno とプロセスタイプ間の直接ネットワーク接続が可能になりますが、ルーティングスタックは提供されないため、リクエストのログ記録や SSL ターミネーションも提供されません。
  • 信頼済み IP 範囲​は、Space 内のすべてのアプリへの外部アクセスを一連の CIDR 範囲に制限しますが、アプリ単位の粒度は提供されないため、IP 範囲を最新に保つ必要があります。

内部でルーティングされるアプリの作成

Internal Routing はアプリ作成時にしか設定できません。既存のアプリで Internal Routing を有効にすることはできません。

新しいアプリを作成するときに --internal-routing​ オプションを含めます。

$ heroku apps:create --internal-routing --space test-space
Creating app... done, ⬢ frozen-oasis-70544
http://frozen-oasis-70544.herokuapp.com/ | https://git.heroku.com/frozen-oasis-70544.git

内部でルーティングされるアプリの操作

内部でルーティングされるアプリのデプロイは、他の Heroku アプリのデプロイ​との違いはありません。他のアプリと同様に、カスタムドメインを追加​すると、https://<appname>.herokuapp.com​ URL と追加の DNS ターゲットを取得します。

他のアプリと違って​、これらの URL とターゲットは内部的なプライベート IP アドレスに解決され、これは Private Space の RFC 1918 CIDR 範囲内のアドレスです。結果として、Internal Routing を有効にしたアプリでは、以下から開かれた接続のみを受け入れます。

  • Private Space ネットワーク内で実行されている他のアプリ
  • VPC ピアリング​または VPN 接続​されたネットワーク内で実行されているソフトウェア

デフォルトドメインでは、プライベート IP を正しく解決するために、少なくとも 1 つの Web dyno が実行されている必要があります。

Internal Routing は、アドオン、ログ記録、アプリケーション関連のメトリクス、カスタムドメイン、SSL ターミネーションなど、他のほとんどの Heroku 機能と互換性があります。

必要な検証を Heroku の証明書パートナーが実行できないため、Automated Certificate Management​ は Internal Routing と互換性がありません​。.herokuapp.com ドメインでデフォルトの SSL メカニズム​を使用するか、またはカスタムドメインで Heroku SSL​ を使用できます。

内部でルーティングされるアプリのトラブルシューティング

Internal Routing を有効にしたアプリのトラブルシューティングを最もすばやく実行するには、heroku logs​ でログを確認するか、heroku run bash​ セッションから curl​ コマンドを実行します (アプリ自体、または同じ Private Space 内の他のアプリを使用できます)。

$ heroku run bash -a frozen-oasis-70544
...
$ curl -I http://frozen-oasis-70544.herokuapp.com/
HTTP/1.1 200 OK

内部でルーティングされるアプリのトラブルシューティングとデバッグは、難しい場合があります。最初に、内部でルーティングされないアプリを使用して、コードの開発とテストを行うことを検討してください。標準的なアクセス制御 (たとえばユーザー名とパスワード、信頼済み IP 範囲)​ を使用し、一切の機密データが含まれないようにしてください。

ピアリングされた VPC からのアクセス

ピアリングされた VPC から内部でルーティングされるアプリにアクセスするには、Private Space の /16​ CIDR 全体に対するルートが VPC に必要です。内部でルーティングされるアプリに到達するために使われるエンドポイントが dyno の CIDR 範囲内にないことがその理由です。(以前は、Heroku のドキュメントでは、dyno を含む 2 つの Private Space /20​ サブネットに対するルートのみを追加することを推奨していました。)

まず、次の AWS CLI コマンドを使用して VPC のルーティングテーブル ID を取得します。

$ aws ec2 describe-route-tables

使用している VPC と同じ VPC ID を持つルートテーブルを探し、そのルートテーブル ID を取得します。AWS CLI コマンドの create-route​ で、この ID を指定します。

$ aws ec2 create-route --route-table-id rtb-your-route-table-id --destination-cidr-block 10.0.0.0/16  --vpc-peering-connection-id pcx-111aaa111

/20​ dyno CIDR に対する 2 つの既存ルートは、新しいルートによってカバーされるため、削除してもかまいません。