Caddyを常時実行する

Caddyはコマンドラインインターフェースで直接実行できますが、サービスマネージャーを使用してCaddyを常時実行することで、システムの再起動時に自動的に起動したり、stdout/stderrログをキャプチャするなど、多くの利点があります。

Linuxサービス
Windowsサービス
- sc.exe
- WinSW
Docker Compose

Linuxサービス

systemdを使用するLinuxディストリビューションでCaddyを実行する推奨方法は、公式のsystemdユニットファイルを使用することです。

ユニットファイル

ユースケースに応じて選択できる2つの異なるsystemdユニットファイルを提供しています。

caddy.service は、CaddyfileでCaddyを設定する場合に使用します。異なる設定アダプターまたはJSON設定ファイルを使用する場合は、ExecStartコマンドとExecReloadコマンドをオーバーライドできます。
caddy-api.service は、APIだけでCaddyを設定する場合に使用します。このサービスは--resumeオプションを使用しており、デフォルトで永続化されるautosave.jsonを使用してCaddyを起動します。

これらは非常に似ていますが、ワークフローに対応するためにExecStartコマンドとExecReloadコマンドが異なります。

サービスを切り替える必要がある場合は、別のサービスを有効にして開始する前に、前のサービスを無効にして停止する必要があります。たとえば、caddyサービスからcaddy-apiサービスに切り替えるには

sudo systemctl disable --now caddy
sudo systemctl enable --now caddy-api

手動インストール

いくつかのインストール方法では、Caddyをサービスとして自動的に設定します。そうでない方法を選択した場合は、次の手順に従ってサービスとして設定してください。

要件

ダウンロードまたはソースからビルドしたcaddyバイナリ
systemctl --version 232以上
sudo権限

例えば、caddyバイナリを$PATHに移動します。

sudo mv caddy /usr/bin/

動作確認

caddy version

caddyという名前のグループを作成します。

sudo groupadd --system caddy

書き込み可能なホームディレクトリを持つcaddyという名前のユーザーを作成します。

sudo useradd --system \
    --gid caddy \
    --create-home \
    --home-dir /var/lib/caddy \
    --shell /usr/sbin/nologin \
    --comment "Caddy web server" \
    caddy

設定ファイルを使用する場合は、作成したばかりのcaddyユーザーが読み取り可能であることを確認してください。

次に、ユースケースに基づいてsystemdユニットファイルを選択します。

ExecStartおよびExecReloadディレクティブを二重に確認してください。 バイナリの場所とコマンドライン引数が、インストールに合わせて正しいことを確認してください！たとえば、設定ファイルを使用する場合は、デフォルトと異なる場合は--configパスを変更します。

サービスファイルを保存する一般的な場所は/etc/systemd/system/caddy.serviceです。

サービスファイルを保存したら、通常のsystemctlコマンドで初めてサービスを開始できます。

sudo systemctl daemon-reload
sudo systemctl enable --now caddy

実行されていることを確認します。

systemctl status caddy

これで、サービスを使用する準備ができました！

サービスの使用

Caddyfileを使用する場合は、nano、vi、または好みのエディターで設定を編集できます。

sudo nano /etc/caddy/Caddyfile

静的サイトファイルは、/var/www/htmlまたは/srvのいずれかに配置できます。caddyユーザーがファイルを読み取れるようにしてください。

サービスが実行されていることを確認するには

systemctl status caddy

statusコマンドは、現在実行中のサービスファイルの場所も表示します。

公式サービスファイルで実行している場合、Caddyの出力はjournalctlにリダイレクトされます。完全なログを読み取り、行が切り捨てられるのを避けるには

journalctl -u caddy --no-pager | less +G

設定ファイルを使用する場合は、変更を加えた後にCaddyを正常にリロードできます。

sudo systemctl reload caddy

サービスを停止するには

sudo systemctl stop caddy

Caddyプロセスはcaddyユーザーとして実行され、その$HOMEは/var/lib/caddyに設定されます。つまり

デフォルトのデータ保存場所（証明書やその他の状態情報）は/var/lib/caddy/.local/share/caddyになります。
デフォルトの設定保存場所（主にcaddy-apiサービスで役立つ自動保存されたJSON設定用）は/var/lib/caddy/.config/caddyになります。

systemdを使用したローカルHTTPS

HTTPSでローカル開発にCaddyを使用する場合、localhostまたはapp.localhostのようなホスト名を使用する場合があります。これにより、CaddyのローカルCAを使用して証明書を発行するローカルHTTPSが有効になります。

Caddyはサービスとして実行されている場合、caddyユーザーとして実行されるため、システムの信頼ストアにルートCA証明書をインストールする権限がありません。これを行うには、sudo caddy trustを実行してインストールします。

internal発行者を使用する場合に他のデバイスがサーバーに接続できるようにするには、これらのデバイスにもルートCA証明書をインストールする必要があります。ルートCA証明書は/var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crtにあります。多くのWebブラウザーは現在、独自の信頼ストアを使用しているため（システムの信頼ストアを無視しているため）、手動でブラウザーにも証明書をインストールする必要がある場合があります。

オーバーライド

サービスファイルの側面をオーバーライドする最良の方法は、このコマンドを使用することです。

sudo systemctl edit caddy

これにより、デフォルトのターミナルテキストエディターで空のファイルが開き、ユニット定義にディレクティブをオーバーライドまたは追加できます。これは「ドロップイン」ファイルと呼ばれます。

たとえば、設定で使用するために環境変数を定義する必要がある場合は、次のように行うことができます。

[Service]
Environment="CF_API_TOKEN=super-secret-cloudflare-tokenvalue"

同様に、環境変数（envfile）を維持するための別々のファイルを使用する場合は、EnvironmentFileディレクティブを次のように使用できます。

[Service]
EnvironmentFile=/etc/caddy/.env

または、たとえば、CaddyfileのデフォルトからJSONファイルを使用するように設定ファイルを変更する必要がある場合（Exec*ディレクティブは新しい値を設定する前に空文字列でリセットする必要があります）。

[Service]
ExecStart=
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/caddy.json
ExecReload=
ExecReload=/usr/bin/caddy reload --config /etc/caddy/caddy.json

または、たとえば、予期せずクラッシュした場合に5秒後にCaddyが自身を再起動するようにしたい場合。

[Service]
# Automatically restart caddy if it crashes except if the exit code was 1
RestartPreventExitStatus=1
Restart=on-failure
RestartSec=5s

次に、ファイルを保存してテキストエディターを終了し、サービスを再起動して有効にします。

sudo systemctl restart caddy

SELinuxに関する考慮事項

SELinuxが有効になっているシステムでは、2つのオプションがあります。

COPRリポジトリを使用してCaddyをインストールします。 systemdファイルとcaddyバイナリは既に作成され、正しくラベル付けされているため（このセクションを無視できます）、カスタムビルドのCaddyを使用する場合は、以下に説明されているように実行ファイルをラベル付けする必要があります。
このサイトからCaddyをダウンロードするか、xcaddyでコンパイルします。いずれの場合も、ファイルを自分でラベル付けする必要があります。

Systemdユニットファイルとその実行ファイルは、それぞれsystemd_unit_file_tとbin_tでラベル付けされていない限り、実行されません。

systemd_unit_file_tラベルは/etc/systemd/...に作成されたファイルに自動的に適用されるため、手動インストール手順に従ってcaddy.serviceファイルをそこに作成してください。

caddyバイナリにタグを付けるには、次のコマンドを使用できます。

semanage fcontext -a -t bin_t /usr/bin/caddy && restorecon -Rv /usr/bin/caddy

Windowsサービス

WindowsでCaddyをサービスとして実行するには、sc.exeまたはWinSWの2つの方法があります。

sc.exe

サービスを作成するには、次を実行します。

sc.exe create caddy start= auto binPath= "YOURPATH\caddy.exe run"

(YOURPATHをcaddy.exeの実際のパスに置き換えます)

開始するには

sc.exe start caddy

停止するには

sc.exe stop caddy

WinSW

これらの手順に従って、WindowsにCaddyをサービスとしてインストールします。

要件

ダウンロードまたはソースからビルドしたcaddy.exeバイナリ
WinSWサービスラッパーの最新リリースからの任意の.exe（以下のサービス設定はv2.xリリース用です）

すべてのファイルをサービスディレクトリに入れます。次の例では、C:\caddyを使用します。

WinSW-x64.exeファイルをcaddy-service.exeに名前変更します。

同じディレクトリにcaddy-service.xmlを追加します。

<service>
  <id>caddy</id>
  <!-- Display name of the service -->
  <name>Caddy Web Server (powered by WinSW)</name>
  <!-- Service description -->
  <description>Caddy Web Server (https://caddy.dokyumento.jp/)</description>
  <executable>%BASE%\caddy.exe</executable>
  <arguments>run</arguments>
  <log mode="roll-by-time">
    <pattern>yyyy-MM-dd</pattern>
  </log>
</service>

これで、次を使用してサービスをインストールできます。

caddy-service install

サービスが正しく実行されているかどうかを確認するために、Windowsサービスコンソールを開始することをお勧めします。

services.msc

Windowsサービスはリロードできないため、Caddyに直接リロードするように指示する必要があります。

caddy reload

タスクマネージャーの「サービス」タブなど、通常のWindowsサービスコマンドで再起動が可能です。

サービスラッパーのカスタマイズについては、WinSWドキュメントを参照してください。

Docker Compose

Dockerで簡単に使い始めるには、Docker Composeを使用します。公式Caddy Dockerイメージの詳細については、Docker Hubのドキュメントを参照してください。

設定

最初に、compose.ymlファイルを作成します（または、既存のファイルにこのサービスを追加します）。

services:
  caddy:
    image: caddy:<version>
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./site:/srv
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

イメージ<version>に、Docker Hubの「タグ」セクションに一覧表示されている最新のバージョン番号を入力してください。

これを行うこと

unless-stopped再起動ポリシーを使用して、マシンが再起動されたときにCaddyコンテナーが自動的に再起動されるようにします。
HTTPとHTTPSのポート80と443、およびHTTP/3の443/udpにバインドします。
Caddy設定であるCaddyfileファイルをバインドマウントします。
/srvからサイトの静的ファイルを提供するために、siteディレクトリをバインドマウントします。
重要な情報を永続化するための/dataと/configの名前付きボリューム。

次に、compose.ymlの横にCaddyfileという名前のファイルを作成し、Caddyfile設定を記述します。

静的ファイルを配信する必要がある場合は、設定ファイルの横にsite/ディレクトリを作成し、root を root * /srv で設定します。静的ファイルがない場合は、/srv ボリュームのマウントを削除できます。

プラグインを含むCaddyのカスタムビルドが必要な場合は、Dockerビルド手順に従ってカスタムDockerイメージを作成します。compose.yml の横に Dockerfile を作成し、compose.yml の image: 行を build: . に置き換えます。

使用方法

その後、コンテナを起動できます。

docker compose up -d

Caddyfileを変更した後、Caddyを再読み込みするには

docker compose exec -w /etc/caddy caddy caddy reload

Caddyの最新の1000件のログを表示し、fを押すと新しいログがストリーミング表示されます。

docker compose logs caddy -n=1000 -f

Docker を使用したローカル HTTPS

HTTPS を使用したローカル開発に Docker を使用する場合、localhost や app.localhost のようなホスト名を使用することがあります。これにより、Caddy のローカル CA を使用して証明書を発行するローカル HTTPS が有効になります。つまり、コンテナ外部の HTTP クライアントは、Caddy によって提供される TLS 証明書を信頼しません。これを解決するには、ホストマシンの信頼ストアに Caddy のルート CA 証明書をインストールします。

docker compose cp \
    caddy:/data/caddy/pki/authorities/local/root.crt \
    /usr/local/share/ca-certificates/root.crt \
  && sudo update-ca-certificates

docker compose cp \
    caddy:/data/caddy/pki/authorities/local/root.crt \
    /tmp/root.crt \
  && sudo security add-trusted-cert -d -r trustRoot \
    -k /Library/Keychains/System.keychain /tmp/root.crt

docker compose cp \
    caddy:/data/caddy/pki/authorities/local/root.crt \
    %TEMP%/root.crt \
  && certutil -addstore -f "ROOT" %TEMP%/root.crt

多くのWebブラウザは独自の信頼ストアを使用するようになっており（システムの信頼ストアを無視します）、そのため、上記のコマンドでコンテナからコピーしたroot.crtファイルを使用して、手動でブラウザにも証明書をインストールする必要がある場合があります。

Firefox の場合、設定 > プライバシーとセキュリティ > 証明書 > 証明書を表示 > 認証機関 > インポートに移動し、root.crt ファイルを選択します。
Chrome の場合、設定 > プライバシーとセキュリティ > セキュリティ > 証明書の管理 > 認証機関 > インポートに移動し、root.crt ファイルを選択します。