[Osaka/Yokohama] Looking for infrastructure/server side engineers!

[Osaka/Yokohama] Looking for infrastructure/server side engineers!

[Deployed by over 500 companies] AWS construction, operation, maintenance, and monitoring services

[Deployed by over 500 companies] AWS construction, operation, maintenance, and monitoring services

[Successor to CentOS] AlmaLinux OS server construction/migration service

[Successor to CentOS] AlmaLinux OS server construction/migration service

[For WordPress only] Cloud server “Web Speed”

[For WordPress only] Cloud server “Web Speed”

[Cheap] Website security automatic diagnosis “Quick Scanner”

[Cheap] Website security automatic diagnosis “Quick Scanner”

[Low cost] Wasabi object storage construction and operation service

[Low cost] Wasabi object storage construction and operation service

[Reservation system development] EDISONE customization development service

[Reservation system development] EDISONE customization development service

[Registration of 100 URLs is 0 yen] Website monitoring service “Appmill”

[Registration of 100 URLs is 0 yen] Website monitoring service “Appmill”

[Compatible with over 200 countries] Global eSIM “beSIM”

[Compatible with over 200 countries] Global eSIM “beSIM”

[Compatible with Chinese corporations] Chinese cloud / server construction, operation and maintenance

[Compatible with Chinese corporations] Chinese cloud / server construction, operation and maintenance

[YouTube] Beyond official channel “Biyomaru Channel”

[YouTube] Beyond official channel “Biyomaru Channel”

【AWS】オートスケールをAWS CLIを使って手早く作成!

こんにちは。
開発チームのワイルド担当、まんだいです。

AWSでオートスケールを利用する場合、起動設定を作ったり、オートスケールグループを作ったり、開発中も運用が始まってからも実施する事は多いと思います。
AWSコンソールから毎回ポチポチやるのは時間も掛かりますし、何度もやっていると漏れも出てきます。

AWSには、AWS CLIというコマンドラインツールがあるので、一度それを作ってしまえば、安心安全確実に素早く作ってしまう事ができます。

何番煎じか分からないくらいこの手のコンテンツはたくさんありますが、それはそれ。これはこれ。ということで、早速行きましょう!

 

オートスケールの起動設定とオートスケールグループ

オートスケールは、まずテンプレートになる起動設定を作る必要があります。
この際に、AMIの登録をする必要がありますが、一度作った起動設定は変更することが出来ません。
つまり、AMIに必要なコマンドを入れ忘れたり、ユーザーデータの変更、環境設定の変更があったりした場合は、起動設定の作り直しになります。

起動設定が変わると、オートスケールグループも、新しい起動設定から作り直す事になりますので、この辺りも一気にやりたいところですね。

awsから始まるコマンドは、Amazonが提供している、Amazon Linuxなら、AMIからインスタンスを立ち上げた時点でインストールされていますが、他のAMIやローカル環境には、インストールしないといけません。

AWS CLI のインストールと設定 - Amazon Kinesis Streamsに詳しく載っていますので、各OSにあったインストール方法でインストールします。

 

オートスケールの起動設定を作成する、「aws autoscaling create-launch-configuration」コマンド

オートスケールの起動設定を作成するには、「aws autoscaling create-launch-configuration」コマンドを利用します。
使い方がよくわからない、どんなオプションがあるか分からない場合は、「aws autoscaling create-launch-configuration help」でオプションの一覧が確認できます(英語ですが)。

必須のオプションもありますので、基本形は以下のようになります。

aws autoscaling create-launch-configuration \
  --launch-configuration-name [起動設定の名前] \
  --image-id [使用するAMIのAMI ID] \
  --security-groups [適用するセキュリティグループを列挙] \
  --instance-type [起動するEC2インスタンスのタイプ]

上のコマンドで、注意すべき点は特に無いですが、セキュリティグループの設定をする際、「sg-xxxxxxx」を複数個スペース区切りで列挙する必要があります。
bashでシェルスクリプトを組む場合は、以下のようにする事ができます。

sg=(
  "sg-xxxxxxx1"
  "sg-xxxxxxx2"
  "sg-xxxxxxx3"
)

aws autoscaling create-launch-configuration \
  --launch-configuration-name hogehoge \
  --image-id ami-xxxxxxxx \
  --security-groups ${sg[@]} \
  --instance-type t2.micro

セキュリティグループは複数登録する事が多いので、配列化しておけば、展開するだけなので管理が簡単にできます。
multi-azで環境構築する事が多いのでAZも同じように、以下のように列挙しておけばいいかと思います。

az=(
  "ap-northeast-1c"
  "ap-northeast-1a"
)

 

起動設定にユーザーデータの指定する「--user-data」オプション

オートスケールでEC2インスタンスを立ち上げる際、ユーザーデータを使って初期設定を行うケースは多いと思います。
ユーザーデータは起動設定を作成する際、登録するので、こちらも変更があった場合、起動設定の作り直しになりますので、想定通り動くか何度か試す回数分、起動設定を作り直す事を考えると、やはり自動化してしまった方がよいのではないかと思います。

AWS CLIから起動設定にユーザーデータを登録する場合は、上記の基本形に加え、「--user-data」オプションでファイルの指定が必要です。

aws autoscaling create-launch-configuration \
  --launch-configuration-name [起動設定の名前] \
  --image-id [使用するAMIのAMI ID] \
  --security-groups [適用するセキュリティグループを列挙] \
  --instance-type [起動するEC2インスタンスのタイプ] \
  --user-data "file:///path/to/user-data.sh"

ユーザーデータはローカルファイルを指定します。
「file://」の後ろに「/path/to/user-data.sh」のように絶対パスを付ければ、AWS CLIを実行するマシンの該当パスからファイルを取得しようとします。

「file://user-data.sh」のようにパスをスラッシュなし(スラッシュ2つ)で指定した場合は、カレントディレクトリから取得しようとします。

なお、ヘルプを読めばわかる事なのですが、AWSコンソールからはbase64で登録するオプションがあるのですが、cliからはファイルパスの指定で済みます。

 

オートスケールグループを作成する、「aws autoscaling create-auto-scaling-group」コマンド

起動設定の作成が終わったら、オートスケールグループを作成します。
起動設定を以下のような形で作成したとすると

aws autoscaling create-launch-configuration \
  --launch-configuration-name my-test-lc \
  --image-id ami-123123 \
  --security-groups sg-xyzxyz \
  --instance-type t2.large

オートスケールグループの作成コマンドは以下のようになります。

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-test-asg \
  --launch-configuration-name  my-test-lc \
  --min-size 2 \
  --max-size 4 \
  --desired-capacity 2 \
  --target-group-arns "arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxxxx:targetgroup/hogehoge-group/1234567890abcdef"
  --availability-zones "ap-northeast-1c" "ap-northeast-1a" \
  --vpc-zone-identifier "subnet-aaaaaaaa,subnet-bbbbbbbb"

上記のコマンドだと、

  • オートスケールグループの名前は「my-test-asg」
  • オートスケールグループで使用する起動設定名は「my-test-lc」
  • 最小サイズは2台
  • 最大サイズは4台
  • 希望するインスタンス数は2台
  • ターゲットグループのARNは「arn:aws:elasticloadbalancing:...(以下略)」
  • 使用するアベイラビリティゾーンは「ap-northeast-1c」と「ap-northeast-1a」
  • VPCサブネットは「subnet-aaaaaaaa」と「subnet-bbbbbbbb」

という事になります。
VPCの設定だけ、何故かカンマ区切りというややこしい事になっていますが、これはこういうものなので覚えるしかないですね。

また、今回はアベイラビリティゾーンを2つ選択しているので、初期の2台はそれぞれ別のアベイラビリティゾーンに収容されるはずです。

 

設定してみて

AWSコンソールからだと、ポチポチと色んな項目を選んで、チェック忘れでうまく動かなかったり、煩わしい気持ちになりますが、一度設定すると、基本的には同じものができるはずなので、思う存分AMIを作り直す事もできますし、ユーザーデータの検証をすることもできます。

正直、使わないと時間の無駄くらいに思っても良いんじゃないかと思うくらいです。

この辺りの処理をSQSなどと連携して自動化する事もできますが、あまり手の込んだ事をすると目的を見失ってしまう事もあるので、要注意ですね。

以上です。

この記事がお役に立てば【 いいね 】のご協力をお願いいたします!
0
読み込み中...
0 票, 平均: 0.00 / 10
2,737
X facebook はてなブックマーク pocket
[2024.6.30 CentOS support ended] CentOS server migration solution

[2024.6.30 CentOS support ended] CentOS server migration solution

[2025.6.30 Amazon Linux 2 support ended] Amazon Linux server migration solution

[2025.6.30 Amazon Linux 2 support ended] Amazon Linux server migration solution

[Osaka/Yokohama] Actively recruiting infrastructure engineers and server side engineers!

[Osaka/Yokohama] Actively recruiting infrastructure engineers and server side engineers!

The person who wrote this article

About the author

Yoichi Bandai

My main job is developing web APIs for social games, but I'm also fortunate to be able to do a lot of other work, including marketing.
Furthermore, my portrait rights in Beyond are treated as CC0 by him.