AWSのEBSの再確認

# はじめに
今更ですがAWSの基礎の学習をしています。今回は普段（というか今まで全く）気にしていなかった、EBSの動作の再確認をしました。

# やること
- ボリュームをインスタンスにアタッチして、そのボリュームを他のインスタンスに再アタッチしてちゃんとデータが残っていることを確認する。
- ストレージと言えばS3ばかりだったが、ローカルボリューム(EBS)も保存領域といういみでは使えるということの再確認。

# 作業の流れ
1. ebsの作成
2. ebsをインスタンスAにアタッチ
3. インスタンスAで、ebsにファイルを作成(hoge.txt)
4. インスタンスBに、ebsを再アタッチ
5. インスタンスBで、ebs内を確認してhoge.txtがあるかを確認

# 1. ebsの作成

![ボリューム | EC2 Management Console 0002-11-13 12-23-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9884/4f06ad14-e423-6e9b-916c-f575f778ef81.png)

`test-ebs`を作成しました。4Gで作成をしました。HDDでも、SSDでも何でも大丈夫です。

# 2. ebsをインスタンスAにアタッチ

![ボリューム | EC2 Management Console 0002-11-13 12-25-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9884/694b9d25-81be-aead-4963-44cb7a1e47b9.png)

![ボリューム | EC2 Management Console 0002-11-13 12-26-28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9884/d83d3439-5793-f32b-fbb5-6da3a989352c.png)

インスタンスAにアタッチしました。

ボリュームがアタッチされているか確認。インスタンスAにsshします。

```
Last login: Fri Nov 13 03:16:54 UTC 2020 on pts/0
[root@ip-xxx-xxx-xxx-xxx ~]# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   4G  0 disk
```

`xvdf`という名前で、4Gがアタッチされていることが確認できました。このデバイスファイルは、`/dev/xvdf`に存在します。

# 3. インスタンスAで、ebsにファイルを作成(hoge.txt)

ファイルシステムをlinux用にフォーマットします。

```
[root@ip-xxx-xxx-xxx-xxx ~]# mke2fs /dev/xvdf
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
262144 inodes, 1048576 blocks
52428 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
```

これでLinuxファイルシステムにマウントができる形になりました。

`/mnt`にマウントします。

```
[root@ip-xxx-xxx-xxx-xxx ~]# mount /dev/xvdf /mnt
[root@ip-xxx-xxx-xxx-xxx ~]# ls /mnt/
lost+found
```
マウントされたことが確認できました。

このボリュームの中にファイルを作成します。

```
[root@ip-xxx-xxx-xxx-xxx ~]# ce /mnt
[root@ip-xxx-xxx-xxx-xxx mnt]# echo hoge > hoge.txt
[root@ip-xxx-xxx-xxx-xxx mnt]# cat hoge.txt
hoge
```

作成して中身にhogeと記入しました。

# 4. インスタンスBに、ebsを再アタッチ

まずは、インスタンスAのボリュームをアンマウントします。

```
[root@ip-172-31-27-44 ~]# ls /mnt/
hoge.txt  lost+found

[root@ip-172-31-27-44 ~]# umount /mnt
[root@ip-172-31-27-44 ~]# ls /mnt/
[root@ip-172-31-27-44 ~]#
```

`umount`したので、`/mnt`の中身は空になっています。

AWSコンソール上でデタッチします。

![ボリューム | EC2 Management Console 0002-11-13 12-39-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9884/8cb476b0-9150-456c-5fa1-aa8648f3cab3.png)

インスタンスAの時と同じやり方で、ebsをサーバーBにアタッチします。

# 5. インスタンスBで、ebs内を確認してhoge.txtがあるかを確認

インスタンスBにsshして確認をして、ボリューがアタッチされているかを確認します。

```
yokohama@ip-yyy-yyy-yyy-yyy [12:41:29 PM] [~] [master *]
-> % lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  64G  0 disk
└─xvda1 202:1    0  64G  0 part /
xvdf    202:80   0   4G  0 disk
```

4Gのやつがされています。デバイスファイル名は、`xvdf`でした。マウントして中身を確認します。

```
[root@ip-yyyy-yyyy-yyyy]~# mount /dev/xvdf /mnt

[root@ip-yyyy-yyyy-yyyy]~# ls /mnt
hoge.txt  lost+found

[root@ip-yyyy-yyyy-yyyy]~# cat /mnt/hoge.txt
hoge
```

マウントしたebsの中には、hoge.txtが存在しており、中身もちゃんと保存されていることが確認できました。

# まとめ
使い所は色々とありそうですが、このようにebs内のデータが永続的に保存されていることの確認ができました。

ちなみにこのボリュームを複数のec2にアタッチできたら便利だなと思いましたが、AWSコンソール上でのメニューを確認する限りでは、できないようでした。

あらためて感じますが、２０年ぐらい前までは物理的なハードディスクをマザーボードに追加してファイルシステムのフォーマットしてマウントしてましたが、エラスティックな時代だな〜