パブリッククラウドへのデプロイの自動化

 最近は、Webアプリケーションの本番環境やテスト環境として、パブリッククラウド(ここでは、EC2やAzureなどのIaaSを指すことにします)を使用する事例をよく聞きます。パブリッククラウドを使用するときの課題として、アプリケーションのデプロイの自動化があります。

デプロイの自動化の課題

 オンプレミスの場合は、WebサーバとCIサーバ(CIツールを動かすマシンを便宜上CIサーバと呼ぶことにします)を閉じたネットワーク上に配置することで、デプロイ用のインタフェースを外部からブロックすることができます。ですので、CIツールでのデプロイの自動化が安心して行えます。

 しかし、パブリッククラウドに上記のWebサーバ・APサーバを持っていくと、デプロイ用のインタフェースがインターネットに公開されることになり、外部からアクセスされる危険がでてきます。かといって、デプロイ用のインタフェースを外部(インターネット)からブロックすると、CIサーバからもアクセスできなくなります。


課題の解決

 この問題を解決する手段はいろいろあると思いますが、手段の1つとしてSSHトンネルを使う方法があります。外部からのアクセスをブロックしつつ、SSHトンネルを使うことで、SSHでログインできるマシンにだけデプロイ用のインタフェースを公開する形にすることができます。


SSHトンネルの設定例

APサーバとCIサーバをSSHトンネルで繋ぐため、CIサーバ上で以下のコマンドを実行します。

ssh -f userfoo@apserver.example.com -L 9999:localhost:8080 -N

「-f」は、バックグランドで動作させるためのオプションです。「userfoo@apserver.example.com」は、「apserver.example.com(APサーバ)」に「userfoo」ユーザでSSHでログインするという意味です。「-L 9999:localhost:8080」は、ローカル(CIサーバ)のポート9999にアクセスすると、SSHトンネルでapserver.example.comに転送され、そこからlocalhost(APサーバ)のポート8080(デプロイ用のインタフェースのポートを想定)にアクセスするという意味になります。「-N」は、リモートでコマンドを実行しないというオプションです(トンネルするだけなのでこのオプションを付けます)。

さいごに

 この方法がベストかどうかは分かりませんが、1つの手段として参考になれば幸いです。

補足:Tomcatのデプロイ用のインタフェースの注意点

 Webサーバ経由でTomcatにアクセスする場合、デプロイ用のインタフェースをうっかり外部に公開しないように注意が必要です。Tomcatのデプロイ用のインタフェースは、Webアプリケーションとして提供されており、Webサーバ経由でアクセスすることができます。ですので、Webサーバの設定で、デプロイ用のインタフェースのWebアプリケーションのパス(/manager)は、Tomcatに転送しないようにする必要があります。