KUSANAGIに移設する際の5つの手順をまとめてみた

この記事はKUSANAGI Advent Calendar 2016の10日目の記事です。
なんだかいつの間にかリレーブログのようにはせべーこと長谷川君(がわじゃねーよ!)もとい長谷部君よりバトンが渡されておりました。

1.KUSANAGIで移設先のサーバを用意する

もちろんどこのクラウドでもいいです。
クラウドの管理画面からKUSANAGIでサーバを起動、rootでログインしたら以下のコマンドでWordPressをインストールします。

# kusanagi init
# kusanagi provision kusanagi_html

特にDB名やDBユーザ名にこだわりがないのなら、移設元のwp-config.phpに書かれているDB名、DBユーザ名、DBパスで作っておくとちょっと楽かも。あまり意味はないけど。
ただし、基本的にwp-config.phpはコピーしてきません。KUSANAGI用のキャッシュコマンドなどが書かれているので上書きするとbcashとかちゃんと動かなくなるかも(対処法はある)。

2.WordPressをインストールする

ここでいくつかコツがあります。

パターン1 独自ドメインを移設 + 常時SSL化

すでに稼働中の独自ドメインでWordPressを運用していて、移設に際してLet’s Encryptで常時SSL化を行う場合。

この場合、いずれにしてもまずWordPressを新規インストールするのですが、運用中のドメインを停止したくはないため、hostsを書き換えてからWordPressをインストールします。

例)Windows10の場合
C:\Windows\System32\Drivers\etc\hosts

hostsファイルは管理権限で書き換えないとだめです。やり方は適当にググってください。

www.outbreak2000.com 192.168.0.1

最初が取得している独自ドメインで、後が新しく建てたクラウドの仮想マシンのIPアドレスです。
これで一時的に独自ドメインで新しいサーバにアクセスできるようになりました。

常時SSL化は実際にサーバに外からドメインでアクセスできないと設定できないので後から行います。

パターン2 独自ドメインを新規に取得 + 常時SSL化

独自ドメインを新規に取得する場合は、kusanagi povision の時点でLet’s Encryptを設定してしまいます。
注意するべきは、プロビジョニング時点ではクラウドに建てた仮想マシンのIPアドレスにドメインが紐づいているようにすることです。

もちろんWordPressをインストールする時点で https でアクセスすることをお忘れなく(おそらくこの時点でリダイレクト設定もされてるはず)。

3.wp-content以下をバックアップして持ってくる

wp-content以下をバックアップするにはだいたい以下のコマンドです。

# cd /var/www/html
# tar cvzf wp-content_20161210.tar.gz wp-content/

移設元のサイトがシェル使えないとか、WordPressがインストールされている場所とかそれぞれ違うとか、適当にやってください。
要はwp-content以下のファイルがあれば代替大丈夫です。

注意すべきは移設元のWordPressのバージョンが極端に古いとか、wp-content以外のドキュメントルートにしこたまファイル置いているとか、個別の事情がある人は気を付けましょう。

WordPressごと移設しても良いですが、たまにはクリーンにするのも良いですよ(自己責任)。

KUSANAGIはFTPが禁止されていますので、SFTPかSSH(SCP)でファイルを持ってきます。
KUSANAGIは各プロファイルのDocumentRoot以下のファイル権限がkusanagiユーザなので、kusanagiユーザのルートディレクトリにでもとりあえず置いておけばいいんじゃないかな。

直接scpするならだいたい以下な感じ。

# scp kusanagi@192.168.0.2:~/wp-content_20161210.tar.gz /home/kusanagi/
kusanagi@192.168.0.2's password:

展開はだいたい以下な感じ。

# tar xvzf wp-content_20161210.tar.gz

この時wp-content内のユーザ権限を変更しておくと良いかもしれない。
管理画面上からアップデートをかけるpluginsやthemesなどはkusanagiユーザで、WordPressが直接編集するuploadsはhttpdユーザでグループはwwwにしておくと良いかも。

# chown -R kusanagi:kusanagi wp-content/
# chown -R httpd:www wp-content/uploads/

他にプラグインが自動生成したファイルやディレクトリがあるかもだけど、基本は上のルールと同じ。

ちなみに、プラグインやテーマがkusanagiユーザになっているので、管理画面からアップデートをかけようとするとFTPユーザやパスワードを聞いてきます。
これは間違いではなくて、kusanagiユーザで自分自身にFTPを許可して書き込みを行っているので、仮に脆弱性のあるプラグインなどがあってそれらが他のPHPファイルに書き込みを行おうとしても、権限がkusanagiユーザなので勝手に書き換えられたリされない(できない)って言うセキュリティ上の対策なのですね。

これにより管理画面からテーマの編集やプラグインの編集ができなくなるけど、もしもの時のセキュリティを気にするか、利便性を気にするかですね。

ここでの注意点は移設先のwp-content内にあるmu-pluginsを削除してしまわない事。
よくあるのがwp-contentをリネームしてまるっと置き換える方法。これやっちゃうとKUSANAGI用のオリジナルプラグインがなくなっちゃいますので、リネームしたディレクトリから移しておきましょう。

KUSANAGI用のオリジナルプラグインはWordPressの高速化の一端を担っています。
多言語に対応したWordPressが日本語で表示できるのは当たり前ですが、この翻訳が管理画面なども遅くする原因にもなっています。ですので、翻訳ファイルをキャッシュしてしまうことでWordPressの高速化を図っています。

なせ、オリジナルプラグインなのか。それはWordPressのコアを修正したりしないためです。
良く勘違いされるのがKUSANAGIで導入されたWordPressはチューニング(改造)されていると言う間違いですね。これやっちゃうとバージョンアップできなくなるので絶対やりません。

4.MySQLのダンプデータを持ってきてインポートする

MySQLをダンプするにはだいたい以下のコマンドです。

# mysqldump -u user -p dbname > dbname_20161210.sql
Enter password:

これもphpMyAdminしか使えないとか、その辺は適当にググってください。移設先のWordPressがクリーンな状態ですので、dropしなくてもまあ大丈夫だとは思いますけど、phpMyAdminからダンプするならdrop入れてダンプしても良いかもしれません。

同様にFTPなりSCPなりしたらDBインポートします。
念のためdropしておくならだいたい以下な感じ。

# mysql -u root -p
Enter password:
~ 省略 ~
MariaDB [(none)]> show databases;
~ 省略 ~
MariaDB [(none)]> drop database dbname;
Query OK, 16 rows affected (0.21 sec)
MariaDB [(none)]> create database dbname;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> quit;
Bye

DBインポートは以下な感じ。

# mysql -u dbuser -p dbname < dbname_20161210.sql
Enter password:

ここで元々SSLで動いていなかったサイトを常時SSL化するならwp-cliを利用してDBを書き換えたりする必要があります。

例えば新規にドメインを取得して違うドメインから移設した場合であれば以下のような感じ。

# wp search-replace 'https://www.outbreak2000.com' 'http://example.com'
+------------------+-----------------------+--------------+------+
| Table | Column | Replacements | Type |
+------------------+-----------------------+--------------+------+
~ 省略 ~
Success: Made 555 replacements.
# wp option update home 'https://www.outbreak2000.com'
Success: Updated 'home' option.
# wp option update siteurl 'https://www.outbreak2000.com'
Success: Updated 'siteurl' option.

ドメインの変換をかけたあとに、homeとsiteurlも書き換えています。
これやっとかないとhttpにリダイレクトかかったり、旧サイトにリダイレクトかかったりしちゃいます。

さて、これでだいたい移設は終わりました。ドメインが同じなのであればDNSの切り替えなどが必要ですが、新しいドメインならすぐにアクセス可能ですね。
いづれにしても公開前にサイトの確認は行いましょう。まずはログインしてみて管理画面がちゃんと動作しているのか確認し、フロント側の表示も確認します。

ここで注意なのが、移設で新たにKUSANAGIにした場合、wp-contentの移設時にあったKUSANAGIオリジナルプラグインがちゃんと設定されているか確認をしておきます。
管理画面にKUSANAGIメニューがあればmu-pluginは動作していますので、上部メニューから翻訳アクセラレーターを選んで設定を確認しましょう。

確認する点は、高速化を有効にするにチェックが入っていること、タイプはAPCになっている方が良いです。
ログイン/サインアップ画面の翻訳と管理画面の翻訳はキャッシュを使用で良いと思います。サイトに表示される翻訳された文章については使用しているテーマなどによります。
例えば、自作のテーマで、テーマファイル内に直接書かれている文章がそのまま日本語になっている場合、テーマ側で翻訳を必要としませんので、翻訳を停止にしてしまうとよいでしょう。
既存のテーマを使用している場合で、サイドバーのメニュー項目やコメント欄などを翻訳して使っている場合は、キャッシュを使用にすると高速化が図れます。

5.テーマなどの高速化を行う

さて、KUSANAGIは既存サイトを移設しただけでも十分に速くなります。しかし、実際にはテーマ、プラグインの問題でKUSANAGI本来のスピードを殺してしまっていることが多々あります。

まずは何が原因で速度が落ちているのか確認をします。
おおよその目安は、ログインしていると表示される管理バー右側のパフォーマンス表示の数値です。サイトトップで0.100 sec(100ミリ秒)は最低でも切りたいですね。

WordPressで問題が発生した場合に良く行う手法として、テーマをデフォルトに戻し、プラグインをすべて停止すると言うのがあります。
公開サイトでこれを行うのはいろいろと難しいところがありますが、上で説明してきたクラウド上に新たに仮想マシンを建てて、hostsでアクセスする手法を使えば、テストサイトを作ってゆっくり試すことも可能です。

テーマをデフォルト、プラグインをすべて停止して20ミリ秒を超えてくるようなら十分にKUSANAGIのスピードを出せています。ちなみにKUSANAGIの公式サイトでは0.006 secなんて数値をたたき出していますが、これはKUSANAGIの最大性能(WordPress実行時間3ミリ秒台)を引き出すために特別にチューニングされたオンプレミスのサーバですので、クラウド環境ではさすがに難しいかもしれません。

テーマをデフォルト、プラグインをすべて停止しているのにあまり速度が出ていない場合は、サイドバーやテーマによってはヘッダーやフッダーに使用されているウィジェットエリアが問題になっているかもしれません。
この場合、テーマに改造を加えて、Transientsを駆使した部分キャッシュなどで高速化を図ることもできます。詳しくは「詳解WordPress」のP178などに詳しく説明されてます。

プラグインをひとつずつ有効化していくと突然遅くなる物があるかもしれません。
どうしても外せないプラグインの場合、同じ機能の他のプラグインを探すと言う方法もありますが、同様の機能がない場合には仕方がありません。自分がエンジニアで改修ができるのであれば改造すると言う方法もありますが、結構難しいですね。
仮に公式のプラグインを改修して高速化できたのであれば、是非作者にもパッチを送ってあげてくださいね。

速度テストやセキュリティテストなどが行われて、KUSANAGIで動作することを検証したプラグインやテーマを公開しているKUSANAGI Ready プロジェクトというサイトがありますので、こちらも参考にするとよいです。

十分な速度が出せるようになったら公開しましょう。
あまりアクセスのないサイトなら推奨環境のメモリ4GBでなくても十分に動作させることができます。まあ、あまりメモリが少ないと100ミリ秒を切るのも難しくなってしまうかもしれませんけども。

みなさんが無事にKUSANAGIで高速WordPressでサイトが公開できるようサンタさんにもお祈りしておきます。
なんと明日はいつもバグ報告や要望などをあげてくださる経験値を運営していらっしゃるトツオさんです!

videoタグとコーデックのお話し

html5には動画を文書に埋め込むための<video>タグがありますね!
html5も2012年12月17日にW3Cが策定完了の発表を行ったり、2013年1月6日には全国のコワーキングスペースなどで新春!!HTML5KARUTA大会が行われるなど、話題にも事欠きませんが、流行のiPad、iPad miniなどiOS系ではFlashなどの技術が基本的には使えないなど、動画の世界もhtml5を利用した技術へとシフトしてきた感があります。

当方も今までFlashやWMVで提供していた動画を、各種スマートフォンやタブレットなどでも再生ができるように<video>タグによる動画再生へと変更することにしました。が!これが意外と面倒でしたよっと…技術的な覚え書きを残しておきます。

まずはhtml5のコードですね。
一応、現在作成中のサイトはIE7以下をばっさり切り落として作成しているので、IE8以降と一部の有名ブラウザ程度をカバーする程度の内容でございます。元々存在していたFlash動画をIE8用に再生できる仕様にはしていますが、完全ではございませんのでご注意ください。

<video poster="/img/movie/movie.jpg" preload="metadata" controls="controls">
  <source src="/img/movie/webm/movie.webm" type="video/webm" />
  <source src="/img/movie/mp4/movie.mp4" type="video/mp4" />
  <object id="movie" data="/img/movie/flash/movie.swf" type="application/x-shockwave-flash" width="356" height="200">
    <param name="allowScriptAccess" value="sameDomain" />
    <param name="movie" value="/img/movie/flash/movie.swf" />
    <param name="quality" value="high" />
    <param name="wmode" value="transparent" />
    <param name="scale" value="showall" />
      Movie
  </object>
</video>

<video>タグについての詳しい説明は省きますが、posterは動画再生前の静止画を指定できます。
preloadをmetadataにしているのは、モバイル端末などで自動再生されると相当な容量のデータをページを開いただけでダウンロードさせることになるので、動画の情報だけを取得するようにしています。
controlsは指定しておけば再生などのインターフェースを表示できます。

sourceは様々なブラウザでも再生できるよに複数のコーデックを使い分けができるように別表記しています。このソースではその下にobjectタグでFlashを指定していますが、一応<video>タグに対応していないIE8などのために入れてあります。通常は<p>動画を再生するには、videoタグをサポートしたブラウザが必要です。</p>などのように指定しておけばいいようです。

動画のコーデックに関しては、Wikiなどを見ると各ブラウザで迷走中のようですが、IE9~10、Firefox、Chromeなど各最新版のブラウザをターゲットにするならmp4とWebMがあれば十分対応できると思います。

さてこれで指定した場所に動画のファイルがあれば再生されるはずなんですが…

「ローカルで再生するのにサーバーにアップロードすると再生しないじゃんか!」

なんてことが起こります。まあ、多分ほとんどこのケースのようです。そんな時にも慌てず騒がず.htaccessに以下の記述をしましょう。

AddType video/mp4 .mp4
AddType audio/webm .webm

サーバーがmp4やwebmの形式を認識できていない事が原因のようですのでほとんどの場合これで解決します。

さて、mp4とWebMコーデックの準備なんですが、最初はWebMのエンコードに手間取りました。最初はMiro Video Converterなるフリーソフトで変換してみましたが、Firefoxできれいに再生されませんでした。
最終的にはFree Studioというさまざまな動画変換をパックにしたフリーソフトで対応しました(Macの方は別のソフトをお探しくださいorz)

WebMに関してはこれで変換するだけで問題なく再生されると思います。

mp4ですが、これもややはまりました。同じくFree Studioで変換をしたのですが、IE9で再生されませんでした。IE9でmp4が再生されない時の調査方法は、[F12]で開発者ツールを開いてネットワークタブを開きます。

photo_20101118_0038
この状態で[F5]ないしページの更新を行えばページで使われているファイルが取得される様子が分かります。ここで先ほどソースに書いたsourceのsrcに書かれている/img/movie/mp4/movie.mp4がちゃんと読まれているのか確認できます。
アップロードしたmp4ファイルの種類がvideo/mp4になっていなかったら前述した.htaccessなどでファイルタイプを指定していないとそのサーバーでは再生できません。すぐに指定しましょう。(できないサーバーもあると思います)

しかし、ここが間違っていなくてもIE9で再生できない場合があります。私はそうでした。
これは、拡張子mp4のコーデックには2種類あり、MPEG4形式のものとH.264形式のものがあって、IE9ではH.264形式のものがサポートされているということだそうです。
前で紹介したFree Studioでmp4形式に変換できますが、デフォルトではH.264でサイズフリーのもの(変換元の動画のサイズを変換しないもののこと)がプルダウンにありませんでした。でも自分で設定できるので、

photo_20101118_0039
などのように適当に作成して変換してしまいましょう。

これでIPad、IE9、Firefox18、Chrome24で再生を確認できました。
html5が使えるブラウザが増えてきて<video>タグなども気軽に使えるようになってきましたが、サーバーの設定やコーデックなど、ソースコードだけではどうにもならないものもありますので、みなさんの参考になればいいなー

写真部で勉強したことを仕事に生かす

先日2012年5月27日にFacebookの写真を撮りに行こうグループで開催した「写真撮影 初心者勉強会」にて優太郎君がプレゼンしてくれた3分割構図をさっそく仕事でも役立ててみようと思いました。

もともとは写真を撮影する際にある程度構図を考えながら撮影すると良い写真が撮れますよっていう内容なのですが、仕事で写真を編集してWeb用のパーツ等を作る際にも活用できます。

まずはPhotoshopで3分割構図の作業をするために役に立つグリッドを入れてみます。(メニュー等はCS5.5 Windows版)

[編集(E)]から[環境設定(N)]を選択し、[ガイド・グリッド・スライス(S)]を選んで下記のように設定します。グリッド設定

次に[表示(V)]から[表示・非表示(H)]から[グリッド(G)]にチェックを入れれば表示されます。

3分割グリッド表示こんな感じですかね?

ここに写真部で撮影した画像を乗せてみます。

写真を配置

一応グリッドを意識してスカイツリー部分をグリッド配置してみました。写真そのものは縦で撮ったため右側が空いているのとスカイツリーが斜めってますね。少し補正をかけてみます。

斜めを垂直に補正

スカイツリーは垂直になりました。ものさしツールで測ってから修正すると角度が分かって楽に補正できます。

でもまだ右側に画像の足りない部分がありますねぇ。なんとかしたいところです。

編集したい部分を範囲選択

修正したい部分を適当に範囲選択して…[編集(E)]から[塗りつぶし(L)]したいところですが…できませんね。まずは取り込んだ写真のレイヤーを右クリックして、レイヤーをラスタライズしてしまいましょう。

これで塗りつぶしが使えるようになりました。そしてやっぱりこれですね!

コンテンツに応じた塗り

え?そんな項目ない?新しいPhotoshop買ってくださいヽ(´ー`)ノ

完成!

ほうら、簡単。これで今日の仕事は終わりです(ぉ

優太郎くん、次の構図勉強待ってますよ~

いろいろなCSSの記述方法(メモ)

HTML5+CSS3で新サイトを構築していたら、CSSの特にセレクタ周りでいろいろとできるな~と思ったので忘れないうちにメモしておきます。ちなみにCSS3からのセレクタもありますが、CSS2.1でもセレクタはたくさんありました。それらも含めて使ったものの紹介なので、CSS3に特化したものではないことにご注意ください。

まずはよくある「最初だけ」とか「最後だけ」とか「偶数・奇数」などなど。

htmlコード

<section id="contents">

  <h1>title</h1>

  <article>
    <h2>sub_title1</h2>
    <p>contents1</p>
  </article>

  <article>
    <h2>sub_title2</h2>
    <p>contents2</p>
  </article>

  <article>
    <h2>sub_title3</h2>
    <p>contents3</p>
  </article>

  <article>
    <h2>sub_title4</h2>
    <p>contents4</p>
  </article>

</section>

例えばこのようなソースがあったとします。この時以下のことをやるには…

1.最初のコンテンツだけ枠をつけたい
CSSコード

#contents article:first-child {
  border:1px solid;
}

2.最後のコンテンツだけ枠をつけたい
CSSコード

#contents article:last-child {
  border:1px solid;
}

3.偶数のコンテンツだけ枠をつけたい
CSSコード

#contents article:nth-child(even) {
  border:1px solid;
}

4.奇数のコンテンツだけ枠をつけたい
CSSコード

#contents article:nth-child(odd) {
  border:1px solid;
}

まあ、このあたりはgoogle先生でCSSセレクタで探すと普通に書いてありますね。
さらに…

5.最初のコンテンツ以外に枠をつけたい
CSSコード

#contents article:not(:first-child) {
  border:1px solid;
}

上記5の書き方で他に、
・特定のclassが描かれているコンテンツを省く
CSSコード

#contents article:not([class="hoge"]) {
  border:1px solid;
}

などもできますね!

これらは組み合わせることもできるので、例えば
CSSコード

section:not(:last-child) article:ntn-child(odd) {
  border:1px solid;
}

とかすると、最後のセクション以外の奇数のアーティクルに枠をつけるなんてこともできますね。

もっと変態な書きかたをすれば…

#contents article:not(:first-child):not(:last-child) {
  border:1px solid;
}

なんて書けば最初と最後のアーティクル以外に枠をつけます。

いやぁ、深いですねぇ。

レスポンシブWebデザインの時に考えるhtaccess

最近はレスポンシブWebデザインでホームページを作ることも増えてきましたよね。

ただ、気をつけなくてはいけないのが、スマートフォンなどの携帯ブラウザで見たときも同じサイズの画像が表示されるってことです。(基本的にはですけどね)

CSSの書き方にもよるのでしょうけど、@media screen and (max-width: 569px)なんて書き方で分岐していても、CSSで読まれていないはずの場所の画像が実は読まれているなんてことはよく耳にします。FireMobileSimulatorなどを導入してFirebugなどで調べれば実際に読み込まれているか調査できますのでご自身のサイトで確認してみるといいですよ。

で、media screenなどの分岐ではなく、画像はそのまま表示しちゃいましょうとなると、やはり気になるのは画像サイズですね。

PCブラウザ用に作られた画像は、例えば文字の乗って入るバナーのような画像とか、ファイルサイズ的にはそんなに大きくなくても、スマートフォンの小さな画面に縮小されてしまうと文字が読めなくなるなどの弊害も考えられます。

今回、管理サイトのリニューアルに際し、サイトのWidthが大きくなることになりました。そしていくつかのランディングページ的な役割のファーストビュー部分をインパクトを持たせるためにサイドバーなしの大きな画像で表現することになってしまったため、その大きな画像をスマートフォンに読ませないために色々工夫することになりました。

そこで思いついたのがスマートフォン用の画像を別に用意してhtaccessで分岐させてしまおうという方法です。

ただし、すべての画像をスマートフォン用に用意するのは嫌なので、スマートフォン用の画像が用意されている場合はそちらを読み込み、それ以外はPC用の画像をそのまま使用するという方法で行うことにしました。

しかし、タブレット(iPadやAndroidタブレット)ではPC用の表示を行いたいためスマフォ用画像は使わない(タブレットを省く)設定にしなくてはいけません。

で、行き着いた先のhtaccessがこちらです。

# スマートフォンでアクセスがあった場合に画像フォルダを変更
RewriteEngine on
RewriteBase /img/

RewriteCond %{REQUEST_URI} !mobile/
RewriteCond %{HTTP_USER_AGENT} (iPhone|iPod|Android.*Mobile|BlackBerry|Windows\ Phone|Windows\ CE) [NC]
RewriteCond %{REQUEST_URI} ^/img/(.*)$
RewriteCond %{DOCUMENT_ROOT}/img/mobile/$1 -f
RewriteRule (.*) /img/mobile/$1 [R,L]

ルートにimgのフォルダがあります。その中に普通にページごとにフォルダ分けされており、/img/hoge/fuga.jpgなどのように置かれています。

スマートフォン用の画像はimgの下にmobileフォルダを作り、PC用画像のフォルダと同じ構成で/img/mobile/hoge/fuga.jpgなどのように置いています。

まず{REQUEST_URI}でmobileフォルダの場合はリライトを無効にします。

次に{HTTP_USER_AGENT}でスマートフォンを抜き出しますが、Androidには携帯とタブレットの両方があります。iPadはUserAgentがはっきり分かれていますが、Androidはどちらもほぼ同じです。しかし、Android携帯の場合UserAgentにmobileという記述が入ってくるらしいので、これが入っていないものはタブレット(もしくはAndroidOS搭載のPC?)とみなしてリライトしません。(Windows系の記述はどっかからの丸コピで実際に試していませんのでご注意)

そして次の行でimg以下のURLを取得し、RewriteCond %{DOCUMENT_ROOT}/img/mobile/$1 -fでmobileフォルダ配下に画像が存在しているかどうかを-fのフラグでチェックしています。この「リライト先に画像があるのかないのか?」の判定をhtaccess上で行うのがちょっと苦労しました。Neo Inspirationさんの.htaccess で RewriteCond の後方参照がとても参考になりましたのでご紹介しておきます。

iPhone4S、iPad、Android携帯での実機検証もしていますが、何か不具合や問題点の指摘などがありましたら教えてください。自力だとこれが限界です(汗)ソーシャルの力を信じましょうw