◆引っ越しました

GCPなら無料でWordPress運用できそうだねと思ったので引っ越し。あばよAzure！アスタラビスｔ…

あ、仕事で使うわ。

引っ越しやってみた感想としては、意外と楽。変に混乱して一時間くらいサイト見られなくなったり、記事投稿しようとして「更新に失敗しました」とかいわれて死んだりしたけど。

引っ越し記念に手順を備忘る。

以下の記事を元ネタとした。タイトルがなんかキショい。「図が見てぇ」と思ったら記事を参照しろ。

1時間で出来る！最強のWordPress環境構築(永久無料)

想定読者は、時間がそれなりにある人。弱小ブログを運営している人。カスタムドメインな人。「httpsにしてぇなぁ」と思っている人。

そいで、以下手順を実行するときは、内容を一通り読んでから取り組むこと。

◆結果

  • WordPressをAzureからGCPに引っ越し
  • ブログのTSL対応（httpsにしたって意味だよ）
  • 運用費用が無料になった（たぶんずっと）
  • サイト表示が速くなった気がする
  • 技術スキルが上昇した

◆引っ越し先作れ

  1. ここにアクセスし、管理用のGoogleアカウントでログインしろ。アカウントねぇなら作れ。
  2. 「WordPress with NGINX and SSL Certified by Bitnami」つくるよページを開け。一応だけど開いたページで名前あってるか確認しろ。
  3. WordPressをぶち込みたいプロジェクトを選択しろ。よくわからないなら「My First Project」とかに入れておけ。あるいは「ブログが載ってるっぽい名前のプロジェクト名」で新しくプロジェクト作れ。
  4. 「無料トライアルに登録」しろ。クレカが必要だから、持ってねぇなら作ってこい。
  5. Deployment nameを適当に変えろ。
  6. Zoneが「usなんちゃら」であることを確認しろ。ただしus-east4。テメーはダメだ。
  7. Machine typeをmicroにしろ。
  8. Boot disk size in GBを30GBまででイイ感じにしろ。
  9. 「デプロイ」しろ。
  10. 待て。
  11. Deployment Managerページみて「デプロイされてる」と思え。

◆IP固定しろ

VPCネットワークページで「エフェメラル」ってなってんのを「静的」にしろ。

◆ログインしろ

Deployment Managerページでアレを選ぶとログインURLのリンク張ってあるから、Admin userとAdmin passwordを適当にコピってAdmin URLからログインしろ。

◆コピーしろ

All-in-One WP Migration Importプラグイン入れろ。しかしただ入れるんじゃだめで、このページでzip落として直でプラグインをインポートしないと移行可能な容量が30MBとかになってしまう。

引っ越し先で全てのプラグインを除去したのち、インストールしろ。方法はこのページ見ろ。英語だけど図があるから何とかなれ。

引っ越し元と引っ越し先の両方にプラグインを入れろ。んで、インストール終わったら画面更新しろ。

「All-in-One WP Migration Import」メニューが左のツールバーに増えるから、引っ越し元のほうで開いて「Export」だの「エクスポート先」だのを選んで「ファイル」を選べ。

サイトのコピーファイルが生成されるから、そのファイルを引っ越し先でインポートしろ。ノリで。

◆bitnamiを消せ

サイトを開くと右下に何か良く分からんロゴが表示されるから消せ。ここみろ。

わかんねぇって？甘えてんじゃねぇよ。説明してあげる💖

Deployment Managerページでさっき作ったのを選択しろ。「SSH」をクリックし、SSH起動するのを待て。起動したらおもむろに以下のコマンドを打ち込め

sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1
sudo /opt/bitnami/ctlscript.sh restart nginx

そして消えた事を確認しろ。

◆確認しろ

引っ越し先がちゃんと動いてるかどうか確認しろ。ログインログアウトとかの動作確認をしろ。

Login Rebuilderってプラグインが何気に停止していることに気づいたから再セットアップした。いつから止まってたのかわからん。引っ越しで停止したんだろか？

◆ヨダン

TSLにしたろうと思ってこのページ眺めて「おーええやん」と思って一応ググってたらこんなページが出てきて「bncert-toolがnginxを対応しれ！」という思いが生まれた。

しばらくやり過ごすためにCloudflareを使ってTSL対応する。

◆ドメインをカスタムしろ

DNSって知ってるだろうか。わからないなら下の記事がオススメです（ダイレクトマーケティング）

IPアドレスとかドメインとかDNSのはなし

よし。DNSについて理解できたな。じゃあ移行していく。

サイトはまだTSLに対応していないわけだが、Cloudflareという無料なアイツを使ってTSL対応しながらCDNも導入しちゃう。別にそんな画像使ってないから個人的にはCDNいらねぇけど。

Cloudflareに行ってアカウント作れ。んで、ダッシュボード行ってブログのドメイン入れろ。サブドメインにブログ入っててもいいんだけど、親のドメインまでCloudflareされちゃうから気をつけろ。そしてサブドメインのサブに入ってる人は知らない。TSLできないかも。自分で調べろ。

プランはFreeを選べ。

「DNS設定しろや」と言われるので、もともと使ってたDNSのレコードを眺めながら、必要なやつ（AとかTXTとかAAAAとかCNAMEとかNSとか）をCloudflareのDNSにポチポチとコピーしろ。

「ネームサーバー設定してこい」とか言われるけど、後でいいから、まぁ適当にコンテニューしろ。

Deployment Managerページで「外部アドレス」が分かるから、コピれ。（CloudflareのDNSにおいて、）ブログの載っているドメイン（あるいはサブドメイン）のAレコードをそれにしろ。

◆TSLしろ

ダッシュボード行ってサイト開いて「Crypt」を開け。下の通りにしろ。

  • SSLが「Full」
  • Always Use HTTPSが「On」
  • Automatic HTTPS Rewritesも「On」

◆向き先変えろ

※こっからブログの向き先が変わるから注意して操作しろ。「ドメインの浸透」というワードに聞き覚えのない人間はとりあえず言う通りにしろ。

元使っていた（つまり今使っている）DNSの、ブログURLを指しているレコードをNSにしたい気がする。

例えばだけど、このブログは「insider」サブドメインにいる。もともとCNAMEで別のドメインを指定していた。それを「こっちのネームサーバーで処理してね」っていう風に設定すればいいわけだ。

（元使っていたDNSで）NSレコードを作り、ブログの載っているドメインをNAMEに指定し、VALUEをCloudflareのネームサーバーにしろ。2019年6月現在では「erin.ns.cloudflare.com」と「newt.ns.cloudflare.com」の2つだ。両方設定しろ。

最新のネームサーバーを確認したいならダッシュボード行ってサイト開いて「DNS」を選んだら「Cloudflare Nameservers」とかいう見出しを探せ。

NSレコードができたから、ブログを指していた「CNAME」あるいは「A」レコードはお役御免だ。消せ。それにより向き先が変更される。なんか壊れたんなら慌てて元に戻せ。

そいで、サイトを開いてhttpsで開けるかどうか確認しろ。なんかhttpsの反映までにラグがあるらしいからチンポでもしごいてろ。

◆Azureとめろ

停止しろ。不安なら止めるな。止めても別に問題ないはずだけど一応サイトをチラ見しろ。サイト表示できなくなってたらDNSの設定おかしいから疑え。

この後の手順全部終わらせて、なおかつ不安じゃないならインスタンスを葬るくらいの男気を見せろ。

◆記事とか編集できるようにしろ

なんか記事編集しようとしたら

更新に失敗しました（笑）

とか言われた。ふざけんな。せめて理由を教えろ。

Chromeくんも

このページは承認されていないソースからのスクリプトを読み込もうとしています。（笑）

とか煽ってくる。くやしい。

しょうがないからChromeくんのF12でConsoleを確認したら。

Mixed Content: The page at なんちゃら was loaded over HTTPS, but requested an insecure script うんにゃら . This request has been blocked; the content must be served over HTTPS.

とか喚いていた。うおおおお黙れ！

つまり「おめぇページはhttpsのくせにスクリプトはhttpなんだな！オラわくわくすっぞ！」という無慈悲な死刑宣告だ。

「えー」とか言いながらWordPressの「設定」⇒「一般」を開いた。

  • WordPress アドレス
  • サイトアドレス

って欄があるんだけど、それがhttpじゃん。さらに悪いことに編集不可になってっしよ（激怒）

しゃあない。さっきのSSHってあったじゃん？それでwp-configをいじる。「wp-configいじっちゃ駄目だよ」派がいるんだけど、すでにbitnamiくんが奪っちゃってるから構わず犯す。

糞あぶないから、落ち着いてやること。移行したときのバックアップファイルがあるから壊れても死ぬわけじゃないが。

さっきと同じ手順でSSH開いて下記コマンドを打つと、wp-config.phpを編集できる。編集できるんだが、操作がむずいから注意しろ。余計なキーを押すと死ぬ。ショートカットキーとかは忘れろ。

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php
  • アローキーでカーソルを移動。マウスは不可。
  • define(‘WP_SITEURL’)とか書かれている記述を探す。
  • 右っかわに「http://」とか書かれているんで、「https://」的な感じで「s」を追加する。
  • define(‘WP_HOME)の行もそうする。
  • Ctrl + Xでエディタを終了。
  • 「保存する？」って聞かれるから「y」を入力。
  • Enterで確定。

これでよし。一般でURL書き変わってるのを確認しろ。そして記事が編集できることを確認しろ。

◆リンクなおせ

All-in-One WP Migrationくんが、自サイト内リンクを全部移行先のIPアドレスに変えてしまった。かわいい。

<h1>タグを<h2>に一斉置き換えしたときに世話になったSearch Regexというプラグインでリンクを置き換える。

このサイトでは以下の感じになった。お前のサイトに見合う感じにしろ。

◆Search pattern
http://34.67.37.11/
◆Replace pattern
https://insider.10bace.com/

「Replace」ボタンで変更をレビューできる。変更結果でもってページを開けることを確認し、「Replace & Save」ボタンで置き換えちゃいなさい。

◆ネームサーバー変えろ

ドメインを購入したサイトとか行って、ネームサーバーの指定をCloudflareの奴らに変えろ。

変えたからって、元のDNSを消しちゃあダメです慌てんぼさん。3日くらい待ちなされ。

◆Cloudflareの拡張機能

入れていいよ。プラグインで「Cloudflare」って検索すればそのものがでてくるからインストールしたり、しなかったりしろ。

「Optimize Cloudflare for WordPress」って項目があるんで、「Apply」って押せばいいよ。でも親のドメインまで影響するから注意な。あと「Automatic Cache Management」も「On」にしとけ。

Cloudflareくんはページをキャッシュしてくれるんだけど、それゆえにデザインの変更が反映されなかったりする。待ってれば反映されるんだけど、「今すぐキャッシュ消したいナリよ」と思ったら「Purge Cache」しろ。

◆画像ファイルとかを外だし

参考にしたページでやってたんだけど、とりあえず興味ないね。やりたい人は参照しろ。

◆IP Geo Block

GCPくんは中国とオーストラリアからのアクセスについて料金を課すらしい。やめて（懇願）。でもまぁどうでもいいわ（レ）。無料枠をぶち抜いてくるほどじゃねぇだろ。ちゃんと調べてねぇけどCloudflareくん挟んでれば何とかなるんじゃねぇか？

対策したい人はIP Geo Block入れればいいらしいよ。

◆PhpMyAdmin

特にいらねぇかな。欲しいならここみて頑張れ。

◆ちゃんとHTTPS対応

Cloudflareくんのおかげさまでhttpsなんだけど、本体のほうはhttpですね。でもとりあえずbncert-toolがnginxに対応するまでいいや。

◆スクリプトの遅延読み込み

WordPressだからスクリプトなんざ後で読めばよろしい。

「Speed」のしたに「Rocket Loader」というものがあるんで、Onにしておいた。

◆Cloudflareで Error 524 A timeout occurred

なんか表示できなくなった。GCPみたら「microじゃむり」っていわれた。日に300アクセス程度で死んじゃうってなに。

Compute Engineの画面からsmallにスケールアップした。とりあえず無料枠でいけるしね。同じ症状になったらとにかくGCPみてこい。

ログ（モニタリング）を確認したらディスクIOで読み取りが58回/分からの書き込み7MB/分とか良く分からん動きをしていた。CPUは100%に届きかけていた。原因は不明。なんかプラグインが悪さしたとか？

つまり、引っ越し後とかは同じ症状が発生しうるということじゃなかろうか。インスタンスちいさいならあんまり大きい負荷かけちゃだめね。

⇒追記：2019/7/16

MySQLくんでした。レプリケート（複製、複製による冗長化）やらデータ復旧で使える操作ログを生成しまくって自爆していた。

MySQLに頑張ってログインしてbinlogをパージしなければならない。

大障害起こしました

で、SSHでログインしてMySQL以外を停止してMySQL再起動したりでログをパージして

SET GLOBAL binlog_format = 'STATEMENT';

かまして「my.cnf」ファイルで

binlog_format=statement
expire_log_days = 3

追加した。

https://dev.mysql.com/doc/refman/5.6/ja/binary-log-setting.html

◆結論

GCP触ったりCloudflare触ったりSSHでmysqlのコマンド叩いたりして楽しかったです。（作文）

「わかんねぇ」とか「わかりづれぇ」とか「死ね」とか感じたらコメントしていけ。