こんにちは、スタメンエンジニアの松谷です。 組織のエンゲージメントを高めるプロダクト TUNAG(ツナグ) を開発しています。 開発・運用に関わる中で日々思うのは、アプリケーションの管理をよりシンプルにし、セキュアで信頼性が高く、スケーラブルに運用することを容易にしたいということです。AWS Systems Manager には、これらのニーズを満たす多くの機能があることを知り実際に導入してみました。簡単に導入することができ、運用上大きな効果を得ることができたので共有させていただきます。
TL;DR (概要)
スタメンのSystems Managerを活用することで、SSHレスで安全なオペレーションを実現し、監査可能な操作ログを保存し、現状のサーバーの状態を簡単に把握できるようになりました。具体的な活用事例とともに紹介します。
目次
スタメンにおける活用事例
AWS Systems Managerが持つ機能のうち、スタメンで活用している機能とその運用について説明します。
セッションマネージャーでSSHアクセスの廃止
セッションマネージャーの機能の説明は以下の公式ドキュメントをご確認ください。
セッションマネージャー を使用して、インタラクティブなワンクリックブラウザベースのシェル、または AWS CLI を介して Amazon EC2 インスタンスを管理できます。セッションマネージャー は、インバウンドポートを開いたり、踏み台ホストを維持したり、SSH キーを管理したりすることなく、安全で監査可能なインスタンスの管理を提供します。セッションマネージャー は、Amazon EC2 インスタンスへの簡単なワンクリックのクロスプラットフォームアクセスをエンドユーザーに提供しつつ、インスタンスへの制御されたアクセス、厳格なセキュリティプラクティス、インスタンスアクセスの詳細を含む、完全に監査可能なログを必要とする企業ポリシーに準拠することを容易にします。 AWS Systems Manager Session Manager - AWS Systems Manager
簡単に説明すると、SSH接続せずに、AWSマネジメントコンソール(もしくはAWSCLI)上でEC2インスタンスに対してオペレーションができる機能です。 適切なロールがEC2にアタッチされていて、SSMエージェントがインストールされているインスタンスが以下のように、一覧で表示されます。
インスタンスを選択して、セッションを開始をクリックすると、セッションが開始され以下のようにシェルライクな画面がブラウザで表示されます。
任意の操作が完了した後、終了をクリックするとセッションが終了します。 そして、セッション履歴のタブをクリックすると、過去に起動したセッションの履歴を確認することができ、ここでは、いつ、だれが、どのインスタンスのセッションを起動したのか、そして、そのセッションでどのようなオペレーションを実行していたのかは、設定画面で「S3 バケットストレージの有効化」または、「CloudWatch Logs ストリームの有効化」をONにしていれば確認することができます。ローカルのターミナルでオペレーションをしていた頃は、問題が起きた時に過去のログを遡ることができない場合があり、困ったことがありましたがこれで安心です。 また、新しいセッションが始まった時点でSNS通知をすることも可能です。
セッションマネージャーの導入により、各開発者からのSSHアクセスが不要になり、踏み台サーバーを廃止することができました。セキュアになるだけでなく、踏み台サーバ代も節約できて良いこと尽くしです。
オートメーションで日常タスクを1クリックで自動化
オートメーションの機能の説明は以下の公式ドキュメントをご確認ください。
Systems Manager オートメーションを使用して、一般的なメンテナンスとデプロイのタスクを自動化します。オートメーションを使用すると、Amazon Machine Image の作成と更新、ドライバーとエージェントの更新プログラムの適用、Windows インスタンスでのパスワードのリセット、Linux インスタンスでの SSH キーのリセット、および OS パッチまたはアプリケーション更新プログラムの適用が可能になります。 オートメーションドキュメントは、Systems Manager がマネージドインスタンスおよび AWS リソースで実行するアクションを定義します。ドキュメントは JavaScript Object Notation (JSON) や YAML を使用し、これにはユーザーが指定するパラメータおよびステップが含まれます。ステップは順番に実行されます。 AWS Systems Manager オートメーション - AWS Systems Manager
Systems Managerで実行する各種操作はドキュメントとして定義されています。AWSが定義済みのドキュメントや、自分で作成するカスタムドキュメントがあります。 スタメンでのオートメーションの活用例の一つに、ステージング環境へのデプロイがあります。以下は、特定インスタンスに対して、デプロイスクリプトを実行する、カスタムドキュメントです。
---
description: "deploy staging"
schemaVersion: "0.3"
parameters:
BranchName:
type: "String"
description: "(Required) Deploy target Branch"
InstanceId:
type: "String"
description: "(Required) InstanceId to run command"
default : "instance id"
S3BucketName:
type: "String"
description: "(Required) S3BucketName"
default : "tunag-systems-manager"
S3KeyPrefix:
type: "String"
description: "(Required) S3KeyPrefix"
default : "staging/deploy"
mainSteps:
- name: "deployStaging"
action: "aws:runCommand"
inputs:
DocumentName: "AWS-RunShellScript"
InstanceIds: ["{{ InstanceId }}"]
OutputS3BucketName: "{{ S3BucketName }}"
OutputS3KeyPrefix: "{{ S3KeyPrefix }}"
Parameters:
commands:
- su operator -c "source ~/.zshrc; cd /home/app; ./bin/deploy_staging.sh {{ BranchName }}"
これは、ステップ数が1つのシンプルなドキュメントです。parametersで、パラメータ化したいキー・バリューを指定しています。aws:runCommandは、指定されたドキュメントを実行するアクションです。aws:runCommandでは、1つ以上の管理対象インスタンスでコマンドを実行するためのオプションが指定可能です。DocumentNameで、Systems Manager が実行するドキュメント(AWS-RunShellScript)を指定しています。
なお、commandsオプションで実行されるコマンドリストは、1つ1つssm-userというユーザーで実行されます。弊社のデプロイフローでは、特定Linuxユーザーに限定してデプロイをしていたので、suコマンドのcオプションを利用することで、ユーザーを切り替えた状態でコマンドの実行をしています。
また、オートメーションの実行リンクを、チームに共有すれば簡単に特定タスクの実行画面にアクセスすることができ便利です。下図を例にすると、デプロイしたいブランチ名を入力パラメータに入れて実行をクリックするだけでデプロイを開始することができます。
今までアプリケーションエンジニアは、デプロイを実行したいだけなのにSSH鍵の登録が必要になっていました。今回、オートメーションを使うことで、アプリケーションエンジニアに特定リソースへのSSHアクセス権限を付与する必要なく、特定のリソースの特定のタスクに対するアクセス権限をIAMによって提供できるようになりました。これはセキュリティ的に大きな前進でした。
また、Systems Managerによるドキュメント化によって、チーム内で属人化していた運用のベストプラクティスを リージョンやIAMグループ間で簡単に共有ができるようになりました。また、ドキュメントが受け入れる許可パラメータ値のバリデーションも行うことができ、ミスオペレーションを防ぐことができます。
今回はとてもシンプルなタスクをSystems Manager上で管理できるようにしましたが、Systems Managerは、インスタンスだけでなく周辺のサービスも含めて自動化できるフレームワークなので、積極的に複雑なタスクを簡素化・自動化していきたいと思います。 オートメーションには数多くのアクションがあるのでぜひ公式ドキュメントをご確認ください。
Systems Manager Automation アクションのリファレンス - AWS Systems Manager
イベントリでインスタンスの状態を簡単に把握
イベントリの機能の説明は以下の公式ドキュメントをご確認ください。
インベントリを使用して、Amazon EC2 インスタンスおよびオンプレミスサーバー、またはハイブリッド環境の仮想マシン (VM) から、オペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集できます。メタデータを照会すると、ソフトウェアポリシーに従ってソフトウェアと設定を実行しているインスタンスと、更新が必要なインスタンスをすばやく把握できます。 AWS Systems Manager インベントリ - AWS Systems Manager
インベントリ情報を取得することで、インスタンスの全ての構成要素(OS, ミドルウェア, ライブラリ)の一覧とそのバージョンを簡単に管理することができます。OSのセキュリティ設定に問題はないか、不要なミドルウェアは存在しないかなど、各インスタンスの状況を把握することができます。また、取得した情報は、以下のようにダッシュボード形式で表示することができます。
まとめ
まだまだSystems Managerの一部機能しか使いこなしていませんが、この時点で既に感じているメリットは以下の4つです。
1. 権限の可視性と制御性の向上
- IAMロールで制御可能になるので、誰がどのサーバーにどのアクセス権限をもっているのかがAWS上で簡単に管理が可能
2. セキュリティとコンプライアンスの向上
- 踏み台サーバーが不要
- SSH用のインバウンド用ポート開放が不要
- SSHキーペアの管理不要
- サーバーのインベントリ情報の管理が簡単に
- アクセス履歴がS3やCloudTrailで可能になり、サーバーアクセスなど監査可能なログを必要とする企業ポリシーに準拠が可能
3. 運用業務の自動化と定型化
- 繰り返し作業の自動化と定型化ができ、コスト削減とミスオペレーションの削減が可能
4. 無料で利用可能
サービスを運営するにあたって必要なセキュリティ要件も、AWSのサービスを利用することで、ほとんど工数を掛けず、サービス全体のセキュリティを高めることができました。これからも適切なAWSサービスを選択し、運用コストを下げていこうと思います。
スタメンでは一緒にシステムの信頼性を向上させていく仲間を募集しています。ぜひ こちら からご連絡ください。