インフラ配属の新卒エンジニアが入社後3ヶ月でやってきたこと 【IaC編】の後編です！
前編はこちら↓
新規技術の検証・導入
1. Capistrano から AWS CodeDeploy へ
ウィルゲートではこれまで、アプリケーションのデプロイには Capistrano を利用していました。 しかし、せっかくなら AWSのSaaS を利用してデプロイ作業を自動化させようということで、 AWS CodeDeploy を利用することにしました。
アプリケーションのソースコードを対象のブランチにマージした際、 CI ツールが動き AWS S3 へ ZIP ファイルとして配置します。 また、 S3 へ配置したと同時に CodeDeploy を実行させることで、 CodeDeploy は S3 から最新のソースコードを取得しデプロイを実行します。
これまで利用していた Capistrano は In Place デプロイを行うため、多少のダウンタイムや新旧が混在する時間が生まれてしまいます。 しかし、 CodeDeploy を利用することで Blue/Green デプロイが可能となり、ダウンタイムゼロのデプロイ環境を構築することができました。
2.（ Packer + Terraform ）+ Ansible
CodeDeployを利用して Blue/Green デプロイを行う際、上図のように既存のオートスケーリンググループ とは別のオートスケーリンググループ を作成します。
しかし、AWS が提供しているオートスケーリングは、スケールアウトした際にあらかじめ起動設定として指定した AMI を元にインスタンスを生成するため、 nginx や users などの設定がされていないまっさらなインスタンスが出来上がります。
そのため、スケールアウトし web アプリケーションが乗っかっていても web サーバが入っていないという事態に陥ってしまうことがあります。
そこで、 「Packer」 を活用して上記の問題を解決することにしました。
■Packer とは
上記に書いた通り、 Packer は AMI を作成する際に Ansible を流すことができるため、一通りの設定がすでに完了したイメージを作成することができます。
Packer で作成した AMI を起動設定としたオートスケーリンググループ を Terraform から作成することにより、スケールアウトしても一通りの設定が済んだ状態でインスタンスが作成されるようになりました。
3. AWS Lambda の導入・連携
前述した CodeDeploy を利用するにあたり、デプロイの進行状況が AWS の管理画面を確認しないと分からないという問題がありました。
そこで、 AWS Lambda を活用し、デプロイのステータスが変わるごとに Slack へ通知するようにしました。
■AWS Lambda とは
サーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービス。 AWS SNS や SQS 、 S3 のイベントをトリガーとして Python などのスクリプトを実行することができる。
結果、 CodeDeploy の進行状況が都度 Slack に対して通知がくるので、一目でデプロイ状況が確認できるようになりました。
標準開発環境のホスティング先移行
最後に余談ですが、ウィルゲートの開発室では標準開発環境と呼ばれる1人1つの自由に使うことができる開発環境を提供しています。
これまでは、契約している専用サーバで開発環境を提供しており、Windows の vSphere クライアントから仮想環境の構築やコピーを行っていました。 しかし、専用サーバのリソースの問題や環境のコピーに時間がかかるなどの問題から、標準開発環境を専用サーバから全て AWS EC2 へ移行を行いました。
個々人のインスタンスは全て Terraform で構成・管理されており、誰かのインスタンスをコピーして欲しいという要望に対しても、迅速に対応することが可能となっております。
おわりに
まだ入社して間もない私ですが、様々なことにチャレンジさせて頂ける環境があることに対し、とてもやり甲斐を感じています。
これからも新しい技術に触れていき、より組織に貢献できるよう頑張っていきます！
