terraform cloudで初めるAWS その3: EC2 + Volume

Oct 13, 2020 aws

Share on:

これはシリーズ化する予定なので過去の記事や続きは←リンクからどうぞ。

ちなみに最低限AWS使った事ある人(EC2くらい起動した事ある人)向けの記事です

前回まで

EC2ホストの起動
Workspace内で構成したもののdestroy
ElasticIPの割り当て
SSHで接続したりpingを通したり

ここでは

ボリュームを作成し、アタッチします

なお、ここではterraformの操作よりもボリュームに対する知識を深めるという中で割と冗長になっています。スナップショットに関しては解説しません。いずれするかもだけどとにかくここではしません。

無料枠

無料枠のボリュームには30GiBのEBS無料枠があるらしいです。こちらではあんま検証してないです。

dataとresource

前回見てきたように、増えたり消えたりするものはresourceという扱いで、消えちゃ困るものはdataという指定になっておりました。というよりはterraformから作るものがresource、webコンソールから作るものが`dataP sourceでよいと思います。

ボリューム(記憶領域)はもちろんこれ消えたらマズいものなのでresourceじゃなくてdataとなります。

ちなみに^dataからはじまるものは正式にはdata sourceです。大抵dataってしてますけど。

ボリュームを作成する

この世界は1にデータ、2にデータっていうか全部データって感じなので「消えてもいいもの」と「消えたら確実にマズいもの」の2つをまずきっちり見定める必要がありますね。例えばプログラムのソースコードなどはVCS、たとえばgitだったらcloneしてくれば取ってき放題なので別段消えてもいいって事になりますがデータベースのデータとかは消えたらもちろん相当にマズいし、ユーザがアップロードしたファイルなどもまた然りなわけです。

これらを踏まえてボリュームを作成します。

物理ハードディスクと違って 99% くらい壊れません。まあ壊れたらクレームを放ってもいいと思うけど、とにかく壊れないので、これが最高に強いって事になるでしょう。

(そもそも最初にイカれるのは、長年この手の仕事やってきた人なら釈迦に説法だろうが、ストレージって相場は決まってますしね。)

アベイラビリティゾーン

東京リージョンはa, c, dの3つのゾーンがるという話をしましたが、実はボリュームとEC2インスタンスは同じゾーンに配置する必要があります。これが結構面倒くさい所で、今までのチュートリアルではゾーンを1つしか作ってない(というか根本的に意識していない)んですが、ロードバランサーを入れる場合はゾーンを2つ指定する事になります。つまり

ゾーンAのEC2
ゾーンDのEC2

といった感じにフロントが振り分けるわけだけど、どっちに飛んでいくかは神のみぞ知るという構成です。ゾーンAかもしれんしゾーンDかもしれません。こういう場合に使うディスクもあるんですが、このような場合はどっちかのゾーンにボリュームを置いてNFSで共有するとかいう芋っぽい事をしなくてはならない事もあります。

かなり逸れましたけど、このセクションで重要な事はEC2とボリュームは同じゾーンじゃないと使えないって事です。

EC2のゾーンを見てみる

今回何も指定していないので、(多分)どこのゾーンに置いてあるかわからんのでコンソールから確認する必要があります。

どうやら ゾーンC(ap-northeast-1c) に配置されたようです。さすがにゾーンがどこかわからんというのもアレなので指定したい所ではあります。

ここではゾーンCが指定されていたので、ひねくれてゾーンDを指定してみましょう。この辺は自由にどうぞ。ただ、ゾーンの指定はサブネットでやります。

1resource "aws_subnet" "pub" {
2  vpc_id            = aws_vpc.vpc.id
3  cidr_block        = "192.168.1.0/24"
4  availability_zone = "ap-northeast-1d" # <-これ
5
6  tags = {
7    Name = local.workspace
8  }
9}

コミットして適用します。networkが変わるのでEC2は作りなおしになります。

このようにEC2は基本頻繁に壊れたり生まれたりするので(そもそもEC2固有の数を意識しない事がクラウドである)EC2の起動している領域に重要なファイルを置くといつのまにか消えてる事とかあるかもしれないのでこれは避けにゃなりません。

さて、こうするとゾーンがdに移動しました。にしても随分攻めたプライベートIPアドレスっすね^^;

ボリュームを作成する

https://ap-northeast-1.console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Volumes:sort=state

これはwebから行います。既に何かいろいろボリュームが見えると思いますが、大抵インスタンスを起動するために生えたボリュームです。ま、とにかく「ボリュームの作成」ボタンから作っていきます。

まずボリュームタイプがよくわからんと思います。これに関しては「汎用SSD(gp2)」にしときましょう。io1とかio2の方が性能はよいですが金額はなかなかのものになります。st1とsc1は用途がアレです。とにかくこのサイトを読んでいるという方ははっきりいって多分そんなに経験がないはずなのでgp2にしましょう。何にしてもマグネティックは選択肢から外してください。

アタッチするサイズですが、まあなんというかある程度当たりを付けてやります。ここでは20Gくらいにしてみましょう。増やす事とかもできますが、テクが必要です。それに関してはここでは解説しません。

アベイラビリティーゾーンは1dにしてください。ここまで散々解説してきたのでいいとは思うけど間違えないように。

スナップショットIDは今回は使いません。ただし、後で使う予定ですので一応気にしといてください。

暗号化も使いません

さて、タグですが、Nameにworkspaceの名前を確実に入れます。これは、ここまでのチュートリアルをやってればわかりますがEIPと同じようにfilterで探してくる必要があるからです。

こちらの環境で大体こんな感じです。アベイラビリティーゾーンさえ合わせておけば後は何でもいいけどボリュームタイプとサイズを適当に設定すると値段がフィーバーするので注意してください。

こちらのボリュームのお値段

これは20Gの汎用SSDなのでざっと以下のような計算となりました。

https://aws.amazon.com/jp/ebs/pricing/

 11 instances x 730 instance hours = 730.00 total instance hours
 2730.00 instance hours / 730 hours in a month = 1.00 instance months
 320 GB x 1.00 instance months x 0.12 USD = 2.40 USD (EBS Storage Cost)
 4Total snapshots: 59.83
 5Initial snapshot cost: 20 GB x 0.0500000000 = 1 USD
 6Monthly cost of each snapshot: 3 GB x 0.0500000000 USD = 0.15 USD
 7Discount for partial storage month: 0.15 USD x 50% = 0.075 USD
 8Incremental snapshot cost: 0.075 USD x 59.83 = 4.48725 USD
 9Total snapshot cost: 1 USD + 4.48725 USD = 5.48725 USD
105.48725 USD x 1.00 instance months = 5.49 USD (total EBS snapshot cost)
112.40 USD + 5.49 USD = 7.89 USD (Total EBS cost)
12Amazon Elastic Block Storage (EBS) 総コスト (monthly): 7.89 USD

正直この程度の容量だとタイプを変えてもそんな変わんないのかな0という気もします。あとスナップショットの頻度とかありますが、スナップショットは自動的には取得されません(ここがデータベースとかと違う所です)。スナップショットを取得するとかいう奴をやりはじめると記事がながくなるのでまたいずれ。

EC2にボリュームをアタッチする

web.tfに書いてもいいしstorage.tfでもいいけどまあwebに結構関係してるからここに書いちゃいましょうか。

 1resource "aws_instance" "web" {
 2  instance_type = "t2.micro"
 3  ami           = "ami-0662319323823ba88" # jessie
 4  subnet_id     = aws_subnet.pub.id
 5  key_name      = "xxxxxx"
 6  tags = {
 7    Name = local.workspace
 8  }
 9}
10
11data "aws_ebs_volume" "web-data" {
12  most_recent = true
13
14  filter {
15    name   = "tag:Name"
16    values = [local.workspace]
17  }
18}
19
20resource "aws_volume_attachment" "web-data" {
21  device_name = "/dev/sdf"
22  volume_id   = data.aws_ebs_volume.web-data.id
23  instance_id = aws_instance.web.id
24}

これは実はそんなに難しくないっすね。ただ、アタッチするだけならね。

ディスクは付けただけじゃ使えないよね?

windowsだろうがなんだろうがハードディスクを増設しただけじゃ何ともならんわけです。

terraformからapplyしてみるとわかるけどインスタンスを作り直す事すらしませんね。ホットプラグって感じで。

当該ホストにsshします。/dev/sdfにアタッチするとdebianの場合**/dev/xvdf**に実際には装着されるようです。なのでこんな感じでパーティションを割ります。

 1admin@ip-192-168-1-254:~$ sudo fdisk /dev/xvdf
 2
 3Welcome to fdisk (util-linux 2.25.2).
 4Changes will remain in memory only, until you decide to write them.
 5Be careful before using the write command.
 6
 7Device does not contain a recognized partition table.
 8Created a new DOS disklabel with disk identifier 0x492cad8c.
 9
10Command (m for help):

fdiskが難しいならcfdiskとかでもいいですよ…

 1Command (m for help): n
 2Partition type
 3   p   primary (0 primary, 0 extended, 4 free)
 4   e   extended (container for logical partitions)
 5Select (default p): p
 6Partition number (1-4, default 1):
 7First sector (2048-41943039, default 2048):
 8Last sector, +sectors or +size{K,M,G,T,P} (2048-41943039, default 41943039):
 9
10Created a new partition 1 of type 'Linux' and of size 20 GiB.
11
12Command (m for help): w
13The partition table has been altered.
14Calling ioctl() to re-read partition table.
15Syncing disks.

これで**/dev/xvdf/**から**/dev/xvdf1**が生えたので、ここにext4とか作ります。いや、ext4じゃなくてもいいんですよ?

1admin@ip-192-168-1-254:~$ sudo mkfs.ext4 /dev/xvdf1
2admin@ip-192-168-1-254:~$ sudo tune2fs -r0 /dev/xvdf1

予約ブロックを0にしときました。なんとなく

ってわけで

これでEC2にボリュームをマウントできました。

ここでworkspaceの中身をdestroyして、また作り直してみてください。

再度ログインします。

あたりまえなんですが、ボリュームはアタッチされているものの、マウントはしていません。そりゃまあマウントポイントの指定なんてここまで与えていませんしね

1admin@ip-192-168-1-145:~$ df -h
2Filesystem      Size  Used Avail Use% Mounted on
3/dev/xvda2      7.8G  1.1G  6.4G  14% /
4udev             10M     0   10M   0% /dev
5tmpfs           200M  4.2M  196M   3% /run
6tmpfs           500M     0  500M   0% /dev/shm
7tmpfs           5.0M     0  5.0M   0% /run/lock
8tmpfs           500M     0  500M   0% /sys/fs/cgroup

ただ、マウントはできます。

 1admin@ip-192-168-1-145:~$ sudo mount /dev/xvdf1 /mnt
 2admin@ip-192-168-1-145:~$ df -h
 3Filesystem      Size  Used Avail Use% Mounted on
 4/dev/xvda2      7.8G  1.1G  6.4G  14% /
 5udev             10M     0   10M   0% /dev
 6tmpfs           200M  4.2M  196M   3% /run
 7tmpfs           500M     0  500M   0% /dev/shm
 8tmpfs           5.0M     0  5.0M   0% /run/lock
 9tmpfs           500M     0  500M   0% /sys/fs/cgroup
10/dev/xvdf1       20G   44M   20G   1% /mnt

ファイルシステムの話になるとOSより上のレイヤと下のレイヤでざっくり割れてしまうわけです。だから、ディスクを伸長するのもムズい、という話なんですが、その話は置いておいたとしてもEC2を作り直した時にディスクがmountされてないのはちょっと困るポンという話になる、でしょ？多分。

これに関してはEC2が起動した後で構成する方法があるので、次回それを解説します。これに関してはちょっと当該OSの知識が必要です。起動していちいちmountを手で仕掛けていいという状況ならそれもまた手かもしれませんしね(そんな頻繁に消えたり生えたりしない場合とか)

ただ、これはディスクだけの話ではないのですが

一度運用が初まると気軽に壊せなくなる

というのを念頭に置いておいてください。逆にいうと気軽に破壊できる環境を目指しておけば、簡単に破壊生成ができるわけで、そういった環境を作成するにあたってはとにかく破壊生成テストを繰り返すしかないのでした。