いやはやたっぷり2ヶ月以上あきましたわけだが。
9月中頃までは目が回るほどの多忙でただの放置だったんだけど、9月も下旬に近くなってエントリ挙げようとしたら投稿できなくなっておったのよ。
どうやら容量不足らしいのね。SSHでサーバにつないでdfやってみたら、10GB確保した容量が100%で空きなし、と。そんでもう1文字も投稿できんで、ってことらしい。
AWSのEC2サーバなので拡張は簡単だが、メディア類を他の場所(S3)に退避しているのに10GBを使い果たすとは異常なんで、まずは調べてみることにしたのだ。
そんでやたら時間を食って今までエントリなしだったのね。でも今日ようやくスッキリ出来上がり無事解決。またも長かったなぁ。
以下は作業の記録。画面キャプチャとか多いよ。
あれっ、と思ったのはこのBlogに投稿できなかったことがきっかけだが、容量不足が発覚した要因は同じAWS EC2 + WordPressでやっている事業サイトのバックアップができなくなっていたことなのだわ。
常用のWordpressプラグイン All-in-One WP Migration で数カ月ぶりにバックアップ取ろうとしたら容量不足と言われまして。で、SSHでつないでdf -hやってみたら100%、と。
調べてみると容量を食っているのはWordpress更新時の一時ファイルっぽいんだな。
でも正体不明だし依存関係とかメンドーなので apt-get autoremove してみたら、エラー多発で結局できやしねぇ。
そこでこのBlogのほうを同じくdf -hやってみたら、これも同じく100%。ただしこっちはautoremoveできて3GBほど空いたんだけど、アクセス数はBlogより格段に少ないとはいえオシゴトサイトは大事なので、まずそちらを優先で直そう、と。
ただね、もうだいぶ前からWordpressからは”PHPが古い”と警告されておったのよ。
でもPHPの更新はなんか手間で手順に不明点もあるので手を付けていなかったのだわ。
2,3週間試行錯誤してどうにも容量が空かず、そうこうしているうちにSSL証明書の期限切れが迫りやっぱり容量不足で更新できない、となり、もうここは思い切ってバックアップとって最初から再構築すべぇ、ってことにした。
バックアップ取るのはね、実は簡単だ。EC2の容量を一時的に増やしてバックアップとりゃええ。で、無事バックアップ完了。
何やら細々トラブりつつもなんとか先週復旧させたので、同じ手順でこのBlogの方もバッサリ作り直すことに。
まずはバックアップをとった。
続いてAWS EC2でもう1個仮想PCを用意するぞ。
右上オレンジの”インスタンスを起動”クリックで、wordpress で検索をかける。
こんな結果が出たので、AWS Marketplace で・・・、のリンククリック。
ズラッと出てくる。
証明書の自動更新設定とかメンドーだな、と常々思っておったのだが、この WordPress with NGINX and SSL Certified by Bitnami を使うとそのへんの設定一発で済ませてくれるらしいのでコヤツを選ぶぞ。
ちょっと名前が違うが気にしない。90日有効ですぐに更新はできないので自動更新できているかどうかはわからんが、オシゴトサイトは動いているっぽいし。
おなじみのコレ。次。
推奨はt3a.smallとなっていて最初はそれが選ばれているが、高いのでその半額のt3a.microを選ぶ。
今まではt2.nanoだったがt3a.microのほうが少し安くてCPU2つになるのでオトクっぽいんで。
んでもうスパッと”確認と作成”。
無料期間とっくに終わっているのでどのみち有料につき別に構わんのだ。起動ぢゃ。
するってぇとコレね。すでにあるキーを流用。完成したら前のインスタンス消すし。
はい完了。起動完了まで数分待つ。
こうなれば終了。一番下の”-“ね。
まぁ、名前は変えるでしょやっぱ。
まずは現状の公開アドレスで見てみましょうね。
はいOK。
ここからは手順がある。
この状態でバックアップを差し戻してそれからドメイン設定とか証明書取得とかするとSSLとかで問題が起こるので、バックアップ差し戻しは最後にして先にドメイン周りを終わらせる。
Elastic IP なるものを取得。
コレを取ってインスタンスに関連付けておかないと、サーバ再起動でIPアドレスが変わってしまって繋がらなくなるので必須ぢゃ。
取ったら右上オレンジ”Elastic IP アドレスの割り当て”。
さっき作ったインスタンスを割り当てる。
あとはDNS設定すればドメイン名でアクセスできるわけだが、今回はもともと使っていたElastic IPを流用したのでDNSはすでにできている状態。なので、
はい、行けたね。右下のウザいBitnamiロゴが読めていないけどまぁ気にしない。
続いてはSSHでつないでサーバ内部ファイルの設定。
昔はTera Termを使っておったがここ数年はPuTTYに馴染んでいるので。
AWSもPuTTY対応がよくなったし。
認証はキーペアなので設定はこんな具合で。
で、”Open”。
ここハマった。
この WordPress with NGINX and SSL Certified by Bitnami は、ログイン名がadminでもubuntuでもなく、bitnami なんである。
こんなクッソつまらんことに数日ハマったわ。
ログインできたら証明書取得。
最後に、証明書更新のために毎月のcron設定できるで、とか言われるのでやってもらう。
サーバのnginxを再起動。今までのApacheと同じくなんか設定変えたら再起動っちゅうことらしい。
参照サイトにあった、httpからhttpsへのリダイレクト設定。
前回の構築ではどうにもうまくできず断念したところだ。便利になったもんぢゃのぅ。
んで、サーバ再起動して動作を見てみる。
できたね、鍵付きで警告なし。
でも忘れておった、右下のウザいbitnamiロゴ消していなかった。
というわけでこうして、
こうぢゃ。駆逐完了。
これでCMSの準備はできたってことで、コンテンツ内容の差し戻しだ。
まずはWordpress管理画面へのログイン情報ね。
ここで”システムログを取得”すると、
ここに出ている。
ほんで末尾に/wp-login.phpつけてやると、
馴染みのログイン画面。ここでさっき調べたシステムログにあった情報でログイン。
バックアッププラグインの All-in-One WP Migration を入れようとしたら既に入っておったので、有効化するだけ。
でもコレだけだと40MBまでのバックアップファイルしか差し戻せず全然足りないので、ココでさらなるプラグインをもらってくる。
ココの、
コレで、
さっきもらってきた.zipファイルを指定、Install now。
Activate plugin すれば512MB未満のファイルが差し戻せる。
あとは、
フツーに差し戻せば宜しいな。
ところが、このあとオシゴトサイトで出なかった問題が起こるのだった。
まずは、差し戻した直後は正常にblogコンテンツが見られるのだが、管理画面にログインするとコンテンツが502エラーになるという問題。管理画面は正常。
試行錯誤の末、全プラグインを一旦無効化して再度1個づつ有効化したら直った。なんなんだろう。
で、OKかと思ったらまだダメで、投稿しようとすると”オフラインのようです”とか出て投稿できない。
コレはフォーラムの情報とかあたっても直らず、結局プラグイン Classic Editor を入れたら投稿できるようになった。なんなんだろう。
まーあれだ、メディアをS3に退避とかいじっているからだと思うが。ややこしくてついていけないのでコレでいいや、動いているし。
