【第5回】GCPの無料枠でdev.toなみの爆速WordPress環境を構築する(KUSANAGI Runs on Docker編)

投稿者:  |  公開日 :  |  更新日 :

はじめに

前回【第4回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する(ドメイン設定編)ではドメイン周りの設定を終わらせたので、今回【第5回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する(KUSANAGI Runs on Docker編)では前々回に構築したVMインスタンスに「KUSANAGI Runs on Docker」をインストールしていく。初心者にはちょっと難しい内容になるが、手順通りに進めていけば無事に構築できるはず。焦らずに進めていこう。

今回の作業は上記のサイトを参考にしている。上記のサイトの方法ではいくつかの不具合が残ったまま構築することになるが、今回ここで紹介する手順で構築すれば諸問題は解決することができる。

Google Cloud PlatformでのSSH接続

Google Cloud PlatformにSSH接続する方法はいくつかあるが、今回はブラウザから手っ取り早くログインできる方法で進めていく。

SSH接続 ブラウザウィンドウで開く

VMインスタンスの画面から「接続」→「SSH」→「ブラウザウィンドウで開く」を選ぶ。

SSH 接続を開始しますか?

SSH 接続を開始するか尋ねられるので「接続」をクリックする。

SSH 接続

するとターミナル画面が表示されるので、ここでコマンドを実行して構築していくことになる。

「KUSANAGI Runs on Docker」の環境を構築

さて、これからいくつものコマンドを実行していく。CUIに慣れていなくても一つ一つコマンドを実行していけば問題なく構築できるのでご安心を。

スワップ領域の設定

この環境で何度かWordpressを構築してきたが、サイトの移行などで大きいファイルを扱ったるする際にメモリの少なさが原因でサーバが非常に重たくなる。始めにスワップ領域を設定しておくことで、サーバの負荷を軽減することができるので設定しておこう。

作業の前にスワップ領域がないことを下記のコマンドで確認してみよう。

free -m

Swapが下記のように「0」と表示されていれば未設定。

              total        used        free      shared  buff/cache   available
Mem:            588         267          83          42         237         149
Swap:             0           0           0
  • Swapファイル領域を確保(処理に1ー2分かかる)

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
  • パーミッションを変更

sudo chmod 600 /swapfile
  • Swapの作成

sudo mkswap /swapfile
  • Swapを有効にする

sudo swapon /swapfile
  • Swapの確認

先ほど「0」になっていたのが「1023」となっている。

free -m
              total        used        free      shared  buff/cache   available
Mem:            588         256          69          42         262         159
Swap:          1023           0        1023

このままでは再起動した際にSwapファイルは無効になるので下記のコマンドで永続化する必要がある。長いコマンドなのでちゃんと行末までコピペするように。

sudo sed -i '$ a /swapfile                                 swap                    swap    defaults        0 0' /etc/fstab

念のために再起動。問題なくSwapが永続されているかを確認してみよう。

sudo reboot
SSH 再接続

上記のような画面が表示されるので「再接続」をクリック。再起動には1〜2分かかる。

もう一度下記のコマンドを実行しスワップ領域が確保されていれば大丈夫。

free -m
              total        used        free      shared  buff/cache   available
Mem:            581          91         327           2         162         376
Swap:          1023           0        1023

Dockerをインストール

次にDockerに必要なパッケージをインストールする。

curl -fsSL https://get.docker.com/ | sh

問題なく起動しているか確認するために下記のコマンドを実行してみよう。

sudo docker run hello-world

問題なくインストールされていれば

Hello from Docker!
This message shows that your installation appears to be working correctly.

と表示されているはずだ。

再起動しても自動的にDockerが起動するように下記のコマンドを実行。

sudo systemctl enable docker

問題なく動作するか確認するためにVMインスタンスを下記のコマンドで再起動させてみる。

sudo reboot
SSH 再接続

上記のような画面が表示されるので「再接続」をクリック。再起動には1〜2分かかる。

もう一度下記のコマンドを実行し動作していれば大丈夫。

sudo docker run hello-world

Docker-composeをインストール

次にDocker-composeをインストール。まず下記のコマンドでファイルをダウンロードする。

sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose

Docker-composeファイルの権限を変更する。

sudo chmod +x /usr/local/bin/docker-compose

問題なくインストールできているかバージョン確認してみよう。

docker-compose --version

問題なければこのように表示されるはずだ。

docker-compose version 1.21.0, build 5920eb0

これで下準備ができた。ではDockerを使って実際に環境を構築していく。

「KUSANAGI Runs on Docker」の構築

まず「KUSANAGI Runs on Docker」の環境を構築するにあたって、Let’s Encrypt(SSL)を登録するためのE-MAILアドレスと、いくつかのdocker-compose.ymlが必要となってくる。

下記のコマンドでファイルをダウンロードし、環境構築に必要な階層とdocker-compose.ymlのファイルを準備する。

sudo curl https://www.karelie.net/wp-content/uploads/wordpress.tar.gz --output "/home/wordpress.tar.gz"

ダウンロードしたファイルを解凍する。

sudo tar -zxvf /home/wordpress.tar.gz -C /home/

すると下記の構造でhomeの階層に必要なファイルが揃う。

+ home
  + wordpress
     + nginx-proxy
      - docker-compose.yml
      - nginx.conf
     + mariadb
      - docker-compose.yml
     + kusanagi-php7
      - Dockerfile
      + files
     + kusanagi-1
      - docker-compose.yml
     + kusanagi-2
      - docker-compose.yml
     - uploads.ini

コマンドでそれぞれのdocker-compose.ymlを編集していくので、先に権限も変更しておく。

sudo chmod 707 /home/wordpress/*/docker-compose.yml

Dockerネットワークを作成

Dockerのネットワーク環境を下記のコマンドで構築する。

sudo docker network create --driver bridge common_link

プロキシサーバーコンテナを起動(nginx-proxy)

下記のコマンドでプロキシサーバーコンテナを起動させる。

sudo docker-compose -f /home/wordpress/nginx-proxy/docker-compose.yml up -d

データベースサーバーコンテナの設定と起動(mariadb)

設定ファイル(docker-compose.yml)の変更

docker-composeで起動させる前に設定ファイル(docker-compose.yml)を4箇所、変更する必要がある。

  • データベースルートパスワード

  • データベースユーザー名

  • データベースパスワード

  • データベース名

下記のコマンドで「****」部分を設定したい文字列に変更して実行する。「****」部分を読者の設定したい文字列に必ず置き換えること。それぞれのコマンドをメモ帳などに一度コピーして****部分を置き換えれば作業しやすくなる。

また、「データベースユーザー名」「データベースパスワード」「データベース名」は、Wordpressのインストール時に必要になってくるので忘れないように。

  • データベースルートパスワードの設定変更

sudo sed -i -e "s/{データベースルートパスワード}/****/g" /home/wordpress/mariadb/docker-compose.yml
  • データベースユーザー名の設定変更

sudo sed -i -e "s/{データベースユーザー名}/****/g" /home/wordpress/mariadb/docker-compose.yml
  • データベースパスワードの設定変更

sudo sed -i -e "s/{データベースパスワード}/****/g" /home/wordpress/mariadb/docker-compose.yml
  • データベース名の設定変更

sudo sed -i -e "s/{データベース名}/****/g" /home/wordpress/mariadb/docker-compose.yml
  • 設定変更のサンプルコマンド

例えばデータベース名の設定を「wordpress」とする場合、下記のコマンドになる。

sudo sed -i -e "s/{データベース名}/wordpress/g" /home/wordpress/mariadb/docker-compose.yml

もしターミナルからのテキスト処理に慣れているのなら下記のコマンドで直接ファイルを変更しても問題ない。

vi /home/wordpress/mariadb/docker-compose.yml

コンテナの起動

上記の設定ファイルの準備ができたら下記のコマンドを実行してデータベースサーバーコンテナを起動させる。

sudo docker-compose -f /home/wordpress/mariadb/docker-compose.yml up -d

kusanagi-php7のビルド

次に公式の「kusanagi-php7」のイメージではPHPのJPEGに対応していないので、今回は独自にビルドする。JPEG処理に対応させないとサムネイルの作成や画像のトリミングなどの編集ができない。

ビルド用のファイルは先ほどダウンロードしたファイルに含めているので下記のコマンドを実行すれば良い。

sudo docker build -t kusanagi-php7 /home/wordpress/kusanagi-php7/

ビルドには10分ほどかかるのでしばらく待つ。

KUSANAGI WordPressサイト1(kusanagi-1)の設定と起動

設定ファイルの変更

こちらもdocker-composeで起動させる前に設定ファイルを2箇所、変更する必要がある。

  • ドメイン

  • E-MAILアドレス

下記のコマンドで「****」部分を設定したい文字列に変更して実行する。「****」部分を必ず置き換えること。

  • ドメインの設定変更

sudo sed -i -e "s/{ドメイン}/****/g" /home/wordpress/kusanagi-1/docker-compose.yml
  • E-MAILアドレスの設定変更

sudo sed -i -e "s/{E-MAILアドレス}/****/g" /home/wordpress/kusanagi-1/docker-compose.yml

例えばドメインの設定を「www.free-wordpress.cf」とする場合、下記のコマンドになる。

sudo sed -i -e "s/{ドメイン}/www.free-wordpress.cf/g" /home/wordpress/kusanagi-1/docker-compose.yml

ちなみに今回はCloudflareでサイト全体をキャシュさせるのでKusanagiのキャッシュ機能は無効にしている。キャッシュ機能を有効にしたい場合はdocker-compose.ymlファイル内の

  • BCACHE: “off”

  • FCACHE: “off”

部分を “on” に変更すること。

下記のコマンドでも変更可能。

  • BCACHEを有効にする場合

sudo sed -i -e 's/BCACHE: "off"/BCACHE: "on"/g' /home/wordpress/kusanagi-1/docker-compose.yml
  • FCACHEを有効にする場合

sudo sed -i -e 's/FCACHE: "off"/FCACHE: "on"/g' /home/wordpress/kusanagi-1/docker-compose.yml

コンテナを起動

上記の設定ファイルの準備ができたら下記のコマンドを実行してKUSANAコンテナを起動させる。

sudo docker-compose -f /home/wordpress/kusanagi-1/docker-compose.yml up -d

コマンドが実行し終わってもLet’s Encrypt(SSL)の処理に15分弱かかるので気長に待とう。(処理が完全に終わるまでは設定したドメインにアクセスしてもエラーになってサイトは表示されない。)

無事に処理が終わるとめでたくこのようにwordpressの設定画面が表示される。

Wordpress設定画面

もし下記のようにリダイレクトが発生しサイトにアクセスできない場合は「Cloudflare」の「Crypto」にある「SSL」の設定を「Full」にすること。

ダイレクトが発生

複数サイトの立ち上げ

今回は「[WordPress] KUSANAGI Runs on DockerでLet’s EncryptのSSL付きマルチサイトを立ち上げる」を参考にし、一つのサーバーで複数のKUSANAGIを起動するマルチサイト運用にも対応させているので、その方法も紹介しておく。

KUSANAGI WordPressサイト2(kusanagi-2)の設定と起動

まず、ドメインはあらかじめ「kusanagi.karelie.net」というのを準備しておいた。

kusanagi.karelie.net

次にすでにある「kusanagi-2」の階層内にある「docker-compose.yml」ファイルを「kusanagi-1」の時と同様に「ドメイン」「E-MAILアドレス」を変更する。

下記のコマンドで「****」部分を設定したい文字列に変更して実行する。「****」部分を必ず置き換えること。またコマンドの階層部分が「kusanagi-1」ではなく「kusanagi-2」となっていることも確認すること。

  • ドメインの設定変更

sudo sed -i -e "s/{ドメイン}/****/g" /home/wordpress/kusanagi-2/docker-compose.yml
  • E-MAILアドレスの設定変更

sudo sed -i -e "s/{E-MAILアドレス}/****/g" /home/wordpress/kusanagi-2/docker-compose.yml
  • コンテナを起動

sudo docker-compose -f /home/wordpress/kusanagi-2/docker-compose.yml up -d

これで二つ目のサイトが立ち上がる。こちらも起動するまで10〜15分ほどかかる。

「kusanagi-2」のフォルダを複製しdocker-compose.ymlファイル内の「kusanagi-*」部分を適正に変更すれば、一つのインスタンス内に三つでも四つでもWordpressを立ち上げることができる。おそらく小規模でアクセスの少ないサイトであれば10サイトほど同時に立ち上げても大丈夫なんじゃないかなと思う。

【第5回】GCPの無料枠でdev.toなみの爆速WordPress環境を構築する(KUSANAGI Runs on Docker編)」への13件のフィードバック

  1. ピンバック: 【第5回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する(KUSANAGI Runs on Docker編) | カレリエ | みんなの「転職」「起業」まとめ

  2. 丁寧に手順を示していただけており、素人ながらここまでたどり着きました、ありがとうございます。
    >無事に処理が終わるとめでたくこのようにwordpressの設定画面が表示される。
    の部分で自動的に画面が表示されないのですが、何かわかりますでしょうか。
    wordpressをほとんど触ったことがなく、取得したドメインや外部ipへの手動アクセスは試したのですがどうも違うようで。

    返信
    1. きめら 投稿作成者

      試していただいてありがとうございます。どのような画面が表示されますでしょうか?一応注意書きで「コマンドが実行し終わってもLet’s Encrypt(SSL)の処理に15分弱かかるので気長に待とう。(処理が完全に終わるまでは設定したドメインにアクセスしてもエラーになってサイトは表示されない。)」と書いてますので、少し時間をおいてからアクセスして見てください。

      返信
  3. ピンバック: GCP+KUSANAGI Runs on DockerによるWordPress環境構築の備忘録。 – Siren.

  4. shiki

    sudo docker-compose -f /home/wordpress/kusanagi-1/docker-compose.yml up -d
    ここで失敗です。
    pull access denied for kusanagi-1, repository does not exist or may require ‘docker login ‘
    で止まります。docker loginとやらが必要でしょうか。

    返信
    1. きめら 投稿作成者

      試していただきありがとうございます。このようなエラーに遭遇したことがありませんので正確な原因がわかりませんが、そちらの環境は今回紹介しているGoogle Cloud Platform で VMインスタンスでOSは「Ubuntu 16.04 LTS」を利用していますか?それとも違う環境でしょうか?

      また/docker-compose.ymlの内容は下の通りになっていますでしょうか?
      {ドメイン}と{E-MAILアドレス}は括弧ごと置き換えてますでしょうか?

      version: '2'
      
      services:
        kusanagi-data:
          container_name: kusanagi-1
          image: busybox
          restart: always
          stdin_open: true
          tty: true
          volumes:
            - /etc/nginx/conf.d
            - /etc/httpd/conf.d
            - /etc/kusanagi.d
            - ./data:/home/kusanagi
            - /home/wordpress/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
          command: /bin/sh
      
        kusanagi-nginx:
          image: primestrategy/kusanagi-nginx:1.10.0-1
          environment:
            VIRTUAL_HOST: {ドメイン}
            VIRTUAL_PORT: 443
            VIRTUAL_PROTO: https
            LETSENCRYPT_HOST: {ドメイン}
            LETSENCRYPT_EMAIL: {E-MAILアドレス}
            LETSENCRYPT_TEST: "false"
            PROFILE: {ドメイン}
            FQDN: {ドメイン}
            WPLANG: ja
            BCACHE: "off"
            FCACHE: "off"
          volumes_from:
            - kusanagi-data
          links:
            - kusanagi-php7:php
          external_links:
            - mariadb:mysql
          ports:
            - "443"
          restart: always
          networks:
            - common_link
      
        kusanagi-php7:
          image: kusanagi-php7
          external_links:
            - mariadb:mysql
          volumes_from:
            - kusanagi-data
          restart: always
          networks:
            - common_link
      
      networks:
        common_link:
          external: true
      返信
      1. shiki

        お返事ありがとうございます。
        申し訳ありません、何からの異常で、直前のビルド作業で失敗していたようです。
        これを再度ビルドし直す事で、正常に起動しました。
        また、Cloud flareの設定も変更しておらずリダイレクトの状態だったため、
        そちらも変更し、無事にWordpress画面へとアクセスできました。
        本当にありがとうございました!

        返信
          1. shiki

            全て設定して、無事爆速になりました。
            一番小さいインスタンスとは思えない凄まじい速度ですね。
            本当にお世話になりました。あなたが神です(確信

            以上、ご報告まで。本当にありがとうございます!

  5. ピンバック: GCPに引っ越した | アントニオもときのプロレス日誌

  6. Gontankun

    爆速のWordPressサイトが無料で構築でき、大変感謝しております。
    WordPressサイトのサイトマップをGoogleに通知すべく、Google XML Sitemapsプラグインを導入したのですが、Nginxを使っているので設定を変更するようアナウンスが表示されています。
    どの様に対応すれば良いか、指南頂けると幸いです。

    Webserver Configuration
    Since you are using Nginx as your web-server, please configure the following rewrite rules in case you get 404 Not Found errors for your sitemap:
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ “/index.php?xml_sitemap=params=$2” last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ “/index.php?xml_sitemap=params=$2;zip=true” last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ “/index.php?xml_sitemap=params=$2;html=true” last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ “/index.php?xml_sitemap=params=$2;html=true;zip=true” last;

    お忙しいところ恐縮ですが、よろしくお願い致します。

    返信
    1. きめら 投稿作成者

      返事が遅くなってすいません。当サイトでもGoogle XML Sitemapsのプラグインを使用しており同様の内容が表示されておりますが、問題なく動作しているので無視しています。別サイトでこの問題について書かれている記事がありますので、下記のサイトを参照していただけますでしょうか。
      https://www.yamamanx.com/sitemap-robots/

      ちなみに、nginxのconfファイルはDocker内にありますので、Dockerのコマンドで中に入ってconfファイルを編集する必要があると思うので、Dockerに慣れていなければちょっと変更するのも難しいと思われます。

      返信
      1. Gontankun

        回答ありがとうございます。
        私のところも、問題無く動作しているように見えますので、このメッセージは無視することにしました。
        このプラグインは、sitemapファイルを動的に作成するので、そのためのURLにリダイレクトする設定だと認識しています。この設定をしないと、静的なファイルを取得しようとして、Not foundになるという現象が発生するはずなのですが、なぜか問題無く取得できており、???な状態です。実際、Dockerの中を覗いてみても、静的ファイルは存在しない様に見えるので、動的にファイルが生成されている様なのですが、Nginxの設定ファイルを見ても、どういう仕組みで生成されているのか、理解出来ていません。DockerもNginxもWordPressも経験が無いので、理解するのが大変ですが、ぼちぼちやってみようと思います。とりわけ、セキュリティは大丈夫なのか?本格的にブログを運営しても大丈夫か?という不安に駆られています。
        また、運用に当たって、相談させて頂くかもしれませんが、その際は、よろしくお願い致します。
        お忙しいところ、ありがとうございました。

        返信

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です