WordPressの運用にJenkins / IntelliJ / wordmove を使ってみる。
相変わらず自分でアプリを作れず、OSSのツールを使って色々お仕事させていただいている日々です….。(もちろん、それはそれで楽しいです！）
現在はPloneに代わってWordPressの環境構築／調整の作業が増えています。
（※サービスや外に出すお仕事ではないです）
とは言え、WordPressの経験はそんなに長い訳でもなく、phpがちゃんと書けるわけでも無いのですが、サーバ管理面／運用面でいくつか工夫してみていることが溜まってきたので、記事を書いてみます。
今回も、Cacooを使った図も載せてみます。まだまだ良くわかっていない点、知らない点がたくさんありますので、WordPressに詳しい方をはじめ、皆さんからのアドバイスやご指摘をいただけると幸いです。
わたしの担当は、素のOSインストール後に始まります。（ネットワーク周りの設定は別で、OSを引き渡してもらってからです）
これはわたしの問題なので、これからも覚えなくてはいけないことは多そうですね(^^;
ひとまずアプリケーションを動かせるようになったら、検証機で基本の設定をし、リバースプロキシ下で動かすためのWebサーバの調整、DBやphpのキャッシュを効かせるための調整をします。
この段階で、どんどん /etc/ 以下の設定ファイルは変更が入って行きます。設定の変更については、少なくともリポジトリに変更を記録していくようにしています。
最近は、@kusukawa さんのyggdrassil というrubyのツールを使って設定変更の記録／未コミットの記録のチェックを行うようになりました。
OSの設定ファイルは、WARやディレクトリ単体で完結するアプリケーションとは違って、/ 直下から枝葉のように広がってファイルがたくさんあります。
最初は /etc 以下だけを管理してたので、/etc 専用のリポジトリを持っていたけど、/var 以下も必要になってしまいリポジトリがバラバラになって困った、という経験があるので、yggdrasil を使うようになって、この悩みがスッキリしました！
yggdrasilについては、こちらの記事もどうぞ。
WordPressを動かす前段階の設定と並行して、WordPressの仮サイトも仕込みをします。デザイン面や記事そのものはわたしの担当では無いのですが、サイトのオーナーの要望から、カテゴリ設定やパーマリンクの設定など、ベースのサイトを作っていきます。
WordPressプラグインでのキャッシュ設定や、アカウントのActiveDirectory / LDAP連携といった、OSや外部リソースとの突き合わせが必要な設定も担当します。 その上で、サイトのオーナー、デザイン／テーマ作成担当の方に検証環境を開放し、書き込みのチェック、デザインの作り込みをお願いしています。
通常、テーマやテーマに必要な素材は、デザインやプラグイン開発担当者がローカルPCで作成を行います。そのうえで、FTPでアップしたりWordPressの管理画面から直接テーマ編集をしたりできますが、わたしがFTPサーバとしての設定を横着しており、ただいまデザイン担当の方には、FTPでの直接アップは行わないでもらっています。
（scpなら許可という管理者の勝手な都合を押し付けています….)
なぜかというと、最初、テーマのバージョン管理をデザイン担当の方に行ってもらっていなかったので、直接サーバのものをいじると変更が分からなくなってしまう危険性があったからでした。
代わりに、Subversionのリポジトリサーバを調整して、DAVのフォルダにアップしてもらい、Subversion側のAutoCommit機能を使って変更を登録したあと、Jenkinsを使って検証用のサーバにテーマをdeployをし、サーバ環境での動作確認をしてもらっています。
検証環境は本番とほぼ同じ構成で、wp-config.php やキャッシュ設定用のファイルなどが違うだけになっています。
さらに、時々、本番環境から記事やアップされた画像を検証機に同期をさせて、検証機でもより本番に近いデータを使ってチェックできるようにしています。
ちなみに、WordPressはリバースプロキシを通して利用しており、サーバ間のディレクトリ構成も若干の違いがあります。コンテンツのデータの溜まったDBにも、URLをハードコード（絶対パスでの記載）をしている部分があるので、単純なrsync, mysqldump ではうまく稼働できません。
こちらについては、試行錯誤しつつ、Jenkinsのシェルベースのジョブを組んで、rsync後に一部ファイルのパスを書き換える、mysqldump後に文字列を置換してからインポートするといった処理を加えています。
さて、上記の通り、デザイン担当の方には、サーバに対する直接変更はしないようにしてもらっているものの、サーバ管理する側としては、まだまだサーバ自体の設定 (/etc なにがしとか) は、チケット切って直接編集して変更してコミットというのを抜けきれていません….。
「人にはお願いしておきながら、自分だけは本番直接いじってもいい」というのも如何なものかと思っているので。 気持ちとしても、できるだけ検証機とか仮想環境で /etc 以下の設定をFixさせてから、設定反映 〜プロセス再起動をしたいので、chefとかserverspecとか扱えるようにしないとなあと考えています。
そのために、ただいま自分のローカルのMacで仮想環境を作って練習したり、WordPressのデバッグをできるように取り組んでいます。
ここでお世話になってるのがIntelliJ。コード／アプリケーション開発者とは言えない身ですが、サイトを安全安心に運用したいよね、という気持ちはあるので、デバッグにIntelliJ活用させていただいてます(_ _)
ローカル環境ではMAMPを使っています。
また、データベースやソースの同期（再現）には、wordmoveというruby製のコマンドラインツールを最近使うようになりました。 wordmove の使い方、オプションについては、こちらの記事にも書きました。
上記のようなやり方で、色々試しながらWordPressをセットアップ〜運用しています。
ユーザをたくさん抱えるような大規模なブログサービスなんて、どうやってるんだろう…と全く想像もつきませんが、経験も無いとわからないので、恥ずかしながら『手を動かして結果を確認して理解する』ということの繰り返しになっています。
ただし、WordPressについては本当に情報が多いので、その点は有り難く、情報発信して下さっている皆様には、本当に感謝です。
現在はPloneに代わってWordPressの環境構築／調整の作業が増えています。
（※サービスや外に出すお仕事ではないです）
とは言え、WordPressの経験はそんなに長い訳でもなく、phpがちゃんと書けるわけでも無いのですが、サーバ管理面／運用面でいくつか工夫してみていることが溜まってきたので、記事を書いてみます。
- セットアップ作業（まだまだ要改善）
- WebサーバやDBの調整
- 検証環境と本番環境の同期 (with Jenkins)
- サーバ管理者も、もっと安心したい / デバッグしたい
(with wordmove, IntelliJ) - こんなやり方でいいのか、時々ふりかえる
今回も、Cacooを使った図も載せてみます。まだまだ良くわかっていない点、知らない点がたくさんありますので、WordPressに詳しい方をはじめ、皆さんからのアドバイスやご指摘をいただけると幸いです。
セットアップ作業（まだまだ要改善）
わたしの担当は、素のOSインストール後に始まります。（ネットワーク周りの設定は別で、OSを引き渡してもらってからです）
- yumリポジトリの追加
- DBやphp、Webサーバの設定、基本のWordPress稼働の確認
- 実際の稼働に見合ったパラメータ調整
- リバースプロキシ適用のための調整
などを行います。
ただ、残念ながら、上記のセットアップ作業は、まだまだChefなどのプロビジョニングツールによる効率化ができていません。
どのWebサーバで、phpの高速化にはなにが適しているか、といったあたりはまだまだ試行錯誤なので、検証機を先に作って、VMを必要に応じてコピー、というやりかたで凌いでいます。
ただ、残念ながら、上記のセットアップ作業は、まだまだChefなどのプロビジョニングツールによる効率化ができていません。
どのWebサーバで、phpの高速化にはなにが適しているか、といったあたりはまだまだ試行錯誤なので、検証機を先に作って、VMを必要に応じてコピー、というやりかたで凌いでいます。
これはわたしの問題なので、これからも覚えなくてはいけないことは多そうですね(^^;
WebサーバやDBの調整
ひとまずアプリケーションを動かせるようになったら、検証機で基本の設定をし、リバースプロキシ下で動かすためのWebサーバの調整、DBやphpのキャッシュを効かせるための調整をします。
この段階で、どんどん /etc/ 以下の設定ファイルは変更が入って行きます。設定の変更については、少なくともリポジトリに変更を記録していくようにしています。
最近は、@kusukawa さんのyggdrassil というrubyのツールを使って設定変更の記録／未コミットの記録のチェックを行うようになりました。
OSの設定ファイルは、WARやディレクトリ単体で完結するアプリケーションとは違って、/ 直下から枝葉のように広がってファイルがたくさんあります。
最初は /etc 以下だけを管理してたので、/etc 専用のリポジトリを持っていたけど、/var 以下も必要になってしまいリポジトリがバラバラになって困った、という経験があるので、yggdrasil を使うようになって、この悩みがスッキリしました！
検証環境と本番環境の同期
WordPressを動かす前段階の設定と並行して、WordPressの仮サイトも仕込みをします。デザイン面や記事そのものはわたしの担当では無いのですが、サイトのオーナーの要望から、カテゴリ設定やパーマリンクの設定など、ベースのサイトを作っていきます。
WordPressプラグインでのキャッシュ設定や、アカウントのActiveDirectory / LDAP連携といった、OSや外部リソースとの突き合わせが必要な設定も担当します。 その上で、サイトのオーナー、デザイン／テーマ作成担当の方に検証環境を開放し、書き込みのチェック、デザインの作り込みをお願いしています。
通常、テーマやテーマに必要な素材は、デザインやプラグイン開発担当者がローカルPCで作成を行います。そのうえで、FTPでアップしたりWordPressの管理画面から直接テーマ編集をしたりできますが、わたしがFTPサーバとしての設定を横着しており、ただいまデザイン担当の方には、FTPでの直接アップは行わないでもらっています。
（scpなら許可という管理者の勝手な都合を押し付けています….)
なぜかというと、最初、テーマのバージョン管理をデザイン担当の方に行ってもらっていなかったので、直接サーバのものをいじると変更が分からなくなってしまう危険性があったからでした。
代わりに、Subversionのリポジトリサーバを調整して、DAVのフォルダにアップしてもらい、Subversion側のAutoCommit機能を使って変更を登録したあと、Jenkinsを使って検証用のサーバにテーマをdeployをし、サーバ環境での動作確認をしてもらっています。
検証環境は本番とほぼ同じ構成で、wp-config.php やキャッシュ設定用のファイルなどが違うだけになっています。
さらに、時々、本番環境から記事やアップされた画像を検証機に同期をさせて、検証機でもより本番に近いデータを使ってチェックできるようにしています。
ちなみに、WordPressはリバースプロキシを通して利用しており、サーバ間のディレクトリ構成も若干の違いがあります。コンテンツのデータの溜まったDBにも、URLをハードコード（絶対パスでの記載）をしている部分があるので、単純なrsync, mysqldump ではうまく稼働できません。
こちらについては、試行錯誤しつつ、Jenkinsのシェルベースのジョブを組んで、rsync後に一部ファイルのパスを書き換える、mysqldump後に文字列を置換してからインポートするといった処理を加えています。
サーバ管理者も、もっと安心したい / デバッグしたい
さて、上記の通り、デザイン担当の方には、サーバに対する直接変更はしないようにしてもらっているものの、サーバ管理する側としては、まだまだサーバ自体の設定 (/etc なにがしとか) は、チケット切って直接編集して変更してコミットというのを抜けきれていません….。
「人にはお願いしておきながら、自分だけは本番直接いじってもいい」というのも如何なものかと思っているので。 気持ちとしても、できるだけ検証機とか仮想環境で /etc 以下の設定をFixさせてから、設定反映 〜プロセス再起動をしたいので、chefとかserverspecとか扱えるようにしないとなあと考えています。
そのために、ただいま自分のローカルのMacで仮想環境を作って練習したり、WordPressのデバッグをできるように取り組んでいます。
ここでお世話になってるのがIntelliJ。コード／アプリケーション開発者とは言えない身ですが、サイトを安全安心に運用したいよね、という気持ちはあるので、デバッグにIntelliJ活用させていただいてます(_ _)
ローカル環境ではMAMPを使っています。
また、データベースやソースの同期（再現）には、wordmoveというruby製のコマンドラインツールを最近使うようになりました。 wordmove の使い方、オプションについては、こちらの記事にも書きました。
- wordmoveを使ってWordPressサーバのデータを開発機に再現 (on Qiita)
こんなやり方でいいのか、時々ふりかえる
上記のようなやり方で、色々試しながらWordPressをセットアップ〜運用しています。
ユーザをたくさん抱えるような大規模なブログサービスなんて、どうやってるんだろう…と全く想像もつきませんが、経験も無いとわからないので、恥ずかしながら『手を動かして結果を確認して理解する』ということの繰り返しになっています。
ただし、WordPressについては本当に情報が多いので、その点は有り難く、情報発信して下さっている皆様には、本当に感謝です。
コメント
コメントを投稿