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
250
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.2k
SELinux_howto_20190218.pdf
intrajp
0
250
PHP ハウトゥ
intrajp
0
230
Other Decks in Technology
See All in Technology
生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』
toshiblues
1
210
プロダクト観点で考えるデータ基盤の育成戦略 / Growth Strategy of Data Analytics Platforms from a Product Perspective
yamamotoyuta
0
250
Grafanaのvariables機能について
tiina
0
180
EDRからERM: PFN-SIRTが関わるセキュリティとリスクへの取り組み
pfn
PRO
0
110
[TechNight #86] Oracle GoldenGate - 23ai 最新情報&プロジェクトからの学び
oracle4engineer
PRO
1
170
消し忘れリソースゼロへ!私のResource Explorer活用法
cuorain
0
140
[JAWS-UG栃木]地方だからできたクラウドネイティブ事例大公開! / jawsug_tochigi_tachibana
biatunky
0
130
(Simutrans) 所要時間ベース経路検索のご紹介
teamhimeh
0
100
CNAPPから考えるAWSガバナンスの実践と最適化
nrinetcom
PRO
1
330
Server Side Swift 実践レポート: 2024年に案件で採用して見えた課題と可能性
yusuga
1
420
パフォーマンスとコスト改善のために法人データ分析基盤をBigQueryに移行した話
seiya303
1
100
Windows Server 2025 へのアップグレードではまった話
tamaiyutaro
2
260
Featured
See All Featured
Scaling GitHub
holman
459
140k
Adopting Sorbet at Scale
ufuk
74
9.2k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Rails Girls Zürich Keynote
gr2m
94
13k
Speed Design
sergeychernyshev
25
760
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Optimizing for Happiness
mojombo
376
70k
How to train your dragon (web standard)
notwaldorf
89
5.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
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/