何言ってるか分からねーと思いますが、SEO対策を始めた人間にとって、Google Search Console に対するsitemap.xml読み込みは死活問題なのです。いくら良いコンテンツを作成しても、Google様の検索に引っかからなければ、意味がないのです。 すいません。 田中(゜p゜)もアフェリで一発当ててえとかじゃなくてこのサイト運営に月額1000円ほどかかるので、そのくらいは回収させていただきたく、SEOを実施しております。 事象 ↓コレ。いつ何時、何回やってもsitemap.xmlが読み込まれない。google様で「sitemap ＋ 読み込まれない」で検索すると、Googleのサポートに山ほどトピックできてて、どれも解決してない根深い問題。中の人も、たぶんバグで読み込まれてるよ、みたいな適当な回答。 ワークアラウンド WordPressでGoogle XML Sitemapsプラグインを入れます。 プラグインを適当に設定します。 search ConsoleのサイトマップのURLに「/index.php?xml_sitemap=params=」と入力します。 読み込みが成功します。 このURLというのは、パーマリンクの設定が基本(無効)じゃないと出てこない、プラグインが生成しているURLです。 つまり、プラグインがパーマリンクとしてsitemap.xmlを見せとるということです。 ですが、なんでこっちの生のURLの方がsearch console通るのかは全然分かりません！ その後 残念ながら、他のプラグインでも、パーマリンクで特定のURLを生成しているものがいくつか発覚し、パーマリンクを使わないという昨日の方針はもろくも崩れ去りました。つまりまたもやリンク修正地獄。 ま、今回は生リンクで貼り直してたんで、修正してなくても問題ないんですけどね。 なんか、このあたりまとめて個人用のWordPressの運用ベストプラクティスとしてまとめようかしら。

たぶんテーマの挙動なんだろうけど、スラッグの構造が変わってしまい、リンク全部貼り直しました。 スラッグとは サイトのURLの特定の文字列を、Wordpressの記事IDに紐付ける仕組みで、例えば スラグ無しオリジナル https://tmp-net.biz/?page_id=189スラッグ有り https://tmp-net.biz/記事一覧/ITコンサルタントとは？ という感じで、サイト構造に合わせてURLをか分かりやすいものにできる便利な機能で、田中(゜p゜)も気に入っていて使っていました。 SEOサイトで、検索にかかりやすくなるので日本語URLオススメ！みたいな記事もあったしね！ テーマ適用後に小トラブル ただ、先日採用したテーマは、バリデーション(入力値)チェックでスラッグに日本語、英大文字が使えないようなのです。 具体的にいうと上のURLは、 https://tmp-net.biz**/page-392/it/** という感じに強制変換されてしまうのです。 当初は新規作成した記事だけがそうなっていて、苦々しい気持ちでいっぱいだったんですが、それでも我慢して使ってました。 そして大事故 ある日、サイトのメニュー構成のパートで手が滑ってしまい、階層がずれたメニューを元に戻したところ、結果メニュー配下の記事のスラッグが全てバリデーションチェックの対象となってしまう大事故に。 つまり固定で書いてたリンクも全てリンク切れ。 リンク修正地獄のはじまりです。 修正に当たって 取り急ぎ翻訳ツール使っての英語化や、やっつけでのリンク修正も考えましたが、テーマ変えたり,環境変えたりして事故ったらたまらんので、WodPressのOriginに近いものにしよう、ということで、当サイトの内部リンクは全てスラッグを止め、WordPressのページID表記となりました。 リンクチェッカー使ったりして場所は確認したけど、修正はほぼ手動。 しんだ。 結果 階層構造ではなくなったけど、まあシンプルにはなったので、田中(゜p゜)としては満足。 あと、階層構造と日本語化を勧めるSEOサイトには憎しみの気持ち(笑) ただ、影響は内部だけかと思ったら、外部からのリンクや、検索結果のリンクが全てリンク切れに。orz いや、当サイトはまだ1ヶ月ちょっとしか経ってないので、影響は最小限と思われますが。 教訓 テーマも、スラッグ機能も便利で、色々やってくれるスグレモノですが、何をやってるのかを理解して使わないと、事故った時にえらいことになるんだなー、というのが教訓でした。 あと、普段はいい加減なのに、こういう構造とかが異常に気になる自分の性格はなんとかしたい。 怖いし、めんどくさいので触らない、というのも選択肢としてはアリだと思うんですよね。

テストサイトがあまりにうまく行ったので、勢いで移行しちゃいましたが、デプロイ時のTypoやテーマの挙動に苦しみました。 が、ようやっと今日になってそこそこ納得行く結果になったかもしれない。 これを契機にAdsenseも配置してみましたが、ユーザビリティを損なわずに上手く配置できた。…気がする。 添付画像の赤枠が腐ってたキャッシュで、ココにIPが入っちゃってました。そのせいか、サイトのスピードも落ちていたような。 ※たぶんテーマが悪いんじゃなくて、田中(゜p゜)の使い方がトンチキなだけ。 今回の結果を受けて、GAE移行のエントリに、運用時の注意点も追記しました。 はー。疲れたわぁ。

転職前のボーナス期間も今日までなので、サイトの仕上げにかかってます。 やった内容は以下二点。 軽量化・デザイン向上目指してLuxeritasテーマの導入 AddSenseの導入 しかし、GAEの仕様、Adsenseの仕様、テーマの仕様に苦戦…。 別々にやればよかったんだけど、テーマ入れたタイミングでAdsenseのOK出るんだもんなー。もうグダグダです。 苦戦ポイント そもそもLuxeritasとAddsenseの仕様把握に苦戦 LuxeritasのjsコードにローカルIPが埋め込まれており、取り除くのに苦戦 直したと思ったら、GAEのエッジキャッシュが効いてすぐには反映されず app.yamlにTypoあり、jsじゃなくてjsiを対象にしてしまってた。バカすぎ。 ChromeのF12で赤字探してエラー潰しまくってるんですが、田中(゜p゜)のPCのブラウザ、シークレットタブ、スマホ、ぜんぶ見た目が違います。 一体全体ユーザ様からはどう見えてるんだろうか。 あと、せっかくPageSpeed(Googleのサイト構成チェックツール)で、前のテーマから30ポイント近く向上したのに、Adsenseのせいで元に戻った。orz いや、自分の所のツールなんだから、少し甘くしてくれても良さそうなものなのに。 昔々、Webサイトを手で全部書いてたので、コンポーネント組み合わせるだけだろー、とか思ってたら、ぜんぶ高機能すぎてホントウに大変です。 イマドキのWebエンジニア様って大変なんだなぁ。

結局、GAEの使い勝手がかなり良くなっていたので、サラッとこのサイト移行して記事化しちゃいました。 WordPress on GAEに移行 GKEどうしよ…。 意外とハードが深く絡んでて、個人で検証するにはしんどいんだなぁ。 ちなみに田中(゜p゜)は転職に伴い有給休暇を頂いており、10月から新しい仕事になりますが、ここまで3割英語、3割ブログ4割GCPという感じでしたね。 前のお仕事が、なかなか勉強の時間も取れないようなレガシーなお仕事だったので、学習意欲という面ではだいぶ満たされました。

いやー、ハマりました。4時間位無駄にしてしまったかも。 ハマったので備忘録ついでにワークアラウンド書いておきます。 スクリーンショット取っておかなかったのが悔やまれますな。 事象 GCEにSSHアクセス時に、「Permission denied (publickey,gssapi-keyex,gssapi-with-mic).」エラーが出る。 ローカルSSHでもクラウドシェルでも事象は同じ 鍵を手動作成しても事象は変わらない。 特定のプロジェクトだけで事象が発生 正常なプロジェクトと比較すると、GCEの「メタデータ」に鍵が作成されている。何度消しても蘇る。正常なプロジェクトは、「認証鍵鍵生成」タブに生成される。 参考にしたサイト(外部リンク) 同様の事象で悩んでた方。田中(゜p゜)はこれで解決しなかった。 https://qiita.com/keisukeYamagishi/items/baff3383a95bdd829636Google公式SSHトラブルシューティング。相変わらずわかりにくい…。 https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh?hl=jaワークアラウンド ダメだったときには次に行く感じで、上から順に実行してます。これで鍵の再作成が走り、だいたい復旧します。 任意のユーザ名はローカルのログインユーザに合わせ、任意の鍵名はホントに任意です。どうせ再作成されるので。 コンソールのGCEのページで出力されるコマンドに、以下の太字部分を追加。 gcloud compute ssh –zone “<ゾーン名>” “<任意のユーザ名>@<対象のマシン名>” –project “<プロジェクトID>” –ssh-key-file=~/.ssh/<任意の鍵名> –force-key-file-overwrite 「1」に加えて「rm-rf ~/.ssh/google*」実行。 「1」「2」に加えて、GCEのメタデータのsshKeys(任意のユーザ名に対応するもの)、認証鍵生成のタグにあるユーザを全て削除。 ただ、**メタデータの削除については、正直プロジェクト内での設計を確認したほうが良い**です。他に影響出てしまうかも。 あくまでワークアラウンドなので、根本原因、解決策お持ちの方は教えて下さい… トリガー？ 正常なプロジェクトとの違いは以下のような感じです。 GKEでクラスタ作った AppEngine、およびGAEのAPIを有効化した CloudSQL利用のためにサービスアカウントへの権限付与、およびAPIを有効にした。 他プロジェクトからイメージ引っ張るためにIAMをゴニョゴニョした 参考サイトにもありますが、正直どうしてこうなるのか全く持って不明です。 こういう時、AWSなら事例がたくさんあって楽なのにな…。

前回のKusanagi on GKEギブアップからまだ懲りてません(笑) 今度はGoogle App Engine(GAE)を使ってWordPressを構築します。 ちなみにStandardの方で構築するので、CloudSQL以外は、使った分だけお金を支払えばよいというスグレモノ。しかもスケーリングも証明書も、何もかもやってくれるオマケ付き。 間違えてフレキシブルで構築すると、自由度が高い代わりにGCEインスタンス代がコンスタントにかかってしまうので注意です。比較表はこちら(外部サイト) https://www.serversus.work/topics/5jbu7y90jk81kcdqfzf0/進捗状況 今回のは実はもうサイトできてます。既存のサイトからの移行方法も検証済。 サイトはこちら。 ※2020/09/29追記 移行しちゃったのでもうありません。 ハハッ。 田中(゜p゜)の技術者としての能力も捨てたもんじゃないね！ というか、田中(゜p゜)は昔この構成でWordPressやったことあるんですけどね！ 最近チュートリアルがアップデートされて、画像ファイルとかの扱いがさらに容易くなりました。 GKEであれだけ苦戦してたのがウソのよう。 GAEサイコー! 運用上の注意点 ただし、そんなに上手い話は世にはなかなかないのです。 カンタンにできるから真似してみよう！ と思われる方のために注意点。 この構成の一番の問題は、GAEに上げちゃったが最後、WPのGUIから更新できないものが発生することです。 更新できないものを以下に並べます。 プラグイン(設定は除く) テーマ(設定は除く) 投稿・固定ページへの直接画像貼り付け(メディアライブラリからはOK) 3つともかなり致命的だと思います。 これに関連してWP側でエラーが出ることがありますが、そもそもGAEはディスクに書き込めないものだというのを知っておかないと混乱します。 回避方法 カンタンにいうと、ローカルにサーバを立てて、そこで管理します。 GAEはCloudSQL Proxyってのを使わないとCloudSQLには接続できないので、ローカルにも同じプロキシを入れてDBにアクセスできるようにします。 図中の①です。 また、ローカルのWordPressは、環境構築した後、yaml書いてGAEにデプロイします。 図中②の部分です。 じゃあ更新はどうするのかというと、ローカルにPHPサーバ構築して、WordPressのGUIを動かして更新します。 記事はDBに書かれるので特にアクションは必要ないですが、画像、テーマ、プラグインを更新した場合は②のデプロイが必要になります。 デプロイはワンライナーですけどめんどくせえ・・・。 けど、WordPressをクラスタ化したら、どのみち更新用の端末とか必要になってきそうだしなー。 構築方法 それでもやりたい方のために、構築を方法を書きます。 つ Googleのチュートリアル。 https://cloud.google.com/community/tutorials/run-wordpress-on-appengine-standard?hl=ja …というだけでは投稿の意味がないので、注意点を少し。 チュートリアルにミス。 ×php vendor/bin/wp-gae ○php vendor/bin/wp-gae create WP CLIのインストールは、チュートリアルじゃなくて公式のほうが良い。 https://wp-cli.org/ja/ サーバの作り方が書いてないが、php、php-mysqlインストールして、以下で行ける。 cd <WordPressのフォルダ> php -S 127.0.0.1:9000 ブラウザでhttp://127.0.0.1:9000/にアクセス。 ただし遅いので、レスポンス気になるならきちんとサーバ立てたほうが良い。 更新の早い世の中ですから、公式と最新版のギャップは大きくなっていくものと思われます。もちろんこのブログもです。 以下、既存のWordPressサイトからの移行方法ですので、新規の方は見なくて良いと思います。

タイトルに書いた通り今回を持ってギブアップでございます。残念です。 以下に経緯と理由書きます。 Kubenetesチャレンジ その1 Kubenetesチャレンジ その2 Kubenetesチャレンジ その3 Kubenetesチャレンジ その4 そもそもの要件は何だったのか やってるうちに自分でも何がしたかったんだか分からなくなってきたので今一度整理しますが、そもそもの要件は、「Kusanagi on Dockerのイメージそのままに、yamlちょろっと書き換えてGKEに上げたいなー」です。 こちらもKusanagi on Dockerやってらっしゃいますが、イメージは自身で作成されたものをGCRからPullする形になってます。 バージョンがコロコロ変わることを考えると、**公式DockerHUBからPullしてGKEにデプロイできないかな、**というのが狙いでした。 敗因 えー、簡潔にいうと、Kusanagiプロビジョニング時に利用するシェルスクリプトをGKE用にカスタマイズできない、もしくはカスタマイズにとてつもなく時間がかかる、からです。 以下の図を見て下さい。 青線はボリュームのマウント状態、緑はコマンド実行の流れです。DockerへのKusanagiプロビジョニングは**「kusanagi-docker(.sh)」で実行**されますが、ステップは主に以下の3つです。 ①変数から環境設定ファイル、dockerデプロイ用yamlファイル作成。 ②docker-compose経由でコンテナをデプロイ ③(たぶん)config用コンテナにゴニョゴニョして環境設定。ローカルで環境設定したWordPressをインストール。 ※簡略化するために、色々すっ飛ばしてます。 ①②は問題ないです。田中(゜p゜)がちょいyaml書き換えて、GKEに問題なくデプロイできてます。 問題は③です。 ちょろっとシェルスクリプト修正すりゃーkubectl化できる話じゃないのです。 ファイルが十数個にまたがってるのと、docker、docker-compose、wp-cliコマンドフル活用で、流れ追うのもやっと。そもそもコレをkubectlに変換すんの？ つうかできんの？ 立ち止まって考えてみた結果 そもそもの要件は「ちょろっとyaml書き換えてGKEに上げよう！」だったので、シェルスクリプトを重厚に書き換えるのは脱線しすぎです。 よしんばコミュニティへの貢献とかのために、頑張って田中(゜p゜)がシェルスクリプト書いたとしても、ろくでもない品質のために迷惑かけかねませんし、田中(゜p゜)もシェルスクリプトをマスターしたいわけじゃないです。 ※いや、仕事で2ヶ月くれるっつうなら頑張るけど…。 よって潔くギブアップ！ 残念ですけど、GCPにWordPressデプロイするとしたら以下の2パターンにしようと思います。 公式よろしく無難なハッピーセットでGKEにデプロイ Kusanagi on GCEでデプロイ 趣味のWordPressなら、後者のほうが圧倒的にコスパ良さそうですけどね。 仕事用にするんでも、後者はMySQLオミットしてCloudSQLに切り替え、コンテンツ領域をPersistentDiskにすれば、ロードバランサ＋オートスケーラーでブン回せそうですし。おすし。 今後の展開 なんでこのシェルスクリプトはDockerFileに置き換えないんだろなー、とか考えましたが、そもそもフツーのOSに載せていたスクリプトから派生しているようなのと、Kusanagiのロードマップやビジネスプランなどから、あまりパワーを入れたくない領域なのかもしれません。 田中(゜p゜)個人としては、Dev/Opsのインフラ領域について理解を深めたいので、それっぽいテーマ定めてKubernetesトレースしたいと思います。 skaffoldあたりやってみたいなー。 でも田中(゜p゜)プログラミング開発環境あんまりだからなー。

まだ続いてます(笑) 相変わらず、何かの問題解決目的に来た方は、ご期待に添えず申し訳ございません。 Kubenetesチャレンジ その1 Kubenetesチャレンジ その2 Kubenetesチャレンジ その3 しかし、その3で突っかかってた「Dockerでデプロイできて、MinikubeではPodのConfig中にコケる」事象は不本意ながら解決しました。↓ つまり、Minikubeではデプロイできないけど、GKEではデプロイでけた。 何じゃそりゃ。 ローカルの権限周りをトレースしてみたいけど、目的はローカルで動かすんじゃなく、GKEで動かすことなんだから、ローカルに固執する理由は何もない。 ということで、せっかく作った**ローカルのKubernetes(Minikube)環境は全部廃棄。 ** これで2GBくらいディスク空いたった。 よく考えたら、マシンリソース節約してコスト削減するために、開発環境を必要な時だけ上げとくなんてのは、当たり前のことだね。 あと、イメージPullするのにWi-Fiのギガ消費するのも抑えられるし。※田中(゜p゜)家はモビリティ重視でWiMAXなのです。 ということでその3の悩みはスッキリ解決。 あとはyamlゴリゴリ書くだけだぜー。 よーしお父さん、次の次あたりにKusanagi on GKEのタイトルで記事化しちゃうぞー！ 続く。

まあ案の定、詰まっとります。 今突っかかってるのは概ね2つ。 問題その1 デプロイ時権限差異？ Dockerでデプロイできたイメージが、Minikubeだとデプロイできない。どうも権限が違うっぽい。 PoDのログはコレ↓。具体的には、docker-entrypoint.shというスクリプトがファイル書き込みのPermissionでコケてる。スクリプト動いてるのはhttpdというユーザなのに、書き込み先はwwwというユーザに割り当てられてる。 Kubeさんのポリシーが関係してるのかもしれない。トレースが必要。 https://unit42.paloaltonetworks.jp/non-root-containers-kubernetes-cve-2019-11245-care/ うーん。 DockerFileからいじらせてもらえば権限問題もなんとでもなる気がするんだけどなあ。 問題その2 ローカル環境の理解不足 どうも田中(゜p゜)の入れたMinicubeってのはDockerコンテナの一つでしかないみたいで、リポジトリを共有してないっぽい。仮想マシンで動かすタイプもあるみたいなので、他のもそうかもしれない。 切り分けのためにDockerでデプロイしたコンテナをコミットして、ちょっとMinikubeで動かしたいだけなのに、Docker上でレジストリサービス用のコンテナ立てたりしないとならんらしい。 ローカルでファイル受け渡ししたいだけなのに、面倒なことです。 あと、Dockerリポジトリの切り替えがシェルの環境変数でしかできないのも面倒 上手くいってるもの Minikubeでのボリュームマウントと、環境変数の受け渡し(ConfigMap)は思ったよりずっとあっさりでけた。 要はKusanagiの環境変数ファイルをConfigMapに読み込んで、yamlで呼んでやればよいだけ。 https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files 結局ヤバそうなのは早々に片付き、想定もしてなかったのが課題になっとる感じ。 続きます。