インフラ屋のAWSはじめた日記─GUIを捨てよ

第3回CLIのパワーアップとEC2を起動する

前回S3にhtmlをアップロードしてブラウザから表示するところまで、できた。その後、いろいろ試していくうちに、CSSやJSも同じように置くことで、静的なサイトであればすべてS3だけで運用できることがわかった。もし、静的なページのためにサーバを借りているならS3で済んでしまうんじゃないかと思った。

でも、やっぱりサーバ構築がしたい。正直ミドルウェアをインストールしている時が自分にとって最高に気持ちのいい時間だし、⁠俺ってインフラエンジニアやってるな」って気になれる。

今日はサーバを起動して、なんかミドルウェアなんかを入れていい感じに動かしてみる、なんてことをやってみようと思う。

CLIをパワーアップ

補完をきかす

前回S3を使ってみた時に思ったことだけど、いちいちコマンドを調べるのが面倒くさくて仕方ない。chmodだってあると思ったのになかったし、こういう無駄な作業が嫌いだ。

気持ちよくコマンドを操りたい俺はどうにかしてこのコマンドを効率的にかっこ良く打てる方法がないかを探した。

普段気持よく打てている時はそう、Tabキーを押す回数が多い。コンピュータに補完させて、テキパキコマンドを入力していく、そんな俺は非常に気持ちがいい。

というわけで、即ググる。やっぱりちゃんとあった、あると思ったんだ。というかAWS CLIのGitHubのREADMEにちゃんと書いてあった。どうしてすぐにやらなかったんだろう。少し後悔している。

やり方は簡単で、bashなら

$ complete -C aws_completer aws

これで大丈夫だった。同じページにはtcshとzshでの方法も書いてあったけど、PowerShellでの設定の仕方は書いていなかった。残念。これでAWS CLIをさくさく使い倒す準備はできた。ここからは一気にかっこよくサーバ立ち上げをしたり、落としたりする。できるよな、たぶん。

jsonを処理する

補完はきいた。AWS CLIのgithubのREADMEに書いてあった、jqを使うとjsonを処理できるらしい。ついでなのでこれもやっておく事にする。

ここからダウンロードして、PATHの通っているところに放り込むだけという簡単インストール。俺は聖域 /usr/local/binへ入れた。使い方はオンラインマニュアル にていねいに書いてあるので、読んでおくとよい。

EC2のインスタンスを起動する。

AWSには今まで触ってきたサーバと同じように、扱える機能もあるらしい。Elastic Compute Cloud を略してEC2と呼ぶようで、VPSに似ているようだけれど、料金が1時間あたり何ドルといった時間課金になっているらしい。仮想化されたマシンの事をインスタンスと呼ぶらしいので、これからは⁠EC2⁠とか⁠インスタンス⁠とか言って知ったかぶることにしよう。

とりあえずインスタンスを1台起動してみて遊んでみることにする。

AMIってなに?

コマンドに補完が効くので、はっきり言ってもう怖いものはない。

$ aws ec2 [Tab連打]

Tabを押すと153個ものサブコマンドが出てくる。でも、なんとなく名前で判断できそうだ。たぶん、run-instancesこれで間違いない。

aws ec2 run-instances [Tab連打]

Tabを連打したら、なんとオプションまでしっかり出してくれる。本当にこの補完のやつを設定してよかった。だがしかし、わらわらと50個近いオプションが出てくる。たぶん全部指定する必要はないので、まずは必須項目が何なのか知るために、無駄撃ちしてみる。

$ aws ec2 run-instances
usage: aws [options] <command> <subcommand> [parameters]
aws: error: argument --image-id is required

--image-idというのが必須だということがわかった。ちゃんと必要な項目がエラーで出てくるこの安心感。必要な項目はわかったけれど、--image-idには何を指定するものなんだろう??

EC2と言うのはOSのイメージを指定して起動するらしいので、--image-idにはおそらくOSのイメージを指定するんだろう。後で知ったことだけど、このOSのイメージの事をAMI(Amazon Machine Image)と呼ぶらしい。 とりあえず再度

$ aws ec2 [Tab連打]

それらしきものを探す。aws ec2 describe-images というのがある。どうもAWSはdescribeという言葉が好きらしく、何か情報を取得するときにはたいていdescribeで良さそう。今回はimageについて知りたいので、とりあえずdescribe-imagesというのを打ってみる。describe-*のコマンドはたいてい情報取得系なので、適当に実行しても安全そうだ。暇な時にはdescribe-*をやってみるのも良いと思う。

$ aws ec2 describe-images 

いっぱい出てきた。見るのが面倒くさい位わんさか出てきた。ちょっと出過ぎなので、なんかフィルター的なのをしてみたい。というわけでまたTabを連打する。

すると--fileters というのがあった。これでなんかフィルタリングできそうな気がするけど、結局よくわからないので、諦めてリファレンスを見ることにした。リファレンスを見てみたら、--ownersというのでイメージのオーナーで絞り込めるらしく、今回は噂のAmazon謹製 Amazon Linuxが使いたいので、--owners amazonを指定して実行してみる。

さっきよりはだいぶ短くなったけれど、それでもまだ見づらい。今回知りたいのはimage-idだから、image-idだけを抜出したい。

ここで、天から「jqを使うが良い」とのお告げがあったので、jqを使ってみることにする。

$ aws ec2 describe-images  --owners amazon |jq .[][].ImageId

とするとImageIdだけが取得できることがわかった。これでも結果が沢山あって、さらにprefixがami-のものとari-のものとakiのものがあって混乱しそう。ari-*とaki-*は今度調べることにして、今回はamiだけの情報を取り出したい。

とりあえず、データを見ていたらImageTypeというのが、machineとなっているものがamiという法則を見つけた。Amazon ⁠Machine⁠⁠ Imageだからmachineなんだろう。aki はkernelになっているし、ariはinitrdになっている。

なんとなくわかった気がするけど、利用用途は今のところよくわからない。とりあえず、amiのIDとImageの名前を表示してみることにした。

$ aws ec2 describe-images  --owners amazon |jq '.[][] |select(.ImageType == "machine") | {"Name" :.Name,"ImageId":.ImageId }'
〜略〜
{
  "Name": "Windows_Server-2012-RTM-English-64Bit-SQL_2008_R2_SP2_Express-2014.12.10",
  "ImageId": "ami-fe1815ff"
}
{
  "Name": "Windows_Server-2003-R2_SP2-Language_Packs-64Bit-SQL_2005_SP4_Express-2014.12.10",
  "ImageId": "ami-fe727fff"
}
{
  "Name": "Windows_Server-2008-R2_SP1-Portuguese_Brazil-64Bit-SQL_2008_R2_SP2_Standard-2014.12.10",
  "ImageId": "ami-fe7974ff"
}
{
  "Name": "Windows_Server-2012-R2_RTM-Brazilian-64Bit-Base-2014.12.10",
  "ImageId": "ami-fe7b76ff"
}
{
  "Name": "suse-sles-11-sp3-byos-v20141023-hvm-ssd-x86_64",
  "ImageId": "ami-fffdcefe"
}

このコマンドで、いい感じにとれた。さらっと書いたけど、jqの使い方を調べるのと、ここまで書いている間に日が変わってしまったというのは秘密。一覧の中から、amznとか付いているし、Amzon Linuxっぽいので、このAMIを使うことにする。

{
  "Name": "amzn-ami-hvm-2012.09.1.x86_64-ebs",
  "ImageId": "ami-fd7ef9fc"
}

$ aws ec2 run-instances --image-id ami-fd7ef9fc

A client error (InvalidParameterCombination) occurred when calling the RunInstances operation: Non-Windows instances with a virtualization type of 'hvm' are currently not supported for this instance type.

なんだかhvmというvirtualization typeだとこのinstance typeは使えないと言っておられる。だけどinstance typeは指定していない。ということはデフォルトで何か指定されていて、それは使えないということなんだろうと思う。

少し調べてみると、virtualization typeというのはparavirtualとhvmという2つがEC2には存在するらしく、最近だとhvm推しだということがわかった。そしてhvmではt1.microは使えない。逆にpv(paravirtual)ではt2.*は使えないということがわかった。

t1とかt2というのは、インスタンスのスペック毎に名前が付いているようだ。そのうちこの辺りも調べて行きたいと思う。とりあえず、t2.microというのは無料枠というのが用意されているので、なんと1台無料で使えるらしい。

というわけで、コマンドに--instance-typeというオプションを付けて実行してみる。

$ aws ec2 run-instances --image-id ami-fd7ef9fc --instance-type  t2.micro

今度はエラーではなく、jsonで立ち上がったインスタンスの情報が表示された。しかし、その情報にはSSHでつなげるようなpublicっぽいIPアドレスは表示されていない。どうやってSSHで接続するんだろう。だけど、よくよくオプションを見てみると,--associate-public-ip-addressというオプションがあったので、付けて実行してみると今度もpublicっぽいIPアドレスはついてなかった。途方にくれた。

結局散々悩んだ結果、つい画面をclearしてしまって、describe-instances してみたら、いつの間にかpublicっぽいIPアドレスとホスト名が表示されていた。後で知ったのだけど、少ししないとpublic IPはついてこないということと、--associate-public-ip-addressを付けないと、public IPアドレスが付与されないというわけではない。

Security Group

これで無事に起動はできたから、ここからSSHで接続していじっていこうと思ったけれど、ユーザ名もわからないし、パスワードもわからない。describe-instancesしたら書いてあるかと思ったけれど、書いてない。とりあえず、ユーザ名rootでアクセスしてみる。

$ ssh root@ec2-**-**-**-***.ap-northeast-1.compute.amazonaws.com
ssh: connect to host ec2-**-**-***-***.ap-northeast-1.compute.amazonaws.com port 22: Operation timed out

正直もう心が折れそうです。このSSHのエラーを見る限りだと、そもそもネットワーク的に届いていない可能性がある(もしくは、向こうからのレスポンスが返ってこないだけかも⁠⁠。

AWSにはSecurity GroupというFirewallのようなものがある。Security Groupはプロトコルとポートを開いて、それをEC2に適用するというものだ。今起動した、instanceにはdefaultという名前のSecurity Groupが付けられている事はdescribe-instancesで確認できた。このdefaultというSecurity Groupに対してsshが繋がるような設定をしていくことにした。

$ aws ec2 authorize-security-group-ingress --group-id sg-xxxxxxx --port 22 --cidr 0.0.0.0/0  --protocol tcp

ポートとプロトコル(L4)とCIDRを指定してあげれば良いようだ。これはリファレンスを見なくても結構直感的にわかった気がする。そろそろコマンドラインの使い方が身についてきたんだろうか。

ここまで来たら、もう行けるだろうとsshでの接続を再チャレンジ。

$ ssh root@ec2-**-**-**-***.ap-northeast-1.compute.amazonaws.com
Warning: Permanently added 'ec2-**-**-***-**.ap-northeast-1.compute.amazonaws.com,**.**.**.***' (RSA) to the list of known hosts.
Permission denied (publickey).

そろそろ本気で、心が折れそうだ。鍵認証に失敗していると言われている。そもそもパスワードでの認証ではないみたいだ。

今度はKey Pairだ

sshでログインできないと何も始まらないから、なんとかしてつなげたい。

ちょっとだけ調べてみると、Key Pairというのを使って認証するらしい。KeyPairというのは所謂SSHのKeyPairなんだけれど、AWSでは事前に公開鍵を登録しておく事で、EC2起動時にauthrizaed_keysに入れておいてくれるという。そもそも更に大事な事に気づいたわけだけど、ユーザ名はrootではなくec2-userというところまでは分かった。

というわけで、公開鍵を登録する。公開鍵の登録は2つの方法があるらしく、既存の公開鍵を登録する方法と、新しくKeyPairを作成して、秘密鍵をもらう方法がある。create-key-pairというのがあったので、--key-nameを指定して実行してみたら、あっさりと秘密鍵をもらえた。

aws  ec2 create-key-pair --key-name id_rsa-cli
{
    "KeyMaterial": "-----BEGIN RSA PRIVATE KEY-----〜略〜 -----END RSA PRIVATE KEY-----",
    "KeyName": "id_rsa-cli",
    "KeyFingerprint": "45:4e:28:02:7b:9c:da:a2:35:c0:b4:aa:5c:b4:f8:dd:cf:3d:e7:00"
}

KeyMaterialというところが秘密鍵になっているので、これをコピーして、貼り付けて、ちょっとイケてないのが、改行が⁠\n⁠という文字列になってしまっているので、改行に置き換えて保存する。

$ chmod 600 .ssh/id_rsa_cli 

としたら、これで行けるはず。

$ ssh -i .ssh/id_rsa_cli ec2-user@ec2-**-**-***-**.ap-northeast-1.compute.amazonaws.com
Warning: Permanently added 'ec2-54-64-102-48.ap-northeast-1.compute.amazonaws.com,54.64.102.48' (RSA) to the list of known hosts.
Permission denied (publickey).

あと少しなのに、どうして。どうしても何も、よく考えたら、起動時にauthorized_keysに登録されるので、起動する時にkey_pairを指定しないといけないみたい。

というわけで、速攻でさっき立ち上げたインスタンスを落とすことにした。落とすのは簡単で

$ aws ec2 terminate-instances --instance-ids i-xxxxxxxxx 

とinstance-idを指定してこのコマンドを叩けばよい。これでお金がかからないと思うと恐ろしい時代になったなと思う。減価償却とかサーバ利用率とは何だったんだろうか。

改めてEC2を立ち上げる。

$ aws ec2 run-instances --image-id ami-fd7ef9fc --instance-type  t2.micro --key-name id_rsa-cli

--key-nameにさっき作ったkeypairの名前を指定して、実行する。

やっとSSHでつなげた

そして…、ついにSSH接続ができた。ここまでできたけど、今日はもう疲れたよ。

Last login: Wed Jan  7 05:15:30 2015 from kd106155124035.au-net.ne.jp

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
There are 50 security update(s) out of 227 total update(s) available
Run "sudo yum update" to apply all updates.
Amazon Linux version 2014.09 is available.

ミドルウェアをどうこうしようと思ったけれど、EC2の起動はなれないと結構大変で、調べながらやっていたら、思ったよりも時間がかかってしまった。今日は疲れたのでここでおしまいにする。

今日は深く調べなかったけど、ちょいちょいVPCという言葉を見かけたので、明日はVPCを調べて見るつもりなのと、EC2に実際にミドルウェアのインストールとかその辺りもできたらいいなと思う。


心が折れそうと言いながらも、EC2、SSHとやってのけた、とあるエンジニア。次回はVPCということで、イケイケな気配。もちろん次回もブラウザなしで。乞うご期待!

AWSの仕事ができるようになる、トレーニングプログラム

http://tr.pasonatech.co.jp/wpaws01

おすすめ記事

記事・ニュース一覧