Basics of EC2 (etbe - Russell Coker)
元記事：http://etbe.coker.com.au/2008/11/04/basics-of-ec2/ （2008/11/04)
以前、Amazon EC2の管理ツールのパッケージについて書いたことがあった。（1）
I have previously written about my work packaging the tools to manage Amazon EC2 [1].
EC2の管理でまずすることは、ログインして認証鍵を作ることである。（自作の認証鍵をアップロードすることも可能だが、EC2のアカウントを複数持っていて、鍵を共通にしたいとき以外はそんなことをしないだろう）。作成された認証データのうち、X509の秘密鍵（今、仮にpk-X.pemというファイル名とする）と公開鍵(cert-X.pemと名づける)をダウンロードして手元に置く。私がDebian用に作ったEC2のAPIパッケージでは、これらのファイルは~/.ec2もしくは /etc/ec2に置かれる（前者のほうが優先される）。
First you need to login and create a certificate (you can upload your own certificate - but this is probably only beneficial if you have two EC2 accounts and want to use the same certificate for both). Download the X509 private key file (named pk-X.pem) and the public key (named cert-X.pem). My Debian package of the EC2 API tools will look for the key files in the ~/.ec2 and /etc/ec2 directories and will take the first one it finds by default.
この認証データの替わりになにかを使いたいとき（私のパッケージを使わずに作業する場合など）は、EC2_PRIVATE_KEYとEC2_CERTの環境変数に、適宜秘密鍵と公開鍵のパスを指定する。
To override the certificate (when using my Debian package) or to just have it work when using the code without my package you set the variables EC2_PRIVATE_KEY and EC2_CERT.
このAmazonのサイトのページ（2）では、SSHのクライアントソフトウェアとRSA鍵の設定方法について書かれている。ここではもっとも重要なことだけを書こう。
This Amazon page describes some of the basics of setting up the client software and RSA keys [2]. I will describe some of the most important things now:
"ec2-add-keypair gsg-keypar > id_rsa-gsg-keypair" というコマンドで、EC2のサーバにログインするための秘密鍵と公開鍵のペアが作成できる。公開鍵はAmazon EC2上に送られ、秘密鍵はSSH接続のクライアントでrootとしてサーバにログインするために保存される。作成した鍵でサーバのインスタンス（実体）を生成するには、"-k gsg-keypair"オプションを使う。従って、鍵を共有するインスタンスを作成する場合、作業ディレクトリも共有することになる。
註：gsg-keypairというオプションの引数は別の文字列でもかまわない。たとえば、それぞれ別のEC2インスタンスが別の人によって管理されていて、ビジネスにインパクトが有る場合などは、そうしたほうがいいかもしれない。しかし、大抵の場合は、鍵を共通にしていて問題は無いと思われる。
The command “ec2-add-keypair gsg-keypair > id_rsa-gsg-keypair” creates a new keypair for logging in to an EC2 instance. The public key goes to amazon and the private key can be used by any ssh client to login as root when you creat an instance. To create an instance with that key you use the “-k gsg-keypair” option, so it seems a requirement to use the same working directory for creating all instances. Note that gsg-keypair could be replaced by any other string, if you are doing something really serious with EC2 you might use one account to create instances that are run by different people with different keys. But for most people I think that a single key is all that is required. Strangely they don’t provide a way of getting access to the public key, you have to create an instance and then copy the /root/.ssh/authorized_keys file for that.
このAmazonのページ(3)には、サンプルのサーバイメージをセットアップする方法が書いてある。
This Amazon page describes how to set up sample images [3].
ここでまず書かれているのは、
ただし、Amazonとしては、彼らのイメージを使ってもらうことを想定しているわけではないようだ。一応、386のCPU(32bit版)用のイメージとしては、Fedora Coreの４と８、そして、バージョンが明記されていないものが３つ。AMDの64bit版のOS用のイメージはFedora Core6と8がある。もし、本当に使ってもらう気があるのなら、CentOS版（もしくは他のRHEL互換OS)やDebian版があってしかるべきだろう。こういう状況はセキュリティの面からは望ましくない、ということは以前も書いた(4)が、とにかく、Amazonが提供している古いＯＳのイメージは、テスト用途以外では使わないこと。
The first thing it describes is the command ec2-describe-images -o self -o amazon which gives a list of all images owned by yourself and all public images owned by Amazon. It’s fairly clear that Amazon doesn’t expect you to use their images. The i386 OS images that they have available are Fedora Core 4 (four configurations with two versions of each) and Fedora 8 (a single configuration with two versions) as well as three other demo images that don’t indicate the version. The AMD64 OS images that they have available are Fedora Core 6 and Fedora Core 8. Obviously if they wanted customers to use their own images (which seems like a really good idea to me) they would provide images of CentOS (or one of the other recompiles of RHEL) and Debian. I have written about why I think that this is a bad idea for security [4], please make sure that you don’t use the ancient Amazon images for anything other than testing!
テスト用ならば、Amazonが用意した386版を使うと良いだろう。一番安価なインスタンスでも動作するからだ。
To test choose an i386 image from Amazon’s list, i386 is best for testing because it allows the cheapest instances (currently $0.10 per hour).
インスタンスを起動する前に、SSHでアクセスできるように、次のコマンドを実行しておく（sshの使う22番のポートがファイアウォールを通過するように設定する）
ec2-authorize default -p 22
註：このコマンドによって、サーバインスタンスのポート22番は、インターネットの何処からでもアクセスできるようになってしまう。これを避けるために、アクセスできるIPアドレスの範囲を設定するオプションもあるが、ここはとにかくサーバを起動させることに集中しよう。もちろん、そんな風にして作った第1作のサーバインスタンスは使いたくないだろうけれど、安全で信頼性の高いインスタンスを作るには、まず経験が大事なのだ。
実際、サーバを終了すれば、ディスク領域は（まだＳ３のデータ保存サービスを利用していないので）消去されてまっさらの状態に戻ってしまうし、特に重要なデータを保存しないうちはそれほどセキュリティに神経質になる必要は無いだろう。
Before launching an instance allow ssh access to it with the command “ec2-authorize default -p 22“. Note that this command permits access for the entire world. There are options to limit access to certain IP address ranges, but at this stage it’s best to focus on getting something working. Of course you don’t want to actually use your first attempt at creating an instance, I think that setting up an instance to run in a secure and reliable manner would require many attempts and tests. As all the storage of the instance is wiped when it terminates (as we aren’t using S3 yet) and you won’t have any secret data online security doesn’t need to be the highest priority.
例えば、インスタンスを起動するコマンドは次のようになる。
A sample command to run an instance is “ec2-run-instances ami-2b5fba42 -k gsg-keypair” where ami-2b5fba42 is a public Fedora 8 image available at this moment. This will give output similar to the following:
INSTANCEで始まる行のパラメータは、インスタンスのシリアル番号だ。この番号を使って
というコマンドを実行すれば、インスタンスの情報が得られる。すでに起動していれば（起動のリクエストを出して数分経ってから）次のような結果になる。
The parameter after the word INSTANCE is the serial number of the instance. The command “ec2-describe-instances i-0c999999” will provide information on the instance, once it is running (which may be a few minutes after you request it) you will see output such as the following:
次のようにSSHを実行すると、rootユーザとしてログインできる。”10-11-12-13”という部分は、サーバのグローバルアドレスを示している。このアドレスは例であって実在しないので10.11.12.13というアドレスにアクセスしても無駄だが、実際には、Amazonが割り当てたアドレスになる。仮のアドレスにしたのは、ロボットなどのソフトウェアでアクセスされるのを避けるためだ。
The command “ssh -i id_rsa-gsg-keypair root@ec2-10-11-12-13.compute-1.amazonaws.com” will then grant you root access. The part of the name such as 10-11-12-13 is the public IP address. Naturally you won’t see 10.11.12.13, it will instead be public addresses in the Amazon range - I replaced the addresses to avoid driving bots to their site.
domU-12-34-56-78-9a-bc.compute-1.internalというサーバ名は、Amazon内部のDNSで通用するもので、プライベートIPアドレスが、このサーバインスタンスに割り当てられていることを示す。（10.0.0.0/8の領域だ）サーバインスタンスには、グローバルアドレスは割り振られておらず、NAT接続する必要がある。NAT接続しても、HTTPやSMTPなど、大抵のサーバを運用するには問題ない。しかし、FTPやUDPを利用したサービスについては問題だ。ところで、ホスト名の12-34-56-78-9a-bcの部分は、eth0デバイスのMACアドレスを示す。
The name domU-12-34-56-78-9a-bc.compute-1.internal is listed in Amazon’s internal DNS and returns the private IP address (in the 10.0.0.0/8 range) which is used for the instance. The instance has no public IP address, all connections (both inbound and outbound) run through some sort of NAT. This shouldn’t be a problem for HTTP, SMTP, and most protocols that are suitable for running on such a service. But for FTP or UDP based services it might be a problem. The part of the name such as12-34-56-78-9a-bc is the MAC address of the eth0 device.
サーバを停止するには、rootユーザでshutdownもしくはhaltコマンドを実行する。または、ec2-terminate-instancesコマンドも使える。その場合、引数にインスタンスＩＤを指定する。最も望ましいのは、サーバの状態を記録・保存して、実行中のサービスを完全に終了するまでの時間をとるようなスクリプトをまず実行してから、ec2-terminate-instancesを実行することだろう。
To halt a service you can run shutdown or halt as root in the instance, or run the ec2-terminate-instances command and give it the instance ID that you want to terminate. It seems to me that the best way of terminating an instance would be to run a script that produces a summary of whatver the instance did (you might not want to preserve all the log data, but some summary information would be useful), and give all operations that are in progress time to stop before running halt. A script could run on the management system to launch such an orderly shutdown script on the instance and then uses ec2-terminate-instances if the instance does not terminate quickly enough.
もう少したったら、EC2についてもっと書く予定だ。サーバの構成をダイナミックに変更する方法や、ダイナミックDNSの利用、そしてS3の利用法などだ。
In the near future I will document many aspects of using EC2. This will include dynamic configuration of the host, dynamic DNS, and S3 storage among other things.
参照：
元記事：http://etbe.coker.com.au/2008/11/04/basics-of-ec2/ （2008/11/04)
以前、Amazon EC2の管理ツールのパッケージについて書いたことがあった。（1）
I have previously written about my work packaging the tools to manage Amazon EC2 [1].
EC2の管理でまずすることは、ログインして認証鍵を作ることである。（自作の認証鍵をアップロードすることも可能だが、EC2のアカウントを複数持っていて、鍵を共通にしたいとき以外はそんなことをしないだろう）。作成された認証データのうち、X509の秘密鍵（今、仮にpk-X.pemというファイル名とする）と公開鍵(cert-X.pemと名づける)をダウンロードして手元に置く。私がDebian用に作ったEC2のAPIパッケージでは、これらのファイルは~/.ec2もしくは /etc/ec2に置かれる（前者のほうが優先される）。
First you need to login and create a certificate (you can upload your own certificate - but this is probably only beneficial if you have two EC2 accounts and want to use the same certificate for both). Download the X509 private key file (named pk-X.pem) and the public key (named cert-X.pem). My Debian package of the EC2 API tools will look for the key files in the ~/.ec2 and /etc/ec2 directories and will take the first one it finds by default.
この認証データの替わりになにかを使いたいとき（私のパッケージを使わずに作業する場合など）は、EC2_PRIVATE_KEYとEC2_CERTの環境変数に、適宜秘密鍵と公開鍵のパスを指定する。
To override the certificate (when using my Debian package) or to just have it work when using the code without my package you set the variables EC2_PRIVATE_KEY and EC2_CERT.
このAmazonのサイトのページ（2）では、SSHのクライアントソフトウェアとRSA鍵の設定方法について書かれている。ここではもっとも重要なことだけを書こう。
This Amazon page describes some of the basics of setting up the client software and RSA keys [2]. I will describe some of the most important things now:
"ec2-add-keypair gsg-keypar > id_rsa-gsg-keypair" というコマンドで、EC2のサーバにログインするための秘密鍵と公開鍵のペアが作成できる。公開鍵はAmazon EC2上に送られ、秘密鍵はSSH接続のクライアントでrootとしてサーバにログインするために保存される。作成した鍵でサーバのインスタンス（実体）を生成するには、"-k gsg-keypair"オプションを使う。従って、鍵を共有するインスタンスを作成する場合、作業ディレクトリも共有することになる。
註：gsg-keypairというオプションの引数は別の文字列でもかまわない。たとえば、それぞれ別のEC2インスタンスが別の人によって管理されていて、ビジネスにインパクトが有る場合などは、そうしたほうがいいかもしれない。しかし、大抵の場合は、鍵を共通にしていて問題は無いと思われる。
The command “ec2-add-keypair gsg-keypair > id_rsa-gsg-keypair” creates a new keypair for logging in to an EC2 instance. The public key goes to amazon and the private key can be used by any ssh client to login as root when you creat an instance. To create an instance with that key you use the “-k gsg-keypair” option, so it seems a requirement to use the same working directory for creating all instances. Note that gsg-keypair could be replaced by any other string, if you are doing something really serious with EC2 you might use one account to create instances that are run by different people with different keys. But for most people I think that a single key is all that is required. Strangely they don’t provide a way of getting access to the public key, you have to create an instance and then copy the /root/.ssh/authorized_keys file for that.
このAmazonのページ(3)には、サンプルのサーバイメージをセットアップする方法が書いてある。
This Amazon page describes how to set up sample images [3].
ここでまず書かれているのは、
ec2-describe-images -o self -o amazonというコマンドを使って、自分が作成したのと、Amazonが公開しているサーバイメージのリストを表示する方法だ。
ただし、Amazonとしては、彼らのイメージを使ってもらうことを想定しているわけではないようだ。一応、386のCPU(32bit版)用のイメージとしては、Fedora Coreの４と８、そして、バージョンが明記されていないものが３つ。AMDの64bit版のOS用のイメージはFedora Core6と8がある。もし、本当に使ってもらう気があるのなら、CentOS版（もしくは他のRHEL互換OS)やDebian版があってしかるべきだろう。こういう状況はセキュリティの面からは望ましくない、ということは以前も書いた(4)が、とにかく、Amazonが提供している古いＯＳのイメージは、テスト用途以外では使わないこと。
The first thing it describes is the command ec2-describe-images -o self -o amazon which gives a list of all images owned by yourself and all public images owned by Amazon. It’s fairly clear that Amazon doesn’t expect you to use their images. The i386 OS images that they have available are Fedora Core 4 (four configurations with two versions of each) and Fedora 8 (a single configuration with two versions) as well as three other demo images that don’t indicate the version. The AMD64 OS images that they have available are Fedora Core 6 and Fedora Core 8. Obviously if they wanted customers to use their own images (which seems like a really good idea to me) they would provide images of CentOS (or one of the other recompiles of RHEL) and Debian. I have written about why I think that this is a bad idea for security [4], please make sure that you don’t use the ancient Amazon images for anything other than testing!
テスト用ならば、Amazonが用意した386版を使うと良いだろう。一番安価なインスタンスでも動作するからだ。
To test choose an i386 image from Amazon’s list, i386 is best for testing because it allows the cheapest instances (currently $0.10 per hour).
インスタンスを起動する前に、SSHでアクセスできるように、次のコマンドを実行しておく（sshの使う22番のポートがファイアウォールを通過するように設定する）
ec2-authorize default -p 22
註：このコマンドによって、サーバインスタンスのポート22番は、インターネットの何処からでもアクセスできるようになってしまう。これを避けるために、アクセスできるIPアドレスの範囲を設定するオプションもあるが、ここはとにかくサーバを起動させることに集中しよう。もちろん、そんな風にして作った第1作のサーバインスタンスは使いたくないだろうけれど、安全で信頼性の高いインスタンスを作るには、まず経験が大事なのだ。
実際、サーバを終了すれば、ディスク領域は（まだＳ３のデータ保存サービスを利用していないので）消去されてまっさらの状態に戻ってしまうし、特に重要なデータを保存しないうちはそれほどセキュリティに神経質になる必要は無いだろう。
Before launching an instance allow ssh access to it with the command “ec2-authorize default -p 22“. Note that this command permits access for the entire world. There are options to limit access to certain IP address ranges, but at this stage it’s best to focus on getting something working. Of course you don’t want to actually use your first attempt at creating an instance, I think that setting up an instance to run in a secure and reliable manner would require many attempts and tests. As all the storage of the instance is wiped when it terminates (as we aren’t using S3 yet) and you won’t have any secret data online security doesn’t need to be the highest priority.
例えば、インスタンスを起動するコマンドは次のようになる。
ec2-run-instances ami-2b5fba42 -k gsg-keypairここで、ami-2b5fba42 というのは、Amazonが公開しているFedoraCore8のイメージである。これを実行すると、大体次のような画面表示になるだろう。
A sample command to run an instance is “ec2-run-instances ami-2b5fba42 -k gsg-keypair” where ami-2b5fba42 is a public Fedora 8 image available at this moment. This will give output similar to the following:
RESERVATION r-281fc441 999999999999 default INSTANCE i-0c999999 ami-2b5fba42 pending gsg-keypair 0 m1.small 2008-11-04T06:03:09+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc
INSTANCEで始まる行のパラメータは、インスタンスのシリアル番号だ。この番号を使って
ec2-describe-instances i-0c999999
というコマンドを実行すれば、インスタンスの情報が得られる。すでに起動していれば（起動のリクエストを出して数分経ってから）次のような結果になる。
The parameter after the word INSTANCE is the serial number of the instance. The command “ec2-describe-instances i-0c999999” will provide information on the instance, once it is running (which may be a few minutes after you request it) you will see output such as the following:
RESERVATION r-281fc441 999999999999 default INSTANCE i-0c999999 ami-2b5fba42 ec2-10-11-12-13.compute-1.amazonaws.com domU-12-34-56-78-9a-bc.compute-1.internal running gsg-keypair 0 m1.small 2008-11-04T06:03:09+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc
次のようにSSHを実行すると、rootユーザとしてログインできる。”10-11-12-13”という部分は、サーバのグローバルアドレスを示している。このアドレスは例であって実在しないので10.11.12.13というアドレスにアクセスしても無駄だが、実際には、Amazonが割り当てたアドレスになる。仮のアドレスにしたのは、ロボットなどのソフトウェアでアクセスされるのを避けるためだ。
ssh -i id_rsa-gsg-keypair root@ec2-10-11-12-13.compute-1.amazonaws.com
The command “ssh -i id_rsa-gsg-keypair root@ec2-10-11-12-13.compute-1.amazonaws.com” will then grant you root access. The part of the name such as 10-11-12-13 is the public IP address. Naturally you won’t see 10.11.12.13, it will instead be public addresses in the Amazon range - I replaced the addresses to avoid driving bots to their site.
domU-12-34-56-78-9a-bc.compute-1.internalというサーバ名は、Amazon内部のDNSで通用するもので、プライベートIPアドレスが、このサーバインスタンスに割り当てられていることを示す。（10.0.0.0/8の領域だ）サーバインスタンスには、グローバルアドレスは割り振られておらず、NAT接続する必要がある。NAT接続しても、HTTPやSMTPなど、大抵のサーバを運用するには問題ない。しかし、FTPやUDPを利用したサービスについては問題だ。ところで、ホスト名の12-34-56-78-9a-bcの部分は、eth0デバイスのMACアドレスを示す。
The name domU-12-34-56-78-9a-bc.compute-1.internal is listed in Amazon’s internal DNS and returns the private IP address (in the 10.0.0.0/8 range) which is used for the instance. The instance has no public IP address, all connections (both inbound and outbound) run through some sort of NAT. This shouldn’t be a problem for HTTP, SMTP, and most protocols that are suitable for running on such a service. But for FTP or UDP based services it might be a problem. The part of the name such as12-34-56-78-9a-bc is the MAC address of the eth0 device.
サーバを停止するには、rootユーザでshutdownもしくはhaltコマンドを実行する。または、ec2-terminate-instancesコマンドも使える。その場合、引数にインスタンスＩＤを指定する。最も望ましいのは、サーバの状態を記録・保存して、実行中のサービスを完全に終了するまでの時間をとるようなスクリプトをまず実行してから、ec2-terminate-instancesを実行することだろう。
To halt a service you can run shutdown or halt as root in the instance, or run the ec2-terminate-instances command and give it the instance ID that you want to terminate. It seems to me that the best way of terminating an instance would be to run a script that produces a summary of whatver the instance did (you might not want to preserve all the log data, but some summary information would be useful), and give all operations that are in progress time to stop before running halt. A script could run on the management system to launch such an orderly shutdown script on the instance and then uses ec2-terminate-instances if the instance does not terminate quickly enough.
もう少したったら、EC2についてもっと書く予定だ。サーバの構成をダイナミックに変更する方法や、ダイナミックDNSの利用、そしてS3の利用法などだ。
In the near future I will document many aspects of using EC2. This will include dynamic configuration of the host, dynamic DNS, and S3 storage among other things.
参照：
* [1] http://etbe.coker.com.au/2008/10/04/getting-starte...
* [2] http://docs.amazonwebservices.com/AmazonEC2/gsg/20...
* [3] http://developer.amazonwebservices.com/connect/ent...
* [4] http://etbe.coker.com.au/2008/10/13/ec2-security/
タグ
コメントをかく