所属する会社がAWSに力を入れているため、実際に触ってみようということで、
- Amazon LinuxにApacheをインストールして、PCからhttp接続
- EBSを新たにアタッチ、マウントして使用する
- バックアップを保存し、EC２インスタンスをまるごと削除し、復元する。
という課題にチャレンジしました。
ハンズオン形式でしたので、「まずは最後までサクッと経験しよう」の期待とは裏腹に、トラブりましたので顛末を書いてみようと思います。
数カ月後に読み返した際に、かわいいなぁと思えるように。
想定していたプロセス
- EC2インスタンスをたてる
- ・AMIはAmazon Linux 2
- ・ユーザデータにApacheのインストール、起動、再起動後も有効とするシェルスクリプトを記載
- ・セキュリティグループにHTTPを設定
- ターミナルでEC2の起動確認をする
- ・ssh接続でEC2インスタンスに接続
- ・Apacheが正常に起動しているか確認（systemctl statusコマンド）
- ・起動ログを確認してユーザデータに記載した内容を確認（cat /var/log/cloud-init-output.log）
- EBSをアタッチ・マウントする
- ・同一のAZにボリュームを作成する
- ・作成したEC2インスタンスにアタッチする（デバイスには /dev/sdf と入力）
- ・ファイルシステムを作成する(mkfs -s /dev/xvdf)
- ・ファイルシステムの型を確認し、UUID=~~~をメモしておく(mkfs -s /dev/xvdf)
- ・マウントするディレクトリを作成する（mkdirコマンド）
- ・マウントする（mount /dev/xvdf マウント先ディレクトリ）
- ・ディスク情報を確認し、マウントされたことを確認する（de -hコマンド）
- ・削除後、復元した際に自動でマウントする設定をする（vi /etc/fstab）
- ・マウントを解除する(umount マウント先ディレクトリ)
- ・再起動する（reboot コマンド）
- ・ssh接続で再度EC2インスタンスに接続
この先もまだプロセスがありましたが・・・
エラーが起きた箇所
マウントを解除して、再起動後、ssh接続ができませんでした。
コマンドを打ってもプロンプトが現れてくれません。
振り返る
rebootもumountもシンプルで間違えていないよなと。
vi /etc/fstabでミスしたのはほぼ間違いなさそうそうでした。
原因と対処
とりあえず出てきたエラーや状況をコピペして暗中模索。。
AWSマネジメントコンソールから直接ログを見ることができることを知り、ログを見てみると
emergency mode 〜なんちゃら〜
と出力されており、下記ページにたどり着きました。
EC2 Linux インスタンスが起動せず、緊急モードになるのはなぜですか?
詳細は上記にあるので、流れだけ書くと下記の手順で復旧できました。
1. 復旧したいEC2インスタンスを停止し、ルートボリューム（デフォルトでアタッチされているボリューム）をデタッチ
2. 同一AZで新しくEC2インスタンス（救世主）を起動し、１でデタッチしたボリュームをセカンダリ（２つ目）としてアタッチ
3. 救世主にSSH接続し、マウント先ディレクトリを作成、マウントする
4. vi /etc/fstabで教わったとおりに書き換えて保存する！
5. ボリュームをアンマウントし、救世主からセカンダリボリュームをデタッチする
6. 復旧したいEC2インスタンスにアタッチして、起動
7. SSHできることを確認！（涙
学べたこと
正直なことろ、viコマンドで再度/etc/fstabを書き換える際は復旧に必死で、
「どこを間違えたのか」
という最も大事なことをわからず復旧してしまったことは、最大の後悔です。
しかし、文字ひとつですべてが動かなくなる怖さを学べましたし、よしとしようかなと。
今度は冷静に原因分析しないとなと思った次第です。
おわりに
Markdownというもの初めてだったので、
https://qiita.com/Qiita/items/c686397e4a0f4f11683d
を見ながら記述しました。纏めていただいておりとても助かりました、感謝です!