Wocker

WockerでWordmoveを使う

Wockerバージョン1.3にてWordmoveが実装されました。


今回はWordmoveをつかって、このブログのテーマをWocker内のWordPressに反映させてみます。
Wordmoveを使うと、PC内の開発用WordPressとサーバの本番環境のWordPressをコマンド一つで「同期」できます。
公式サイトでは「自動的なミラー」(複製)と書いています。

Wordmove is a gem that lets you automatically mirror local WordPress installations and DB data back and forth from your local development machine to the remote server.

Wocker自体の使い方は、公式サイトwocker.ioを参照して下さい。
Windowsでの使い方は当ブログに解説記事があります。WindowsでWockerを使う ― Autumnsky

ローカルのフォルダ構成、リモートの構成

作業前にローカルのフォルダ構成と、サーバ側のWordPressの設定を確認します。
当方ではDドライブ内にwockerのフォルダを作っています。
下記のコマンドでtest-wordmoveというコンテナを作りました。

$ wocker run --name test-wordmove

ローカルのWordPressが入っているフォルダはD:\wocker\data\test-wordmoveとなります。
wocker start test-wordmoveコマンドで、このフォルダ内のWordPressがPCで実行されます。
当ブログはさくらのレンタルサーバ スタンダードプランに構築されています。
サーバ側のWordPressは別途フォルダを作ってwordpress内にインストールしていますので、

WordPress アドレス (URL): https://autumnsky.jp
サイトアドレス: https://autumnsky.jp

上記の通りになっています。

Wordmoveのmovefile.ymlを生成する

ローカルのWordPressの設定、本番環境が動いているサーバの設定、等の設定をmovefile.ymlに記載します。
movefile.ymlに記載された設定を元に、Wordmoveは同期を行います。
.ymlは、YAML(ヤメル)というデータ形式のファイルです。私は「ヤムル」と読んでいます。
ローカルのWocker内には、初期状態ではmovefile.ymlはありません。
まず、Wockerコマンドでmovefile.ymlを生成します。

$ wocker wordmove init

result_wordmove_init
movefile.ymlが作成されました。テキストエディタで開いてみます。
(Windowsではメモ帳は使わないで下さい。)created_movefile
この時点で、Wocker内のWordPressは設定済みです。
下記のglobal:からproduction:の手前までの部分。
movefile_global_section

global:
  sql_adapter: wpcli # default is not available for Wocker
local:
  vhost: http://wocker.test
  wordpress_path: /var/www/wordpress # use an absolute path here
  database:
    name: wordpress
    user: wordpress
    password: "wordpress" # could be blank, so always use quotes around
    host: localhost

movefile.ymlを編集する

先に生成したymlファイルに本番環境(サーバー側、リモート)の設定を書いていきます。
production:以下、インデントが一つ下がっている項目は、サーバー側の本番環境の設定項目です。
例えば、database以下はproduction(本番環境)のデータベース設定です。databaseのname、databaseのuser、databaseのpasswordと設定が必要です。
これを本番環境のサーバー設定に書き換えていきます。
WordPressの設定、wp-config.phpとmovefile.ymlの設定を対応させると下図のようになります。
サーバ側 WordPress 4.9.2 / ローカル Wocker v1.3 の場合
prodction_server_settings
書き換え後の例

production:
  vhost: https://autumnsky.jp
  wordpress_path: /home/autumnsky/www/wordpress
  database:
    name: wp-config.phpからコピー
    user: wp-config.phpからコピー
    password: wp-configからコピー
    host: wp-configからコピー
    # port: 3308 # Use just in case you have exotic server config
    # mysqldump_options: --max_allowed_packet=1G # Only available if using SSH

vhost:は最後のスラッシュは書きません。リモートのデータベースをローカルへプルした際、データベース内にあるproduction: vhostのURLをlocal: vhostの文字列に書き換えています。サーバー側とローカルで、サイトURLが変わるため、URLを書き換えなければローカルのWordPressが正しく動きません。
正確に記載されていないと、書き換えに失敗します。
production:以下のwordpress_pathはサーバー側のWordPressを設置しているパス(フォルダ)の指定です。

サーバーのテーマフォルダをプル

それではサーバのテーマをローカルのWockerに引っ張ってみます。
今回はSSHという接続を使います。

SSH(Secure Shell) とは、物理的に遠いところから、サーバを操るための手段のひとつです。
さくらのレンタルサーバ SSHについて

SSHでの接続設定はサーバごとに異なりますので、各自ご確認下さい。
まず、先と同様にmovefile.ymlのSSH項目の設定を書きます。
SSHの設定は初期状態ではコメントアウトされているので、#を半角スペース2個で置き換えます。
左が編集前、右がコメントアウトを外した状態です。
下記の画像では分かりやすいように、エディタの設定でスペースを_で可視化しています。
enable_ssh
さくらレンタルサーバなら、hostとuser設定だけでもOKです。wordmoveする都度、パスワードを入れる必要がありますが。
インデントの半角スペースの個数、インデントの段数に気をつけて下さい。
YAML形式のインデントは半角スペース2個です。
このインデントの深さがデータの階層構造に対応します。
movefile.ymlは下記のツリーのような階層構造となっています。

movefile.yml
├─ local:(PCのローカルWordPressの情報)
│   ├─ vhost: http://wocker.test (サイトURLはwocker.test)
│   ├─ wordpress_path: /var/www/wordpress # use an absolute path here
│   └─ database:(ローカルのデータベース設定)
│        ├─ name: wordpress
│        ├─ user: wordpress
│        ├─ password: "wordpress" # could be blank, so always use quotes around
│        └─ host: localhost
│
└─ production:(本番環境のサーバ、WordPressの情報)
    ├─ vhost: http://example.com (本番環境のサイトURL)
    ├─ wordpress_path: /var/www/your_site (本番環境のサーバー内のパス)
    ├─ database: (本番環境のデータベース設定)
    │   ├─ name: database_name
    │   └─ ...
    ├─ exclude (除外ファイル)
    ├─ ftp (本番環境へのFTP接続の設定)
    ├─ ssh (本番環境へのSSH接続の設定)
    └─ ...

WordmoveはRubyで書かれています。YAML形式はRubyの構文に近いです。インデントが空白2個で文法上の意味があるのも、Rubyと同じです。WordPressはPHPなので、随分と勝手が違いますね。
ではいよいよWordmoveコマンドでテーマを取得します。
その前に

  • 注意 サーバーに存在しないテーマは、ローカルのフォルダから削除されます!

サーバー側にないファイルは、一旦待避してください。
では実行します。

$ wocker wordmove pull -t

pullはサーバー側のファイルを引っ張ってくる、-t はテーマのみとする指定です。
実行結果はこのようになります。
success_pulling
success_download
movefile.ymlが読み込めない時は、下記のようにRuby実行環境がエラーを出します。
yaml_parse_error
「あるべきはずの設定値が見つからなかった」という意味ですね。
この場合は「28行目を含むブロックを解析中に見つかりませんでした」とのことです。
(黄色背景の強調表示は筆者が独自につけています。)
YAMLファイルの書き方が正しいかチェックしてくれるWEBサービスもあります。
例)YAML フォーマットチェッカーCGI

プルしたテーマを確認する

Wordmove pullは、サーバー側とローカル側のテーマフォルダを完全に同期します。
サーバー側に存在しないテーマをローカルで使っている場合など、wocker.testを開くとホームは真っ白になる場合があります、
http://wocker.test/wp-login.phpからダッシュボードにログインして、テーマを確認します。
after_pulling
左側のスクリーンショットが空白のテーマが選択されています。
当サイトはWordPress4.9.2のデフォルトテーマであるTwentySeventeenを入れていないため、ローカルのWockerから削除されています。
右側のShirohanadaを有効化します。
WockerでShirohanadaテーマが表示されました。
mytheme_in_wocker

おわりに

今回はプルしか試していませんが、もちろんプッシュも可能です。
また、Wocker V1.3では若干、制限があります。

  • 公開鍵認証を使ったSSH接続
    できると思いますが、Wockerのコンテナ内にid_rsaファイルを設置する必要があります。
  • FTP接続
    FTP接続は今のところできません。これもWockerのコンテナの設定で出来るようになります。

多少の制約もありますが、使いやすく実装できていると思います。
是非活用して下さい。
movefile.ymlの書き方については、こちらを参考にしました。
Wordmove の正しい設定方法 Qiita @miya0001

WindowsでWockerを使う 光速編

先に書いた、WindowsでWockerを使う 記事の要約版です。
Windowsで最短手順でWockerを立ち上げる方法です。

インストール

3つのソフトをインストールして下さい。全て公式にインストーラがあります。
Wockerはダウンロードして展開するだけです。

  1. VirtualBox
  2. Vagrant 
  3. Git for Windows
  4. Wocker

Wockerの展開フォルダはどこでも構いませんが、漢字や空白のあるフォルダ内は避けた方がよいそうです。
私はDドライブ直下の D:\wocker に入れています。

コマンドラインから仮想化環境を起動

コマンドラインからWockerを起動します、コマンドは5つほどです。
Git Bashを管理者権限で起動します。

Git Bashを「管理者として実行」していれば、公式解説の通りで問題なく起動できます。

git1
git2
ここからGit Bashでコマンドを入れて操作します。
初回のみ、Vagrantプラグインを入れます
$ vagrant plugin install vagrant-hostsupdater
インストール済みのプラグインの一覧の確認は次のコマンドで。

$ vagrant plugin list

次に、Wockerのフォルダへ移動。

$ cd /d/wocker

現在のフォルダが/wockerになっていればOK。(下図の黄色い文字)
続けてVagrantコマンドで仮想化環境を起動。

$ vagrant up

git3
ずらずらっとログが出ます。
git4
起動に成功したら、再び$マークでコマンドが入力可能になります。

Wockerコンテナの起動と停止

$ vagrant ssh

上記コマンドで仮想化環境へコマンドラインから接続します。
Wockerへコマンドを送るために、この接続操作が必要です。
接続に成功したら、$の前が wocker ~ となっているはずです。
git5
Wockerデフォルトを起動してみます。

$ wocker start wocker

Wockerの起動に成功したらコンテナ名が表示されて、コマンド入力が可能になります。

$ wocker ps

また、上記コマンドで実行中の「コンテナ」が確認できます。
これでWordPress本体がローカルPC内で走っていますので、ブラウザで表示を確認します。
ブラウザから下記アドレスにアクセスします。

http://wocker.dev/

4.5のデフォルトテーマ TwentySixteenで”Hello Wolrd”記事が表示されます。(WordPressのバージョンは16年5月現在のWockerデフォルト)
wocker-dev
インストールとWockerの準備が終わってGit Bashでコマンドを打ち始めて、スムーズなら20分ぐらいでここまできます。
初回起動時はVagrant・Wockerが色々とダウンロードするので時間がかかりますが、二回目からはGit Bashを開いて1分程度で起動可能です。WindowsとWockerが同じSSDドライブに入っていればもっと速いかもしれません。
最後にWockerを止めて、仮想化環境も一時停止します。
再びGit BashからWockerへ停止コマンドを送ります。

wocker ~ $ wocker stop wocker

停止したら、Wockerへの接続から抜けます。

wocker ~ $ exit

仮想化環境を止めます。

$ vagrant halt

wocker-command1
停止しました。ブラウザから http://wocker.dev/ へアクセスしても、WordPressは表示されません。
この先は、「コンテナ」を作って個別の開発環境を用意していきます。
先に書いたこの記事が参考になればと思います。
WindowsでWockerを使う
Windowsでも快適なテーマ開発ライフを送りましょう。
それではごきげんよう。

WindowsでWockerを使う

このサイトのテーマshirohanadaの作成には、仮想化WordPress環境Wocker(ウォッカー)を使用している。
手順のみの記事も書きました。:WindowsでWockerを使う 光速編
(16年5月29日追記)

Wockerとは

コマンドをいくつか叩くだけでWordPressがローカルPC内で立ち上がる素敵システム。
WordPress実行環境=(OS+Apache+MySQL+PHP+WordPress本体) これらが一塊になっていて、それが仮想化されてWindows内で実行される。わけがわからないよ。なので、仮想化やVagrant、Dockerについては今回は触れません。
今回はWockerをWindowsで実行する際のポイントに絞って紹介します。
こんな感じでWindowsでは動きます。

仮想化ソフトウェアを入れる

インストールするのは2つ。どちらもWindows向けのインストーラが用意されている。ザックリ下記のような理解で十分にWockerは使える。というか、中の人がそういうレベルの理解である。

  1. VirtualBox  仮想化OSの構築+実行用のアプリケーション
  2. Vagrant  その構築と実行を自動化するソフト

これと別にWockerをローカルにダウンロードする。
WockerのダウンロードはGithubからZIPをダウンロードしてもいいが、git cloneでの取得をオススメしたい。というのも、この後の行程でGit Bashを使うからである。Git for WindowsというGit公式Windowsクライアントツールが提供されている。それに含まれるコマンドラインツール(CUI)がGit Bashである。
git cloneの解説は山のようにあるので本項では割愛する。
ちなみに、私の使用ソフトのバージョン(2016年5月現在)

  1. Windows 10 build 10586.218
  2. VirtulaBox 5.0.10
  3. Vagrant 1.7.4

hostsの変更

ブラウザからPC内のWockerへアクセスしてWordPressを表示するための設定を行う。
Mac/Linuxでの標準手順ではhosts updaterというVagrantプラグインを使う。このプラグインは、Windowsだと管理者権限を必要とする。毎回「管理者として実行」を指定してコマンドラインを動かすのは、面倒でもあるしセキュリティ上よくないように思う。
なので、Windowsシステム内にあるhostsファイルに追記をする方法を紹介する。
逆にWindowsのシステムファイルを変更したくない場合は、この項目は飛ばして次の項へ。
hostsファイルを書き換える場合は下記ファイルに追記する。

C:\Windows\System32\drivers\etc\hosts

このファイルの中身はテキストファイルとなっており、Windows内でIPアドレスとURLの紐付けを設定している。
メモ帳でもよい、テキストエディターを「管理者として実行」してフォルダを辿っていってhostsファイルを開く。
hosts file dir
私の場合は下記のように追記している。
my hosts file screen shot
追記したのは23行目

10.0.23.16 wocker.dev

この設定を追記する。必要に応じてコメントも追加しておこう。
これで「http://wocker.dev/ への接続要求は、アドレス10.0.23.16 へ繋ぐ」という設定がなされた。設定しておけばVagrant実行時に管理者権限は不要になる。
また、Wocker内でもhosts情報を使っているようで、これを正しく設定しないとWordPressのテーマCSSが読み込まれない等の不具合が起きる。
重ねての注意になるが、hosts updaterプラグインを使用する際は追記しなくてよい。

仮想化環境を起動する

ここからコマンドラインでの操作となる。
実際に実行するのは3コマンド程度なのだが、前置きが長い。
要点を抜き出すと、SSH機能を備えたコマンドラインソフトを使うことである。
Windows10付属のコマンドラインは二つある。

  1. コマンドプロンプト (ファイル名をして実行 > cmd)
  2. Windows PowerShell(WPS)

どちらからもWockerの起動は不可である。

そこで私はGit Bashを使っている。
Wockerの操作は仮想化環境へリモートアクセスして行う=同じPC内だけども別のOSが実行されるためリモートアクセスとなる。だが、SSHによるリモートへのアクセス機能をWindowsは備えていない。コマンドプロンプトやWPSで実行して進めていくと「ホームにsshクライアントは入っているか?」とエラーが出る。VagrantのエラーメッセージによるとCygwinやMinGW、Gitはないか?とのことである。
Git Bashは本来、Windowsでgitバージョン管理システムを操作をするために用意されているわけだが、今回は別の用途に拝借するのである。
前置き終わり。
ではGit BashからWockerを起動しよう。
hostsを書き換えていない場合は、「管理者として実行」する。
git1
git2
初回のみ下記コマンドでhosts updaterプラグインをインストールする。hostsを書き換えていれば、不要である。

$ vagrant plugin install vagrant-hostsupdater

インストール済みのプラグインの一覧の確認

$ vagrant plugin list

hostsを書き換えている場合は、プラグインのインストールは不要である。
では、仮想化環境を立ち上げよう。
まず、GitBashのカレントをWockerをダウンロードしたディレクトリへ移動。D:\wockerがWockerをダウンロードもしくはCloneしたフォルダだとする。

$ cd /d/wocker

WockerのフォルダでVagrantコマンドを入力して仮想化環境を起動。

$ vagrant up

これだけで、wockerの設定を読み込んでVirtualBoxで仮想化環境を立ち上げてくれる。git3
ずらずらっとログが出てくる。
git4
仮想化環境が起動した。別のOSがWindows内で実行されているということだ。
次の項ではWockerへコマンドを送ってWordPressを起動する。
この項のまとめ

  1. Git Bashなどsshコマンドが使用可能なコマンドラインツールを使う。
  2. hostsファイルを書き換えていない場合は、「管理者として実行」してvagrant up

WordPressへアクセスする

仮想化環境が立ち上がったので、SSHで接続する。
(この辺りから、詳細に解説するには理解が追いついていないので手順の紹介にとどめます。)

$ vagrant ssh

これで仮想化環境のOSに入る。
接続に成功したらユーザーがwocker ~ $  となっているはずだ。
git5
ここでwocker runを入力。

wocker ~ $ wocker run

WockerデフォルトのWordPress本体が立ち上がるので、ブラウザから

http://wocker.dev/

へアクセスする。
WordPressの”Hello World”記事が現れたら、正しく起動している。
wocker-dev

コンテナを止める

Wockerは、Dockerという仕組みをベースにしており、そこでは「コンテナ」という単位で仮想化環境を管理している。
先の操作では、Wockerデフォルトのコンテナを起動してWordPress本体を走らせている。
wocker runで起動させたので、停止させてみよう。
Git BashのWockerに接続している状態で、下記コマンドを入力。

wocker ~ $ wocker stop

ブラウザからwocker.devへアクセスしてもタイムアウトでページが表示されないはずである。
次に仮想化環境も停止させよう。
一旦Wockerから抜けて、停止のためのVagrantコマンドを入力する。

wocker ~ $ exit

Wockerから抜けたら

$ vagrant halt

これで仮想化環境が停止する。
wocker-command1

コンテナを作る

wocker run というコマンドは、新規にコンテナを作成して起動せよという命令である。
再度runさせても初期状態のWordPressが立ち上がってしまう。
そこで、テスト用のコンテナとしてdev-testというコンテナを作ってみよう。
では再び vagrant up、SSH接続、wockerコマンドを入力。

$ wocker run --name dev-test

runコマンドにコンテナの名前を指定する。
dev-testという新たなWordPress本体が作成されて、起動する。
表示の確認は、先の通りブラウザからhttp://wocker.dev/へアクセス。
また、下記コマンドで実行中のwockerコンテナが確認できる。

$ wocker ps

停止中のコンテナも含めて、作成した全てのコンテナを確認するには-aを付ける。

$ wocker ps -a

wocker-command2
dev-testが作成されて実行中である。(右端のNAMES列)
dev-autumnskyはこのサイトのテーマ開発用コンテナである。
コンテナのWordPress本体とコンテンツ、アップロードファイルはwockerフォルダのdata内に保存される。
例えば、dev-testコンテナのTwenty Sixteenのテンプレートファイルは

D:\wocker\data\dev-test\wp-content\themes\twentysixteenwocker-data

このDataフォルダ内のPHPやCSSを編集すれば即座にwocker.devに反映される。
http://wocker.dev/wp-login.phpにアクセスすれば、ログイン画面が表示される。
初期状態のWockerではuser:admin password:adminと設定されている。
wocker-login
折角なのでエクスプローラからCSSファイルを編集したり、ダッシュボードから何か投稿したりしてみよう。
ブラウザから即座に変更が確認できるはずだ。
一度作ったコンテナを立ち上げる場合は、runでなくstartコマンドを使う。
試しに作ったdev-testを再起動する場合はwockerに入って、

$ wocker start dev-test

一度、停止させて仮想化環境も止めてから、再度Vagrant up /wocker startしてみよう。再起動したWockerは先の変更を保持しているはずだ。もちろんWockerが立ち上がっていなくてもdata内のファイルは編集できる。WockerがWindowsのファイルシステムと自動で同期する仕組みを備えているので、いつでも編集できる。
ここまで確認できていれば、一通りの初期設定は終了、テーマやプラグイン開発に利用できる。
(私はプラグインは作っていないが、テーマは問題なく作れた。)
コンテナは複数作成できるし、不要になったらwockerコマンド一つで削除できる。
Wocker 公式にはWockerに対して使えるコマンド、Wocker内でWordPressの操作に使えるコマンドがまとめられている。

手順のまとめ

方法1 毎回、管理者権限で起動する
WindowsでWockerを使う 光速編 はこちらの方法です。

  1. VirtualBoxとVagrantをインストールする。
  2. Vagrantのプラグインを入れる。
  3. Git Bashを「管理者として実行」する。
  4. Git Bashで$ vagrant up
  5. $ vagrant ssh
  6. wocker ~ $ wocker start container-name

方法2 hostsファイルを書き換えておく

  1. VirtualBoxとVagrantをインストールする。
  2. hostsにWocker用の設定を追記する。
  3. Git Bashで$ vagrant up
  4. $ vagrant ssh
  5. wocker ~ $ wocker start container-name

WockerVCCWなど、仮想化環境を使うメリットを挙げると

  1. 開発環境の構築が簡単になる。
  2. 不具合があってもWindows本体や他のアプリケーションに波及しない。
  3. 複数のWordPress実行環境を短時間で切り替えることができる。
  4. 複数人で開発をする場合、全員で全く同じ環境を用意できる。

などなど。
ハードルが高いように思えるが、実はかえって面倒がない。
さらにWockerのPHP/WordPressはデフォルトで開発に適した設定にしてくれている。
仮想化のメリットは実はWindowsこそ大きいと思うが、解説があまりない。そこで、本記事が役に立てば幸いである。
では、Windowsでも快適なWordPress開発を。

補遺 Wockerが使用するIPアドレス

バージョンによって変わる可能性があるので、WockerコマンドでIPアドレスを確認する方法も紹介する。
SSHでWockerに接続して、

wocker ~ $ ip addr show | grep inet

inetの行だけリストアップされるはずなので、このうちの末尾がscope global eth0のどれかである。
私では今のところ、ここまでしか分からない。健闘を祈る。