はじめに
ある案件で、社内のユーザーが使用する数台のサーバを提供しているものがありまして
その案件のテストサーバで先ごろ特殊な要件が出てきました。（以降、G案件と記載します）
Global IPアドレス変更に関するプログラム側への影響をテストをしたい
具体的には、期間限定で定期的にGlobal IPを変更することが要件になります。
G案件はAmazon Lightsail（2016年末から日本リージョンに提供されたVPSサービス）で構築されています。
EC2であればLambdaで色々手を入れられるので、こうした細工は問題なくできそうに思いましたが、
AWS SDKがLightsailに対応しているか分からなかったので調査するところから始めました。
結果としては、SDKもLightsailに必要十分に対応していたので、必要なことはすべて実装できて
な結末となりました。
ここでは、ハマった点も含めハンズオン形式で紹介してみようと思います。
どうやって実装する？
Lightsailでは静的なGlobal IPアドレスがアカウントあたり5つしか確保できない仕様があるので、
エフェメラルで設計するのが通常です。（むしろこの仕様が元で今回の要望が出てきたわけです！）
つまり、サーバを再起動してもGlobal IPアドレスは変わりませんが、サーバを一度停止させると
IPアドレスが解放され次回の起動時に別のGlobal IPアドレスが割当てされることになります。
よって、変更時にサーバが短時間ダウンすることを許容するとして、
- 影響のない時間に各サーバを停止させる
- 数分後に各サーバを起動させる
（必要なサービス群などは自動で起動するよう、あらかじめ仕込んでおく）
というだけの簡単な処理で実装することができます。
本件ではユーザーもサーバログインが必要なので、変更期間中もGlobal IPアドレスを確認できるように、
Lightsailの画面で情報が確認できるだけの制限IAMアカウントも用意しておくことにします。
対象とシナリオ
- 対象
G案件のテストサーバということで下記の名前のサーバ5台をLightsailインスタンスで用意します。
test-g01
test-g02
test-g03
test-g04
test-g05
- シナリオ
各サーバは週1回、下記の日時にて停止/起動を行うことで運用することとします。
停止曜時 ： 日曜日 22:55
起動曜時 ： 日曜日 23:00
Lambdaファンクション設定①（インスタンス起動）
AWSのアカウントにサインインし、[サービス] > [Lamda] > [関数] と開きます。
[関数の作成] をクリックして今回のファンクションを作成開始します。
まず、ファンクションが使用するロールを定義します。
[ロール] > [カスタムロールの作成] をクリックします。
自動的にIAMロールを作成する画面に飛ぶので、ロール名をals-instances-opと入力したうえで
[ポリシードキュメントを表示] > [編集] とクリックして、下記のjsonを記述します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"lightsail:*"
],
"Resource" : "*"
}
]
}
lightsailのActionはもう少し細かく制御してもいい気もしますが、Lambdaファンクション以外では
使用しないロールなので、セキュリティも特に問題ないでしょう。
入力ができたら [許可] を押してロールを作成します。
元の画面に戻ったら、以下のように設定して [関数の作成] をクリックします。
| Factor | Value |
|---|---|
| 名前 | als-instances-start |
| ランタイム | Python 2.7 |
| ロール | 既存のロールを選択 |
| 既存のロール | als-instances-op |
作成された関数の画面に遷移したら、【関数コード】の項目を探して早速コードを書いていきましょう。
Lambdaでは現在さまざまな言語がサポートされるようになりましたが、
実装したいことに応じて特性に合わせたものを選択すると良いと思います。
今回は純粋なインフラ運用なので、計算処理などに向いたPythonが良いのではないでしょうか。
Python自体シンプルに書けるのと、やりたいことも単純なのでとても短いコードでできます
まず、ファイル名はals-instances-start.pyとして、
ハンドラ名をals-instances-start.lambda_handlerに、そして以下のようなコードを書きます。
import boto3
lightsail = boto3.client('lightsail')
instances = ['test-g01', 'test-g02', 'test-g03', 'test-g04', 'test-g05']
### lambda_handler.
def lambda_handler(event, context):
start_instance(instances)
### definition of 'start_instance' function.
def start_instance(lists):
for name in lists:
log = lightsail.start_instance(
instanceName=name
)
print 'started instance: ' + name
print log
続けて、万一台数が増えた場合に実行時間が延びるといけないので「タイムアウト」は少し延ばしておきます。
とりあえず8秒くらいならまず大丈夫でしょうか。
そのまま [保存] して作成したファンクションを一旦保存します。
保存ができたら、[テスト] をして実際にインスタンスが起動できることを確認しましょう。
※ 予め全てのインスタンスは落としておいてください。
テストをするためには、テストイベントが必要なので自動で作成画面が立ち上がります。
ここではイベント名をtest01として（何でもいいです）、下部の [保存] をクリックします。
作成した関数の画面に戻ったら、[テスト] をクリックして停止インスタンスが起動することを確認して下さい。
次にこのファンクションを実行するトリガーを設定します。
今回は定時起動なので、cronのスケジュール形式で設定します。
[CloudWatch Events]をクリックします。
【トリガーの設定】から以下のような設定をして、[追加] > [保存] と進めて設定を上書きします。
| Factor | Value |
|---|---|
| ルール | 新規ルールの作成 |
| ルール名 | rule-als-instances-start |
| ルールタイプ | スケジュール式 |
| スケジュール式 | cron(00 14 ? * SUN *) |
| トリガーの有効化 | ✔︎ |
保存された後に以下のようなトリガーが追加されていることを確認します。
これで、サーバ起動の設定は完了です。
なお、スケジュール式では時刻をUTCで入力しますので注意が必要です。
詳しい仕様については下記で紹介されています。
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html
Lambdaファンクション設定②（インスタンス停止）
基本的には起動と同様の設定なので、詳しい設定は割愛してコードのみを記載します。
関数の名前をals-instances-stopとして、各種の名前もそれに合わせて変えますが、
IAMロールは新しく作成せずals-instances-opを共用します。
import boto3
lightsail = boto3.client('lightsail')
instances = ['test-g01', 'test-g02', 'test-g03', 'test-g04', 'test-g05']
### lambda_handler.
def lambda_handler(event, context):
stop_instance(instances)
### definition of 'stop_instance' function.
def stop_instance(lists):
for name in lists:
log = lightsail.stop_instance(
instanceName=name,
force=False
)
print 'stopped instance: ' + name
print log
起動とほぼ同様の内容ですが、強制停止をするかどうかで以下の定義を1行追加しています。
force=False
あと当然ですが、CloudWatch Events のcronスケジュール式の設定値も以下のようになります。
cron(55 13 ? * SUN *)
ユーザーが変更後のGlobal IPアドレスを確認するためのIAM
今回は「lightsail_general」というIAMユーザーを作成して、Policy Generatorで
Lightsailの読み取り権限のみを持つポリシーを生成しました。
本筋からずれるので、ここではユーザー設定の画面イメージと生成されたjsonだけ紹介します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1513765439000",
"Effect": "Allow",
"Action": [
"lightsail:GetActiveNames",
"lightsail:GetBlueprints",
"lightsail:GetBundles",
"lightsail:GetDomain",
"lightsail:GetDomains",
"lightsail:GetInstance",
"lightsail:GetInstanceAccessDetails",
"lightsail:GetInstanceMetricData",
"lightsail:GetInstancePortStates",
"lightsail:GetInstanceSnapshot",
"lightsail:GetInstanceSnapshots",
"lightsail:GetInstanceState",
"lightsail:GetInstances",
"lightsail:GetKeyPair",
"lightsail:GetKeyPairs",
"lightsail:GetOperation",
"lightsail:GetOperations",
"lightsail:GetOperationsForResource",
"lightsail:GetRegions",
"lightsail:GetStaticIp",
"lightsail:GetStaticIps"
],
"Resource": [
"*"
]
}
]
}
ハマったところ
1. ドキュメント探しに時間がかかった
Lambda経験が浅かったので、SDKのドキュメントが見つけられず地味に苦労しました。
他の方が同じ轍を踏まないよう、URLを書いておきます。（JSで書くことも検討したので併せて）
-
Python
https://boto3.readthedocs.io/en/latest/reference/services/lightsail.html -
JS
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Lightsail.html
2. LightsailのIAMの記載方法が特殊
IAMの権限が足りず、Lambdaファンクションのテスト実行がなかなか通らず苦労しました。
IAMでは、"Resource"で許可するリソースのカテゴリやリージョンまで絞るのがセオリーだと思います。
しかし、Lightsailコントロールの全権限を与えるユーザー定義として下記のような制御では権限が足りず
Lightsailのダッシュボード画面が403エラーで表示できませんでした。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lightsail:*"
],
"Resource": [
"arn:aws:lightsail:::*"
]
}
]
}
原因までは探りませんでしたが、下記のようにすると大丈夫でした。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lightsail:*"
],
"Resource" : "*"
}
]
}
おそらくLightsailは、何らか他のAmazonリソースに依存しているのだと思います。
おわりに
いかがでしたでしょうか。
Lightsail運用については、現時点（2017年末）ではさほど多くの情報を見つけることができませんでしたが、
EC2に近いようなことはだいたい実装できるのではないかという所感でした。
簡便に使用を始められることと、安さや課金体系の分かりやすさはLightsailの大きな魅力だと思います。
ほどほどの運用も敷けそうなので、スモールサービスなどに検討してみてはいかがでしょうか。