Onishiたいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)今回のゴールデプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施するウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更するデプロイ元の環境で鍵ペアを作る今回はVCCWを使ったVagrant内のWordMoveを使います。WordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。~/.ssh/id_rsa.pub秘密鍵のパスフレーズは必要に応じて設定してください。ように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。いう名前で作成します。authorized_keysを保護デプロイユーザーが対象のディレクトリに書き込めるようにする今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。グループに書き込み権限を与えるこれで終わり...なら簡単で、記事にすることもないんですが、2つ問題があります。deployerでファイルの編集をしてみます。/usr/share/nginx/html/index.php次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。/usr/share/nginx/html/index-new.php次にパーミッションをチェックします。index-new.php1つめの問題です。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。これを解決する方法として特殊なパーミッションビット、setgidを使います。並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。bitは使わないので省略します。idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。指定することで設定できます。/usr/share/nginx/html/index-new2.phpチェックしてみます。index-new2.phpデフォルトでグループがnginxに割り当てられています。思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。デフォルトパーミッションを変更するここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。002(=664、自分とグループの人が書き込み可)に変更したいわけです。002テストしてみます。index-new3.php新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。WordMoveでデプロイしてみる今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。--themesちゃんとプッシュできていることを確認して終わりです。雑感ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。Onishi非SSL環境で動かしていたWordPressをSSL化するときの手順です。Encryptを使って認証された証明書が手に入ったので、これを使ってWordPress全体をSSL化してみました。手順を備忘録として残しておきます。wp-config.phpの修正まずは基本ですね。WP_HOMEとWP_SITEURLを書き換えます。FORCE_SSL_ADMINを設定することで管理画面はHTTPSを強制できます。option_nameカラムがsiteurlになっているレコードを探し、値のhttp://をhttps://に書き換えます。続いてoption_nameカラムがhomeになっているレコードを探し、同じように書き換えます。HTTP接続をHTTPSにリダイレクト上の2ステップでWordPressのシステム的な部分の移行が終わりました。HTTPSで適当なページを開いて正しくリンクが遷移できるか、リンク遷移後もページもHTTPSになっているか、画像や画像のサムネイルが正しく読み込めているか、管理画面へHTTPSのままログインできるか、などをチェックします。問題がないようであれば、httpでの接続はすべてhttpsにリダイレクトするようにします。httpsにすると若干サーバーの負荷も増えますので、ハイトラフィックなブログを運営されている方はhttpの方が有利という考え方もできます。ブログであれば、http/httpsどちらでもアクセス出来るようにしておき、通信を暗号化するかどうか判断をユーザーに委ねるのも良い方法です。)今回nginxを使っているので、nginx.confを書き換えることにしましょう。リダイレクトにはrewiteを使っているブログも多く見られますが、nginx.orgではreturnが使われていたのでreturnを使うことにします。計った訳ではないですが、シンプルな分処理も早そうです。ssl;}保存したらnginxを再起動します。restart再起動が終わったら、適当なURLを叩いてみてHTTPSに正しくリダイレクトされることを確認します。Content問題)これで9割方終わっていて、SSLにするという目的自体は達成なのですが、次のように「このページに安全でない他のリソースが含まれています。」と表示され、URLのアイコンや文字色も緑色にならないことがあります。これは、アクセスしているページはSSL接続にも関わらず、そのページ内から非SSLの静的ファイル等をロードしているためです。続く形でロードしていることに起因するものが多いです。これらを見つけて、httpsが提供されているコンテンツはhttpsでロードするように、提供されていない場合はライセンスを確認して自分のサーバーでホスティングできるか確認して移行するなどの対策を行います。量が多いと結構大変ですね...。Chromeのデベロッパーツールにあるコンソールが助けになります。上の画像のように、過去にアップロードした画像ファイルに起因するものであれば、次の項を読んでみてください。テーマやプラグインに起因するものは、手動で直さなければいけません。URLという仕様により、CSSやJavaScriptをロードする際のhttpやhttpsを省いて記述すると、読み込み元のスキーム(SSLか非SSLか)に従って読み込むスキームも変更されポータビリティが高まります。SSLのページからロードさせた場合はhttps://〜と解釈され、非SSLのページからロードさせた場合はhttp://〜と解釈されます。Contents問題を直すこの場合、基本的には記事を編集して、画像へのURLを書き直すことで修正できますが、過去の記事・画像が多いと直すのに骨が折れます。RelativeなURLに画像リンクを書き換えるSQL文を使うと一瞬で解消できるでしょう。テストしていますが、万一のために必ず実行前にテーブルのバックアップを取ってください。ContentsによるSSLの警告も消えました。雑感サクっとこなすつもりが意外と色々気にすることがあって大変でした。一度やっておくとノウハウ的に使い回せるので、知識として蓄えておきたいですね。SPDY対応や、証明書の透明性確保あたりを触れたらいいなと思っています。OnishiWordPressを使ってウェブを作っているみなさん!まだXAMPPでMAMPで消耗してるんですか!?VCCWを使う選択VCCWというのは、VagrantをベースにしたWordPressの開発環境です。従来、何もないところからWordPressの開発をはじめるとなると、WebとDBサーバーをインストールして、データベースを作って、WordPressをダウンロードして、接続情報を入力して...など、多くの手順を踏まなくてはいけませんでした。Web、DBサーバーも独立しているため管理も煩雑になりがちです。VCCWを使うと本当に簡単に開発環境が整います。WordPressの開発に便利な色々な支援ツールも一気に使えるようになります。WordPressのサイト個々にOSイメージが作られるため、一つのMySQLサーバーで複数のサイトを飼いながら開発...なんてこともなくなります!テーマを作るデザイナーの方は少し敷居が高いかもしれませんが、プラグインなどを作るエンジニアよりの方は是非一度お試しください!一度これに慣れると、もう従来の方法でなんて開発できませんよ!事前準備VCCWはVagrantfileを使って仮想環境を構築するため、先にVagrantを使えるようにしなければいけません。したがって、VirtualBox+Vagrantの開発環境を先に整えてから読み進めてください。Windowsの方はこのプラグインを使えないので読み飛ばしてください。編集」とかでググってください。vccw.dev)でアクセスできるようになります。これは完全に好みですが、複数サイトを開発する際に直感的な名前でアクセスできるので私は便利に使っています。インストールは次のコマンドを実行します。グローバルにインストールされるので、好きなディレクトリ上で実行して構いません。触れたように、仮想マシンの起動にはBoxが必要です。VCCWで用いるBoxをダウンロードしておきます。miya0001/vccwBoxのダウンロードにはまた時間がかかるので、ダウンロードしている間に次のステップを終わらせておきましょう。VCCWをダウンロード前述のステップでBoxは用意しましたが、このBoxを使うためには予め用意されたVagrantfileと環境構築用のスクリプト(内部ではChefを使っています)が入ったVCCW本体と呼べるものをダウンロードして、それを作業用のフォルダとして使います。次のVCCW公式ページからzip、もしくはtar.gz形式で圧縮されたVCCW本体をダウンロードしてきてください。執筆時点の最新バージョンは2.18.0です。http://vccw.cc/ダウンロードしたら解凍して、サイトの名前など分かりやすいものに変更します。今後頻繁に開くことになるので、開発用のフォルダなど決めているのであれば移動しておきましょう。実際に起動する前に、日本語のWordPressが導入されるように設定を変更しておきましょう。これを設定しておかないと、デフォルトで英語のWordPressがインストールされることになります。後から変更するのは一手間です。VCCWを配置した下のprovisionフォルダにあるdefault.ymlを、VCCWのフォルダ直下にsite.ymlという名前でコピーしてきてください。コピーするということになります。(私はここでprovisionフォルダ内にコピーするものと思い込み、何故動かないのかソースコードを読んでコピー先の位置間違いに気付きました......。開いて、次の通りlangを変更します。Settingsのmemoryとcpusの数を増やしておくと良いでしょう。Settingsのhostnameをサイト名などを使ったホスト名に変更しておくと良いと思います。このホスト名を使ってWordPressにアクセスできるようになります。VCCWを起動BoxとVCCWの準備が終わったらいよいよ起動してみます。ダウンロードしてきたVCCWが入っているディレクトリにターミナルで移動して、その中にあるVagrantfileを元にVagrantを起動します。upVCCWを初めて起動する場合、仮想マシンのコピーに加えて、Apache+MySQLサーバーのダウンロードやWordPressのダウンロード、開発支援ツール群のダウンロードなど、様々な処理がVagrant内で行われます。これにも結構な時間がかかります(私の環境で5分程度)ので、気長に終わるのを待ちましょう。前述したhostsupdaterプラグインをインストールしている場合、その処理が実行される際にrootユーザーのパスワードを求められることがあります。入力しないと進まないので気をつけましょう。