Scribble at 2021-03-17 13:28:36 Last modified: unmodified

SAKURA インターネットで2015年から借りている「専用サーバ エクスプレスシリーズ」というプランのサーバが、昨年あたりから頻繁に落ちるようになった。ssh や会員サイトのコンソールでもアクセスできなくなるので、電源を強制停止したりするのだが、それでも復旧しないことがある。ただ、そうこうしてるうちにアクセスできるようになって、また暫く使えるという次第だ。それはそうと、そんな致命的な障害が何度も起きているのに、Zabbix のエージェントが何も検知していない。この Zabbix も、ちょっと信用できかねるソフトウェアだという気がしてきた。やはり一定の予算を組んで Mackerel に戻そうかしら。というわけで、今月の末に納品する予定の小さなウェブサイトでステージング環境を作ろうと思っていたら、サーバが停止してしまったため、クラウドにウェブ・サーバのインスタンスを建てたところである。自治体の安い案件だし、そもそもステージング環境を用意すること自体が弊社の持ち出しとなってしまっているため、クラウドの最小構成である1コア+1 GB RAM + 20 GB SSD という、月額にして2,000円にも満たないコストのサーバを建てた。日本の政令指定都市の予算なんて、もうこんな金額すら捻出できないところまで来ているらしい。

恐らくは広告代理店案件でも、今後はこの手の安い仕事をかき集めないとやっていけない。10年以上も前に「ウェブ業界はどこを向いているのか」という文書で、広告代理店案件と中小零細の「ホームページ」案件とで乖離してくると書いたのだが、実情は更に劣悪となっている。つまり広告代理店案件の予算規模ですら大きく零落していて、大手上場企業のキャンペーンですら四桁前半の予算を確保するのがやっとである。印刷会社やデザイン事務所や名刺屋が手慰みに営業していた「ホームページ屋さん」が殆ど死滅したのは、市場や業界の適正な品質の維持という名目では良かった。でも、それらの事業者が一時的にせよ引きずり下ろした実勢価格によって、今度はクラウド・ワーカーの受注価格が低いレベルでの過当競争となり、結局は広告代理店案件も影響を受けてどんどん予算規模が縮小している。これに加えて、今般の「コロナ禍」とやらで広告の出稿元であるトップ・クライアントの多くが打撃を受けて広告予算を縮小してしまった。そのため、二言目には「安く」が合言葉となって、いまや上場企業や大企業で立ち上げるウェブサイトの過半が WordPress のコピペである。

そういうわけで、こちらも手間などかけてはいられない。SAKURA のクラウドで安いインスタンスを使って WordPress のサイトを構築する機会が増えているため、手順を決めておくのがよい(もちろん、その目的は僕が何をするべきかということに尽きている)。

(1) まず、クラウドの管理画面でインスタンスを作成し起動する。ステージング・サーバなんて最小構成の「1コア+1 GB RAM + 20 GB SSD」でよい。ひどい場合は、今回の自治体案件のように、実際には納品するまでの半月しか使わないサーバもある。こんなものにスペックなど求めても意味はないし、現実に弊社の持ち出しなのだから尚更だ。なお、当然のことだが、この場合に弊社の持ち出しとして最もコストがかかっているのは、もちろん leading and distinguished developer であり弊社の部長である僕の工数だ。インスタンスでは、たいてい CentOS 7.9 を選んでいる。いまでは CentOS 8.x も選べるが、8になると PHP が httpd と別プロセスになるため、取り回しが面倒臭い。あと、WordPress のサイトであればプライム・ストラテジーの KUSANAGI でもいいのだが、あれはあれで特別なコマンドを覚えないと運用できないため、既に仕事で100を越える WordPress サイトを実装している人間にとっては、これも面倒臭いものでしかない。

(2) インタンスが起動したら、root で ssh のアクセスは可能になっているため、ターミナル・エミュレータ(Teraterm Pro が多い)でアクセスする。もちろん、クラウドの管理画面で IPv4 のアドレスは確認しておく。最初にやることは yum のアップデートとか yum-cron をサービスとして走らせることだろう。他にも、SAKURA のクラウドのインスタンスは firewall-cmd が ssh など必要最低限のポートしか通さないように設定されているため、http, https, ftp は開ける必要がある(ftp は WordPress やプラグインの更新に必要)。POP3/SMTP は、たいていの案件では使っていない。メールの送信を実装する場合、プロダクション・サーバの仕様によって文字化けが起きやすいため、これはクライアントの公開サーバにテスト領域を作って動かしたり、クライアントが用意しているテスト・サーバに実装して動かすことが多いからだ。

(3) 必要なサービスやソフトウェアをインストールする。httpd, php74, php-mbstring, php-mysqli, php-xml, mod_ssl, mariadb-server, certbot, vsftpd くらいが必要になる筈である。

(4) それぞれのソフトウェアを設定する。

(5) phpMyAdmin を暫定ディレクトリに入れて WP 用のデータベースとユーザを作る。いままで adminer という軽いツールを使っていたのだが、これはユーザの権限を設定すると必ずエラーを起こすという問題が全く解消されないので、たぶん仕様バグというよりも僕の使い方に合っていない実装なのだと思う。アップロードに時間はかかるが、phpMyAdmin を使うほうが手堅い。ただし、phpMyAdmin は世界中のボットがアクセスしてきて狙ってくるため、/phpmyadmin なんて名前のディレクトリを作成してインストールするのは絶対に止めた方がいいし、使い終わったら消すなり # chmod -R 0700 /dirname するなり # chown -R root /dirname して、apache 権限ではアクセス不能にするのが賢明だろう。

(6) 最後に WordPress 本体を入れて設定する。現在は wp-config.php を DocumentRoot の上位階層に置くのが定石となっている。また、ベーシック認証や IP 指定によるアクセス制限もかけておき、Let's Encrypt で HTTPS の通信を提供する。僕の運用では、http -> https への強制リダイレクトをかけると certbot の自動更新が失敗してしまうため、3ヶ月以内の短期的な運用ならリダイレクトをかけてもいいが、長期の運用ならリダイレクトはしない。もちろん、/.well-known にだけ強制リダイレクトの例外を設定することも可能だが、そもそもステージング・サーバに HTTPS まで必要なのかという議論もあるため、これは単純にセキュリティだけの話ではないだろう。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook