aws_save_ami.pdf

技術者仲間における発表資料です。
by 藤原慎太郎

Transcript

1. AWS 上の EC2 マシンの問題を解決した話 藤原慎太郎
2. AWSサーバ上の問題を直した話（私物サーバーの話で す） • 本日話さないこと • 1. 問題の真因（Root Cause）や、Fedora,Amazon Linux,SELinux について • 2. AWS とは何か、実際の細かい手順等、あるいは、ベストプ ラクティスの詳細 • 3. 問題解決時のコマンド等の詳細
3. AWSサーバ上の問題を直した話（私物サーバーの話で す） • 1. トラブルの概要（sshでログインできなくなった） • 2. 今回、対処した方法 • 2-1. スナップショット作成 • 2-2. スナップショットからボリューム作成 • 2-3. 別マシン(amazon linux)を立ててそこに上記ボ リュームをマウント • 2-4. 別マシン上でボリュームの内容を修正 • 2-5. 新たなボリュームをAMI(Amazon Machine Image) として、仮想マシンを再作成する
4. 今回のアーキテクチャ • DNSは、no-ip を使っ ていま す。heavymetalhardr ock.no-ip.info • Elastic IPを登録 • サービスの概要 • Apache, PHP,PostgreSQL を 使ってます。 実際のサイト http://heavymetalhardrock.no-ip.info （参考） 山陰ペチパーズ発表資料 http://intrajp-public-for-web.s3-website-ap-northe php_howto_from_existing_site.pdf （ 約 2,000円/月 AWSのベストプラクティスに則っていない。）
5. 1. トラブルの概要 • システムの制限値を超えてプロセスが開けるファイル数 を設定したところ、ssh で一瞬ログイン出来るが、すぐ ’ に Permission denied’ となって、続行できない。root ボ リュームが一つのみというマシン。 • • サービスは継続できており、運用上は特に問題はない。 • • 復旧方法も不明なため、しばらく（1ヵ月程）放置した。 • • （参考） • 上記トラブルは、手元の物理/仮想マシンでも再現可能です。手元にある物理/仮想マシンであれ ば、シングルモードから、問題を解決できます。
6. 2.今回の対処（2-1. スナップショット作成） • EC2 について、少しお勉強したところ、以下の方 法を試した。 • • EC2 のページから、マシンインスタンスのスナッ プショットを採る（その際、マシンを停止す る）。 • • （参考） スナップショットは、S3 に保存される（別リージョンに保存 できる）。
7. 2.今回の対処（2.2スナップショットからボリューム作 成） • 取得したスナップショットから、ボリュームを作 成する。 • • （参考） ボリュームは、別マシンにマウントできる。
8. 2.今回の対処（2.3別マシンを立てて、そこにマウントす る） • 作成したボリュームを、新たに立てたEC2インス タンスにマウントする。 • • 今回は、/dev/sdf1 として認識されたので、適当 なマウントポイントを作成してマウントしまし た。 • （参考） 簡単にサーバーを立てられるのが、クラウドのよいところで す。
9. AMI -> スナップショット -> ボリューム • 解決手順1： • スナップショットを採 る、それをボリューム 化する、新たなマシン を立ち上げて、元のマ シンをボリューム化し たものをマウントす る。その中身を点検す る。 • SELinux の問題かも、 と思い立ち、audit.log を点検したところ、あ るファイルのラベルが 消えていた。 • また、あるファイルの ある設定をデフォルト 値に修正した。 • この解決策が正しいと 仮定して、ボリューム をAMI 化する。 元のマシン (Fedora28) 問題解決用 マシン (Amazon Linux)
10. 2.今回の対処（2.4 別マシン上でボリュームの内容を修正 ） • 別マシン（Amazon Linux）のインスタンスにマウ ントした、元サーバーのスナップショットからボ リューム化したドライブの内容を編集します。 • • 新たなボリュームをAMI(Amazon Machine Image) として、仮想マシンを作成する • • （参考） 幸い、自分が行なった所業を思い出したので、修正可能でし た。 •
11. EC2 インスタンス -> スナップショット -> ボリューム -> AMI • 解決手順2： • • 作成した AMI から 新たなEC2インスタ ンスを立ち上げる。 • ssh ログインする。 新しいマシン (Fedora28)
12. 今回の対処（2.5 新たなボリュームをAMIとして、仮 想マシンを作成する） • AMI から新たなインスタンスを作成すれば、元の 内容と一緒のマシンができます（ID等は変わりま す）。 • Elastic IP （Global IP）を関連づけて終了です。 • 今度は ssh できました。
13. 教訓および反省事項 • そもそも、冗長化していない実マシンで試験をしてしまったの が間違い。 • でも、今回のようなトラブルの場合なら、修復できることがわ かった。 • 他の修復方法はなかったか？ • そもそも AWS のベストプラクティスはどうなっているのだろ う？ • … 少なくとも4台のサーバーを立てる必要がある。 • クラウドの柔軟性を体感できた
14. 参考サイト等 • 参考： • • blog「AWS に ssh できなくなったのを直した」 • http://intrajp-computer.hatenadiary.jp/entry/2018/11/24/224817 • blog「AWS 上の EC2 サーバー上のトラブルを直した話」 • http://intrajp-computer.hatenadiary.jp/entry/2018/12/04/080857 • AWS のアイコンについて • https://dev.classmethod.jp/cloud/aws/aws-architecture-icons-2018/