ArchLinux * Nginx * php-fpm * MariaDB * WordPress

wordpress

TOP
Old Archives
ArchLinux * Nginx * php-fpm * MariaDB * WordPress

慣れている人にとっては常識レベルなのだろうけれど、つまずきどころ満載だったので、メモ。

Nginxのインストール

# pacman -S nginx

PHP / php-fpmのインストール

# pacman -S php-fpm

MariaDBのインストール

“MySQL”と認識している人も多いだろうけれども、現在は圧倒的にMySQLよりMariaDBが一般的である。

MySQL自体は継続しているが、MySQLを提供しているディストリビューションは非常に少なく、そもそもアプリケーションが想定しているデータベースもMySQLよりMariaDBのほうが一般的だ。

MariaDBはMySQL5.5から派生したコミュニティベースのデータベースである。

# pacman -S mariadb

有効化する前に 初期設定を行う。

# mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql

そしてセキュアな設定を行う。 (省略しても構わない)

# mysql_secure_installation

リモートホストからのアクセスを拒絶しておく。 /etc/mysql/my.cnfのskip-networkingをアンコメントすればOK。この状態でもローカルホストからは接続できる。

これでMariaDBを起動・有効化できる。

PHPの設定

PHPのモジュールが無効になっているので有効にしておく。これがなければデータベースに接続できず、500 Internal Server Errorになる。

/etc/php/php.iniを編集する。bz2, mysqli, pdo_mysqlを有効にする必要がある。

これをしていないとWordPressの初期設定でデータベース設定後に500エラーになることになり困惑することになる。

これでphp-fpmを起動・有効化できる。

Nginxの設定

まずはサーバー設定を書いておく。設定を書かない場合、WordPressにアクセス自体できない。

どこに何を書くかという解説はしない(Nginxについて説明をはじめると長い)ので、それを理解しているという前提で進める。もしろん、コピペでなく値は合わせること。

最低限だとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;

  access_log /var/log/nginx/blog-example.log;

          location / {
               index  index.html index.htm index.php;
          }
          location ~ \.php$ {
               fastcgi_index  index.php;
               include        fastcgi.conf;
          }

}

公式の設定から引用するとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;


  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  rewrite /wp-admin$ $scheme://$host$uri/ permanent;

  location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 24h;
    log_not_found off;
  }

  location ~ \.php$ {
    try_files $uri =404;
    
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#   fastcgi_intercept_errors on;
    fastcgi_pass php;
  }

}

公式の場合サイト別ではなく上流で次のような設定も必要になる。

upstream php {
  server unix:/run/php-fpm/php-fpm.sock;
}

php-fpmのソケットファイルが間違っている場合、502 Bad Gatewayになる。

WordPressのインストール

「公式パッケージはあるけどWordPress公式からインストールしたほうがいいよ」というのがArchの姿勢。

$ cd /srv/http
$ wget https://wordpress.org/latest.tar.gz
$ tar xvzf latest.tar.gz
$ sudo chown -R http:http wordpress
$ mv wordpress blog/example.com

パーミッションが間違っていると403 Forbiddenになる。これは主に所有者で、Nginxプロセスの所有にする必要がある。現在のArch LinuxではNginxプロセスはhttp:httpで動作する。

起動と有効化

# systemctl start nginx
# systemctl enable nginx
# systemctl start mariadb
# systemctl enable mariadb
# systemctl start php-fpm
# systemctl enable php-fpm

php-fpmが起動されていない場合は502 Bad Gateway、MariaDBが起動されていない場合は500 Internal Server Errorになる。

別のWordPressから移行する

WordPressのファイル側にもファイルがあるらしい(どうも画像データはこっちらしい)ので、MySQLのエクスポートと同時にファイルもとっておく必要がある。

取得したファイルはWordPressインストールの代わりに展開し、パーミッション(所有者)を変更する。パーミッションの変更は忘れがち。

SiteGuardでログインアドレスを変更している場合は、この機能がApacheに依存しているためログインできなくなってしまうので、wp_content/plugins/site-guardを削除しておく。あるいは、エクスポート前にこの機能を無効にしておいてもいい。ログインページをNginx上で変更したい場合は他のプラグインを仕様する必要がある。私の場合は“Login Rebuilder”を利用した。

従来が第三者サービスなどによって提供されていたWordPressで、データベース名やユーザー名が好ましくない場合、あるいは複数サイトをインストールするために指定したい場合はwp_config.phpも編集。

データベースをインポートする前にデータベースを用意しておく。

# mysql
> create database <database_name>
> create user '<username>'@'localhost'
> grant all privileges on <database_name>.* to '<username>'@'localhost' identified by '<password>'
> quit

そしてインポート

# mysql <database_name> < wordpress_database_file.sql

そんなわけでブログ引っ越し完了

ブログはXdomainの付属サービスから自サーバーに移動した。

これによりパフォーマンスが改善し、またスマートフォンでの閲覧において広告がでなくなった。

パフォーマンスは最善ではない。これはこのサーバーでWordPressだけが動いているわけではないため、リソースをWordPressに大量に割くことができないからだ。必要ならば将来的にWordPressを独立したサーバーにしてパフォーマンスを向上させたり(Kasanagi導入が妥当だろう)、リソースを増強してパフォーマンスチューニングを行うかもしれない。

現状ではこのChienomiのほうのデイリーPVは1500から6000程度である。特に広告などを出して収益があるわけでもないので、今のところあまり考えていない。そうね、ヒューマンユニークがデイリー1500を越えるか、月間1000円以上の広告収入が発生するようなことがあれば考えようかな。

いずれ広告を出す可能性があるにせよ、それはChienomi側で選定しコントロールした話であり、プロバイダー広告が出るのは(広告を出さないというポリシーに基づく)ユーザービリティ的にもパフォーマンス的にもデメリットしかないので、Chienomiがそれなりにアクセスがあることを踏まえて対応した。