第98回 雲勉【オンライン：上級者向け】Auto Scaling構成でのAMI自動更新ソリューション

Transcript

1. 第98回 雲勉【オンライン︓上級者向け】 Auto Scaling構成でのAMI⾃動更新ソリューション 2023/03/09
2. ⾃⼰紹介 2 • 野崎 ⾼弘（のざき たかひろ） • アイレット株式会社 クラウドインテグレーション事業部 プロジェクト企画推進セクション インフラ技術 • インフラ構築・保守やSOCセキュリティアナリストをやってました • 現在は技術検証やドキュメント作業が主 • 趣味︓資格取得、⽝の散歩、ドラクエ、巨⼈ファン、ドラマ鑑賞 • 現在、AWSは全冠、GCPは5冠 3
3. 本LTの⽬的 3 Auto Scaling構成で、AMIの更新を⼿動でやっているところが多いかと思います。 しかし、コンテンツの更新頻度が多いと、運⽤に⼯数が取られてしまいます。 そこで、Auto Scaling構成でのAMI⾃動更新ソリューションを試みましたので、その⽅法を紹介します。 （参考） （デプロイ） Tutorial: Deploy WordPress to an Amazon EC2 instance (Amazon Linux or Red Hat Enterprise Linux and Linux, macOS, or Unix)（Linuxデプロイ⽤） Tutorial: Deploy a "hello, world!" application with CodeDeploy (Windows Server)（Windowsデプロイ⽤）
4. 条件と注意事項 4 条件 • ⾃動で、AMI取得、Auto Scaling起動テンプレート更新、ローリングアップデートまで⾏えること • メンテが極⼒いらない構成であること • 失敗時にエラーを検知できること 注意事項 • 対象AMIがWindowsの場合、デプロイコマンドをAWS-RunPowerShellScriptで実⾏している関係上、事 前にAWS CLIを⼊れておく必要があります。運⽤上そういったものを⼊れておくことはできない場合は、 Windowsでは本スクリプトは使えません。 • ローリングアップデートは今動いているEC2に対しても更新をかけるため、ローリングアップデート前に 何かしらアップデートや変更作業を実施していた場合、それが消えてしまいます。 • EC2SSMRoleにCodeDeployを実⾏するためのポリシーを付与する必要があります。 • 起動設定でインスタンスプロファイルを割り当ててなかったので、起動テンプレートに CodeDeployDemo-EC2-Instance-Profileというインスタンスプロファイルを設定する必要があり、新し いEC2のロールにはこれが付与されています。
5. 全体像 5
6. 事前作業 6 1. デプロイ環境が作成されていることが前提なので、今回はEC2のLinuxでデプロイ環境を作ってみまし た。Apacheを起動してWordPressを構築するサイトを作るものです。以下のファイルを⽤意します。 /tmp |--WordPress/ |-- appspec.yml |-- scripts/ |-- wp-admin/ | |-- (various files...) |-- wp-content/ | |-- (various files...) |-- wp-includes/ | |-- (various files...) |-- index.php |-- license.txt |-- readme.html |-- (various files ending with .php...)
7. 事前作業 7 2. アプリケーションのファイルを単⼀のアーカイブファイルにバンドルし、アーカイブファイルをS3にプッ シュします。 3. 今回使うコードを GitHub - YoshiiRyo1/aws-autoscaling-amiupdate からクローンしておきます。 4. autoscaling-amiupdate.yaml の69⾏⽬「# deployment command here」を実際のデプロイコマンド （⾃分の場合は以下）に置き換えます。 - aws deploy create-deployment --application-name WordPress_App --deployment-config-name CodeDeployDefault.OneAtATime --deployment-group-name WordPress_DepGroup --s3-location bucket=nozaki-codedeploybucket,bundleType=zip,key=aaa/WordPressApp.zip --region ap- northeast-1 aws deploy create-application --application-name WordPress_App aws deploy push --application-name WordPress_App --s3-location s3://nozaki- codedeploybucket/aaa/WordPressApp.zip --ignore-hidden-files
8. 事前作業 8 awsコマンド実⾏時に「You must specify a region.」と怒られないように、--region ap- northeast-1 を指定しておくのがポイントです。 5. ⽤意するのは、あらかじめSSMエージェントが⼊っているAmazon Linuxに、CodeDeployエージェント を⼊れたEC2が対象になります。 Amazon Linux または RHEL ⽤の CodeDeploy エージェントをインストールする 6. あらかじめAWS CLIを⼊れておきます。 wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast- 1.amazonaws.com/latest/install
9. 事前作業 9 7. ⾃動化の中で起動する仮EC2で使⽤するインスタンスプロファイルを作成 8. SSM ドキュメント実⾏時に使⽤するIAMロールを作成 9. Lambda 関数実⾏時に使⽤するIAMロールを作成 10. ⾃動化プロセスの⼀部であるLambda関数 Automation-UpdateAsg を作成 11. ⾃動化プロセスを記述したSSMドキュメント CreateGoldenImageandupdateASG を作成 $ bash 00-createinstanceprofile.sh $ bash 01-createrole.sh $ bash 02-createlambbarole.sh $ bash 02-createlambdafunction.sh $ bash 03-createdocument.sh
10. 事前準備 10 12. 起動テンプレートと、それに対応したAuto Scaling Groupを⽤意します。 起動テンプレート（lt-083faf0904270e2b9） • AMI︓ami-03b335fd24efd420e Auto Scaling Group（nozaki-ASG） • 起動テンプレート︓lt-083faf0904270e2b9 • 希望・最⼩・最⼤容量︓2
11. 事前準備 11 13. デプロイ対象となるWordPress_DepGroupの環境設定は、SSMAutomationが作成するEC2に対して実 ⾏したいため、以下のようにタグを使って指定しました。
12. 事前確認 12 14. nozaki-ASGというAuto Scalingによって、AMI IDが ami-0f4b172cebf2c200c のEC2が2台⽴ち上 がっている事を確認します。 15. そしてこのインスタンスにはWebサーバーが ⼊っていないので、Webサイトを閲覧できません。
13. 作業⼿順概要 13 No 作業内容 1 Systems Manager Automationを実⾏ 2 既存のAMIから仮のEC2を起動 3 S3からデプロイコマンドを実⾏ 4 仮EC2をシャットダウンし、新しいAMIを作成 5 起動テンプレートのAMI IDを新しいAMIのものに修正 6 Lambda関数を呼び出す 7 Auto Scalingグループの起動テンプレートを新しいものに修正 8 ローリングアップデートにより、新しいAMIからAuto Scaling配下でEC2を起動 9 古くなったAMIを削除（今回は未実施）
14. 1．Systems Manager Automationを実⾏ 14 設定項⽬ 説明 ⼊⼒値 AutomationAssumeRole CustomRoleSSMCreateImageASG を探す (実装⼿順通り実⾏した場合) CustomRoleSSMCreateImageAS G subnetId 起動するサブネット subnet-00ab469f37c8b313a instanceprofileName EC2SSMRole(実装⼿順通り実⾏した場合) EC2SSMRole targetASG 対象のAutoScalingグループ名 nozaki-ASG sourceAMIid メモした最新ゴールデンイメージのAMI ID その都度⼊⼒(ami-03b335fd24efd 420e) securityGroupId 仮EC2⽤のセキュリティグループ sg-0ae5c41a8ae289cd9 targetAMIname GoldenImage-{{global:DATE_TIME}} launchtemplateId 更新対象の起動テンプレートID lt-083faf0904270e2b9 SSMドキュメント（CreateGoldenImageandupdateASG）を、主に以下の⼊⼒項⽬で実⾏します。
15. デモ環境構成図 15
16. デモ 16 ここからデモも交えて実際の動きを⾒ながら説明します。 （全部で10〜15分くらいかかります） 1. Run from SSMAutomationというインスタンスが起動していることを確認（このインスタンスにデプロ イしています） 2. ステップ2を開始すると、ec2AppDeployが完了するのを⾒守らないですぐに次のステップ4のインスタン ス停⽌を実⾏してしまうため、デプロイの時間を⾒込んでステップ3で2分間Sleepを⼊れています。 3. デプロイ済みのインスタンスから新しいゴールデンイメージを⽣成します。 4. 最後にAuto Scalingによってインスタンスが更新されます。 5. 〜/WordPress/wp-admin/ が⾒れることを確認 6. 起動テンプレートlt-083faf0904270e2b9においても、起動AMIがちゃんとGoldenImageのAMIに書き変 わっています。