何かしらのAMIを作る時、本来使うインスタンスよりも高級なインスタンスを使って、
作成するとコンパイルも早いし便利ですよね。
でも、高級インスタンスを使うと時間は短くなったとしても、お高かったりします。
そんな時にはSpotインスタンス。
Spotインスタンスを使ってAMIを作れば安いし、速度的にも快適なことこの上ないです。
Spotインスタンスならc3.xlargeのお値段でc3.8xlargeが使えます。
しかし、SpotインスタンスでAMIを作る時に気にしなくては行けないのは、途中で落ちてしまう事。
(私はSpotインスタンスは最低価格でしか入札しないんです。)
せっかく作ってたのに、途中で落ちてしまっては元も子もありません。
今回はCloudAutomatorを使って自動的にAMIを作り続ける事をやってみます。
まずはSQSでQueueを作ります。
そしてCloudAutomatorでSQSトリガーのジョブを作ります。
こんな感じで作りました。
ここで大事なのは、トリガーになるQueueと成功時に送るQueueを同じにすることです。
これによって、永久ループが完成します。
永久ループが完成するのは良いのですが、このままではCreateImageのAPIの戻りが成功の場合にジョブは成功とみなされ、成功しましたよのMessageがSQSに投げられてしまいます。
そうすると、またSQSトリガーなので、ジョブが実行されてしまうのですが、AMIを作っている途中にもう一度、Create Imageが呼ばれるとAPIは失敗します。=>このジョブは失敗します。
これを回避するために、2つの方法を取ります。どちらか一方でも良いですし、両方やっても良いです。
1.QueueにDelivery Derayを設定する。
2.失敗時にも同じQueueにメッセージを送る。
1についてはほとんどデメリットはありませんが、DeliveryDerayで設定した時間より短い時間でのAMI作成が出来ません。ただ、そんなに高頻度で作っても仕方ないと思うので、デメリットとは言えないかもしれません。
2については、ジョブを大量に消費してしまう可能性があります。プランによっては致命傷です。
ということで、1と2の両方を組合せて使う事でいい感じにAMIを作る事が出来るはずです。
世代管理の数もうまいこと調整して、環境構築の際に変な事してしまっても戻すとか使っても良いと思います。
ちょっと贅沢にCloudAutomatorを使うとこんな事が出来ました。
いちどこのジョブを作っておけば、インスタンスを変更したり、構築中なタグを用意したりすれば、ずっと使えるジョブになります。
運用ではないですが、準備段階でも使い道がありそうなCloudAutomatorでした。
