さくらのクラウドの導入・移行・24時間運用をプロが解説するテックメディア

無料相談・お問い合わせ

さくらのクラウドでCaddyを使ってWebサーバを構築してみた

さくらのクラウド # Caddy # さくらのクラウド

こんにちは、Tomです。今回は、Caddyを使って、さくらのクラウド上に簡単Webサーバを構築してみます。

Caddyとは

Webサーバーといえば、Apache HTTP ServerやNginxを思い浮かべる方が多いのではないでしょうか。

今回は、それらとは別のWebサーバーである「Caddy」を、さくらのクラウド上のサーバーに導入してみます。

Caddyの特徴のひとつが「Automatic HTTPS」です。

公開ドメインをCaddyfileに設定すると、条件を満たしていればTLS証明書の取得・更新やHTTPからHTTPSへのリダイレクトをCaddyが自動的に行います。

今回は、

  • さくらのクラウドでAlmaLinux 10のサーバーを用意
  • Caddyをインストール
  • 静的HTMLを公開
  • caddy.tnagai-wp.click を設定
  • HTTPSでアクセス
  • TLS証明書が自動的に取得されることを確認

という流れで、Caddyを試してみます。

検証環境

今回の検証環境は以下の通りです。

項目内容
クラウドさくらのクラウド
OSAlmaLinux 10
WebサーバーCaddy
ドメインcaddy.tnagai-wp.click
コンテンツ配置先/var/www/html

AlmaLinux 10はRHEL 10との互換性を維持するディストリビューションとしてリリースされています。

HTTPS化するための事前準備

今回はCaddyのAutomatic HTTPSを利用するため、あらかじめ

caddy.tnagai-wp.click
    ↓
サーバのIPアドレス

となるようにDNSのAレコードを設定しておきます。

また、Caddyが公開TLS証明書を自動取得するためには、ドメインのA/AAAAレコードがサーバーを向いていることに加え、外部からTCP 80番・443番ポートへ接続できる必要があります。

さくらのクラウドの「パケットフィルタ」を使用している場合は、HTTP用のTCP/80とHTTPS用のTCP/443へのアクセスを許可しておきます。

Caddyをインストール

それではCaddyをインストールします。

まずOSを確認します。

# cat /etc/almalinux-release

実際の出力例は検証時の結果を掲載します。

AlmaLinux release 10.2 (Lavender Lion)

Caddy公式ドキュメントでは、CentOS/RHEL向けのRPMパッケージのインストール方法としてCOPRリポジトリを利用する方法が案内されています。

今回はこの方法でインストールします。

以下はパッケージ追加を伴う作業コマンドです。

# dnf install -y dnf-plugins-core

今回は既にインストールされていました。では、CaddyのCOPRリポジトリを有効化します。

# dnf copr enable @caddy/caddy
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.

The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.

Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.

Do you really want to enable copr.fedorainfracloud.org/@caddy/caddy? [y/N]: y
Repository successfully enabled.

続いてCaddyをインストールします。

# dnf install -y caddy

インストールできたことを確認します。

# rpm -q caddy
caddy-2.11.4-2.el10.x86_64

Caddy自身のバージョンも確認してみます。

# caddy version
v2.11.4 h1:XKxkMTgNSizEvKG6QHue6cAsFOteU2qA61w2tKkCWi0=

4. Caddyを起動して確認

systemd用のUnitファイルが作られているので、立ち上げましょう。

# systemctl enable caddy
# systemctl start caddy

状態を確認します。

# systemctl status caddy

以下のように、

Active: active (running)

となっていれば起動しています。

ポートの待ち受けを確認

次に、Caddyが使用しているポートを確認します。

# ss -lntp | grep -E ':(80|443)\b'
LISTEN 0      4096               *:80              *:*    users:(("caddy",pid=37274,fd=6))

インストール直後の公式RPMのCaddyfileでは、

:80 {
    root * /usr/share/caddy
    file_server
}

という設定になっており、まずHTTPの80番ポートで待ち受ける構成になっています。

ブラウザから

http://＜サーバーのグローバルIPアドレス＞

へアクセスして、Caddyの初期ページを確認してみるのもよいでしょう。

5. 公開するHTMLを用意する

今回はCaddyの動作確認が目的なので、簡単な静的HTMLを公開します。

公開ディレクトリを作成します。

# mkdir -p /var/www/html

テスト用のHTMLを作成します。

tee /var/www/html/index.html > /dev/null <<'EOF'
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Caddy Test</title>
</head>
<body>
    <h1>Hello Caddy!</h1>
    <p>さくらのクラウド上のCaddyから配信しています。</p>
</body>
</html>
EOF

Caddy公式ドキュメントでも、静的コンテンツの配置場所として /var/www/html または /srv が案内されています。Caddyユーザーから読み取り可能な権限になっている必要があります。

6. Caddyfileを設定する

いよいよCaddyの設定を変更します。

Caddyの設定ファイルは、

/etc/caddy/Caddyfile

です。

まず既存のCaddyfileをバックアップしておきます。

# cp -a /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak

Caddyfileを編集します。

# vi /etc/caddy/Caddyfile

今回は以下の設定にします。

caddy.tnagai-wp.click {
    root * /var/www/html
    file_server
}

非常にシンプルです。

caddy.tnagai-wp.click へのアクセスに対して、

root * /var/www/html

でドキュメントルートを /var/www/html に指定し、

file_server

で静的ファイルの配信を有効にしています。

注目したいのは、HTTPSに関する設定を記述していないことです。

例えば、

証明書ファイルのパス
秘密鍵ファイルのパス
TLSの設定
HTTP→HTTPSリダイレクト

などは今回記述していません。

公開ドメインをCaddyfileに指定し、DNSやポートなどの条件を満たしていれば、CaddyのAutomatic HTTPSによってHTTPSが自動的に有効になります。

Caddyfileをチェックする

設定を反映する前にCaddyfileに問題がないか確認します。

# caddy validate --config /etc/caddy/Caddyfile

問題がなければ設定をリロードします。

# systemctl reload caddy

Caddy公式ドキュメントでも、設定変更時にはサービスを停止・再起動するのではなく、reloadを利用する方法が案内されています。

再度ポートを確認します。

# ss -lntp | grep -E ':(80|443)\b'
LISTEN 0      4096               *:80              *:*    users:(("caddy",pid=37274,fd=11))
LISTEN 0      4096               *:443             *:*    users:(("caddy",pid=37274,fd=9))

HTTPS用の443番ポートでも待ち受けていることを確認します。

7. HTTPSでアクセスしてみる

ブラウザから以下へアクセスします。

https://caddy.tnagai-wp.click

ssl証明書のエラーもなく、無事に表示されています。

curlでも確認

HTTPSでレスポンスを返せることを確認します。

# curl -I https://caddy.tnagai-wp.click

HTTP側も確認します。

# curl -I http://caddy.tnagai-wp.click

CaddyではAutomatic HTTPSがデフォルトで有効な為、Let's EncryptのSSL証明書が自動的に発行され、HTTPからHTTPSへのリダイレクトも自動的に設定されます。

かなりシンプルですし、SSL証明書周りを設定する必要がないのは凄いです。

8. TLS証明書を確認する

本当に証明書が取得されているのか確認してみます。

OpenSSLを使用して、実際に配信されている証明書の情報を確認します。

# echo | openssl s_client -connect caddy.tnagai-wp.click:443 -servername caddy.tnagai-wp.click 2>/dev/null | openssl x509 -noout -subject -issuer -dates

ここでは、

  • Subject
  • Issuer
  • 有効期間

などを確認できます。

Caddyは公開DNS名に対して、Let's EncryptやZeroSSLなどの公開ACME CAを利用して証明書を取得できます。また、Caddyが管理している証明書は自動更新の対象になります。

そのため、従来のように別途Certbotなどの証明書管理ツールを組み合わせなくても、Caddy自身でHTTPSを管理できます。

9. Caddyのログを確認する

続いてログも確認してみます。

公式systemdサービスを使用している場合、Caddyの標準出力・標準エラー出力はjournalに記録されます。

直近100行を確認します。

# journalctl -u caddy --no-pager -n 100

証明書取得時には、TLSやACMEに関係するログも確認できます。

# journalctl -u caddy --no-pager -n 100 | grep -Ei 'certificate|tls|acme' | head -100

HTTPS化に失敗した場合も、まずCaddyのログを確認すると原因を追いやすそうです。

例えば、

  • DNSがまだサーバーを向いていない
  • 80番または443番ポートへ外部から接続できない
  • 証明書の取得処理でエラーになっている

といった場合には、ログを確認して切り分けます。

ちなみに今回も検証の際、パケットフィルタにおける戻りパケットの許可設定を追加し忘れて、Let's EncryptのSSL証明書発行に失敗しました。

Caddyのデータ保存先

systemdサービスとして実行した場合、CaddyユーザーのHOMEは /var/lib/caddy となり、証明書などの状態情報はデフォルトでは、

/var/lib/caddy/.local/share/caddy

配下に保存されます。

ファイルを確認する場合は、秘密鍵の内容自体は表示せず、ファイル一覧程度にとどめます。

# find /var/lib/caddy/.local/share/caddy -maxdepth 5 -type f | head -100

10. まとめ

今回は、さくらのクラウド上のAlmaLinux 10にCaddyをインストールして、静的なWebサイトをHTTPSで公開してみました。

実際に設定したCaddyfileは、

caddy.tnagai-wp.click {
    root * /var/www/html
    file_server
}

と非常にシンプルです。

Caddyを使って特に印象的なのは、HTTPSを利用するための設定が少ないことでした。

ApacheやNginxでもLet's Encryptなどを利用してHTTPS化できますが、Webサーバーとは別に証明書の取得・更新方法を設計する構成も多くあります。

一方、CaddyではAutomatic HTTPSがWebサーバー自体の機能として組み込まれており、

ドメインを設定
    ↓
Caddyを起動・リロード
    ↓
TLS証明書を自動取得
    ↓
HTTPSで公開
    ↓
証明書も自動更新

という流れでHTTPSサイトを構築できます。

今回は静的HTMLを公開しただけですが、Caddyにはリバースプロキシ機能もあります。

そのため次回は、

caddy.tnagai-wp.click {
    reverse_proxy localhost:8080
}

のような構成で、Caddyをリバースプロキシとして利用してみるのも面白そうです。

小規模なWebサイトだけでなく、Webアプリケーションのフロントに配置するWebサーバー・リバースプロキシの選択肢としても、Caddyは検討してみる価値がありそうです。

参考資料

  • Caddy Documentation - Install
    Caddy公式のインストール手順。CentOS/RHEL向けのCOPRを利用したインストール方法を確認。
  • Caddy Documentation - Automatic HTTPS
    TLS証明書の自動取得・更新、HTTPからHTTPSへのリダイレクト、必要なDNS・ポート条件を確認。
  • Caddy Documentation - Keep Caddy Running
    systemdでの実行方法、ログ、証明書などのデータ保存先を確認。
  • AlmaLinux OS 10.0 Stable Now Available
    2025年5月27日公開。AlmaLinux 10とRHEL 10の互換性について確認。
  • さくらのクラウド マニュアル - パケットフィルタ
    2025年12月9日更新。さくらのクラウド上でのポート制御について確認。

この記事を書いた人

tom

猫とお酒好き

さくらのクラウド検定取得

関連記事