Debian 12で緊急Web環境を素早く構築する――Apache・PHP・PostgreSQLを標準パッケージで揃える

大規模障害などで、既存のWebサービスを別サーバーへ緊急退避しなければならないことがあります。

このような場面では、普段と同じ環境を完全再現することよりも、OS標準パッケージを使って短時間で安定した環境を構築する方が有利な場合があります。

１、Debian 12では標準パッケージを優先する

Debian 12（Bookworm）では、Apache、PHP、PostgreSQLをaptでまとめて導入できます。以前はPHPをソースからビルドし、mbstring、OpenSSL、iconv、PostgreSQL、curlなどをconfigureで個別指定していましたが、緊急環境ではパッケージ版の方が再現性と保守性に優れます。

sudo apt update
sudo apt install -y 
  apache2 
  libapache2-mod-php8.2 
  php8.2-cli 
  php8.2-common 
  php8.2-mbstring 
  php8.2-curl 
  php8.2-pgsql 
  postgresql 
  postgresql-client 
  libpq-dev

PHPからPostgreSQLを利用するだけならphp8.2-pgsqlで足りますが、C/C++のプログラムからlibpqを利用してビルドする場合はlibpq-devも必要です。

#include <libpq-fe.h>

libpq-fe.hは通常、次の場所へインストールされます。

/usr/include/postgresql/libpq-fe.h

２、PostgreSQLのpeer認証に注意する

PostgreSQLでロールを作成し、パスワードも設定したのに、ローカルから接続すると「peer認証に失敗しました」と表示されることがあります。

psql -U appusr -l
FATAL:  ユーザー"appusr"で対向(peer)認証に失敗しました

これはパスワードが間違っているのではなく、Unixソケット接続に対してpeer認証が使われているためです。peer認証ではOSのログインユーザー名とPostgreSQLのロール名を照合します。

アプリケーション用ロールをパスワード認証で使う場合は、TCP接続にすると切り分けが容易です。

psql -h 127.0.0.1 -U appusr -l

ローカルソケットでもパスワード認証させる場合は、pg_hba.confを用途に合わせて設定します。postgresロールだけpeerのまま残し、一般ロールはscram-sha-256にする構成も分かりやすいです。

local   all   postgres                 peer
local   all   all                      scram-sha-256
host    all   all   127.0.0.1/32       scram-sha-256
host    all   all   ::1/128            scram-sha-256

変更後はPostgreSQLをreloadします。

sudo systemctl reload postgresql

３、ApacheはVirtualHostでサービスを完全分離する

1台のApacheに複数のWebサービスを緊急収容する場合でも、ファイルを同じディレクトリへ混在させる必要はありません。名前ベースVirtualHostを使い、サービス単位でディレクトリを分けます。

/www/
├── service-a/
│   ├── public/
│   ├── objs/
│   ├── logs/
│   ├── tmp/
│   └── conf/
└── service-b/
    ├── public/
    ├── objs/
    ├── logs/
    ├── tmp/
    └── conf/

DocumentRootはpublicだけに向けます。設定ファイルや内部オブジェクト、ログをWeb公開領域の外へ置けるため、緊急構築でも公開範囲を整理しやすくなります。

<VirtualHost *:80>
    ServerName app.example.com
    DocumentRoot /www/service-a/public

    <Directory /www/service-a/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

設定後は必ず構文とVirtualHostの割り当てを確認します。

sudo apache2ctl configtest
sudo apache2ctl -S
sudo systemctl reload apache2

４、phpinfo()は確認後に削除する

PHPの動作確認ではphpinfo()が便利ですが、モジュール、パス、環境変数など多くの情報を表示します。公開環境へ置いたままにしないよう注意します。

<?php
phpinfo();

確認後は削除します。

rm env.php

５、緊急環境ほど標準構成を選ぶ

緊急時には、過去のサーバーを寸分違わず再現したくなります。しかし、独自ビルドを多数抱えるほど、再構築時の手順と依存関係は増えます。

OS標準パッケージで動かせる部分は標準へ寄せ、アプリケーション固有の部分だけを移植する方が、復旧速度だけでなく、その後のセキュリティアップデートや保守も行いやすくなります。