[レポート]Automate operations management on AWS #COP310-R #reinvent

2022.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、ヌヌです!

本記事は、re:Invent2022のセッション Automate operations management on AWS の参加レポートです。

ワークショップの概要

In this workshop you will automate three common daily operations tasks by using AWS services (DRS agent deployment and testing of failover, detecting and handling unattached EBS volumes, and finding instance that were launched from an unauthorized AMI)

ワークショップの内容

AWSのマネージドサービスのAWS Elastic Disaster Recovery(AWS DRS)を利用して、自動的なDR対策やLambdaとEvent Bridgeを使って使用しないリソースEBSの削除、そして

コンプライアンスのモニタリングを実装します。
元文は以下になります。
  • Disaster recovery configuration, deployment, and testing
  • Deletion of unused Amazon Elastic Block Store (Amazon EBS) volumes
  • Compliance monitoring and remediation

本ワークショップは、ソリューションアーキテクト、SysOps、ServerOps、InfraOps、およびその他のスペシャリスト向けに作成された中級レベルのワークショップです。

本ワークショップを通じて4つのスキルを学ぶことが可能です。

  • DRSがどう動くのか理解できる
  • DRSを利用したサーバー複製
  • DRSを利用したAWSのFailover
  • フェイルオーバが成功したことを確認します。

Part 1 - Disaster recovery replication to AWS

アーキテクチャ

Step1. Access to Bastion Host

  • EC2コンソル画面へ接続し、踏み台サーバーのインスタンスを選択します。
  • 「接続」項目で「Fleet Manager - Remote Desktop」のRDP接続を行います。

Step2. Configure DRS Settings

  • Replicationサーバーの 設定を行います。

    • Staging areaのサブネット、インスタンスタイプを設定します。(本ワークショップでは、プライベートサブネットやT3.smallを選択しました。)
    • セキュリティグループを設定します。(defaultのセキュリティグループ)
    • 追加設定は飛ばします。
    • create defaultボタンを押して設定を完了します。

Step 3. Configure IAM Role

ユーザーのAWSアカウントと相互作用するためのDRSReplicationエージェントにアタッチするIAMを作成します。また、EC2インスタンスへSSMエージェントが設置されているのか事前に確認する必要があります。(ほとんどの場合、AMI(AmazonMachineImages)は、SSMAgentがプリインストールされた状態でインスタンスを起動するように構成されている)

  • IAM Role作成
    • サービス:EC2
    • ポリシー:AWSElasticDisasterRecoveryEc2InstancePolicy

Step 4. Attach IAM Role to EC2

  • 作成したIAMロールを対象のEC2にアタッチします。

Step 5. Tag Resources

ElasticDisasterRecoveryエージェントを複数のインスタンスにインストールするため、EC2インスタンスに共通のタグをつけます。

  • EC2コンソル画面 → 「Tags」カテゴリへ移動します。
  • タグをつける対象のインスタンスを選択します。
  • Key: DRS, Value: true タグをつけます。

Step 6. Installing the Agent

AWS DRSを設定する次のステップは、各マシンにReplicationAgentをインストールし、ソース環境からAWSターゲット環境へのレプリケーションを開始してAWS DRS設定を続きます。

  • SSMのRun Commandコンソル画面へ移動します。
  • 「AWSDisasterRecovery-InstallDRAgentOnInstance」のコマンドを検索します。
  • インスタンスにつけたTagで対象インスタンスを設定します。
  • コマンドの実行が完了できるまで約5分ぐらいかかります。
  • コマンドが成功するとAWS DRSのsource servers コンソル画面へ移動してシンクが完了されるまで数分待ちます。

シンクの内容

  • Create security groups
  • Launch replication server
  • Boot replication server
  • Authenticate with service
  • Download replication software
  • Create staging disks
  • Attach staging disks
  • Pair replication server with Agent
  • Connect agent with replication serverStart data transfer

Step 7. Configure Launch Settings

シンクが成功するとsource serversの設定を行います。

  • Instance type right sizingをnoneで設定します。
  • EC2 launch templateを修正します。
  • defaultバージョンを先ほど作成したlaunch templateで修正します。

Step 8. Failing Over

  • initiate drill を実施します。(完了まで10分ぐらいかかります。)

Step 9. Validating Fail Over

PuTTyを利用して踏み台サーバーから対象のインスタンスへ接続します。

フェールオーバー検証からコマンドを実行(コピー/貼り付け)します。

  • failover-validation.txt

ファイルは、このインスタンスのDNSレコードを更新するためにSSHセッション内の砦のデスクトップにあります。

ADDR=`hostname -I`
HOST=`hostname`
sudo touch /tmp/nsupdate.txt
sudo chmod 666 /tmp/nsupdate.txt
echo "server dns.onpremsim.env" > /tmp/nsupdate.txt
echo "update delete $HOST A" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 A $ADDR" >> /tmp/nsupdate.txt
echo "update delete $HOST PTR" >> /tmp/nsupdate.txt
echo "update add $HOST 86400 PTR $ADDR" >> /tmp/nsupdate.txt
echo "send" >> /tmp/nsupdate.txt
sudo nsupdate /tmp/nsupdate.txt

Part 2 - Deletion of unused Amazon Elastic Block Store volumes

アーキテクチャ

Step 1. Create an Amazon SNS topic

  • ステンダードのSNSトピックを作成します。

Step 2. Create an IAM role for the Lambda function execution

Lambda 関数にアタッチするIAMロールを作成します。

サービス:Lambda ポリシー:

 

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudtrail:LookupEvents",
"cloudtrail:StartLogging",
"cloudtrail:GetTrailStatus",
"logs:CreateLogGroup",
"logs:PutLogEvents",
"ssm:CreateOpsItem",
"cloudtrail:DescribeTrails",
"ec2:DescribeVolumeAttribute",
"logs:CreateLogStream",
"sns:Publish",
"ec2:DescribeVolumeStatus",
"cloudtrail:CreateTrail",
"ec2:DescribeVolumes"
],
"Resource": "*"
}
]
}

 

Step 3. Create the Lambda function configuration

下記のような設定のLambda関数の設定を作成します。

  • Author from scratch
  • runtime: Python 3.7
  • Architecture: x86_64
  • Handler Update: “opsCenterAgedEBSVolumeFinder.lambda_handler

Step 4. Create the Lambda function

下記のコードのLambda関数を作成します。

import json
import itertools
from datetime import datetime, timedelta
import os, os.path, sys
import boto3
import botocore
from botocore.exceptions import ClientError

 

Step 5. Usage Notes

environment variables

EC2またはローカルにCloudTrailログを検査して使用しないボリュームを識別するコードのファイルを作成

  • ファイル名:opsCenterAgedEBSVolumeFinder.py

続いて同ディレクトリで requirements.txt ファイル作成

// requirements.txt
boto3==1.26.1
botocore==1.29.1
awscli==1.27.1

同ディレクトリでboto3, botocore, awscli パッケージのローカルコピーを作成します。

  • コマンド: pip install --upgrade -r requirements.txt -t .

Lambda関数のディレクトリで下記のコマンドを実行します。

  • zip -r9 ../opsCenterAgedEBSVolumeFinder.zip .

cliで既存の関数をアップデートしパッケージをアップロードします。

 

Step 6. test function

Lambda関数のテストを実施します。

Step 7. Review the OpsItem

  • SSMコンソル画面 → OpsCenterへ移動します。
  • 検出された使用しないEBSを確認します。
  • リソースを選択し、Run Automationで設定しておいた自動化を始めます。

Step 8. Schedule the Lambda function

Event Bridgeを利用してLambdaを定義的に実行するイベントを作成します。

まとめ

時間不足でPart3のワークショップへ進めなかったことが残念でした。AWS DRSというサービスは初めて接してみましたが、自動的なDR対象ができることはすごく便利だと思いました。そして、今回はLambdaを利用して使用しないEBSだけ検出してみましたが、他の無駄のリソースを検出できるとすることも可能に見えました。今後挑戦してみたいですね。