こんにちは。
バックエンドエンジニアのまさくにです。
最近はありがたいことにアプリケーション系の案件も増えてきましたが、弊社のビジネスのメインストリームは、やはりコーポレートサイトのリニューアルをはじめとするサイト制作。
もっと言えばWordPressサイト制作なわけで。
「コンテンツを更新する必要がある」というご要件をいただくと、管理画面がすでに用意され、拡張性が高く、弊社ではもっとも開発工数が少なく済み、CMSとしていい意味で枯れている。それらのメリットを享受できるため、第一選択肢にはやっぱりWordPressが挙げられます。
ですが……。
WordPress、デプロイ面倒過ぎやしませんか。
この辺、何がデファクトなんでしょうか。皆さん、各々でやっている気がしますが、管理画面でそのほとんどの管理ができるという特質が「WordPressは簡単だ」という油断を生み、多くの障害を発生させている気がします。
なぜ僕らはその簡単であるはずのWordPressについて悩まされるのか、今のところ自分はどうしているか、特に焦点をデプロイに向けて今回は考えてみたいと思います。本記事の対象はWordPressのテーマを日常的に開発されている方々です。
目次
デプロイが一元化できない理由
コストの問題
多数のインフラ業者さんがいる中で、個人的にはAWS使えればたいてい何とかなるんじゃないかなーって思っています。機能的には。でも案件ごとにフィットするインフラをいろいろ検討するんですけど、何だかんだでAWSはやっぱり高くなりがちなんですよね。コスト。
AWSでも工夫すれば月々のコストは下げられると思うんですけど、それって何もAWSらしい機能使ってなくてオーバースペックなんじゃないのかという気持ちがどうしても拭えません。
また月々定額の精算フローの方が把握しやすいお客様も多いため、AWSの不確定な請求が忌避される傾向にあり、日本発のさくらとか、その辺のVPSサービスを選択することが多くなります。
もしくはお客さんがお手持ちのサーバを引っさげて、「ここに最新のWordPressを乗っけてくれ」って言われることも多いです。他にはサーバは別の管理会社がいるとか、そういうバラエティに富んだ事情も当然汲み取る必要があります。
そうするとどうなるかっていうと、インフラがバラバラでログイン方法も与えられた権限も一案件ごとにバラバラなものだから、WordPressを作るという同じ案件のように見えて、デプロイのアプローチはまったく別になってしまいます。
運用制約の問題
基本的に受託では、納品が終わったらそれはお客様のものです。もちろん運用のご契約を別途いただくこともありますが、基本的にサーバやWordPressはお客様ご自身での運用となります。
なので、当たり前なんですが「お客様にご納得いただけないものは作れない」というものがあります。そもそも弊社のお客様もバラエティに富んでいて、システム管理者が社内にいらっしゃらない、ITとはまったく別業種で今回思い切って依頼をされた、というようなお客様も多いです。それは弊社としては本当にありがたいことです。
そのため「イケてるから」とエンジニアが考えて、AWSでKubernetesをいきなり「導入しましょう」などと言えないのですし、お客様のご予算を考えたコスパの感覚も必要になります（もちろん検討後、それが何であれ、もっとも良い選択であれば導入と説明を行います）。
そのため「運用はお客様が行う」という制約が暗黙的に発生します。これも加味するとデプロイの手法が異なってくる一因となり、「CIとか無理なんじゃないか」と途方に暮れることもしばしばです。
そもそもWordPressの問題
デプロイが面倒というか、コード管理を阻むWordPressのそもそもの機能があります。デプロイをするためには下記のようなWordPress特有の機能を乗り越える必要があります。
自動アップデートの原罪
WordPressには自らを自動でアップデートする機能がついており、バージョンアップがあった場合は（設定によりますけど）、勝手にアップデートを適用してくれます。安心の自己進化機能を搭載、脆弱性への対応を自身でやってくれるのは運用上とても助かります。
なので、弊社でもこの機能は基本ONにしてお客様にお渡しいたします。アップデートはとてもいいことですね。積極的に、半ば強制的に行われるべきものです。そこまでは完全に同意するんですけど。
が、ちょっと待ってくださいよ。
リポジトリとコードの差異はどうなるんですか？ 複数サーバで運用していた場合は？ アップデートっていつ行われるんですか？
ケースバイケースなので、何も考えず温泉などに行きたくなります。
余談ですけど、この前リリースされたバージョン4.9.3は、この自動アップデート機能を殺すという不退転のバグをはらんでいました。「寄る辺ない」とはこのことだと思いました。
寄る辺ない（よるべない）
身を寄せるあてがない。頼りにできる類縁の者がいない。孤独であり不安である。
プラグインやテーマのカルマ
WordPressは素晴らしいCMSだからして、便利なプラグインやカッコいいテーマ、言語の設定が管理画面上からできてしまいますし、それによってサーバ内のファイルが増減しますし、コード管理というものをガン無視いたします。
さすがに弊社の作成したテーマを切り替えて使用されているお客様は見たことないんですけど（それはさすがに泣きます）、数多存在するプラグインはどうしても入れたくなるはずです。WordPressを使用する理由の1/3くらいはこのプラグインの豊富さにあると言ってもいいでしょう。
前述のアップデートもそうなんですけど、こうなってくると、そのコードはサーバ上にしか存在しなくなってしまい、メンテ性が著しく下がり、デプロイ時はデグレなどのリスクが上がります。
uploadsの罪業
wp-content/uploads
ぶっちゃけこのディレクトリ、どうするのが正解ですか？
WordPressの管理画面上から画像などのメディアが保存されるディレクトリです。未だに迷いの中にいます。誰か教えてください。気をつけないと消えちゃうし、バックアップは取りにくいし、一番重くなるし、一番復旧難しいし、でも一番重要だったりして。
AWSでS3に置くというのがもっとも正解に近い気がしていました。どれだけ増えてもコストは安いし、そっちに直接見に行ってもらえばWordPress側には負担になりませんし。
そう、AWSが使えればね。
今の自分が出した3つの解答
それではいよいよ、弊社のよくあるデプロイ方法を述べたいと思います。この方法がめっちゃ楽だとか、めっちゃ解決したとかそういうことではないのですが、「これが問題の起きない方法じゃないか」と考えているパターンを3つをご紹介します。
1. AWSで複数サーバが使える
シンプルに言うとこういう構成で、サーバが複数台あった場合の考察です。弊社が受け持つWeb制作の案件の中では中〜大規模のサイトになります。
とはいえ、AWSを選択する時点で前述の問題点をだいたい乗り越えています。また、AWSの場合基本的にデプロイにはCodeDeployが利用できるので、実はデプロイの手順がバラバラになることはほぼありません。
弊社では下記のような手順でデプロイの実績があります。
- github + CircleCI + CodeDeploy
- Bitbucket Pipeline + CodeDeploy
特に特別なことはしていません。それぞれのサービスの使用方法は別途ご検索ください。後者については自分でも2017年12月、Qiitaに書きました。
2. VPSでSSHが使える
SCPなどでコードをアップする場合です。このパターンがもっとも多様性があり、デプロイとその運用に悩むことが多いです。自由に何でもできるので、案件によってデプロイは千差万別、エンジニアによっても何が正しいか意見が分かれ、属人化の温床になりえます。
DeployerやCapistranoでSSHができればなんとでもなる気がしますが、お客様に渡すことを考えるとあんまり依存をしたくないので、自分でシェルスクリプトを書いたり、案件ごとにやり方を検討しています。
注意点としては、uploadsディレクトリと、pluginsのディレクトリはデプロイで消さないように注意してください。デプロイツールを使うのであれば必ずsharedにする、rsyncを使うのであればexcludeに必ず指定する。絶対にテストをしてください。
3. なんかFTPしか使えない
2018年、このタイプも全然あるからね。
git-ftpを使いましょう。使いたい。使わせてください。感動的に便利なので、FTPをするのであれば、自分の中ではこれ一択です。今社内で広めている最中ですが、本音を言えばFTPを使いたいわけではない。難しい心情です。
この方法のもっともいいところは、一度作られたuploadsを削除しないところです。また.gitignoreに書いてあるファイルやディレクトリも無視します。そのため、もし弊社から運用が切り離されても、お客様だけでFTPを使えばそのまま運用を続けることができます。デプロイにFTP以外の別の要素が入り込みません。
前提を作る努力は不可欠
以上の3つのパターンは、ちゃんとコード管理ができるように死力を尽くすことが前提にあります。運用まで請け負うことを前提でWordPressの自動更新を切っておく、プラグインの導入についてはご連絡をいただく、などのお約束が大切になります。
しかし、その上でサーバ上に入っているものと、コード管理しているものが一致するかどうかも確認します。一致しなかった場合、残念ながらサーバ上のものを正として、動作確認後コミットしておきます。もう動いてしまっているので仕方ありません。
そういった改修をするうえでの約束事もちゃんと決め、社内に周知しておきましょう。担当が変わったときに地獄を見ますし、信頼が失墜する可能性があります。
まとめ
今回槍玉に挙げさせていただいたのがWordPressではあるのですけれど、WordPressが悪いというわけではありません。おそらくお客様のサイトや商材を代理で請け負わせていただき、お客様にその運用を引き渡すというとき、このような悩み事はすべてのCMSやフレームワーク、インフラで発生するはずです。
ちゃんと説明責任を果たすということはもとより、最初から適切な設計と選択ができるよう、努力を怠ってはいけないのだと考えます。
ただ、「WordPressは簡単だけど単純ではないので油断をするな」と自戒を込めて、今日もMVCではない世界でテンプレートを作ります。でもたぶん、もっと冴えた方法があるはずです。
もっと工夫して、もっと手順を簡便化して、もっと工数を削減したい。もっと楽したい。皆さんのご意見、お待ちしております。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
