EBSをデタッチしたときにあせった話

#はじめに
EBSをデタッチして、EC2を停止・起動したらsshログインできなくなって焦った話です。
（EC２のインスタンスステータスチェックも失敗している）
結論から言うと、デタッチする前に/etc/fstabの記述消してねって話です。
/etc/fstabに記述されて自動マウントの設定が入っているのに、EBSをデタッチしてしまって
起動時に、あれ？そんなボリュームなくない？って起動時にエラーになってしまうという…

#追加EBSのアタッチについて
まずEC2に対してルートボリューム以外の追加EBSをアタッチする方法について書きます。
①「Elastic Volume Store」→「ボリューム」→「ボリュームの作成」を選択
![スクリーンショット 2022-01-23 17.43.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/575134/47aef4a1-89fa-77e6-7369-d2154d7735e1.png)

②各パラメータを入力し、「ボリュームの作成」をクリック
※このときの「アベイラビリティーゾーン」はアタッチする予定のEC2と
同じゾーンにする必要があります。
![スクリーンショット 2022-01-23 17.46.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/575134/84c5b832-88dc-a05a-711f-1dd255ca13fd.png)

③EC2にログインし、EBSの状態を確認して、マウントしていく。

```
[ec2-user@ip-172-31-33-165 ~]$ 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   1G  0 disk
[ec2-user@ip-172-31-33-165 ~]$
```
今回追加された1GBのEBS(xvdf)があることを確認する。

```
[ec2-user@ip-172-31-33-165 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            483M     0  483M    0% /dev/shm
tmpfs            483M  404K  483M    1% /run
tmpfs            483M     0  483M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  1.5G  6.5G   19% /
tmpfs             97M     0   97M    0% /run/user/1000
[ec2-user@ip-172-31-33-165 ~]$
```
まだマウントされていないことを確認する。

```
[ec2-user@ip-172-31-33-165 ~]$ sudo file -s /dev/xvdf
/dev/xvdf: data
[ec2-user@ip-172-31-33-165 ~]$
```
ファイルシステムが作られていないことを確認する。
(/dev/xvdf: dataのみだったらファイルシステムは作られていない）

```
[ec2-user@ip-172-31-33-165 ~]$ sudo mkfs -t xfs /dev/xvdf
meta-data=/dev/xvdf              isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[ec2-user@ip-172-31-33-165 ~]$
```
フォーマットして、ファイルシステムを作成する。（今回はxfsで作成します）

```
[ec2-user@ip-172-31-33-165 ~]$ sudo file -s /dev/xvdf
/dev/xvdf: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
[ec2-user@ip-172-31-33-165 ~]$
```
ファイルシステムができていることを確認する。

マウントしていく。

```
[ec2-user@ip-172-31-33-165 ~]$ sudo mkdir /data
```
今回のマウント用のディレクトリを作って

```

[ec2-user@ip-172-31-33-165 ~]$ sudo blkid
/dev/xvda1: LABEL="/" UUID="0a56d206-2a6d-46e6-b65f-11b7052f72cf" TYPE="xfs" PARTLABEL="Linux" PARTUUID="590d752e-20a4-404b-88db-bfebb1f9b90e"
/dev/xvdf: UUID="e4a53635-12a7-4771-b502-f60e86fefc60" TYPE="xfs"
[ec2-user@ip-172-31-33-165 ~]$
```
マウントしたいEBS(xvdf)のUUIDを確認する。
（※デバイス名：/dev/xvdfでもfstabの記述でマウントできますが、Nitro系のインスタンスの場合、UUIDを使っていない場合、デバイス名が変わる可能性があるためUUIDでの記述が推奨されています。
EC2起動時に、複数ボリュームがついている場合、EBSを認識する順番が変わる可能性があるらしく、各ボリュームが違う場所にマウントされてしまう、みたいなことが起きるらしい。）

自動マウントするために、/etc/fstabに記述していく

```
[ec2-user@ip-172-31-33-165 ~]$ sudo vi /etc/fstab
```
でfstabを開いて、

```
UUID=e4a53635-12a7-4771-b502-f60e86fefc60     /           xfs    defaults,noatime  1   1
```
のように新しい行に追記する。

```
[ec2-user@ip-172-31-33-165 ~]$ sudo mount -a
```
でマウントして、

```
[ec2-user@ip-172-31-33-165 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         475M     0  475M    0% /dev
tmpfs            483M     0  483M    0% /dev/shm
tmpfs            483M  404K  483M    1% /run
tmpfs            483M     0  483M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  1.5G  6.5G   19% /
tmpfs             97M     0   97M    0% /run/user/1000
/dev/xvdf       1014M   34M  981M    4% /data
[ec2-user@ip-172-31-33-165 ~]$
```
マウントされていることを確認する（マウント位置に/dataが入っている）

リブートしても、同じようにマウントされていることを確認する。

#EBSのデタッチについて
ここからが本題なのですが、本来であれば、
①先ほど編集したfstabの記述を消して、umountでアンマウント
②EBSをデタッチ→削除
する必要があるのですが、①をすっ飛ばして②を実施してしまうと、
EC2の起動時に「fstabに書かれてるEBSいなくない？」となり、起動に失敗します。。
↓のようにインスタンスステータスのチェックにも失敗し、SSHログインできなくなります。
![スクリーンショット 2022-01-23 17.54.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/575134/59201f84-9b51-e7e9-9de8-fbc8c1267c01.png)

当たり前だよってことかもしれませんが、
開発者とインフラ担当者が分かれているような体制で
開発者から「このEBS消しといてー」って言われたときに陥りがちなミスかと思います。。
まだそのEBSを消す前だったら、再アタッチして①からやり直すことは可能ですが、
もうすでにそのEBSを消してしまっていたら…

#引用
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html