ここまで AMI の作り方の記事を参考に見てきましたが、いよいよ S3 のバケットに AMI に関するファイルを出力する段階になって
ec2-bundle-vol コマンドをキーワードに調べたんですけど
>インスタンス内から ec2-bundle-vol コマンドを実行して、Amazon S3 にアップロードするバンドルを準備します。
インスタンス内から
はい、ということで最初は AWS が提供している AMI を使っていきましょう。
Linux を触るのですけど、二つあって困る
これは、何が違うの？
間違ったの選んだら終わるの？
Amazon Linux 2 のご紹介
既存のAmazon Linuxの後継となるOS
>Amazon Linux 2 は、アマゾン ウェブ サービス (AWS) 上で最適なパフォーマンスを発揮できるように調整された LTS Kernel (4.9)、systemd のサポート、および最新ツール (gcc 7.2.1、glibc 2.25、binutils 2.27) を使用した近代的な実行環境を提供
>Python、MariaDB、Node.js などの一般的なソフトウェアパッケージのより新しいバージョンを含む追加のソフトウェアを、Amazon Linux Extras リポジトリを使用してインストールできます
Red Hat Enterprise Linux 略して RHEL 7 ベースで作られるようになったのが Amazon Linux 2 だとか
「LTS」とは一体何？
長期サポート（LTS）
サポート期間が、従来の2年間から6年間に延長されることになった
通常と比べて長い間サポートされる
Linux KernelのLTSサポート期間が6年に伸びるということはメーカーにとって非常にうれしいニュース
なるほど、これから長いことサーバーを運用していくなら TLS 版のカーネルを利用するのがいいって話か
では Amazon Linux 2 を使っていいんじゃないですかね。
AWS のインスタンス作成に進みますが
VPC はディフォルトで一つありますね、なんか vpc-f6f48xxx みたいな適当な名前のやつ
172.31.0.0/16 の CIDR ブロックが指定されていました 172.31.0.0 ～ 172.31.255.255 までのプライベートIPアドレス範囲か？
IPアドレスはクラスBの範囲だもんだが
なんでこんな IPアドレス範囲にしなければならないのかの基準の考え方が不明
まず CIDR は、ブロック単位のIPアドレス割り当て方式よりも、狭い範囲のIPアドレス割り当て範囲を指定できる仕組み
/16 ってのは 実は 2ブロック指定と同じ、8x8だから、そう /16 は固定 bit 数を指定していて、32bit に対する残りの 16 bit の 0.0 ～ 255.255 の範囲を指定するものだそうだ
/24 とかにすれば 0 ～ 255 の範囲を指定することになる、もうちょっと増やすには /23 とかにすれば 0.0 ～ 2.255 と、割り当て範囲を 2倍にするように指定することが可能だそうだ
今なら VPC の話を記憶しやすくなってきました、VPCで設定するのは全部プライベートIPアドレスなので、超自由
docs.aws.amazon.com
そして、適当に IP アドレスの範囲を CIDR 書式で指定しても
AWS によって必ず 5 つの IP アドレスが予約される
0: ネットワークアドレス
1: VPC ルーター用に AWS で予約
2: AWS で予約されています
3: 将来の利用のために AWS で予約されています
255: ネットワークブロードキャストアドレス、予約されている
ということで、VPC 内にインスタンスを作った場合は 4 ～ 連番でプライベート IP アドレスが振られるんじゃないかな？って予想が立ちました。
さて、インスタンス作成に戻って
VPCとサブネットは AWS がディフォルトで用意してくれていたものを選ぶようになっています。
今のところ VPC を切り替えなきゃいけないということもないので、そのままにしました。
インスタンスタイプでスペックが決まりますが、インスタンス数1, コア数1, メモリ1GB
次にストレージを選ぶのですが…Amazon EBS ボリューム？
Amazon EBS ボリューム - Amazon Elastic Compute Cloud
EBS ボリュームは、EC2 インスタンスの運用状況から独立した永続性を持ち、インスタンスにアタッチして利用する
メリット１：作成したボリュームは、同じアベイラビリティーゾーン内の任意の EC2 インスタンスにアタッチできます。別のインスタンスからストレージを利用するのに便利、インスタンス壊れてもストレージ残るので安全
メリット２：インスタンスがシャットダウンされてもデータが維持される限り、ボリュームの使用料が発生する。一緒に削除オプションはディフォルトで入っている
メリット３：暗号化は、すべての EBS ボリュームタイプでサポート、今回は使わない
メリット４：Amazon EBS は、Amazon S3 ボリュームのスナップショット (バックアップ) を作成し、ボリューム内のデータのコピーを EBS に書き込む機能を備えています。
メリット５：柔軟性
EBS ボリュームは、実稼働環境での設定変更をサポートします。サービスを中断せずに、ボリュームタイプ、ボリュームサイズ、IOPS 容量を変更できます
メリット5がすごいね、ハードディスクの容量が足りない状況で足せるのか、いいね。
ところで ストレージの性能指標 IOPSってなに？
Input Output Per Second のこと、100 はかなり遅い、10000 はかなり速い
ディフォルトでは最小の 100 だった
で、そんな EBS ボリュームを 8GiBでストレージに設定
次はタグをつけるかどうか聞かれる
いや、タグだけじゃ具体的に何なのかイメージできないよ
docs.aws.amazon.com
なるほど、めちゃめちゃインスタンスを立ち上げまくった場合に管理とかリストアップとか大変だから、プログラムのリスト内要素のキー名として、いくつかタグ付けておくと管理楽だよって話ですか
ほんと、マシンがプログラムの配列の要素として機能する社会を表す機能ですね。
セキュリティグループの設定で ssh 接続の IP アドレス制限ですが、マイIPを選択すると、今の家の環境のグローバルIPアドレス教えてくれるんですね
がっくし、じゃあ今後自分の IP アドレスを知るときは AWS のセキュリティグループの設定機能を使いますか
よし、これで SSH 接続できるのはこの家からのみになるはず、インスタンスを作って試してみます。
ec2-user がディフォルトユーザーであるとドキュメントにあったので、Amazpn Linux 2 の AMI から作ると ec2-user しか指定することができない
ssh -i privatekey.pem ec2-user@13.113.xx.xx
確かに実家からアクセスできた
そしてちょうど自宅に戻るので、自宅で同じようにアクセスしたところ、しばらくしてタイムアウト
なるほど！
そして、自宅のマイIPからの接続ルールを SSH に追加して、即座に自宅から SSH 接続に成功することを確認しました。
やったね、これでやっと安全に GNU / Linux を触れるようになった
