プライベートサブネットにあるサーバ上の開発環境Webページにアクセスする方法

こんにちは。 エキサイト株式会社の三浦です。

AWSで開発を行う場合、多くのアプリケーション用サーバはプライベートサブネットに設置することになるでしょう。 つまり、もしWebアプリケーションの開発環境がサーバ上に存在する場合、本来インターネットからアクセスできないプライベートサブネットにあるサーバに、何かしらの方法でアクセスする必要があるということです。

今回は、そのための方法を紹介します。

プライベートサブネット

プライベートサブネットは、以前以下の記事でも紹介しましたが、インターネットから直接アクセスできない場所となっています。

tech.excite.co.jp

そのため、もしプライベートサブネットにあるサーバの開発環境のWebページにブラウザ等からURLでアクセスしたい場合、何かしらの手段を講じる必要があります。

プライベートサブネット上のサーバの開発環境にアクセスする方法

今回はプライベートサブネット上の開発環境にアクセスする方法として、

  1. ALBを使う方法
  2. 踏み台サーバと /etc/hosts を兼用する方法
  3. 踏み台サーバと nip.io を兼用する方法

の3つを紹介します。

ALBを使う方法

AWS上でWebアプリケーションを作っているなら多くの方が本番環境ではALBを使っていると思いますが、これを開発環境でも使うようにすれば、インターネット経由で開発環境にアクセスできるようになります。

この場合は、ALB自体がパブリックサブネットに作られているのでALBにはインターネットからアクセスでき、そのALBがプライベートサブネット上のサーバと通信するため、結果的にインターネットからWebページが見られる、という構図です。

ただしこの場合、URLをどうするかという問題があります。

開発環境のURLでは taro.sample.co.jp のように、開発者のユーザ名をURLに含めることで、開発者ごとに異なるディレクトリを見るようにする場合があると思います。 これを実現するため、ローカルPCの /etc/hosts を使う場合が多いのではないでしょうか。

/etc/hosts では、IPアドレスとURLを指定することで、そのPCで使用する場合に限り、指定したIPアドレスとURLを紐付ける事ができます。

例えば、

10.0.0.0 taro.sample.co.jp

とすれば、 taro.sample.co.jp にアクセスした時に、自動的に 10.0.0.0 というIPアドレスにアクセスしてくれる、といった具合です。

ただしALBを使っている場合はこれには問題があります。

ALBのIPアドレスは不定期に変わる可能性があるため、上記の方法で指定していると、ALBのIPアドレスが変更されるたびに /etc/hosts を変える必要があるのです。

そのため、もしALB経由で開発環境にアクセスしたいのであれば、 /etc/hosts を使うのではなく、開発環境のURLを Route53 パブリックホストゾーンに登録するのがいいかと思われます。

Route53 のパブリックホストゾーンに登録する場合、ALBであればALBそのものをURLのアクセス先として紐付けることができるため、ALBのIPアドレスが変わっても気にする必要がありません。

ただしこの方法を取る場合、パブリックなURLとして開発環境のURLが登録されるということになります。

まとめると以下のようになります。

ALBを使う方法とは

パブリックサブネットにあるALBからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはそのALBに対してアクセスするようにする。

ALBにアクセスするために、Route53のパブリックホストゾーンに開発環境のURLを登録し、ALBと紐付けておく。

利点

本番環境がALBを使用しているなら、それと同じ設定で開発環境にアクセスできる

欠点

  • 開発環境のURLをパブリックなURLとして登録する必要があり、セキュリティ的な心配が残る
  • 開発環境用のパブリックホストゾーン管理が必要になる
  • 場合によっては、開発環境用のURLのためにALBのリスナールールが複雑化する可能性がある

踏み台サーバと /etc/hosts を兼用する方法

2つ目は、踏み台サーバと /etc/hosts を兼用する方法です。

これは簡単に言えば、1つ目のALBを使う方法について、ALBの代わりに踏み台サーバを使うという方法です。

踏み台サーバとは、文字通り「踏み台」に使うサーバです。 このサーバはパブリックサブネットに作っておき、例えばプライベートサブネットに存在するサーバにSSHログインしたい時や、プライベートサブネットに作ったDBに接続したいときなどに使用します。

今回はその踏み台サーバに、例えばNginxを入れて指定のURLが来たら指定のサーバにアクセスを流すようにします。 具体的には、 taro.sample.co.jp というURLが来たら、 10.0.0.0 のIPアドレスのサーバに流す、といった具合です。

server {
    listen 80;

    server_name taro.sample.co.jp;

    location / {
        proxy_pass http://10.0.0.0;
    }
}

そして、 taro.sample.co.jp で踏み台サーバにアクセスが行くように、踏み台サーバのIPアドレスを /etc/hosts を使ってURLと紐付けます。 踏み台サーバのIPアドレスが 99.0.0.0 であれば、

99.0.0.0 taro.sample.co.jp

といった形です。 これで、 taro.sample.co.jp にアクセスすれば、踏み台サーバを経由してプライベートサブネットに存在するサーバにアクセスすることができるようになります。

まとめると、以下のようになります。

踏み台サーバと /etc/hosts を兼用する方法とは

パブリックサブネットにある踏み台サーバからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはその踏み台サーバに対してアクセスするようにする。

踏み台サーバからプライベートサブネットにあるサーバを見られるようにするために、Nginx等でアクセスを流すようにする、

また、踏み台サーバにアクセスするために、/etc/hosts で指定のURLと踏み台サーバのIPアドレスを紐付けておく。

利点

踏み台サーバがあれば、それだけで開発環境にアクセスできる

欠点

  • 踏み台サーバにNginx等の設定が必要になる
  • /etc/hosts の管理が必要になる

踏み台サーバと nip.io を兼用する方法

3つ目は、踏み台サーバと nip.io を兼用する方法です。

nip.io とは、URLだけで向き先IPアドレスを指定してアクセスしてくれるサービスになります。

nip.io

Dead simple wildcard DNS for any IP Address

公式にも書いてあるとおり、例えば 10.0.0.1.nip.io というURLでアクセスした場合、IPアドレス 10.0.0.1 に対してアクセスできるようになります。

これを使用すると、色々と便利になります。

例えば今回の場合、踏み台サーバを使うところまでは同じですが、URLと踏み台サーバのIPアドレスを紐付ける時に、 /etc/hosts を使用しなくても良くなります。

踏み台サーバのIPアドレスが 99.0.0.0 であれば、例えば taro.sample.99.0.0.0.nip.io というURLにアクセスすれば、それだけで 99.0.0.0 のIPアドレス、つまり踏み台サーバへアクセスしてくれるのです。

それに応じてNginxの設定を少し変える必要はありますが、管理するものが増えて煩雑になりやすい /etc/hosts を使わなくてよいのはそれなりの利点となるのではないでしょうか。

server {
    listen 80;

    server_name taro.sample.99.0.0.0.nip.io;

    location / {
        # ホスト名を指定する必要がある場合は、ここで指定
        proxy_set_header Host taro.sample.co.jp;

        proxy_pass http://10.0.0.0;
    }
}

まとめると、以下のようになります。

踏み台サーバと nip.io を兼用する方法とは

パブリックサブネットにある踏み台サーバからプライベートサブネットにあるサーバを見るようにし、ブラウザ等からはその踏み台サーバに対してアクセスするようにする。

踏み台サーバからプライベートサブネットにあるサーバを見られるようにするために、Nginx等でアクセスを流すようにする、

また、踏み台サーバにアクセスするために、nip.io で指定のURLから踏み台サーバのIPアドレスにアクセスするようにする。

利点

  • 踏み台サーバがあれば、それだけで開発環境にアクセスできる
  • /etc/hosts を使う必要がない

欠点

  • 踏み台サーバにNginx等の設定が必要になる
  • URLの命名が、 nip.io の形式に縛られる

最後に

最近は開発環境がコンテナ化されている例も多く、その場合は今回のような設定はあまり必要ないかもしれませんが、例えば何かしらの理由でコンテナ化ができなかったり、全体的に古くからある環境でまだまだサーバ上で開発環境が動いている場合は、もしかしたら上記のような設定も必要になってくるかもしれません。

3つのどれが一番いいというわけではなく、それぞれの利点・欠点をもとに今の状況でもっとも良いものを選ぶのが適切かと思います。 参考にしていただけると幸いです。