PowerShellでAWSをごにょごにょする(その1)
2017.10.04
スクリプト好きとしては、コンソールに入ってぽちぽちするよりも、
スクリプトで色々いじりたくなるものです。
ということで、Windowsではお馴染みのPowerShellを使って、
AWSリソースを操作してみます。
今回はTools for Windows PowerShellを導入してみます。
①前提条件の確認
AWSアカウントが必要なので、持っていない場合は作成しましょう。
ツールはWindowsベースのコンピュータにインストールするので、
以下のシステム前提条件もチェック。
Microsoft Windows XP 以降
Windows PowerShell 2.0 以降
(Tools for PowerShell Core の場合は PowerShell Core 6.0 以降)
②AWS Tools for PowerShellのインストール
インストーラをダウンロードする方法もありますが、
せっかくなのでPowerShellからインストールしちゃいましょう。
管理者権限でPowerShellを起動して、カタカタします。
途中警告が出たり待たされたりしますが、気にしない。
※プログレスバーが出ないのでので不安にはなりますね
③スクリプト実行の有効化
ポリシーによってはスクリプト実行に制限があるので確認します。
ちなみにポリシー一覧は下記の通りです。
Restricted：構成ファイルの読み込みやスクリプトの実行を行いません。既定値は "Restricted" です。
AllSigned：すべてのスクリプトと構成ファイルが信頼された発行元によって署名されていることを要求します (ユーザーがローカル コンピューターに書き込むスクリプトを含む)。
RemoteSigned：インターネットからダウンロードされたすべてのスクリプトおよび構成ファイルが、信頼された発行元によって署名されていることを要求します。
Unrestricted：すべての構成ファイルを読み込み、すべてのスクリプトを実行します。インターネットからダウンロードされた署名されていないスクリプトを実行する場合、スクリプトを実行する前に確認を求められます。
Bypass：何もブロックされず、警告もメッセージも表示されません。
Undefined：現在のスコープから現在割り当てられている実行ポリシーを削除します。このパラメーターは、グループ ポリシー スコープ内で設定された実行ポリシーは削除しません。
確認したところ、Bypassなので次に進みます。
④インストールの確認
インストールは完了しているはずなので、バージョン情報を見てみます。
⑤操作できるAWSサービスの確認
さっきのコマンドにパラメータを追加すると、サポートされているAWSサービスが表示されます。
Service Noun Prefix API Version
------- ----------- -----------
AWS AppStream APS 2016-12-01
AWS AppSync ASYN 2017-07-25
AWS Batch BAT 2016-08-10
AWS Budgets BGT 2016-10-20
AWS Certificate Manager ACM 2015-12-08
AWS Certificate Manager Private Certificate Authority PCA 2017-08-22
AWS Cloud Directory CDIR 2016-05-10
AWS Cloud HSM HSM 2014-05-30
AWS Cloud HSM V2 HSM2 2017-04-28
AWS Cloud9 C9 2017-09-23
AWS CloudFormation CFN 2010-05-15
AWS CloudTrail CT 2013-11-01
AWS CodeBuild CB 2016-10-06
AWS CodeCommit CC 2015-04-13
AWS CodeDeploy CD 2014-10-06
AWS CodePipeline CP 2015-07-09
AWS CodeStar CST 2017-04-19
AWS Config CFG 2014-11-12
AWS Cost Explorer CE 2017-10-25
AWS Cost and Usage Report CUR 2017-01-06
AWS Data Pipeline DP 2012-10-29
AWS Database Migration Service DMS 2016-01-01
AWS Device Farm DF 2015-06-23
AWS Direct Connect DC 2012-10-25
AWS Directory Service DS 2015-04-16
AWS Elastic Beanstalk EB 2010-12-01
AWS Elemental MediaConvert EMC 2017-08-29
AWS Elemental MediaLive EML 2017-10-14
AWS Elemental MediaPackage EMP 2017-10-12
AWS Elemental MediaStore EMS 2017-09-01
AWS Elemental MediaStore Data Plane EMSD 2017-09-01
AWS Glue GLUE 2017-03-31
AWS Greengrass GG 2017-06-07
AWS Health HLTH 2016-08-04
AWS Identity and Access Management IAM 2010-05-08
AWS Import/Export IE 2010-06-01
AWS Import/Export Snowball SNOW 2016-06-30
AWS IoT IOT 2015-05-28
AWS IoT Jobs Data Plane IOTJ 2017-09-29
AWS Key Management Service KMS 2014-11-01
AWS Lambda LM 2015-03-31
AWS Marketplace Commerce Analytics MCA 2015-07-01
AWS Marketplace Entitlement Service MES 2017-01-11
AWS Marketplace Metering MM 2016-01-14
AWS Migration Hub MH 2017-05-31
AWS OpsWorks OPS 2013-02-18
AWS OpsWorksCM OWCM 2016-11-01
AWS Organizations ORG 2016-11-28
AWS Price List Service PLS 2017-10-15
AWS Resource Groups RG 2017-11-27
AWS Resource Groups Tagging API RGT 2017-01-26
AWS Secrets Manager SEC 2017-10-17
AWS Security Token Service STS 2011-06-15
AWS Serverless Application Repository SAR 2017-09-08
AWS Service Catalog SC 2015-12-10
AWS Shield SHLD 2016-06-02
AWS Step Functions SFN 2016-11-23
AWS Storage Gateway SG 2013-06-30
AWS Support API ASA 2013-04-15
AWS Systems Manager SSM 2014-11-06
AWS WAF WAF 2015-08-24
AWS WAF Regional WAFR 2016-11-28
AWS X-Ray XR 2016-04-12
Alexa For Business ALXB 2017-11-09
Amazon API Gateway AG 2015-07-09
Amazon Athena ATH 2017-05-18
Amazon CloudFront CF 2017-10-30
Amazon CloudSearch CS 2013-01-01
Amazon CloudSearchDomain CSD 2013-01-01
Amazon CloudWatch CW 2010-08-01
Amazon CloudWatch Events CWE 2015-10-07
Amazon CloudWatch Logs CWL 2014-03-28
Amazon Cognito Identity CGI 2014-06-30
Amazon Cognito Identity Provider CGIP 2016-04-18
Amazon Comprehend COMP 2017-11-27
Amazon DynamoDB DDB 2012-08-10
Amazon DynamoDB Accelerator (DAX) DAX 2017-04-19
Amazon EC2 Container Registry ECR 2015-09-21
Amazon EC2 Container Service ECS 2014-11-13
Amazon ElastiCache EC 2015-02-02
Amazon Elastic Compute Cloud EC2 2016-11-15
Amazon Elastic File System EFS 2015-02-01
Amazon Elastic MapReduce EMR 2009-03-31
Amazon Elastic Transcoder ETS 2012-09-25
Amazon Elasticsearch ES 2015-01-01
Amazon GameLift Service GML 2015-10-01
Amazon GuardDuty GD 2017-11-28
Amazon Inspector INS 2016-02-16
Amazon Kinesis KIN 2013-12-02
Amazon Kinesis Analytics KINA 2015-08-14
Amazon Kinesis Firehose KINF 2015-08-04
Amazon Kinesis Video Streams KV 2017-09-30
Amazon Kinesis Video Streams Media KVM 2017-09-30
Amazon Lex LEX 2016-11-28
Amazon Lex Model Building Service LMB 2017-04-19
Amazon Lightsail LS 2016-11-28
Amazon MQ MQ 2017-11-27
Amazon MTurk Service MTR 2017-01-17
Amazon Machine Learning ML 2014-12-12
Amazon Pinpoint PIN 2016-12-01
Amazon Polly POL 2016-06-10
Amazon Redshift RS 2012-12-01
Amazon Rekognition REK 2016-06-27
Amazon Relational Database Service RDS 2014-10-31
Amazon Route 53 R53 2013-04-01
Amazon Route 53 Domains R53D 2014-05-15
Amazon SageMaker Runtime SMR 2017-05-13
Amazon SageMaker Service SM 2017-07-24
Amazon Server Migration Service SMS 2016-10-24
Amazon Simple Email Service SES 2010-12-01
Amazon Simple Notification Service SNS 2010-03-31
Amazon Simple Queue Service SQS 2012-11-05
Amazon Simple Storage Service S3 2006-03-01
Amazon Transcribe Service TRS 2017-10-26
Amazon Translate TRN 2017-07-01
Amazon WorkDocs WD 2016-05-01
Amazon WorkMail WM 2017-10-01
Amazon WorkSpaces WKS 2015-04-08
Application Auto Scaling AAS 2016-02-06
Application Discovery Service ADS 2015-11-01
Auto Scaling AS 2011-01-01
Elastic Load Balancing ELB 2012-06-01
Elastic Load Balancing V2 ELB2 2015-12-01
Firewall Management Service FMS 2018-01-01
次回はEC2を操作してみたいと思います。
SimpleADユーザーとGoogleアカウントを同期させる
2017.09.15
こんにちは。YCです。前回の記事でSimpleADにユーザーを作成できました。
今回はそのユーザーをG Suiteに連携したいと思います。
連携の為、使用するツールはGoogleの出しているAD連携ツール
「Google Cloud Directory Sync (以下GCDS)」を使用します。
GCDSの仕組み
1,LDAP サーバーまたは Active Directory のリストからデータが書き出されます。ユーザーが、リストの生成方法を指定するルールを設定します。
2.GCDS は Google ドメインに接続し、ユーザーが指定した Google ユーザー、グループ、共有の連絡先のリストを生成します。
3,GCDS はこのリストを比較し、そのデータに合わせて Google ドメインを更新します。
4,同期が完了すると、ユーザーが指定したアドレスにレポートがメールで送信されます。
環境準備
まずはGoogleの管理コンソールにログインし、
セキュリティ → API リファレンス →API アクセスを有効にする にチェックを付けます。
これでとりあえずAPIが通るようになりました。
環境構築
Google公式の出しているGCDSのダウンロード手順書を見ながら
GCDSをダウンロードします。
ダウンロードしたら、GCDSを開き以下の手順で作業を進めます。
最初に出てくるのはGoogleとの連携です。
Primary Domain NameにGoogleのドメイン名を入力し、
Authrize Nowをクリックします。
(検証後にスクリーンショットを撮ったので既にAuthrizedになってますが気にしないでください。)
そうすると、このようなポップアップが出てくるので、
Sign inをクリックし、Googleドメインにサインインしてください。
出てくるものを全て承認すると、Verification Codeが発行されるので、
Step2に貼り付けてください。
次のLDAP認証が鬼門です。
実際のSimpleADへLDAPで接続します。
設定はこのように致しました。
注意して欲しいのが赤い下線部分です。
まず、ホスト名ですが、AWSのリソースであるSimpleADは自分の指定したドメインの前に
AWSのホスト名が付くので注意しましょう。
コマンドプロンプトから nslookup コマンドで確認して入力します。
次に、ユーザー名です。
ユーザーには事前に全てのユーザー情報の読み取り権限を委任してあげる必要があります。
鬼門なのでユーザーの権限委任から手順を載せていきます。
①グループを作成
②制御の委任をクリック
③委任ウィザードの開始で次へをクリック
④追加をクリック
⑤先ほど作ったグループを追加
⑥権限を追加
⑦ユーザーを作成し、
⑧先ほどのグループをユーザーに割り当てる
これでようやくLdapが通るユーザーが作成できました。
このユーザーを使用して、「ドメイン名¥ユーザー名」で設定します。
最後にベースDNがわからない場合はLdapブラウザなどで確認してください。
基本的には上記画像のように「DC=xxxxxx,DC=xx」で良いと思います。
では、次の設定に参りましょう。
次のGeneral Settingsはとりあえず下記画像だけで問題ありません。
Org Unitsはチェックをつけてください。
Googleの組織を使用するというチェックです。
ユーザーアカウントの設定はこれと同じように設定するだけで構いません。
User ruleは以下のように設定しました。
ここでのOrg Unit NameはGoogle側の組織名です。
Googleで先に組織を作っておいてください。
今回のルールはメールアドレスの最後に.tkが入っているユーザーを見つけるというルールにしています。
次にNotificationsはこのように設定しています。
SMTPホストはGoogleから引っ張っております。
そして、ログの吐き出し先を指定し、
Syncで全項目にチェックが付いていることを確認してsimulate syncをクリックします。
無事、シミュレーションが出来ると、
Google上のユーザ、AD上の検索で出たユーザそれぞれの数が出てきます。
問題がなければSync & apply changesをクリックし、
Googleにユーザーが追加された事を確認してください。
これにてGoogleとADの同期は完了です。
散々詰まりましたが、こちらのサイト様のおかげで
なんとか同期の確認は取れました。
次回はGoogle Password Syncでパスワードの同期を試します。
ブログに載せられる機会があれば載せます。
以上です。では。
AWS Directory ServiceのSimpleADのユーザーをWindows7のローカルPCで管理
2017.09.01
初めまして。YCです。AWSのDirectory ServiceであるSimpleADの管理をする為には
SimpleADのドメインに所属するActive Directoryインスタンスを作成しなくてはなりません。
それをWindows7のローカルPCでやっちゃおうという記事です。
SimpleADとは
Simple AD は、AWS Directory Service が提供する Microsoft Active Directory 互換のディレクトリで、Samba 4 を搭載しています。Simple AD は、ユーザーアカウント、グループメンバーシップ、Linux および Microsoft Windows を実行するドメイン結合 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Kerberos ベースのシングルサインオン (SSO)、グループポリシーなどの一般的に使用される Active Directory 機能をサポートしています。これにより、Linux および Windows を実行する Amazon EC2 インスタンスの管理と AWS クラウドでの Windows アプリケーションのデプロイがさらに容易になります。
構成図
ざっくりと書きましたが、今回はこんな感じで構成していきます。
VPN接続が必要となるので、VPN接続やルータの設定などを行える事が前提です。
この記事ではVPN接続やルータの設定は割愛します。
環境構築
Simple AD構築
まずはAWSコンソール上でSimple ADを構築していきます。
コンソールの“セキュリティ、 アイデンティティ、 コンプライアンス”のDirectory Serviceを押し、
ディレクトリのセットアップからSimple ADを選択します。
各項目を入力し、次へボタンを押す
確認画面で確認し、Simple ADの作成を押す
Simple AD作成完了です。
ここのDNSアドレスは後で使うので覚えておいてください。
※注意点として、SimpleADを作成すると自動でセキュリティグループが作成されます。
EC2コンソールのセキュリティグループでSimpleADのディレクトリIDを検索すると、
見慣れないセキュリティグループが作成されているのがわかります。
今回は検証のため、全部通しましたが、必要に応じたセキュリティグループの設定が必要です。
リモートサーバー管理ツール（RSAT）インストール
Windowsサーバを使用せず、ローカルPCでAWSのDirectory Serviceを管理するためには、
ローカルPCにリモートサーバー管理ツールをインストールする必要があります。
インストール方法はこちらを参考にしてください。
- 正常にインストールが完了すると、管理ツールにこのような管理項目が増えているはずです。
Windows7での設定
最後に管理に使用するWindowsPCをドメイン参加させます。
ドメイン参加のやり方はこちらのサイトを参考に致しました。
手順通りに進めていくとドメイン参加させられるはずです。
ドメイン参加後、先ほどの管理ツールの「Active Directory ドメインと信頼関係」を開き、
「操作」→「フォレストの変更」から作成したSimpleADのドメインを入力します。
そうすると、作成したSimpleADと信頼関係が結ばれるはずです。
信頼関係が結ばれた後、管理ツールから「Active Directory ユーザーとコンピューター」を開きます。
これで、普通のADのようにユーザー管理が出来るようになりました！
インスタンス代金が1台分浮きました。
次回はSimpleADのユーザをGoogleAppsのユーザに同期させる記事を書きたいと思います。
以上、宜しくお願いいたします。
Auto ScalingによりローンチされたEC2インスタンスに紐づくEBSに自動でタグをつけたい
2017.08.18
batchiです。タイトルの通りです。
Auto Scalingグループによって自動的に増えたり減ったりするEC2インスタンス。
EC2インスタンス自体のタグに関しては、
Auto Scalingグループに付与したタグと同じものを自動的に付与させる設定があります。
でもそのEC2インスタンスにアタッチされているEBSにはタグはつかない。
つけたい。
どうしたらいいですか。
AWSサポートからの回答
「同じような要望をたくさんもらってます」
「Feature Requestとして要望中です」
「実装可否や実装時期についてはお答えできません」
「現時点で実装するなら、以下のいずれかでやってください」
・起動設定にユーザーデータ仕込む
・ライフサイクルフックを使う
というわけで、ユーザーデータを仕込むパターンを選択しました。
実装
参考にしたのはクラスメソッドさんの以下の記事。
[小ネタ] EC2インスタンスのEBSルートボリュームに自動でNameタグを付与する
http://dev.classmethod.jp/cloud/add-name-tag-to-root-volume/
カスタマイズしたのは以下のあたり。
・AWS CLIのインストールもユーザーデータで実施する
・タグを複数付与する
・ブロックデバイス名を変更
・インスタンス作成時でなくAuto Scaling起動設定に仕込む
・タグの値にインスタンス名は含めないので変数instance_nameはカット
結果、こうなりました。
#!/bin/bash
#AWS CLIのインストール
curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install awscli
#各種変数の定義
instance_id=`curl -s 169.254.169.254/latest/meta-data/instance-id`
az=`curl -s 169.254.169.254/latest/meta-data/placement/availability-zone`
region=${az%[a-z]}
volume_id=`aws ec2 describe-instances --output text --region $region --instance-ids $instance_id \
--query 'Reservations[].Instances[].BlockDeviceMappings[?DeviceName==\`/dev/sda1\`].Ebs[].VolumeId'`
#タグ付与
aws ec2 create-tags --region $region --resources $volume_id --tags Key=Name,Value=<Nameタグの値> Key=System,Value=<Systemタグの値>
AWS CLIはインストールした状態でAMIを取得してから
起動設定を作成するのが自然だろうと思いますが、
なるたけAMIおよび起動設定をいじりたくなかったのと、
インストールにかかった時間を計測したら数秒程度だったので、そのままにしました。
少しだけわからなかったところ
変数volume_idを取得している箇所で、
--query以降をなんであんな書き方するの？というのがパッとは理解できず。
（Reservationsとか何のために書いてるの？）
--outputをtable形式にするとすんなり理解できました。
（jsonに親しんでいる人はjsonのほうがいいと思います。）
>aws ec2 describe-instances --output table --instance-ids <インスタンスID>出力結果は階層構造になっていて、
お目当ての「VolumeId」に至るまでの、
上位の階層も書いてあげないとダメというわけでした。
以下、無駄に長い出力結果です。
--------------------------------------------------------------------------------
| DescribeInstances |
+------------------------------------------------------------------------------+
|| Reservations ||
|+-------------------------------+--------------------------------------------+|
|| OwnerId | 13xxxxx31447 ||
|| ReservationId | r-03a26xxxx77df49cc ||
|+-------------------------------+--------------------------------------------+|
||| Instances |||
||+------------------------+-------------------------------------------------+||
||| AmiLaunchIndex | 0 |||
||| Architecture | x86_64 |||
||| ClientToken | alfAo1496209729199 |||
||| EbsOptimized | False |||
||| Hypervisor | xen |||
||| ImageId | ami-249fad43 |||
||| InstanceId | i-0cd43xxxxx6953268 |||
||| InstanceType | t2.micro |||
||| KeyName | aws_shared_key_tokyo |||
||| LaunchTime | 2017-07-26T00:35:27.000Z |||
||| Platform | windows |||
||| PrivateDnsName | ip-10-5-1-210.ap-northeast-1.compute.internal |||
||| PrivateIpAddress | 10.5.1.210 |||
||| PublicDnsName | |||
||| PublicIpAddress | 54.xx.84.xxx |||
||| RootDeviceName | /dev/sda1 |||
||| RootDeviceType | ebs |||
||| SourceDestCheck | True |||
||| StateTransitionReason | User initiated (2017-07-26 15:00:06 GMT) |||
||| SubnetId | subnet-91axxxxx |||
||| VirtualizationType | hvm |||
||| VpcId | vpc-dxxxxxbc |||
||+------------------------+-------------------------------------------------+||
|||| BlockDeviceMappings ||||
|||+------------------------------------+-----------------------------------+|||
|||| DeviceName | /dev/sda1 ||||
|||+------------------------------------+-----------------------------------+|||
||||| Ebs |||||
||||+------------------------------+---------------------------------------+||||
||||| AttachTime | 2017-05-31T05:48:51.000Z |||||
||||| DeleteOnTermination | True |||||
||||| Status | attached |||||
||||| VolumeId | vol-00cxxxxxb03bfb5c8 |||||
||||+------------------------------+---------------------------------------+||||
|||| Monitoring ||||
|||+------------------------------+-----------------------------------------+|||
|||| State | disabled ||||
|||+------------------------------+-----------------------------------------+|||
|||| NetworkInterfaces ||||
|||+------------------------------+-----------------------------------------+|||
|||| Description | Primary network interface ||||
|||| MacAddress | 06:cc:05:12:ba:2b ||||
|||| NetworkInterfaceId | eni-xxxxaabe ||||
|||| OwnerId | 1xxxxxxxx447 ||||
|||| PrivateIpAddress | 10.5.1.210 ||||
|||| SourceDestCheck | True ||||
|||| Status | in-use ||||
|||| SubnetId | subnet-9xxxxxe6 ||||
|||| VpcId | vpc-xxxxxxbc ||||
|||+------------------------------+-----------------------------------------+|||
||||| Association |||||
||||+-----------------------------------+----------------------------------+||||
||||| IpOwnerId | 133285731447 |||||
||||| PublicDnsName | |||||
||||| PublicIp | 54.xx.84.xxx |||||
||||+-----------------------------------+----------------------------------+||||
||||| Attachment |||||
||||+------------------------------+---------------------------------------+||||
||||| AttachTime | 2017-05-31T05:48:50.000Z |||||
||||| AttachmentId | eni-attach-5450dbbc |||||
||||| DeleteOnTermination | True |||||
||||| DeviceIndex | 0 |||||
||||| Status | attached |||||
||||+------------------------------+---------------------------------------+||||
||||| Groups |||||
||||+------------------------+---------------------------------------------+||||
||||| GroupId | GroupName |||||
||||+------------------------+---------------------------------------------+||||
||||| sg-dcxxxxb8 | testxxxxavpc-internal |||||
||||| sg-e0xxxx84 | testxxxxavpc-22_from |||||
||||+------------------------+---------------------------------------------+||||
||||| PrivateIpAddresses |||||
||||+----------------------------------------+-----------------------------+||||
||||| Primary | True |||||
||||| PrivateIpAddress | 10.5.1.210 |||||
||||+----------------------------------------+-----------------------------+||||
|||||| Association ||||||
|||||+----------------------------------+---------------------------------+|||||
|||||| IpOwnerId | 13xxxxxxxcx7 ||||||
|||||| PublicDnsName | ||||||
|||||| PublicIp | 54.xx.84.xxx ||||||
|||||+----------------------------------+---------------------------------+|||||
|||| NetworkInterfaces ||||
|||+------------------------------------+-----------------------------------+|||
|||| Description | ||||
|||| MacAddress | 06:ec:04:91:0b:9d ||||
|||| NetworkInterfaceId | eni-8bxxxxc5 ||||
|||| OwnerId | 133285731447 ||||
|||| PrivateIpAddress | 10.5.3.222 ||||
|||| SourceDestCheck | True ||||
|||| Status | in-use ||||
|||| SubnetId | subnet-7xxxxxx6 ||||
|||| VpcId | vpc-xxxxxxxc ||||
|||+------------------------------------+-----------------------------------+|||
||||| Attachment |||||
||||+------------------------------+---------------------------------------+||||
||||| AttachTime | 2017-05-31T08:11:05.000Z |||||
||||| AttachmentId | eni-attach-83xxxxxb |||||
||||| DeleteOnTermination | False |||||
||||| DeviceIndex | 1 |||||
||||| Status | attached |||||
||||+------------------------------+---------------------------------------+||||
||||| Groups |||||
||||+------------------------+---------------------------------------------+||||
||||| GroupId | GroupName |||||
||||+------------------------+---------------------------------------------+||||
||||| sg-dcdb40b8 | testxxxxavpc-internal |||||
||||| sg-e05ac084 | testxxxxavpc-22_fromINF |||||
||||+------------------------+---------------------------------------------+||||
||||| PrivateIpAddresses |||||
||||+----------------------------------------+-----------------------------+||||
||||| Primary | True |||||
||||| PrivateIpAddress | 10.5.3.222 |||||
||||+----------------------------------------+-----------------------------+||||
|||| Placement ||||
|||+------------------------------------+-----------------------------------+|||
|||| AvailabilityZone | ap-northeast-1a ||||
|||| GroupName | ||||
|||| Tenancy | default ||||
|||+------------------------------------+-----------------------------------+|||
|||| SecurityGroups ||||
|||+------------------------+-----------------------------------------------+|||
|||| GroupId | GroupName ||||
|||+------------------------+-----------------------------------------------+|||
|||| sg-dcdb40b8 | tesxxxxxavpc-internal ||||
|||| sg-e05ac084 | testxxxxavpc-22_fromINF ||||
|||+------------------------+-----------------------------------------------+|||
|||| State ||||
|||+-----------------------------+------------------------------------------+|||
|||| Code | 80 ||||
|||| Name | stopped ||||
|||+-----------------------------+------------------------------------------+|||
|||| StateReason ||||
|||+----------+-------------------------------------------------------------+|||
|||| Code | Client.UserInitiatedShutdown ||||
|||| Message | Client.UserInitiatedShutdown: User initiated shutdown ||||
|||+----------+-------------------------------------------------------------+|||
|||| Tags ||||
|||+--------------------+---------------------------------------------------+|||
|||| Key | Name ||||
|||| Value | testxxxxa-member1 ||||
|||+--------------------+---------------------------------------------------+|||
蛇足
以下、お遊びで以下のユーザーデータも試してみました。
#!/bin/bash
#AWS CLIのインストール
curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install awscli
#各種変数の定義
instance_id=`curl -s 169.254.169.254/latest/meta-data/instance-id`
az=`curl -s 169.254.169.254/latest/meta-data/placement/availability-zone`
region=${az%[a-z]}
volume_id=`aws ec2 describe-instances --output text --region $region --instance-ids $instance_id \
--query 'Reservations[].Instances[].BlockDeviceMappings[?DeviceName==\`/dev/sda1\`].Ebs[].VolumeId'`
date=`date`
#タグ付与
aws ec2 create-tags --region $region --resources $volume_id --tags Key=Name,Value=<Nameタグの値> Key=System,Value=<Systemタグの値> Key=Date,Value="$date"
ユーザーデータが実行された時刻をタグとしてつけてしまおうというものです。
Auto Scalingグループのコンソール画面では、
履歴からインスタンスのローンチが行われた時刻が確認できます。
それとこのタグを比較すると…
ローンチ開始から50秒程度後にユーザーデータが実行されているようでした。
（あくまで私が試した環境において。）
なるほど。と思いました。
以上です。
[Auto Scaling]いつのまにか増えていたターゲットトラッキングポリシーを理解する
2017.08.04
batchiです。[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
全6回の無駄に長丁場の記事を書いている最中に、
しれっと新しい動的スケーリングのポリシーが追加されていました。
- 新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー -
https://aws.amazon.com/jp/blogs/news/new-target-tracking-policies-for-ec2-auto-scaling/
ひとまず前回時点では見て見ぬふりをして書き上げたので、
見て見ぬふりをしたツケをこれから払います。
ターゲットトラッキング（追跡）ポリシーとは
簡単に言えば、以下のような挙動です。
・メトリクスを指定する（平均CPU使用率、平均ネットワークI/Oなど）
・メトリクスに対するターゲット値を指定する（60%、5,000byteなど）
・ターゲット値からぶれないようにうまいこと勝手にスケーリングしてくれる
こんな感じです。動的スケーリングの設定としてはかなり簡素化されましたね。
ドキュメントとしては以下を参照しましょう。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-target-tracking.html
補足として下記のようなトピックがあります。
・指定可能なメトリクスは以下の通り
・事前定義されたメトリクス
- ターゲット別のALBリクエスト数
- CPUの平均使用率
- 平均ネットワーク入力（バイト）
- 平均ネットワーク出力（バイト）
・カスタマイズされたメトリクス
- （どうやって設定するんだろう？？）
・オプションでスケールインを無効にすることが可能
・ウォームアップの期間を指定する必要あり
・ポリシー作成時にCloud Watchアラームが自動的に作成される
・メトリクスの値を取得する間隔は1分を推奨
[改訂版]スケーリングプランごとのクールダウン／ウォームアップ
ターゲットトラッキングポリシーでは、
クールダウンの概念ではなくウォームアップの概念が適用されます。
以前私は「ウォームアップはステップスケーリングポリシーだけ」
と謳っていたのですが、修正を余儀なくされました。
というわけで以下の表の通り。
◯…適用される
×…適用されない
| スケーリングプラン | デフォルトのクールダウン | スケーリング固有のクールダウン | ウォームアップ |
| インスタンス数の維持 | × | × | × |
| 手動スケーリング | × | オーバーライド可能 | × |
| スケジュールに基づくスケーリング | × | × | × |
| シンプルスケーリングポリシーによる動的スケーリング | ◯ | オーバーライド可能 | × |
| ステップスケーリングポリシーによる動的スケーリング | × | × | ◯ |
| ターゲットトラッキングポリシーによる動的スケーリング | × | × | ◯ |
ウォームアップの考え方自体は、
ステップスケーリングポリシーの時と変わりありません。
（良かった。）
ターゲットの追跡スケーリングポリシーでは、新しく起動されたインスタンスのウォームアップにかかる秒数を指定できます。その指定されたウォームアップ期間が終了するまで、インスタンスは Auto Scaling グループの集合メトリクスの対象になりません。
スケールアウト時、Auto Scaling はグループの現在の容量の一部としてウォームアップ中のインスタンスは対象にしません。これにより、必要以上の数のインスタンスが追加されることがなくなります。
スケールイン時、Auto Scaling はグループの現在の容量の一部として終了中のインスタンスを対象にします。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。
スケールアウトアクティビティの進行中、スケールインアクティビティを開始することはできません。
ターゲットトラッキングポリシーの実装
さわりの部分だけ紹介します。
Auto Scalingグループのコンソール画面で「ポリシーの追加」を選択すると、
ターゲットトラッキングポリシーの作成画面が開きます。
（他のポリシーを作成したい場合は画面下部から切り替える）
・名前（ポリシー名）
・メトリクスタイプ
・ターゲット値
・ウォームアップの長さ
・スケールインの無効化の有無の指定
上記を指定するだけで完了です。簡単。
ポリシーを作成すると、自動的にCloudwatchアラームが作成されます。
今回の例ではターゲット値として「50」を指定しましたが、
スケールアウトを担うアラームと、スケールインを担うアラームが以下の設定で作成されました。
・1分間の平均CPU使用率が50を超える期間が3回連続で検出された場合スケールアウト
・1分間の平均CPU使用率が45を下回る期間が15回連続で検出された場合スケールイン
具体的にスケールする台数は、Cloudwatchアラームからは確認できません。
よしなにやってくれるので、気にする必要がない部分ですね。
自動的に作成されたアラームは、
ユーザー側では編集も削除もできません。
削除したいときは、ポリシー削除すれば連動して削除されます。
ちなみに、ポリシー作成時に「スケールインの無効化」を有効化していると、
スケールインを担うアラームは作成されません。
というわけでターゲットトラッキングポリシーの紹介でした。
◯◯台という部分をユーザーが握れないので、
ターゲットの値を適切に設定する必要があるポリシーですね。
実際に動かしてみて、適切なターゲットの値を算出するのが良さそうです。
こちらからは以上です。
- 最新の記事
- シンプラインブログ一覧
- 過去の記事一覧