タグ: AWS CLI

AWS EC2（5）ユーザデータによる起動時のコマンドの実行

eijiコメントはこの投稿ではオフになっています。

cloud-init

EC2が起動する際に、cloud-initを使って任意のスクリプトを実行させることが可能である。実行する際に渡すことのできるデータ（ユーザデータ）は、プレーンテキスト・ファイル・Base64エンコードされたテキストで、通常は初回起動時のみ実行されるため、再起動時などは実行されない。スクリプトは、シェルスクリプト形式もしくはcloud-initディレクティブ形式で記述することが可能である。なお、スクリプトは、インタラクティブに動作させることはできないことに注意が必要である。また、このスクリプトは、rootユーザとして実行される。

シェルスクリプトによる実行

シェルスクリプトを実行させるためには、通常のシェルスクリプト同様にインタプリタのパスを最初に記述する必要がある。

#!/bin/bash

その他の処理も、通常のシェルスクリプトと同様に記述することができる。

ユーザデータの登録

ユーザデータの登録は、AWSマネージメントコンソール上、もしくはAWS CLIから行うことが可能である。

AWSマネージメントコンソールから登録

AWSマネージドコンソールで行う場合は、インスタンス作成画面の中で、ユーザデータを登録できる。

ユーザデータの登録

また、登録したユーザデータは、「インスタンスの設定」より確認することが可能である。

ユーザデータの確認

実行中のインスタンスから値を取得することも可能である。

curl https://169.254.169.254/latest/user-data

AWS CLIから登録

AWS CLIからEC2を起動する際に、user-dataオプションを付与することで、ユーザデータを指定することができる。指定するファイルは、シェルスクリプトが記述された通常のテキストファイルでよい。

aws ec2 run-instances --cli-input-json file:///tmp/ec2_settings.json --user-data file:///tmp/cloud-init_userdata.txt

AWS EC2（4）AWS CLIからEC2インスタンスを起動する

eijiコメントはこの投稿ではオフになっています。

JSONファイルから起動する

EC2をAWS CLIから起動する際、JSONファイルに設定情報を記述しておくと、複雑なオプションコマンドを書き連ねる必要がなく、設定の管理もラクである。JSON形式の設定ファイルの雛形は、

<br>
aws ec2 run-instances --generate-cli-skeleton &gt; /tmp/ec2_settings.json<br>

で取得することが可能であるが、不要な設定も多く含まれているので、どの設定を有効とするかは精査が必要である。AWSマネージメントコンソールで設定可能な項目と同程度の設定であれば、以下の設定で起動することが可能である。

<br>
{<br>
    "DryRun": false,<br>
    "ImageId": "ami-XXXXXXXX",<br>
    "KeyName": "XXXXXXXX",<br>
    "SecurityGroups": [<br>
        "XXXXXXXX"<br>
    ],<br>
    "InstanceType": "t2.micro",<br>
    "BlockDeviceMappings": [<br>
        {<br>
            "DeviceName": "/dev/xvda",<br>
            "Ebs": {<br>
                "VolumeSize": 8,<br>
                "DeleteOnTermination": true,<br>
                "VolumeType": "gp2"<br>
            }<br>
        }<br>
    ],<br>
    "Monitoring": {<br>
        "Enabled": true<br>
    },<br>
    "DisableApiTermination": true,<br>
    "InstanceInitiatedShutdownBehavior": "stop",<br>
    "IamInstanceProfile": {<br>
        "Name": "XXXXXXXX"<br>
    }<br>
}<br>

それぞれの設定項目と、AWSマネージメントコンソール上の表示との対応は、以下の通り。

JSON項目名 AWSマネージメントコンソール上の名称 内容
DryRun – 設定ファイル作成時は、DryRunで確認する
ImageId Amazon マシンイメージ AMIのID
KeyName キーペアの選択 キーペア
SecurityGroups セキュリティグループの設定 セキュリティグループ名
InstanceType インスタンスタイプの選択 インスタンスタイプ
BlockDeviceMappings/DeviceName デバイス AWSマネージメントコンソールは、通常/dev/xvdaが指定される
BlockDeviceMappings/EBS/VolumeSize サイズ（GiB） ボリュームサイズ
BlockDeviceMappings/EBS/DeleteOnTermination 合わせて削除 インスタンス削除時にボリュームも削除するか否か
BlockDeviceMappings/EBS/VolumeType ボリュームタイプ
Monitoring モニタリング CloudWatch 詳細モニタリングを有効化
DisableApiTermination 削除保護の有効化 誤った削除からの保護
InstanceInitiatedShutdownBehavior シャットダウン動作 シャットダウン時にインスタンスを削除するか停止するか
IamInstanceProfile IAM ロール IAM インスタンスプロファイル

なお、Tagはインスタンスを起動しないと指定できない。
この設定ファイルを用いてEC2インスタンスを起動する場合は、以下のコマンドを実行する。

<br>
aws ec2 run-instances --cli-input-json file:///tmp/ec2_settings.json<br>

この際、設定ファイルに誤りがある場合には、

<br>
Parameter validation failed:<br>
Invalid type for parameter SecurityGroups, value: XXXXXXXX, type: &lt;type 'unicode'&gt;, valid types: &lt;type 'list'&gt;, &lt;type 'tuple'&gt;<br>

などのように、エラーメッセージが返される。

Amazon Web Services 業務システム設計・移行ガイド

AWS EC2（3）AMIとインスタンス

eijiコメントはこの投稿ではオフになっています。

AMI

AMI(Amazon Machine Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、

  • OSやアプリケーションなどのルートボリュームのテンプレート
  • 起動を許可するAWSアカウント
  • インスタンスにアタッチするボリュームのマッピング

などの情報が含まれている。

AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linuxは、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる。

なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。

リージョンをまたがるコピー

作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。

 $ curl -s https://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g' 



AMIの作成


既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。


$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit



インスタンスからの Linux AMI の作成


ストレージ


ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。


 



 



 



Instance Store


    

  • EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。ただし、再起動ではクリアされない。
    • 

  • インスタンス停止（STOP）することができない。
    • 

  • 無料
    • 



instance store-backed のインスタンス


Elastic Block Store


    

  • ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
    • 

  • デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。
    • 

  • スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。スナップショットを取得する際には、EBSをアンマウントすることが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない。
    • 

  • インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。
    • 



Amazon EBS-backed インスタンス


容量と性能


汎用SSD（gp2）のパフォーマンスは、ボリュームサイズに比例する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。


各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理（バースト）は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD（gp2）は、


    

  • 容量が33.4GB以下であれば、標準性能100IOPS
    • 

  • 容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
    • 

  • 容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持
    • 



と定義されている。また、スループットは、170GB以下では128 MB/秒、170GBを超えると160MB/秒である。


インスタンス


概要


    

  • EC2は、1500MTUに加えてジャンボフレームをサポートする。
    • 

  • ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。
    • 



インスタンスのライフサイクル


インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。


インスタンスのライフサイクル


インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う。


インスタンスの公開鍵


EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。



キーペアのインポート


インスタンスの時刻


デフォルトでは UTC（協定世界時間）時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。


vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime



インスタンスの復旧


ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。


また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。また、ネットワークや電源のメンテナンスが実施される場合もある。


インスタンスメタデータ


実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。


https://169.254.169.254/latest/meta-data/


Amazon Web Services 業務システム設計・移行ガイド

AWS CLI（1）初期設定とコマンド例

eijiコメントはこの投稿ではオフになっています。

初期設定とリージョンの設定

AWS CLIは、AWSのサービスをコマンドラインインタフェースで操作することのできるコマンド群である。AWS CLIを使う前に、aws configureコマンドを使ってアクセスキーやデフォルトリージョンの設定を行っておく。

$ aws configure
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: 
Default output format [None]:

Access Keyは、IAMで設定取得したものを指定する。Default output formatには、通常はjsonを指定する。またこれらの設定情報は、ホームディレクトリ直下の.awsディレクトリ（~/.aws/config, ~/.aws/credentials）に保存される。

なおデフォルトリージョンを設定しない場合は、各コマンドにリージョンオプション（–region ap-northeast-1など）を付けることでリージョンを指定することが可能である。EC2で自作のAMIを作成し複数のリージョンで運用する場合などは、デフォルトリージョンを指定せずに、シェルスクリプト等で都度リージョンを指定する方が設定を変更せずに汎用的に使うことが可能である。

現在のリージョンを取得する

以下のコマンドを実行することで、EC2で現在のリージョンを取得することが可能である。

$ curl -s https://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'

上記コマンドを用いることで、シェルスクリプトから動的にリージョンを指定することも可能である。

region=`curl -s https://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'`
aws dynamodb scan --table-name TABLE_NAME --region ${region} > /tmp/TABLE_NAME.json

コマンド例

s3 – AWS CLI Command Reference

S3にファイルをコピーする

aws s3 cp /SRC_DIR/FILE_NAME s3://BUCKET_NAME/DIR

バケットを生成する

aws s3 mb s3://BUCKET_NAME

dynamodb – AWS CLI Command Reference

テーブルを作成する

aws dynamodb create-table --table-name TABLE_NAME --attribute-definitions AttributeName=ATTR_NAME,AttributeType=ATTR_TYPE --key-schema AttributeName=ATTR_NAME,KeyType=HASH --provisioned-throughput ReadCapacityUnits=NUM,WriteCapacityUnits=NUM

アイテムを書き込む

  • Number型の場合でも「””」で値を囲む必要がある
aws dynamodb put-item --table-name TABLE_NAME --item '{"ATTR_NAME": {"ATTR_TYPE": "ATTR_VAL"}, "ATTR_NAME": {"ATTR_TYPE": "ATTR_VAL"}}'

指定したテーブルをスキャンする

aws dynamodb scan --table-name TABLE_NAME

kinesis – AWS CLI Command Reference

ストリームを生成する

aws kinesis create-stream --stream-name STREAM_NAME --shard-count N

ストリーム保持期間を変更する

  • Kinesis Recordは、通常24時間でデータが消去されてしまう。AWS CLIからこの保持期間を最大7日間（168時間）まで延長することができる。
aws kinesis increase-stream-retention-period  --stream-name STREAM_NAME --retention-period-hours 168

ストリームの設定内容を確認する

aws kinesis describe-stream --stream-name STREAM_NAME

シャードイテレータを取得する

SHARD_IDは、上述のdescribe-streamコマンドから取得する

aws kinesis get-shard-iterator --shard-id SHARD_ID --shard-iterator-type TRIM_HORIZON --stream-name STREAM_NAME

レコードを取得する

SHARD_ITERATORは、上述のget-shard-iteratorコマンドから取得する

aws kinesis get-records --shard-iterator SHARD_ITERATOR

Amazon Web Services 業務システム設計・移行ガイド