作者別: ノリフミ

簡単!DockerでPHP環境構築

先日美容院にいったら小学校以来の短さになったノリフミです。

Dockerについてシリーズ物で記事を書こうとおもっていたのですが、まずは元になる記事をかかねば…
ということで、今回は簡単にPHP環境を構築していきます。

目次

今回の妄想


ア○パ○マ○みたいになってしまいました、、、

今回の妄想は、サーバーやローカルなどでDockerを使い、各プロセスを独立して構築し稼働させることです。
これはDockerの思想?理念?である「1コンテナ1プロセス」に乗っ取った構築図になります。「1コンテナ1プロセス」については色々と論争が絶えないようですが、見なかったことにして進めます。

「簡単」が目標のため、Dockerfileを弄って云々はしません!
コマンドのみで公式debian imageを使って進めますので悪しからず。

Dockerでブリッジネットワークを構築

Dockerで独立して構築したコンテナを相互接続できるようにブリッジネットワークを構築していきます。

既にインストール時に、3種類のネットワークが構築されていますが、分かり易いように独自ネットワークを使いたいと思います。

# dockerブリッジネットワーク構築
docker network create -d bridge --subnet 192.168.99.0/16 --gateway 192.168.99.1 example_nw

「example_nw」は構築するブリッジネットワークの名前になります。
任意で設定してください。

作成が終われば、作成したネットワークを確認しておきます。

# ネットワーク詳細確認
docker network inspect example_nw
[
  {
    "Name": "example_nw",
    "Id": "hashhogehoge",
    "Created": "2017-11-06T00:15:36.163888222Z",
    "Scope": "local",
    "Driver": "bridge",
    "EnableIPv6": false,
    "IPAM": {
      "Driver": "default",
      "Options": {},
      "Config": [
        {
          "Subnet": "192.168.99.0/16",
          "Gateway": "192.168.99.1"
        }
      ]
    },
    "Internal": false,
    "Attachable": false,
    "Ingress": false,
    "ConfigFrom": {
      "Network": ""
    },
    "ConfigOnly": false,
    "Containers": {},
    "Options": {},
    "Labels": {}
  }
]

※ ブリッジネットワーク内のコンテナは設定しているコンテナ名やIPアドレスでアクセスすることが可能です。

Dockerでmysqlを動かす

コンテナを再構築時にもデータを保持できるように、mysqlデータ用のディレクトリをホストに作成しておきます。

mkdir ~/example/mysql

Docker imageはDocker Hubより適当に拝借します。

# docker mysql構築
docker run -d --name mysql \
-v ~/example/mysql:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=root_user_pass \
-e MYSQL_DATABASE=example_db \
-e MYSQL_USER=example_user \
-e MYSQL_PASSWORD=example_user_pass \
--net=example_nw \
--ip=192.168.99.100 \
mysql:latest
Unable to find image 'mysql:latest' locally
latest: Pulling from library/mysql
85b1f47fba49: Pull complete
5671503d4f93: Pull complete
3b43b3b913cb: Pull complete
4fbb803665d0: Pull complete
05808866e6f9: Pull complete
1d8c65d48cfa: Pull complete
e189e187b2b5: Pull complete
02d3e6011ee8: Pull complete
d43b32d5ce04: Pull complete
2a809168ab45: Pull complete
Digest: sha256:hashhogehoge
Status: Downloaded newer image for mysql:latest
hashhogehoge

※ 使用するimageがホストにない場合は初期構築に時間を要します。

mysqlデータ永続化確認

# mysql接続
docker exec -it mysql mysql -u example_user -p example_db
Enter password: 
# テーブル生成 
create table example_tb (id int); 
Query OK, 0 rows affected (0.04 sec) exit; 

# docker-mysql再構築 
docker stop mysql && docker rm mysql 
docker run -d --name mysql \ 
-v ~/example/mysql:/var/lib/mysql \ 
-e MYSQL_ROOT_PASSWORD=root_user_pass \ 
-e MYSQL_DATABASE=example_db \ 
-e MYSQL_USER=example_user \ 
-e MYSQL_PASSWORD=example_user_pass \ 
--net=example_nw \ 
--ip=192.168.99.100 \ 
mysql:latest

再度mysqlに接続し、テーブル確認。

docker exec -it mysql mysql -u example_user -p example_db
Enter password: 
show tables; 
+----------------------+
| Tables_in_example_db |
+----------------------+
| example_tb           |
+----------------------+
1 row in set (0.00 sec)  exit;

Dockerでphp-fpmを動かす

nginxもありますが、先にfpmを構築していきます。

プロジェクト用のディレクトリと簡単なindexファイルを作成しておきます。

mkdir ~/example/src
vi ~/example/src/index.php
<?php
// pdoインスタンス生成
$pdo = new PDO('mysql:host=mysql;dbname=example_db;charset=utf8', 'example_user', 'example_user_pass');
// テーブルリスト取得
$result = $pdo->query('SHOW TABLES')->fetch(PDO::FETCH_ASSOC);
// テーブルリスト表示
echo "example_db table list<br>";
foreach ($result as $row) { echo "{$row}<br>"; }

Docker imageはDocker Hubより適当に拝借します。

# docker php-fpm構築
docker run -d --name php-fpm \
-v ~/example/src:/var/www/html \
--net=example_nw \
--ip=192.168.99.111 \
php:fpm
Unable to find image 'php:fpm' locally
fpm: Pulling from library/php
85b1f47fba49: Already exists
d8204bc92725: Pull complete
92fc16bb18e4: Pull complete
9859644f2c58: Pull complete
eed3518188ca: Pull complete
33c8f7623948: Pull complete
3211acc287de: Pull complete
83bc6e66e57e: Pull complete
c15398ec94ed: Pull complete
Digest: sha256:hashhogehoge
Status: Downloaded newer image for php:fpm
hashhogehoge

※ 使用するimageがホストにない場合は初期構築に時間を要します。

公式imageにデフォルトでmysqlと連携可能なimageが見つからなかったため、手動でインストールしておきます。

# pdo pdo_mysqlインストール、再起動
docker exec php-fpm docker-php-ext-install pdo pdo_mysql
docker restart php-fpm

Dockerでnginxを動かす

nginxの設定ファイルを作成しておきます。

# 設定ファイル用ディレクトリ生成
mkdir ~/example/conf
# nginx設定ファイルを生成
# ドメインは適宜設定しなおしてください
vi ~/example/conf/nginx.conf
server {
 listen 80;
 root /var/www/html;
 server_name example.com;
 index index.php;
 location / {
  try_files $uri $uri/ /index.php?$query_string;
 }
 location ~ \.php$ {
  fastcgi_pass php-fpm:9000;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
  fastcgi_read_timeout 300;
  include fastcgi_params;
 }
 sendfile off;
}

今回はホストの80ポートをポートフォワードさせて、ホストに飛んできたアクセスをdocker nginxに向くように構築します。

# docker nginx構築コマンド
docker run -d --name nginx \
-p 80:80 \
-v ~/example/src:/var/www/html \
-v ~/example/conf/nginx.conf:/etc/nginx/conf.d/example.conf \
--net=example_nw \
--ip=192.168.99.110 \
nginx:stable
Unable to find image 'nginx:stable' locally
stable: Pulling from library/nginx
bc95e04b23c0: Pull complete
f473e7d72364: Pull complete
82cca2490d0d: Pull complete
Digest: hashhogehoge
Status: Downloaded newer image for nginx:stable
hashhogehoge

接続確認

設定したドメインにアクセス可能か、mysql接続が問題ないかを確認します。

ブラウザからアクセス確認した画像
成功!

まとめ

1コンテナ1プロセス…
ローカルmysqlをrdsに変更する場合など、参照先を変更して対象コンテナを削除するだけで、なかったことになるので便利は便利です。

ただ、公開サービスで「リソース監視したい!」と思うだけで
→ munin導入する…?
 → 1コンテナ複数プロセスになる…
  → 実行管理がデフォルトで出来ない…?
   → …etcetc
壁がすごい…

マイクロサービスの運用などには非常に有用ですが、適切に管理するためにはそれなりに知識が必要です。
また機会があればdockerfileやcompose、複数プロセス対応など記事にしたいと思います。

それでは。
 


WordPress開発快適化計画 ~ Wordmoveの簡単導入とメリット・デメリット ~

早く冬が来ないかなとソワソワしているノリフミです。

前回、VCCW on WP-CLIにてWordPressの使い方を紹介しました。

WordPress開発快適化計画 ~ VCCW on WP-CLIを使ってみた ~

Wordmoveを使用してみて、Wordmoveだけでは割と限界があることに気づいてしまいました。

今回はもっと簡単にWordmoveを導入する方法と運用に当たってのメリット・デメリットをご紹介します。

※ 当記事では、Vagrantをインストール済みで、サーバーでWordmoveを公開しており、そのサーバーへssh接続できるものとして話を進めます。

目次

  1. Wordmoveの現状
  2. 今回の妄想
  3. Vagrantで環境構築
  4. Gitの設定
  5. Wordmoveの設定
  6. Wordmoveの使い方
  7. まとめ

Wordmoveの現状

コマンド

init (wordmoveの設定ファイルであるMovefileを生成)

pull (指定環境を元に同期する)
push (実行環境を元に同期する)

-w, [–wordpress], [–no-wordpress]
-u, [–uploads], [–no-uploads]
-t, [–themes], [–no-themes]
-p, [–plugins], [–no-plugins]
-m, [–mu-plugins], [–no-mu-plugins]
-l, [–languages], [–no-languages]

機能フォルダ単位を同期するオプション

-d, [–db], [–no-db]

DBを同期するオプション

-e, [–environment=ENVIRONMENT]

同期環境を複数設定した際に環境を指定するオプション

[–all], [–no-all]

文字通り全てを同期するオプション

メリット

  • ローカル、サーバー間などの別環境のファイルからDBまで簡単に同期できる
  • 同期コマンド(pull,push)にオプションをつけると機能フォルダ別に同期できる
  • 複数環境も設定ファイルに定義しておくと-eオプションで簡単に同期できる
  • 同期時にDBのバックアップがとられる

デメリット

  • ファイル単位の同期はできず、機能フォルダ単位でしか同期できない
  • ファイルの差分は無視される(恐らく更新日時の新しいものが同期される)
  • 差分が無視されて同期されるため、古いファイルは消滅する
  • 間違えてpullやpushしたら取り返しがつかない

今回の妄想

wordmoveとgitを使った管理を表した画像

Wordmoveは複数人開発の際、上記デメリットの点を引き起こしがちです。
今回の妄想ではWordmoveの役目は主にDBの同期とし、ソース管理はgitに任せます。

 

Wordmoveで管理する項目

  • アップロード系の変更 ( -u )
  • プラグイン系の変更 ( -p )
  • language系の変更 ( -l )
  • WordPress自体のバージョンアップ ( –all )
  • その他DBの変更 ( -d )

テーマ以下は基本的にDBに影響を与えないため、git管理とします。

 

作業の基本的な流れ

  • ローカルに環境構築
  • ローカルで作業を進める
  • stagingに作業分を同期し、テストする
  • productionに作業分を同期し、確認する
  • gitにcommitする

複数人開発時、上記工程後の他メンバーは

Vagrantで環境構築

# 適当なフォルダを生成
mkdir wordpress
cd wordpress

# Vagrantfileを生成し設定する
vim Vagrantfile

# nginx設定ファイルを生成
vim nginx.conf

# 設定したipとドメインをhostsに追記
sudo sh -c 'echo "192.168.33.123 example.com" >> /etc/hosts'

# 設定問題なければVagrant起動
vagrant up

….

…..

ここ割と長いですが、最後まで無事終了すれば環境構築完了です。

 

ブラウザからアクセス後、サイト情報を入力し初期設定を完了させてください。

上記構成だと

サイトURL : http://example.com
mysqlユーザー : root
rootユーザーパスワード : root
mysqlデータベース : wordpress

になります。

Gitの設定

初回登録の場合

# Git管理を始める
git init

# 全てをGitに登録する
git add --all

# 確定させる。適宜mオプションでコメント設定
git commit -m 'wordpress install'

# 初めてのpushなので先にRepositoryの場所を決める
git remote add origin GITURL

# branchを設定してpushを実行する
git push -u origin master

決まり文句ですね。

既存Repository使用の場合

# srcディレクトリ削除
rm -rf src
# Repositoryをsrcの名前でclone
git clone GITURL src

 

※ GITURLは適宜Gitの対象RepositoryのURLに変更してご利用ください

Wordmoveの設定


# Wordmove設定ファイル修正
vim src/Movefile

コメントがある箇所と、local部も調整した場合は適宜設定してください。

※ local + 1環境(productionのみなど)の場合、wordmove push or pull時にeオプションにて同期先環境を選択する必要はなくなります。

Wordmoveの使い方

Vagrant内にWordmoveをインストールしているため、Vagrant内のドキュメントルートまで移動する必要があります。

# Vagrant内に接続
vagrant ssh
# ドキュメントルートまで移動
cd /vagrant/src

使用例1(プラグインをインストールし、テーマ以下の調整を行なった場合)

  • 改修者がstagingに同期し確認後、productionへ反映、最後にgitに反映
    wordmove push -e staging -dpt
    wordmove push -e production -dpt
    git commit & push
  • 他メンバーがデータ同期
    wordmove pull -e production -dp
    git pull

使用例2(ブログ引っ越しにて過去記事の画像付きインポートを行なった場合)

  • 改修者がstagingに同期し確認後、productionへ反映
    wordmove push -e staging -du
    wordmove push -e production -du
  • 他メンバーがデータ同期
    wordmove pull -e production -du

その他コマンドについては、上記をご参考ください。

まとめ

これだけ長々と書きましたが、、、
一人の場合はWordmoveだけで管理し、キリのいいところでgitに反映すれば問題ないと思います。

複数人の場合はWordmoveを使った際に、予期せぬ消滅が多々あるので、DB関連の同期のみにしたほうがいいですよ!

というお話でした。

最後までご覧いただきありがとうございました!


WordPress開発快適化計画 ~ VCCW on WP-CLIを使ってみた ~

日に日に暑さが増しておりますが、いつまで経っても見習いプログラマーのノリフミです。

 

Wordpressを使った開発や改修が増えてきている昨今

一人で開発の場合はあまり問題ないのですが、複数人で開発するとなるとどうしても、データの共有面で壁に当たってしまいます。

そこでどうにかならないものかと調べてみると、Wordmoveなるものが良さそうだったのでVCCW on WP-CLIで使ってみました。

 

※ 当記事では、サーバーでWordpressを公開しており、そのサーバーへssh接続できるものとして話を進めます。

 

目次

  1. Wordmoveとは
  2. VCCWとは
  3. WP-CLIとは
  4. 今回の妄想
  5. WP-CLI導入
  6. VCCW on WP-CLI導入
  7. WordPress on Vagrant構築
  8. Wordmoveを使ってみる

お急ぎの方は飛ばし読みを:D

Wordmoveとは

Wordmoveは、ローカルのWordpressインストールとDBデータをローカルの開発マシンからリモートのステージングサーバーに自動的にミラーリングできるようにするgemです。

SSH接続は完全にサポートされていますが、新しい機能が導入されるとFTPサポートは中止される予定です。

プッシュ/プル機能を備えたWordpress用のCapistranoのようなものと考えてください。

Source of github.com/welaika/wordmove

※ 翻訳を使用しております、不自由な日本語にご注意ください

要約すると、

「Wordpressをローカル・サーバー間で簡単に同期出来るんだよ」

ということみたいです。

VCCWとは

これは、WordPressプラグイン、テーマ、またはWebサイトの開発用に設計されたVagrantの設定です。 VCCWには、WordPressのバージョン(またはベータ版)、言語、ホスト名、サブディレクトリ、管理者の資格情報、デフォルトのプラグイン、デフォルトのテーマ、マルチサイト、SSLなどのオプションを設定するためのカスタマイズ可能な変数が含まれています。これらの変数は、特定のニーズに合わせて開発環境を調整する際の柔軟性を提供します。

Source of vccw.cc

※ 翻訳を使用しております、不自由な日本語にご注意ください

要約すると、

「Vagrantを使ってWordpress開発を快適にし、かつ色々と設定出来るんだよ」

ということみたいです。

WP-CLIとは

こちらは、読んで字のごとくなんですが

WP-CLIは、WordPressのインストールを管理するための一連のコマンドラインツールです。 Webブラウザを使用しなくても、プラグインを更新したり、マルチサイトのインストールを構成したりできます。

Source of wp-cli.org

※ 翻訳を使用しております、不自由な日本語にご注意ください

要約すると、

「CLIのみでWordpressを構成、更新が出来るんだよ」

ということみたいです。

 

今回の妄想

一通り説明し終えたところで、今回の妄想のお話

現状はこのような構成で開発しています。

Wordpress開発がgit管理のみなのでデータ同期とれない様子

複数人のWordpress開発でgit管理のみなので、データ同期がとれない。

 

そこでWordmoveを導入してみると

Wordpress開発にWordmoveを導入して快適になった様子

複数人のWordpress開発でWordmoveを導入して、データ同期が簡単にとれるようになる。

 

つまりデータ同期を気にしなくても良くなる!なにこれ素敵!という妄想

 

WP-CLI導入

とりあえず、公式の説明に沿って初期設定をしていきます。

 

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

php wp-cli.phar --info

PHP binary: /usr/local/Cellar/php70/7.0.18_10/bin/php
PHP version: 7.0.18
php.ini used: /usr/local/etc/php/7.0/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI packages dir: /Users/norifumi/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 1.1.0

chmod +x wp-cli.phar

sudo mv wp-cli.phar /usr/local/bin/wp

wp --version

WP-CLI 1.1.0

あっさりインストール成功!

 

VCCW on WP-CLI導入

こちらも、公式の説明に沿って初期設定をしていきます。

 

wp package install vccw/scaffold-vccw:@stable

Installing package vccw/scaffold-vccw (@stable)
Updating /Users/norifumi/.wp-cli/packages/composer.json to require the package…
Using Composer to install the package…

Loading composer repositories with package information
Updating dependencies
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in phar:///usr/local/bin/wp/vendor/composer/composer/src/Composer/Json/JsonFile.php on line 266

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in phar:///usr/local/bin/wp/vendor/composer/composer/src/Composer/Json/JsonFile.php on line 266

メモリが足りないって怒られてしまった…

 

phpのメモリ確認

php -i | grep memory_limit

memory_limit => 128M => 128M

あー少ない…増やそう…

 

編集面倒なので、ワンライナー置換にしておきました。

gsed -i 's/memory_limit = 128M/memory_limit = 512M/g'  "$(php -i | grep 'Loaded Configuration File' | cut -f 5 -d ' ')"

php -i | grep memory_limit

memory_limit => 512M => 512M

成功!

 

再度チャレンジ

wp package install vccw/scaffold-vccw:@stable



Success: Package installed.

成功!

 

WordPress on Vagrant構築

VCCW on WP-CLIを使ってVagrantで動くWordpress構築する。

この時、直下ディレクトリに作成されるので、適当な作業ディレクトリに移動しておくことをオススメします。

※ exampleとなっているコードは適宜置き換えてください

cd example-dir

wp scaffold vccw example-project --host=example.com --ip=192.169.33.123 --lang=ja

Success: Generated. Run `vagrant up`.

cd example-project

vagrant up

==> example.com: [vagrant-hostsupdater] Writing the following entries to (/etc/hosts)
==> example.com: [vagrant-hostsupdater] 192.168.33.123 example.com # VAGRANT: 153b0b8eb7a8772721e73e0acb9f2c0f (example.com) / 08253bf2-edb0-4036-9c6f-9ef33822a578
==> example.com: [vagrant-hostsupdater] This operation requires administrative access. You may skip it by manually adding equivalent entries to the hosts file.
Password:

/etc/hostsに書き込みのためパスワードを求められるので入力

 

ここからは

TASK [hogehoge]

をしばし眺めます。

TASK [hogehoge]

TASK [hogehoge]

TASK [hogehoge]

最終的に

PLAY RECAP *********************************************************************
example.com : ok=62 changed=55 unreachable=0 failed=0

と表示されれば完了!

 

hosts確認してみれば、きっちり追記されています。

cat /etc/hosts | grep example.com

192.168.33.123 example.com # VAGRANT: 153b0b8eb7a8772721e73e0acb9f2c0f (example.com) / 08253bf2-edb0-4036-9c6f-9ef33822a578

 

Wordmoveを使ってみる

さきほど立ち上げたVagrant内で作業していきます。

 

vagrant ssh

Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-38-generic x86_64)

vi /vagrant/Movefile

local部分の

  • vhost
  • wordpress_path
  • database
    • name
    • user
    • password
    • host
    • charset

production部分の

  • vhost
  • wordpress_path
  • database
  • ssh
    • host
    • user
    • port
    • rsync_options

項目を適宜設定してください。

 

サーバーのデータをローカルに反映してみる。

wordmove pull --all

▬▬ ✓ Using Movefile: ./Movefile ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling wordpress core ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Uploads ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Themes ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Plugins ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Mu Plugins ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Languages ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ ✓ Pulling Database ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

成功!

 

確認してみる

mysql -u root -p

mysql> use wordpress

mysql> show tables;

Tables_in_wordpress
——-
server_wp_commentmeta
server_wp_comments

wp_commentmeta
wp_comments

しっかりDBのデータも取得できていました!

 

懸念点

  • 複数人でデータ同期することによって、データが消えてしまう可能性がありそう
  • Wordmoveばかり使いすぎてgitの更新を疎かにしそう
  • そしてgitで修正できないほどの衝突が起こってしまいそう

まとめ

WordPressで複数人開発するなら、Wordmove使った方がデータ同期できて、開発が捗る!

 

でも、簡単にpush -allなどをしてしまうとデータが消えてしまう可能性があるので、こまめにpullしておいたほうが良さそうですね。

 

以上、ありがとうございました。