これまで、CodeDeployによるEC2への自動デプロイは、パブリックIP(グローバルIP)経由でしかできませんでしたが、2020年8月よりプライベートサブネットに配置したEC2へのデプロイも可能となりました。この制約が存在していたため、NATでグローバルIPへの変換をしてEC2からCodeDeployへの導線を確保したり、自前でデプロイサーバーを立てたりしていて、セキュリティ確保やCodePipelineを導入して一括でデプロイするなどのAWSの恩恵をすべての面で得ることができていませんでした。今回、ロードバランサーの後ろの複数のプライベートサブネットに配置したWEBアプリケーションのデプロイを、CodePipelineを使って自動化するためにこの対応を行ったところ、下記3点のはまりポイントがありましたのでポイントのみ記載しています。
1.ネットワーク的な疎通
当たり前な話ですが、まずは、VPC内からCodeDeployに対してプライベートIPでの接続ができる必要があります。これには、エンドポイントを配置して対応します。エンドポイントは、「codedeploy」及び「codedeploy-endpoint-command-secure」の2パターンを作成しておく必要があります。これにより、プライベートIPアドレスでの接続が可能となります。
2.プライベートネットワークにおける名前解決
次に、デプロイ先であるEC2にインストールしたcodedeploy-agentから「 codedeploy.ap-northeast-1.amazonaws.com」や「codedeploy-commands-secure.ap-northeast-1.amazonaws.com」に対して接続を試みます。この際、名前解決されて返されるIPアドレスがプライベートIPアドレスである必要があります。通常は、パブリックIPアドレスが返されるので、先ほどのエンドポイントを作成する際にプライベートのDNSサーバーを参照するよう設定しておきます。
3.エンドポイントのセキュリティ設定
最後のはまりポイントはエンドポイントのセキュリティグループの設定です。エンドポイントは作成したVPCの中のcodedeploy-agent側からhttp/httpsのリクエストで経由して使われますので、対象となるサブネットからの接続を許可する必要があります。これは、エンドポイントからはインバウンドとなりますので、インバウンド側のルールとして設定します。
以上、CodeDeployによるEC2への自動デプロイのはまりポイントを要点のみまとめてみました。正直、これだけでは、どんな操作したんだ？？とか、そもそもどういう構成なの？？という疑問点などあるかと思います。構成などの図式はまたいつか。。。
