VPS でマルチサイトを運用する機会があり、いくつか勉強になったことがあったので記事にします。

またこの記事では、マルチサイトをルートドメインとサブドメインを利用した複数サイトを指していることと、サーバーの設定は最小限の設定ですので本番運用される際は十分にご注意ください。

VPS でマルチサイトを運用する仕組み

この記事で触れること、実装して何ができるかについて説明します。www.example.com または example.com のルートドメインと vhost.example.com のようなサブドメインのディレクトリを用意し、nginx のバーチャルホストを利用してアクセス先を分割します。そして、バーチャルホストに SSL と a-blog cms を動作させるための設定を行い、サブドメインは SFTP のみでアクセスできるようにします。この実装を行うことでルートドメインで運用を行い、サブドメインでは特定のエンドユーザーにサイトを与え、複数のサイト運用ができます。

ディレクトリの構成

ルートドメイン

/var/www/html/ にします。

サブドメイン

/var/www/vhost/ にします。エンドユーザーには触って欲しくないファイルがある場合は、サブドメインのディレクトリ直下に2つ用意し、1つブラウザに表示するためのアプリケーションを設置し、その中からユーザーが触っていいファイルだけもう一つのディレクトリに抜き出して、ブラウザ表示用にシンボリックリンクを貼ります。これにより SFTP での制限を設け、エンドユーザーはファイルを操作することができるようにしていきます。

nginx の Webサーバー設定

まずはサンプルコードをご確認ください。ルートドメインの設定です。

# -------------------------
# サーバー設定
# -------------------------

# www つきにリダイレクト
server {
    listen 80;
    listen 443 ssl;
    server_name example.com;

    location / {
         return 301 https://www.example.com$request_uri;
    }
}

# SSL にリダイレクト
server {
    listen 80;
    server_name www.example.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

# SSL の表示用サーバー設定
server {
    listen 443 ssl;
    server_name www.example.com;

    # SSL / LTS
    ssl_certificate /etc/nginx/ssl/crt/example.crt; // 公開鍵にコモンネームなどの情報をつけたもの
    ssl_certificate_key /etc/nginx/ssl/key/example.key; // 秘密鍵

    # ドキュメントルート
    root /var/www/html;
    index index.php;

    include snippets/example.conf; // a-blog cms のサーバー設定

www付きへリダイレクトしていることが server_name と location から分かります。また、SSLとドキュメントルートが先ほど用意したパスへ繋がるように設定しています。

そしてもう一つ、サブドメインの設定も必要です。server_name を vhost.example.com​ のようにサブドメインに置き換えるだけで大丈夫です。SSL については、サブドメインも含め1つの証明書で暗号化できる Xserver ワイルドカードSSL を使用しています。ですので ssl_certificate​ と ssl_certificate_key​ は、ルートドメインと共通で使用できます。ドキュメントルートもサブドメイン用のディレクトリパスに変えてください。

nginx で動かす a-blog cms

a-blog cms を動作させるためのサーバー設定も必要です。a-blog cms 同梱の .htaccess​ は Apache で動作させるためのファイルですので nginx では使えません。ルートドメインもサブドメインも a-blog cms ですので、共通のファイルで管理をして Webサーバー設定の include で以下の設定を読み込みます。

# -------------------------
# これは、a-blog cms を動作させるための設定です。Apache の .htaccess に当たります。
# -------------------------

# 隠しファイルへのアクセス禁止
location ~ /\. {
        deny all;
}

# アセットのキャッシュ・セキュリティ設定
location ~* \.(css|js)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000";
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header Strict-Transport-Security "max-age=31536000";
        add_header Referrer-Policy "strict-origin-when-cross-origin";
        gzip on;
        gzip_types text/css application/javascript;
        gzip_vary on;
}

# 画像およびメディアファイルのキャッシュ設定
location ~* \.(gif|jpeg|jpg|png|flv|mp4|ico|svg|webp)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000";
        add_header ETag "";
}

# FastCGI 設定
location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;  # PHPのバージョンに応じて変更
}

# 画像のWebP対応
location ~* ^(.+)\.(jpe?g|png)$ {
        set $base $1;
        set $ext $2;
        if ($http_accept ~* "image/webp") {
            set $webp_suffix ".webp";
        }
        if ($arg_type = "original") {
            set $webp_suffix "";
        }
        try_files $base$webp_suffix /path/to/your/webp/images$uri =404;
        add_header Vary Accept;

        location ~* ^(.+)\.webp$ {
            expires 365d;
            add_header Cache-Control "public, max-age=31536000";
            add_header Content-Type image/webp;
        }
}

# ルートディレクトリの処理設定
location / {
try_files $uri $uri/ /index.php$is_args$args;
}

# URL書き換え設定
rewrite ^/(.*)/index\.html/?$ https://$host/$1/ permanent;

SSH / SFTP

ここでは、サブドメインをエンドユーザーが触ることを想定して設定していきます。

前提として、サブドメインのサイトにはユーザーID とパスワードの発行が必要です。このユーザーID とパスワードでディレクトリ権限を与えます。ただ、これだと ssh でアクセスされセキュリティに問題があるので、SFTP でのアクセスのみ許可するようにします。

そのために SFTPサーバーの internal-sftp を使用します。internal-sftp は、外部プログラムに依存せずに、SSHデーモンの一部として動作する内部サブシステムです。internal-sftp を使うにあたって注意点があり、ChrootDirectory で指定しているディレクトリとその親達は root権限にしておく必要があります。そして、アクセスするユーザーに root権限のディレクトリの書き込み権限は与えないようにします。権限を与えていいのは、ChrootDirectory の中の ファイル / ディレクトリ のみです。もし間違っていると、セキュリティ上の理由でアクセス拒否されてしまいます。

以下が sftp の設定です。ChrootDirectory は sftp のアクセス先を設定してください。

Subsystem sftp internal-sftp
Match User !exampleUser1,!exampleUser2
ChrootDirectory /var/www/vhost/sftp
ForceCommand internal-sftp

以上が、ルートドメインで運用を行い、サブドメインでは特定のエンドユーザーにサイトを与え、複数のサイト運用をする仕組みです。

実装をしてみて

実装していてよく権限で困った印象があります。SFTP の ChrootDirectory だったり、a-blog cms の一部が動作しなかったことがありました。サーバー自体この時ほぼ初めて触ったこともあり、いい経験になりました。

2024年4月の名古屋から始まり、5月大阪、6月福岡と東京で「htmx初心者向け勉強会」というイベントを開催してきました。 前半は CMS を絡めず静的な HTML ベースで純粋に htmx で何ができるのかをご紹介し、後半はバックエンド側を a-blog cms にお任せすると、こんな実装になるということをお伝えしてきました。

• 名古屋・大阪で利用した勉強会ドキュメント
• 福岡・東京で利用したハンズオンサイト
• リアルイベントのレポート
  • 名古屋 / 2024年4月23日 16人
  • 大阪 / 2024年5月22日 9人
  • 福岡 / 2024年6月14日 13人
  • 東京 / 2024年6月20日 9人

名古屋・大阪で利用した勉強会ドキュメント

当初は、htmx の属性について1枚の HTML にまとめて、そのファイル自身を修正して自身のサーバーにアップして動きを見てもらうというカタチで開催していました。

• htmx入門
• a-blog cms & htmx 入門

しかし、このカタチだと、話を聞いてもらうだけで実際に手を動かして検証してもらうことが、あまりできてなかったと感じ、後半の地域では 以下のようにアップデート をしています。

福岡・東京で利用したハンズオンサイト

htmx@blog テーマという htmx を使ったブログテーマの上で、CMS にログインする事で簡単に htmx のコードを書き換えて試すことができるようにしました。また、全員が同じサイトではなく a-blog cms のお試しサーバーを利用し、テーマを勉強会用のものを選択すると、個々のサイトがサブドメインで作られるようにしてハンズオンをしっかりできるようにしました。

上記のキャプチャのリンク先は、ログインできないサンプルとしてリンクしておきます。（日数が経つと消えてしまうので、無くなっていたら以下のリンクからハンズオンサイトを作ってご覧ください）

ablogcms.io というお試し専用のサービスサイトは 30日で削除されますので、お気軽にお試しください！

• 勉強会 ハンズオンサイト
• htmx@site（htmx化されたコーポレートサイトのサンプル）
• htmx@blog（htmx化されたブログサイトのサンプル）

リアルイベントのレポート

名古屋 / 2024年4月23日 16人

名古屋での勉強会では、参加者全員が a-blog cms のユーザーの方ばかりでした。そのため、前半のセッションでは、htmx の基本概念や静的な HTML でのデモを通じて、初めての方にも理解しやすい内容を心がけました。後半では、a-blog cms と htmx の連携に重点を置き、実際のプロジェクトでの活用方法を具体的に解説しました。

参加された中でも IDEASOURCE の新さんは、翌日に自社のサイトのコンテンツの一部を htmx 化し、ブログの記事を公開いただきました。 a-blog cmsとhtmx（jsライブラリ）は非常に相性が良い

大阪 / 2024年5月22日 9人

大阪での勉強会では、名古屋でのフィードバックを反映し、より具体的な実装例を交えながら進めました。参加者の皆さんからは、「実際に手を動かすことで、より理解が深まった」との声を多くいただきました。

大阪での定期勉強会のための会場を探しています！ オススメな会場があればお知らせください。

福岡 2024年6月14日 13人

福岡での勉強会では、ハンズオンのやり方を変更し、より実践的で分かりやすい内容に改訂しました。参加者の半分は a-blog cms を知らない方々でしたので、htmx に加え a-blog cms についても詳しく説明する機会となりました。これにより、参加者には htmx と a-blog cms の両方の魅力を感じていただけたと思います。

会場には、さくらインターネット 福岡オフィス をお借りしました。 htmx 化した さくらインターネット版「10万件のサンプルサイト 」

東京 / 2024年6月20日 9人

東京では、午後から仕事時間中に参加が可能な人が参加できるイベントと、仕事が終わってから参加しやすい夜の2部構成で行いました。

htmx のために Ajax 関連の機能についてアップデートがされた a-blog cms 3.1.17 と htmx 2.0 にメジャーバージョンアップされた新しいハンズオンサイトも準備しての開催となりました。具体的な事例としては FAQ コンテンツを htmx を活用して実装するには、どう作るべきかなど、実際のプロジェクトでの活用方法についても触れ、多くの参加者にとって有意義な時間となりました。

最後に

まだ使い始めて4ヶ月くらいで、利用している機能は紹介しているものくらいなので、まだまだ知らない機能も多くあるのではと思っています。持っている情報はできるだけ共有させていただきました。

また、他の地域での勉強会やオンラインイベントも企画を進めておりますので、こんな使い方もオススメだという情報をお持ちの方がいたら、ぜひご参加いただき教えていただけると助かります。

Cloudflare とは？

より良いインターネットの構築をミッションとして作られたもので、ネットワーク / クラウド / アプリケーションをより安全でパフォーマンスが高くあらゆる接続を実現する統合プラットフォームです。これは コネクティビティクラウド と呼ばれていて Cloudflare でも言及されています。そのコネクティビティクラウドを Cloudflare ではどう実現するかについて、「マルチクラウド環境およびハイブリッドクラウド環境を含む、あらゆるタイプのクラウドインフラストラクチャのための一元化されたコントロールプレーンとしての役割を果たす」と表現しています。大雑把にいうと、「クラウドで必要なセキュリティを一元管理できる」ということだと思います。

では、クラウドで必要なセキュリティとはなんでしょうか？
Cloudflare はプランによってできることが増えるのですが、今回はフリープランを元に話を進めていきますので、フリープランで使えるWebサイトのセキュリティに関わる機能をまとめてみました。

• DNS
• 従量制の DDoS 保護
• CDN
• ユニバーサルSSL証明書
• 無料のマネージド ルールセット
• ウェブ アプリケーション ファイアウォール (WAF)
• 3 ページルール

※ これは 2024/4 時点です。詳しい内容はこちらです。

一番のメリットは CDN が使えてパフォーマンスの向上につながることだと思います。また CDN を導入することで、Webサーバーの負荷を軽減できたり、重複トラフィックの削減が見込めます。加えて SSL が利用できるので、SSL のないサーバーを利用しているサービスにもおすすめです。

Cloudflare の導入

導入にあってですが、ドメイン / DNS / Webサーバーが必要です。今回は、ドメインをお名前.com、DNS を Cloudflare、Webサーバーを Xserver でテストしています。Cloudflare にもドメインの発行とサーバーレスが使えるのですが、運用中の Webサーバーに導入というタイトルですので利用していません。サーバーレス機能の Workers は Webサーバーとしては使用しませんが、キャッシュ機能を実現するために後でご紹介します。また、Webアプリケーションは弊社開発の a-blog cms を使用してテストしています。本記事は a-blog cms とは関係ない内容ですが、a-blog cms を使用する場合に a-blog cms で設定が必要な箇所が出てきますので、掻い摘んで説明していきます。

add site から サイトの登録を行います。ステップは ドメイン設定 → プラン → DNS設定 → アクティベーション があり、基本的には add site の流れに沿っていただければ大丈夫です。一つだけ注意点があり、アクティベーションの際にDNS が割り当てられます。この DNS は取得したドメインに割り当ててください。お名前.com を使用している場合は、お名前.com 管理画面からドメインを選択し、ネームサーバー情報から DNS の変更ができます。また、アクティベーションには最大24時間かかる可能性があるのでご注意ください。

Cloudflare の導入だけであればこれで完了です。ただ、これだけだと Cloudflare を通っているだけで、オリジンサーバーに接続していてメリットがありません。SSL の設定がうまくいっておらず、表示すらできなくなっているかもしれません。次からのセクションで Cloudflare が動作するように設定していきます。

Cloudflare SSL/TLS

まずは SSL の設定が必要です。Cloudflare では無料で SSL を提供おり、SSL/TLS から設定できます。4つのモードがあり、以下の設定ができます。

ここで一つ注意点があり、http に アクセスすると https にリダイレクトするという処理が Webサーバーで行われている場合、end-to-end でSSL化する必要があります。end-to-end というのは、ブラウザと Cloudflare の間と、Cloudflare と Webサーバーの間を指します。もし、Cloudflare から Webサーバー へ http で通信しようとするとリダイレクトループが発生します。なので、cloudflare から Webサーバーの間は、SSLの設定をしておかなければなりません。既に Webサーバーで SSL化されている場合は、リダイレクト処理がされてある可能性があるのでご注意ください。

a-blog cms でも、htaccess（Apache Webサーバーの設定ファイル） で SSL アクセスについての記述がありますので、Cloudflare からアクセスするときは SSL でないとリダイレクトされてしまいです。

CDN のキャッシュ

次にキャッシュについてです。運用をしていると、全てをキャッシュするのではなく特定の場合にはキャッシュさせたくない状況も出てきます。例えば、CMS の運用でユーザーがログインし記事を更新する際にキャッシュが効いていると、更新したのに以前の情報が表示されてリアルタイムな情報でなくなってしまうので、キャッシュサーバーではなくオリジンサーバーにアクセスさせる必要がある場合です。

特定のURLパターンで判別する場合は Cache Rules を使って GUI で設定することができます。管理ページであれば URL が閲覧ページとは別のものになると思いますので Cache Rules が使えます。しかし、Cookie や Request Header のみで判断する場合、Cache Rules で設定しきれない時もあります​。そういった時は、Workers を利用することで解決できます。Workers は、Javascript または WebAssembly を使用して、リクエストに対してプログラム的な操作を行うことができます。よって、Cookieやヘッダー・リクエストの種類など、リクエストの詳細に基づいて複雑なキャッシュの決定や制御を行うことができるようになります。

Workers で Cookie を利用したキャッシュ動作の判別を行う

Workers & Pages > Create application > Create worker で Workers が作成できます。作成画面では、既に Hello, World! の文字列をレスポンスで返す処理がされているのですが、そのままデプロイしていただいて大丈夫です。そうすると以下の画面が表示されるので、Edit code からキャッシュの処理をしていきます。

Edit code の画面では、先ほど作成した Workers の処理（Hello, World! の文字列をレスポンスで返す）が書かれています。このコードを Cookie によってキャッシュの処理を切り替えるコードに置き換えます。

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const cookie = request.headers.get('Cookie')
  if (cookie && cookie.includes('acms-logging-in=administrator')) {
    // ログインしている場合はキャッシュをバイパス
    return fetch(request)
  } else {
    // ログインしていない場合はキャッシュされたコンテンツを利用
    return fetch(request, { cf: { cacheTtl: 7200 } })
  }
}

上記のコードは HTTPリクエストから処理を行うためのサンプルコードで、Cookie に personal-blog-logging-in=administrator があるかどうかによってキャッシュの利用を決めています。ご利用される場合は、ご自身の環境によって Cookie のキー、値を変えるようにしてください。

a-blog cms の場合、 v3.1 から/private/system.default.yaml に extra_logged_in_cookie: on を追記すると、ログイン時に Cookie を残せるようになっています。さらに、extra_logged_in_cookie_name: "personal-blog-logging-in" のように追記をすると Cookie に登録するキーを変更することができます。この設定でできた Cookie を条件にして キャッシュにすると、ログイン時だけオリジンサーバーにアクセスするようになります。

Workers の作成ができたら、どの URL で利用するか指定しなければなりません。Websites > 利用しているサイト > Workers Routes > Add route から URL と Workers の指定ができます。

これで設定が完了しました。最後にきちんとキャッシュが動作しているかを確認してみます。

Cloudflare の動作を確認

ブラウザからレスポンスヘッダーを確認してみてください。そこに Cf-Cache-Status があると思います。以下の画像は Google Chrome の検証ネットワークタブから確認しています。このステータスがあると Cloudflare を通して実行されています。ここの値が HIT​ だとキャッシュが返ってきており、BYPA SS または DYNAMIC​ だとオリジンサーバーにアクセスされています。BYPASS は意図的（ヘッダーなどによるキャッシュルール）によるキャッシュ無視を示し、DYNAMIC は動的コンテンツを示します。

Cloudflare Zaraz に少し触れてみる

Cloudflare には Zaraz というサービスもあり、サードパーティツールが管理できます。今回試したのは Google Analytics 4（以下、GA4） の連携です。Zaraz を使用すると、Tag Manager や Analytics へブラウザからアクセスし計測するのではなく、Cloudflare が GA4 と連携してくれるのでパフォーマンスの向上に繋がります。また、クライアントのIPアドレスをGoogle側に送信しない設定ができるので、高いプライバシーを実現することができます。しかし、Webサイトにスクリプトを読み込まずに GA4 がデータを収集できる反面、　Webサイトの読み込みが必要な計測ができなくなる可能性があります。状況に合わせて利用していただければと思います。
詳しくは、CloudflareでGoogle Analyticsを使用する をご確認ください。

スマートフォンで写真をタップすると、もともと表示されているサイズより小さく表示されるような体験をしたことはありませんか？ 2017年にリリースした SmartPhoto.js は、スマートフォンで写真を大きく見たいを実現するために用意したライブラリーです。

弊社の Github 公開しているライブラリの中では、一番 ★ の多いライブラリーで、2024年5月6日現在で 894 となっています。よろしければ https://github.com/appleple/SmartPhoto の右上にある ★ のクリックをお願いします。