Twitter Facebook github

Category “WordPress”

デプロイ用ユーザーの在り方を考える

たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。

 

今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。

WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。

前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。

(後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。)

 

今回のゴール

  • デプロイ用の専用ユーザーを作り、WordMoveはデプロイ用のユーザーからデプロイを実施する
  • ウェブサーバーの実行ユーザーは変更しない(apacheまたはnginx)
  • 上記のままうまく回るようにユーザーとディレクトリのパーミッションを変更する

 

デプロイ元の環境で鍵ペアを作る

今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。

秘密鍵のパスフレーズは必要に応じて設定してください。

ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。

 

デプロイ用のユーザーを準備する

ここでは deployer という名前で作成します。

 

デプロイユーザーが対象のディレクトリに書き込めるようにする

今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。

今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。

 

これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。

deployerでファイルの編集をしてみます。問題なくできます。

 

次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。

次にパーミッションをチェックします。

1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。

これを解決する方法として特殊なパーミッションビット、setgidを使います。

 

setgidを理解する

setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。

setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。

setgidはchmodコマンドで g+s を指定することで設定できます。

チェックしてみます。

デフォルトでグループがnginxに割り当てられています。

今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。

 

デフォルトパーミッションを変更する

ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。

umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022(=新規ファイルは644、自分だけ書き込み可)になっていますので、今回はumask 002(=664、自分とグループの人が書き込み可)に変更したいわけです。

今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。

テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。

新規ファイルも664のパーミッションで、グループを継承できました!念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。

 

WordMoveでデプロイしてみる

今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。

Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。

ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。

 

雑感

ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。

WordPressをSSLに対応させる手順

非SSL環境で動かしていたWordPressをSSL化するときの手順です。ちょうどLet’s Encryptを使って認証された証明書が手に入ったので、これを使ってWordPress全体をSSL化してみました。手順を備忘録として残しておきます。

 

wp-config.phpの修正

まずは基本ですね。WP_HOMEとWP_SITEURLを書き換えます。また、FORCE_SSL_ADMINを設定することで管理画面はHTTPSを強制できます。

 

データベースの修正

WordPressのデータベースに接続し、(WPプレフィックス)_options テーブルを開きます。

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を使うことにします。計った訳ではないですが、シンプルな分処理も早そうです。

保存したらnginxを再起動します。

再起動が終わったら、適当なURLを叩いてみてHTTPSに正しくリダイレクトされることを確認します。

 

安全でないリソースを排除する(Mixed Content問題)

これで9割方終わっていて、SSLにするという目的自体は達成なのですが、次のように「このページに安全でない他のリソースが含まれています。」と表示され、URLのアイコンや文字色も緑色にならないことがあります。

これは、アクセスしているページはSSL接続にも関わらず、そのページ内から非SSLの静的ファイル等をロードしているためです。例えば、サードパーティのCSSやJavaScript、フォントファイル、画像ファイル等を絶対パスでhttp:// に続く形でロードしていることに起因するものが多いです。

これらを見つけて、httpsが提供されているコンテンツはhttpsでロードするように、提供されていない場合はライセンスを確認して自分のサーバーでホスティングできるか確認して移行するなどの対策を行います。量が多いと結構大変ですね…。

どのファイルがMixed Contentなのかは、Google Chromeのデベロッパーツールにあるコンソールが助けになります。

例えば上の画像のように、過去にアップロードした画像ファイルに起因するものであれば、次の項を読んでみてください。テーマやプラグインに起因するものは、手動で直さなければいけません。

ちなみに、Protocol Relative URLという仕様により、CSSやJavaScriptをロードする際のhttpやhttpsを省いて記述すると、読み込み元のスキーム(SSLか非SSLか)に従って読み込むスキームも変更されポータビリティが高まります。(例えば //example.com/main.js をSSLのページからロードさせた場合はhttps://〜と解釈され、非SSLのページからロードさせた場合はhttp://〜と解釈されます。)

 

アップロード画像に起因するMixed Contents問題を直す

この場合、基本的には記事を編集して、画像へのURLを書き直すことで修正できますが、過去の記事・画像が多いと直すのに骨が折れます。

一気に前述したProtocol RelativeなURLに画像リンクを書き換えるSQL文を使うと一瞬で解消できるでしょう。テストしていますが、万一のために必ず実行前にテーブルのバックアップを取ってください。

 

無事にMixed ContentsによるSSLの警告も消えました。

 

雑感

サクっとこなすつもりが意外と色々気にすることがあって大変でした。一度やっておくとノウハウ的に使い回せるので、知識として蓄えておきたいですね。

次はHTTP/2, SPDY対応や、証明書の透明性確保あたりを触れたらいいなと思っています。

VCCWでイマドキWordPress開発環境

WordPressを使ってウェブを作っているみなさん!まだXAMPPでMAMPで消耗してるんですか!?

 

VCCWを使う選択

VCCWというのは、VagrantをベースにしたWordPressの開発環境です。

従来、何もないところからWordPressの開発をはじめるとなると、WebとDBサーバーをインストールして、データベースを作って、WordPressをダウンロードして、接続情報を入力して…など、多くの手順を踏まなくてはいけませんでした。Web、DBサーバーも独立しているため管理も煩雑になりがちです。

VCCWを使うと本当に簡単に開発環境が整います。また、WordPressの開発に便利な色々な支援ツールも一気に使えるようになります。WordPressのサイト個々にOSイメージが作られるため、一つのMySQLサーバーで複数のサイトを飼いながら開発…なんてこともなくなります!

テーマを作るデザイナーの方は少し敷居が高いかもしれませんが、プラグインなどを作るエンジニアよりの方は是非一度お試しください!一度これに慣れると、もう従来の方法でなんて開発できませんよ!

 

事前準備

VCCWはVagrantfileを使って仮想環境を構築するため、先にVagrantを使えるようにしなければいけません。

拙著 Vagrantことはじめ にしたがって、VirtualBox+Vagrantの開発環境を先に整えてから読み進めてください。

 

hostsupdaterプラグインをインストール

(※ Windowsの方はこのプラグインを使えないので読み飛ばしてください。ホスト名でアクセスしたい場合は、「Windows hosts 編集」とかでググってください。)

VCCWで構築したWordPressの環境は、ローカルIPアドレスでアクセスできるようになりますが、PC内にあるhostsファイルというものを編集することで、任意のホスト名(デフォルトであれば vccw.dev)でアクセスできるようになります。これは完全に好みですが、複数サイトを開発する際に直感的な名前でアクセスできるので私は便利に使っています。

インストールは次のコマンドを実行します。グローバルにインストールされるので、好きなディレクトリ上で実行して構いません。

 

Boxの準備

Vagrantことはじめ でも触れたように、仮想マシンの起動にはBoxが必要です。VCCWで用いるBoxをダウンロードしておきます。

Boxのダウンロードにはまた時間がかかるので、ダウンロードしている間に次のステップを終わらせておきましょう。

 

VCCWをダウンロード

前述のステップでBoxは用意しましたが、このBoxを使うためには予め用意されたVagrantfileと環境構築用のスクリプト(内部ではChefを使っています)が入ったVCCW本体と呼べるものをダウンロードして、それを作業用のフォルダとして使います。

次のVCCW公式ページからzip、もしくはtar.gz形式で圧縮されたVCCW本体をダウンロードしてきてください。執筆時点の最新バージョンは2.18.0です。

http://vccw.cc/

ダウンロードしたら解凍して、サイトの名前など分かりやすいものに変更します。また今後頻繁に開くことになるので、開発用のフォルダなど決めているのであれば移動しておきましょう。

 

VCCWの設定

実際に起動する前に、日本語のWordPressが導入されるように設定を変更しておきましょう。これを設定しておかないと、デフォルトで英語のWordPressがインストールされることになります。後から変更するのは一手間です。

まず、VCCWを配置した下のprovisionフォルダにあるdefault.ymlを、VCCWのフォルダ直下にsite.ymlという名前でコピーしてきてください。

仮にVCCWを ~/vccw/ に設置したとすると、 ~/vccw/provision/default.yml を、 ~/vccw/site.yml にコピーするということになります。(私はここでprovisionフォルダ内にコピーするものと思い込み、何故動かないのかソースコードを読んでコピー先の位置間違いに気付きました……。)

コピーできたら、エディタで site.yml を開いて、次の通りlangを変更します。

PCのスペックに余裕がある人は、Virtual Machine Settingsのmemoryとcpusの数を増やしておくと良いでしょう。

また、前述のhostsupdaterを導入した人は、Network Settingsのhostnameをサイト名などを使ったホスト名に変更しておくと良いと思います。このホスト名を使ってWordPressにアクセスできるようになります。

 

VCCWを起動

BoxとVCCWの準備が終わったらいよいよ起動してみます。ダウンロードしてきたVCCWが入っているディレクトリにターミナルで移動して、その中にあるVagrantfileを元にVagrantを起動します。

VCCWを初めて起動する場合、仮想マシンのコピーに加えて、Apache+MySQLサーバーのダウンロードやWordPressのダウンロード、開発支援ツール群のダウンロードなど、様々な処理がVagrant内で行われます。これにも結構な時間がかかります(私の環境で5分程度)ので、気長に終わるのを待ちましょう。ただし、前述したhostsupdaterプラグインをインストールしている場合、その処理が実行される際にrootユーザーのパスワードを求められることがあります。入力しないと進まないので気をつけましょう。

 

使ってみる

無事に起動できたら早速チェックしてみましょう!ブラウザで http://192.168.33.10/ を開いてみてください。hostsupdaterを導入した方は、設定したホスト名でも開けるかと思います(デフォルトは http://vccw.dev/ です)。

ちゃんと日本語のWordPressが表示されればOKです!管理画面は /wp-admin で、IDとパスワードは変更していなければ共に admin です。

 

開発してみる

vagrant upを実行すると、VCCWの中に /www/wordpress というディレクトリが作られます。/www ディレクトリはVagrantの仮想マシン内と共有されています。

例えばテーマを作る時は /www/wordpress/wp-content にある themes  内を編集すればいいですし、プラグインは同じく plugins になります。/www/wordpress の中で従来通りの開発すればよいということですね!

もちろんWordPressの管理画面からテーマやプラグインをインストールした場合も、そのフォルダの中に保存されていきます。もちろんリアルタイムです!

 

まとめ

従来の開発環境と比べて、いかに楽にクリーンで本番環境に近い開発環境が構築できたか体感いただけましたか?これからのWordPress開発はVCCWの時代ですよ!