GCPでWordPress環境の立上げ手順の最新化状況サマリ

ブログ運営
2019.08.15

開始はこのサイト： GCPの無料枠でdev.toなみの爆速WordPress環境を構築する
この記事のおかげで当ブログが立ち上がりました。2018年の記事であり内容は現在でも全く通用します。しかし時間の経過により徐々に陳腐化すると予想されます。この記事は趣味レベルでどこまで陳腐化に抗えるかの記録となってます。

最新化状況サマリ

  • ハンパな状態でも公開します。試したことは更新します。
  • 開始より良くなったところは、下記表で青文字で表記
  • 本ブログとは全く別の環境でテスト
  • 当ブログの環境はこちら。
  • 更新内容は記事を参照。まとまった手順は現在なし。（ニーズあれば別途検討）
現在の最新当初
プラットフォームGoogle Cloud PlatformGoogle Cloud Platform
マシンタイプf1-micro
（vCPU x 1、メモリ 0.6 GB）		 f1-micro
（vCPU x 1、メモリ 0.6 GB）
OSUbuntu 18.04 LTSUbuntu 16.04 LTS
ドメインfreenomfreenom
DNSGoogle Cloud DNSCloudflare
CDNなしなし
karelieではCloudflareの紹介あり
当サイトでは未使用
Docker構文version “3”version “2”
nginx-proxydocker-compose
├　jwilder/nginx-proxy
└　jrcs/letsencrypt-nginx-proxy-companion
wwwとnon-wwwを同じサイト扱いに可能		 docker-compose
├　jwilder/nginx-proxy
└　jrcs/letsencrypt-nginx-proxy-companion
データベースdocker-compose
└　mariadb:10.4.7		docker-compose
└　mariadb:10.1.21
wordpressdocker-compose
└ wordpress:latest		 docker-compose
├　primestrategy/kusanagi-nginx:1.10.0-1
└　primestrategy/kusanagi-php(v7.0.11頃のものをカスタマイズ）

変更点１：Ubuntu16.04LTS⇒Ubuntu18.04LTS

【第3回】GCPの無料枠でdev.toなみの爆速WordPress環境を構築する（Google Cloud Platform編）

「Ubuntu16.04で構築すること！」ってめっちゃ書いてある。でも、新しいのにしたいです。

LTS：Long Time Supportの略で、Ubuntu1804LTSは、2023年までサポート、2028年までセキュリティアップデートが続くので最新の方が安心です。 さてubuntu18.04では動くのでしょうか。

やったこと

$ export compose='1.24.0'
$ sudo curl -L https://github.com/docker/compose/releases/download/${compose}/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

補足

色々試行錯誤がありその際に以下コマンドを切っています。影響不明。いつか検証します。

$ sudo curl https://raw.githubusercontent.com/prime-strategy/kusanagi-docker/master/install.sh | bash

変更点２：wwwとnon-wwwの同居

前回との差分

  • DNSにAレコード追加
    • 今まで、xxx.comのみに対し、www.xxx.comを追加
  • VIRTUAL_HOSTの変更
    • 旧：VIRTUAL_HOST: xxx.com
    • 新　VIRTUAL_HOST: xxx.com,www.xxx.com
  • LETSENCRYPT_HOST
    • 旧：LETSENCRYPT_HOST: xxx.com
    • 新： LETSENCRYPT_HOST: xxx.com,www.xxx.com
  • VIRTUAL_HOST_ALIASを追加
    • 追加：VIRTUAL_HOST_ALIAS: www.xxx.com
  • コンテナを強制再構築
$ cd /home/wordpress/kusanagi-1/
$ sudo docker-compose down
$ sudo docker-compose -f /home/wordpress/kusanagi-1/docker-compose.yml up -d --force-recreate

参考

jwilder/nginx-proxy環境でwww有無のリダイレクト【SSL対応】

変更点３：mariadbのバージョンアップ

前回との差分

  • mariadbバージョン指定
    • 旧： image: mariadb:10.1.21
    • 新： image: mariadb:10.4.7
  • kusanagiコンテナ、mariadbコンテナを強制再構築

変更点４：docker-composeの構文のversion3への変更とDockerボリュームの整理

docker-composeファイルで、volume名が適当なため、さすがに意味が分からないです。これを整理していきたい。

前回との差分

この挑戦、何気にハマってすごく時間かかりました。 要点だけまとめておきます。そろそろgit管理し始めないとつらいか。変更履歴がよくわからなくなってきた。

  • 全てのdocker-composeを停止。※docker-compose.ymlのあるディレクトリに移動し、下記コマンド
    sudo docker-compose down
  • いったんお掃除のため、以下コマンド
    sudo docker system prune
  • Dockerボリュームは消えない。
    • sudo docker volume ls 　で確認、
    • sudo docker volume rm ボリューム名 でお掃除
  • ymlの修正
    • docker構文versionを3へ
    • volumes節を追加
    • volumes節の記述に従いvolumes句を修正

対応後の姿

キレイになりました。 なお、nginx-proxyのvolumeはどうしても一つ、任意ボリュームができてしまう。名前の付け方がわからなかった。いつか対応したい。

エラー対応メモ

  • version “3” にするとvolume_fromが使えない件
  • ERROR: Named volume is used in service but no declaration was found in the volumes section.
    • volumes節を明記すればOK.
  • 『nginx: [emerg] unexpected “>” in ファイル名』
    • ボリューム名称を分離するなどで解決
  • Label the nginx-proxy container to use with ‘com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy’.
    • labels句と、次のキーワードを追加”com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true”

参考サイト

変更点4：kusanagiのバージョン追随・・・うまくいかず・・・

変更前の状況

docker-compose
├　primestrategy/kusanagi-nginx:1.10.0-1
└　primestrategy/kusanagi-php(v7.0.11頃のものをカスタマイズ）

これを少しでもバージョンを上げたい

着眼点

上記から、すでに3年近く経過している。元々の karelie 手順でkusanagi-php7をビルドし直している理由はjpegの扱い。本家ソースでは2018年11月30日のマージでjpeg対応されているように見える。うまく対応すれば手順の簡略化が狙えるはず。

よりどころとなるサイト達

最新化は失敗

2019/08/15時点の最新はこれだ。やってみるぞ。

エラー発生

sudo docker logs [コンテナID]

/docker-entrypoint.sh: line 33: can’t open default.conf.template: no such file

エラー対策をしていくが、、、ゴールにたどり着けず

実験中＆苦戦中。。。バージョンをちょっと古めにしたけど、うまくいかず。趣味の範囲では限界か。。。

  • /docker-entrypoint.sh: line 30: DOCUMENTROOT: DOCUMENTROOT
    • 環境変数が色々必要になったようなので追加して対応
  • /docker-entrypoint.sh: line 30: can’t open default.conf.template: no such file
    • イメージファイルにはtemplateファイルがない？謎だな。
    • 応急処置として、dockerの外にdefault.conf.template 作ってvolumesでマウントしてみた。。。
  • /docker-entrypoint.sh: line 30: can’t create default.conf: Permission denied
    • はぁ、こんどは、default.conf が作れないと。/etc/nginx/conf.dへ権限を持たないユーザで実行しているってことか。user:rootで実行してみる。
  • /docker-entrypoint.sh: line 50: can’t open fastcgi.inc.template: no such file
    • ん？やっとline30の地獄から抜けたが、、、またtemplateが見つからないと。
    • もしかして、イメージファイルにはtemplateファイルなしの、全滅ってことか。。。
    • ここをgit cloneして、files/tempatesを/etc/nginx/conf.dにマウントしてみる。
  • dockerコンテナは上がるようになったが、「502 Bad Gateway」が止まらない
    • default.conf.template とか、ssl.incとか、動いている設定を参考にに書き直し。
    • kusanagi-nginxのポートが8443ベース（昔は443ベース）に変化している点が未考慮だったので微調整。
      • note:「502 Bad Gateway」 は、名前解決OKでproxyより先でNGのケースらしい。
  • 「404 not found」となる
    • きづくと、/home/kusanagiが空っぽ。ここのwordpressのファイルってどうやってできてたんだろう！？
    • kusanagi-nginx:1.10.0-1 だと /home/kusanagi 配下にドメイン名と同じフォルダができる
    • kusanagi-nginx:1.17.3-r0 だと/home/kusanagiは以下にドメイン名と同じフォルダができてくれないようだ。ここに違いがありそう。
  • ACME server returned an error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: {ドメイン名}
  • Let’s Encrypt  の上限にもぶつかったため、次の更新は別途

参考サイト

変更点5：普通のwordpressではどうかを確認。いける。（2019/8/24追記）

ここでの方針

  • いったん整理。kusanagiではなく、waorpressイメージの最新で動作するかを確認

wordpressで実施

  • wordpress最新でOK
  • httpsの機能が怪しく、画面レイアウトが変
    • プラグイン「Really Simple SSL」を利用して解決
  • kusanagiがデフォルトで盛り込んでいる部分が機能しない。
    • 当然だが、KUSANAGIメニューはでない。速度影響を別途調査

計測１回目

  • Add Expires Headers
    • プラグイン「Add Expires Headers」をインストールし再テスト。A(１００)に改善！
  • Use a Content Delivery Network (CDN)
    • 現状ブログでもCDNは使ってないのでここはやらない。
    • CDNは設定を誤ると、管理画面がキャッシュされるなどリスクがあるらしい。いつか研究したいところ。今はCDNなしでもしとする。

計測２回目

  • うん、個人の立上げ時としては十分。
  • 当初参考記事は、320msで圧倒的ですが、それをマネした私の現状サイトは、CDN使ってないし。そういえば、現状は？

参考：2019/08/24時点、当ブログのスコア（CDN未使用）

  • うわ。。良くない。。。現状サイトの改善も考えねば。記事が増えると画像なども増えるのでインストール直後の計測とはまた違ってくる。要検討なのかな。

あとがき

当ブログは2020/4/25にkusanagiからbitnami-wordpressに移行しました。本記事の研究も残念ながら道半ばのまま、終わります。

このブログは、将来に備えた技術力アップや資産運用を情報発信していきます。Twitterもやってますので良ければフォローしてください。 是非意見交換しましょう。

ブログ運営
スポンサーリンク
スポンサーリンク
takaをフォローする
taka
スポンサーリンク

コメント

  1. 【ブログ立上げ】無料でWordPressを入手。手順サイトと採用技術を紹介。 | アフターファイブ改革 より:
    2020年2月16日 5:26 PM

    […] 【随時更新】GCPでWordPress環境の立上げ手順の最新化状況サマリ […]

    返信
  2. 当サイトの動作環境 | アフターファイブ改革 より:
    2020年4月19日 7:09 PM

    […] […]

    返信
タイトルとURLをコピーしました