前回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アドレスが付与されないというわけではない。