Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
aws_save_ami.pdf
Search
Shintaro Fujiwara
August 03, 2019
Technology
0
280
aws_save_ami.pdf
技術者仲間における発表資料です。
by 藤原慎太郎
Shintaro Fujiwara
August 03, 2019
Tweet
Share
More Decks by Shintaro Fujiwara
See All by Shintaro Fujiwara
Moodleの開発者になれたよ
intrajp
0
1.4k
SELinux_howto_20190218.pdf
intrajp
0
280
PHP ハウトゥ
intrajp
0
230
Other Decks in Technology
See All in Technology
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
230
会社紹介資料 / Sansan Company Profile
sansan33
PRO
7
380k
roppongirb_20250911
igaiga
1
250
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
190
MagicPod導入から半年、オープンロジQAチームで実際にやったこと
tjoko
0
110
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
280
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
10
75k
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
110
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
140
AWSで始める実践Dagster入門
kitagawaz
1
750
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
3
200
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Agile that works and the tools we love
rasmusluckow
330
21k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
Transcript
AWS 上の EC2 マシンの問題を解決した話 藤原慎太郎
AWSサーバ上の問題を直した話(私物サーバーの話で す) • 本日話さないこと • 1. 問題の真因(Root Cause)や、Fedora,Amazon Linux,SELinux について
• 2. AWS とは何か、実際の細かい手順等、あるいは、ベストプ ラクティスの詳細 • 3. 問題解決時のコマンド等の詳細
AWSサーバ上の問題を直した話(私物サーバーの話で す) • 1. トラブルの概要(sshでログインできなくなった) • 2. 今回、対処した方法 • 2-1.
スナップショット作成 • 2-2. スナップショットからボリューム作成 • 2-3. 別マシン(amazon linux)を立ててそこに上記ボ リュームをマウント • 2-4. 別マシン上でボリュームの内容を修正 • 2-5. 新たなボリュームをAMI(Amazon Machine Image) として、仮想マシンを再作成する
今回のアーキテクチャ • 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のベストプラクティスに則っていない。)
1. トラブルの概要 • システムの制限値を超えてプロセスが開けるファイル数 を設定したところ、ssh で一瞬ログイン出来るが、すぐ ’ に Permission denied’
となって、続行できない。root ボ リュームが一つのみというマシン。 • • サービスは継続できており、運用上は特に問題はない。 • • 復旧方法も不明なため、しばらく(1ヵ月程)放置した。 • • (参考) • 上記トラブルは、手元の物理/仮想マシンでも再現可能です。手元にある物理/仮想マシンであれ ば、シングルモードから、問題を解決できます。
2.今回の対処(2-1. スナップショット作成) • EC2 について、少しお勉強したところ、以下の方 法を試した。 • • EC2 のページから、マシンインスタンスのスナッ
プショットを採る(その際、マシンを停止す る)。 • • (参考) スナップショットは、S3 に保存される(別リージョンに保存 できる)。
2.今回の対処(2.2スナップショットからボリューム作 成) • 取得したスナップショットから、ボリュームを作 成する。 • • (参考) ボリュームは、別マシンにマウントできる。
2.今回の対処(2.3別マシンを立てて、そこにマウントす る) • 作成したボリュームを、新たに立てたEC2インス タンスにマウントする。 • • 今回は、/dev/sdf1 として認識されたので、適当 なマウントポイントを作成してマウントしまし
た。 • (参考) 簡単にサーバーを立てられるのが、クラウドのよいところで す。
AMI -> スナップショット -> ボリューム • 解決手順1: • スナップショットを採 る、それをボリューム
化する、新たなマシン を立ち上げて、元のマ シンをボリューム化し たものをマウントす る。その中身を点検す る。 • SELinux の問題かも、 と思い立ち、audit.log を点検したところ、あ るファイルのラベルが 消えていた。 • また、あるファイルの ある設定をデフォルト 値に修正した。 • この解決策が正しいと 仮定して、ボリューム をAMI 化する。 元のマシン (Fedora28) 問題解決用 マシン (Amazon Linux)
2.今回の対処(2.4 別マシン上でボリュームの内容を修正 ) • 別マシン(Amazon Linux)のインスタンスにマウ ントした、元サーバーのスナップショットからボ リューム化したドライブの内容を編集します。 • •
新たなボリュームをAMI(Amazon Machine Image) として、仮想マシンを作成する • • (参考) 幸い、自分が行なった所業を思い出したので、修正可能でし た。 •
EC2 インスタンス -> スナップショット -> ボリューム -> AMI • 解決手順2:
• • 作成した AMI から 新たなEC2インスタ ンスを立ち上げる。 • ssh ログインする。 新しいマシン (Fedora28)
今回の対処(2.5 新たなボリュームをAMIとして、仮 想マシンを作成する) • AMI から新たなインスタンスを作成すれば、元の 内容と一緒のマシンができます(ID等は変わりま す)。 • Elastic
IP (Global IP)を関連づけて終了です。 • 今度は ssh できました。
教訓および反省事項 • そもそも、冗長化していない実マシンで試験をしてしまったの が間違い。 • でも、今回のようなトラブルの場合なら、修復できることがわ かった。 • 他の修復方法はなかったか? •
そもそも AWS のベストプラクティスはどうなっているのだろ う? • … 少なくとも4台のサーバーを立てる必要がある。 • クラウドの柔軟性を体感できた
参考サイト等 • 参考: • • 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/