弊社ではAWSのインフラ・アプリケーション管理にAWS OpsWorksを利用しているプロジェクトが多くあります。OpsWorksはインフラからアプリケーションまで含めた環境構築・運用に非常に便利なのですが、ミスしてしまった事例を3つご紹介したいと思います。

インスタンスにセキュリティグループが適用されてない現象

レイヤーに属する既に起動しているインスタンスが存在する状態で、インスタンスにセキュリティグループを新規追加で適用する必要があり、OpsWorksのレイヤーのセキュリティ設定でセキュリティグループを追加しました。

これでインスタンスにセキュリティグループが適用されて完了！という気分になっていたのですが、しかし実際には既存EC2インスタンスにセキュリティグループが追加されていないことが後で判明しました。

実はこれはOpsWorksの仕様で、以下の通りドキュメントに書いてあります。

After you add a security group to a layer, AWS OpsWorks Stacks adds it to all new instances. (Note that instance-store instances that are restarted will be brought up as new instances, so they will also have the new security groups.) AWS OpsWorks Stacks does not add security groups to online instances.

http://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-basics-edit.html より。

要するに、

OpsWorksでレイヤーにセキュリティグループを追加したら、全ての新しいインスタンスに適用される。インスタンスストアインスタンスの場合は再起動で適用される。オンラインインスタンスにはセキュリティグループを適用しない。

ということで、既に起動しているインスタンスには、追加したセキュリティグループは自動的には適用されません。 (セキュリティグループを外した場合も同様です。)

したがって、OpsWorksでセキュリティグループを後から追加/削除する際には、以下のいずれかの対応が必要になります。

• 既存インスタンスについてはEC2コンソールから手動でセキュリティグループを追加/削除する。
• インスタンスストアインスタンスの場合は既存インスタンスを再起動する。

EC2コンソールからセキュリティグループの追加をする際には自動的に適用されるので、ついついOpsWorksでも自動的に適用されるのではと思い込みがちになりますが、要注意です。

Railsのログローテーションがなんだか変現象

Railsの config/environments/production.rb などでRailsのログのローテーション設定を行っていたところ、実際のログのローテーションの動きが何だか変という現象が発生しました。
原因はOpsWorksのRailsレイヤーで自動的にlogrotateによるログのローテーションが動作し、Railsのログファイルに2種類のローテーション機能が適用されていたことでした。
OpsWorksのデフォルトlogrotate設定には要注意です。

間違ってインスタンス削除しちゃった現象

インスタンスが2台あるはずのレイヤーで、ふと見てみたらいつの間にか1台しかインスタンスがないという現象が発生しました。
CloudTrailで　TerminateInstances イベントを探したところ、確かにOpsWorksから該当インスタンスを削除していた履歴がありました。
その時間帯は、同じアカウントの別Stackを構築していた時間帯で、おそらく別のStackの方のインスタンスを消してしまったものと思われます。
OpsWorksは気軽にインスタンスの削除・作成ができるため、誤ったStackを触っていないか、操作には特に注意が必要です。また、CloudTrailを見ても、削除したユーザは OpsWorks と表示されて実際に操作した人が出ないことにも注意が必要です。

以上、3つの失敗例をご紹介しました。この他にもライフサイクルイベントまわりなど、ちょこちょことハマりポイントはあるので皆さまお気をつけください。
それではHappy OpsWorking!

shimo