うえきのブログ

妙高市に住んでいるサーバエンジニアのブログです

EC2へのログインアカウントの制約にみる今後のサーバ運用の自動化の流れについて

最初に結論

  • AWS EC2インスタンスでは複数アカウントによるログインが行いにくくなっている
  • 人による作業は環境に差異が発生しやすくなるから
  • Capistrano,Chef,CloudFormation,OpsWorksなどを使って自動化しましょう

はじめに

いつもは普段使っているパソコンでEC2のインスタンスにsshでログインしていろいろと作業をしていたのですが、ある日事情により人のパソコンを借りて作業の続きをすることがありました。ところがいざログインしようとした時、認証につかう秘密鍵ファイル(*.pem)が手元にないためログインできないことに気付きました。pemファイルの再ダウンロードはできないので別の秘密鍵を作成してインスタンスを作り直す必要がありました。

ちょっと出先で作業したい、といった場合の備えどうしておけばいいのでしょうか?

これまでのUnixサーバ運用的な考えでは

どこでも作業ができるようにするためには以下いずれかの対策が思いつきます。

  1. 秘密鍵のファイルをDropboxなどに置いて共有しておく
  2. EC2インスタンスで独自のアカウント管理を行い秘密鍵がなくてもログインできるようにしておく

1つ目の案は簡単で1人でやるには十分なのです。が、企業での利用など複数のサーバ管理者がいる場合にはすべての人で秘密鍵を共有するのでしょうか? セキュリティの問題からちょっと考えにくいですね。ならば2でいうアカウント管理を独自に管理していこう、となればいいのでしょうが、EC2インスタンスが10台とか100台規模になってきた場合に管理が大変になります。

これまでUnixを管理してきた人ならNISを利用したアカウントの一元管理を思いつくでしょう。ところがAWSではNISサービスを提供していないようです。なぜでしょう? EC2で独自NISサーバを構築すればいいのでしょうか?

AWSの機能不足と考えることもできますが、すでに多くのユーザに利用されているサービスです、ここは需要がないからととらえるのが妥当でしょう。つまりEC2に複数アカウントがなくても困らない運用する、これまでのUnix管理の常識にとらわれない、AWSの富豪的サーバ利用にあったやり方に考え方を変えてみる必要がある、と捉えてみることにしましょう。

補足

ちなみに当初IAM(Identity and Account Management)を使ってユーザ・グループを作成すればEC2サーバへのログインが管理できるのではないかと思い調べたのですが、IAMのFAQに書いてある通りできないそうです。

AWS Identity and Access Management FAQs
Q: ユーザーは、AWS ユーザー名およびパスワードを使用して、EC2 インスタンスに SSH で接続できますか？


いいえ。IAM で作成されたユーザーのセキュリティ証明書は、EC2 のお客様のインスタンスには反映されません。お客様の EC2 インスタンスの認証は、お客様の責任下にあります。

AWSによるこれからサーバ運用

そもそもなぜログインが必要かというとサーバ上での作業が必要だからです。パッケージのインストールや設定ファイルの変更、アプリケーションのデプロイなどがこれにあたりますが、いままでこれらは人手による作業でした。

サービスが大きくなり負荷をさばくために、EC2インスタンスを増やしてスケールアウトさせる方式を採用したとしましょう。このとき重要なのは「各サーバが同じ設定であること」です。あるサーバで動くアプリが環境の違いのため別のサーバで動かず、苦労をしたという経験を、開発者なら何度かあるのではないでしょうか? サーバごとに微妙に設定が違ってしまうのは、人手で作業をしているため、サーバごとに設定漏れが発生してしまうためです。

それならばいっそsshによるログインを制限してはどうでしょう?というのがAWSでのアプローチだと思われます。人手でサーバ設定する機会を減らすことで、スケールアウト時に発生しうる問題を排除するわけです。

手作業による設定やデプロイをする代わりに、最近ではCapistranoやChefといったソフトを使い、これらの作業を自動化する流れが主流になりつつあります。EC2インスタンスを作成した後は、事前に決めた設定に従って自動的にサーバ環境を構築することで、サーバ間の差異がなくなるわけです。


AWSではCloudFormationというAWSの各種サービスと設定を組み合わせたテンプレートを作成できるインフラ構築サービスや、OpsWorksというアプリケーションデプロイのテンプレートサービスも提供しています。AWSを利用することを前提とした今後の運用方法は以下のような流れになるのでしょう。

  1. 試験的なソフト導入や設定修正は個々人ごとにEC2インスタンスを作成してそこで行う
  2. 設定が決まったらChefのレシピに反映する
  3. スケールアウト時にはChefを実行することでサーバに設定を適用する


以上、これからはサーバ運用についても人手から自動化へ考えを変えていく必要があるね、というお話でした。

補足

環境構築の自動化はなにもAWSを利用するときしかメリットがないわけではなありません。アプリケーション開発時には本番環境とは別に、開発環境や本番導入前の検証環境をもっている場合があると思います。もしかしたら仮想化技術を使って個人ごとに開発環境をもっているかもしれません。これら複数の環境を本番環境と一緒にする際にも環境構築の自動化ツールは有用だと思われます。