はじめに
こんにちは。鈴木商店の姜（カン）です。
初めてブログを書いてみますが今後も学んだことなどを書いていければと思います。
今回はAWS Systems Managerを導入して自チームで保守、運用を担当している会員制医療従事者向けポータルサイトのデプロイ作業を簡素化し自動デプロイ環境を構築したので、その内容を共有しようと思います。
※サイトの特性や制約上今回のような構成にしていて、一般的なベストプラクティスではないと思いますのでご容赦ください。
なぜやったか？
それまでのデプロイ作業はエンジニアがサーバにSSHログインして手順に沿ってコマンドを実行する形で行っていました。
特に複雑なことをしていたわけではないですが、以下の問題点があると感じていたので自動化を試してみました。
問題点１． デプロイできる人が限られる
デプロイにはSSHログインが必要でそのための鍵ファイルの管理などの都合上、デプロイを行えるメンバーが限られていました。
問題点２． デプロイ作業が面倒くさい
以下のような手順でデプロイを行っていましたが基本的には毎回同じコマンドを実行しており面倒でした。
また手作業でコマンド実行していたため、作業に抜け漏れがあったり（汗）、ミスすることも少ないながらもありました。
問題点３． 気軽にデプロイしづらい（依頼もしにくい）
上記の理由から簡単な改修などがあっても気軽にデプロイを頼みにくいという状況でした。
やったこと
まずはデプロイ作業手順のテンプレート化(RunCommand Documentの作成）
AWS Systems Manager（SSM）の導入
まずSSHログインせずにデプロイ出来るように AWS Systems Manager（SSM） を導入しました。
詳細な導入手順等はググればたくさん良記事が見つかるのでそちらを見ていただくとして、導入のためにやったことを簡単に説明するとこんな感じです。
公式サイト：EC2 インスタンス用 AWS Systems Manager のセットアップ
IAMロールの設定
対象のEC2に設定しているIAMロールに AmazonSSMManagedInstanceCore ポリシーを追加しました。
以上。
フリートマネージャーに対象のインスタンスが表示されればSystems Managerの導入が完了です！
思ったより簡単に導入できました！
RunCommandを利用してSSHなしでデプロイ作業
SSMを導入出来たので、次にRunCommandを利用してデプロイ作業をワンアクションで行えるようにしました。
RunCommandとは名前の通りコマンドを実行する機能です。
SSHログインなどはせずに、対象サーバにインストールされたSSMエージェントを通して外部（AWSコンソールやCLI）からコマンドを実行することが出来ます。
使いようによってはめっちゃ便利な機能だと思います。
RunCommandではコマンドをパッケージ化したDocumentを作成しておくことで、定型的なコマンドをAWS CLIを利用して実行することが出来ます。
しかも対象とするサーバをタグで指定して選択できるため、複数のサーバに同時に適用することも簡単にできます。
今回は以下のコマンドをまとめたDocumentを作成しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# gitでソースを反映 cd [ソースのデプロイ先のパス] git fetch origin git checkout [指定したブランチ] git pull # キャッシュの削除 rm -fr [キャッシュの保存先] # タグ付け git tag [指定したタグ名] git push origin [指定したタグ名] |
次に一発で外部からデプロイする仕組みの作成（社内Slackからのデプロイ）
RunCommand実行のためのLambda関数作成
デプロイのためのDocumentが完成したので、次にそれを外部から実行するためのLambdaを実装しました。
といっても必要なパラメータを受け取ってRunCommandを実行するだけの３０行足らずの単純な関数です。
Slackと連携してLambda呼び出し
Lambdaが完成したのでそれを呼び出すだけでデプロイ作業が行えるようになりましたが、毎回LambdaのURLを叩いて実行するのも少し味気ない感じがします。
社内のメンバーが簡単に誰でもデプロイ出来るようにするために、Slackと連携してチャットからデプロイ作業が行えるようにしました。
AWS Chatbotを利用して社内Slackと連携
まずはAWS Chatbotを利用してAWSアカウントと社内Slackとを連携します。
デプロイを行うためのチャンネルをSlackに作成し、Chatbotでチャネルを作成しました。
これで対象のチャンネルにawsアプリがインストールされ、SlackからCLIの呼び出しが出来るようになりました。
Slackワークフローを作成しSlackからデプロイ可能に
社内Slackと連携したことでCLIを呼び出すことが出来るようになりましたが、毎回CLIのコマンドをSlack上で入力するのは面倒です。
Slackワークフローを利用して、「デプロイ対象サーバ」、「デプロイしたいブランチ」、「タグ名（任意）」を入力してデプロイ出来るようにしました。
これで社内のメンバーが簡単に誰でもデプロイを行えるようになりました！！
（発展編）特定の環境（テスト環境）へのデプロイ自動化
これまでの対応によって簡単に誰でもワンアクションでデプロイできるようになりましたが、テスト環境などへ毎回Slackでデプロイするのも正直面倒です。
GitリポジトリへのPushをトリガーに出来れば、同じ仕組みを利用して自動デプロイが実現出来そうです。
幸い本プロジェクトで利用しているGitLabにはその仕組みが用意されていました。
CI/CDを実現するためにGitLab Runnerという機能を利用すればイケそうだということがわかりましたので、以下のサイトを参考にして早速試してみました。
GitLab Runnerサーバの構築
GitLab Runner用のEC2サーバを作成してGitLab Runnerをインストールします。
GitLab Runnerのinstallは、公式ドキュメントに沿って進めます。
リポジトリに.gitlab-ci.ymlを追加
今回はLambdaを実行するだけなので、GitLabが用意しているAWS CLIを実行できるコンテナを利用して特定のブランチへのPush時に動作するように設定しました。
|
1 2 3 4 5 6 7 8 9 10 11 |
stages: - deploy deploy-contents-job: stage: deploy image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest only: - [反映したいブランチ名] script: - aws ssm send-command --document-name "xxx-deploy" --document-version "\$DEFAULT" --targets '[{"Key":"tag:Name","Values":["対象EC2のタグ名"]}]' --parameters '{"TargetBranch":["[反映したいブランチ名]"]}' --timeout-seconds 3600 --max-concurrency "50" --max-errors "0" --region ap-northeast-1 |
これでgit pushするだけでテスト環境への自動反映が行われるようになり、チーム全体の開発効率が上がったように思います。
また、自動デプロイの仕組みを導入した後に発生した少し大きめの改修（ページデザインのリニューアル）の際には、それ用のテスト環境を構築し自動デプロイの仕組みを流用したことで、実装→テスト→フィードバックのサイクルを効率的に回すことができ、プロジェクトの円滑化に貢献出来たのではと思っています。
あとがき
自動デプロイやSlackからのデプロイが出来るようになり、運用の負荷がだいぶ改善できたのですがまだまだ足りない点が多く残っています。
当該サイトは10年以上の実績あるサイトで、現在技術刷新のためのプロジェクトが動き始めています。
その中でフレームワークや言語などを刷新していく予定ですが、個人的にはTerraformを利用したInfrastructure as Codeにチャレンジしたいなぁと思っています。
またその経過などもブログに書いていけるようにします。
