入門

Caddyへようこそ！このチュートリアルでは、Caddyの基本的な使い方を探り、大まかなレベルでCaddyに慣れていただくことを目的としています。

目的

• 🔲 デーモンを実行する
• 🔲 APIを試す
• 🔲 Caddyに設定を与える
• 🔲 設定をテストする
• 🔲 Caddyfileを作成する
• 🔲 構成アダプターを使用する
• 🔲 初期設定から始める
• 🔲 JSONとCaddyfileを比較する
• 🔲 APIと設定ファイルを比較する
• 🔲 バックグラウンドで実行する
• 🔲 ゼロダウンタイム設定の再読み込み

前提条件

• 基本的なターミナル/コマンドラインのスキル
• 基本的なテキストエディタのスキル
• caddy と curl が PATH に含まれていること

パッケージマネージャーからCaddyをインストールした場合、Caddyはすでにサービスとして実行されている可能性があります。その場合は、このチュートリアルを実行する前にサービスを停止してください。

まず実行してみましょう

caddy

おっと。サブコマンドがないと、caddy コマンドはヘルプテキストのみを表示します。何をするか忘れたときはいつでもこれを使用できます。

Caddyをデーモンとして起動するには、run サブコマンドを使用します

caddy run

これは永遠にブロックされますが、何をしているのでしょうか？今のところ...何もしていません。デフォルトでは、Caddyの設定（「config」）は空白です。別のターミナルで管理APIを使用してこれを確認できます。

curl localhost:2019/config/

Caddyに設定を与えることで、Caddyを便利にすることができます。これはさまざまな方法で実行できますが、次のセクションでは、curlを使用して/loadエンドポイントにPOSTリクエストを作成することから始めます。

最初の設定

リクエストを準備するには、設定を作成する必要があります。そのコアで、Caddyの設定は単にJSONドキュメントです。

これをJSONファイル（例：caddy.json）に保存します

{
	"apps": {
		"http": {
			"servers": {
				"example": {
					"listen": [":2015"],
					"routes": [
						{
							"handle": [{
								"handler": "static_response",
								"body": "Hello, world!"
							}]
						}
					]
				}
			}
		}
	}
}

次に、アップロードします

curl localhost:2019/load \
	-H "Content-Type: application/json" \
	-d @caddy.json

別のGETリクエストで、Caddyが新しい設定を適用したことを確認できます

curl localhost:2019/config/

ブラウザでlocalhost:2015にアクセスするか、curlを使用して、動作することを確認してください

curl localhost:2015
Hello, world!

Hello, world!と表示されたら、おめでとうございます。動作しています。特に本番環境にデプロイする前に、設定が期待どおりに動作することを確認することをお勧めします。

最初のCaddyfile

Hello Worldだけでちょっと大変でした。

Caddyを構成する別の方法は、Caddyfileを使用することです。上記でJSONで記述したのと同じ設定は、次のように簡単に表現できます

:2015

respond "Hello, world!"

これを現在のディレクトリにCaddyfileという名前のファイル（拡張子なし）に保存します。

Caddyがすでに実行中の場合は停止し（Ctrl+C）、次を実行します

caddy adapt

または、Caddyfileを別の場所に保存した場合、またはCaddyfile以外の名前を付けた場合

caddy adapt --config /path/to/Caddyfile

JSON出力が表示されます！ここで何が起こったのでしょうか？

CaddyfileをCaddyネイティブのJSON構造に変換するために、構成アダプターを使用しました。

その出力を取得して別のAPIリクエストを作成することもできますが、caddyコマンドがそれを行ってくれるため、これらの手順をすべてスキップできます。現在のディレクトリにCaddyfileというファイルがあり、他の構成が指定されていない場合、CaddyはCaddyfileをロードし、それを適合させてすぐに実行します。

現在のフォルダーにCaddyfileがあるため、もう一度caddy runを実行してみましょう

caddy run

または、Caddyfileが別の場所にある場合

caddy run --config /path/to/Caddyfile

（「Caddyfile」で始まらない別の名前の場合は、--adapter caddyfileを指定する必要があります。）

これでサイトをもう一度ロードしようとすると、機能していることがわかります！

ご覧のとおり、初期設定でCaddyを起動する方法はいくつかあります

• 現在のディレクトリにあるCaddyfileという名前のファイル
• --configフラグ（オプションで--adapterフラグを使用）
• --resumeフラグ（構成が以前にロードされた場合）

JSON vs. Caddyfile

これで、CaddyfileがJSONに変換されるだけであることがわかりました。

CaddyfileはJSONよりも簡単に見えますが、常に使用する必要がありますか？各アプローチには長所と短所があります。答えは、要件とユースケースによって異なります。

ユースケースに最適なものを決定する必要があります。

JSONとCaddyfileの両方（およびその他のサポートされている構成アダプター）をCaddyのAPIで使用できることに注意することが重要です。ただし、JSONを使用すると、Caddyの全機能とAPI機能を利用できます。構成アダプターを使用している場合、APIを使用して構成をロードまたは変更する唯一の方法は、/loadエンドポイントです。

API vs. 設定ファイル

また、ワークフローがAPIベースかCLIベースかを選択する必要があります。（同じサーバー上でAPIと設定ファイルの両方を使用できますが、お勧めしません。1つの信頼できる情報源を持つのが最善です。）

APIまたは設定ファイルワークフローの選択は、構成アダプターの使用とは直交しています。JSONを使用できますが、ファイルに保存してコマンドラインインターフェイスを使用することもできます。逆に、APIでCaddyfileを使用することもできます。

しかし、ほとんどの人はJSON+APIまたはCaddyfile+CLIの組み合わせを使用します。

ご覧のとおり、Caddyはさまざまなユースケースやデプロイメントに適しています！

開始、停止、実行

Caddyはサーバーであるため、無期限に実行されます。つまり、プロセスが終了するまで（通常はCtrl+Cで）、caddy runを実行した後、ターミナルはブロック解除されません。

caddy runが最も一般的で、通常推奨されますが（特にシステムサービスを作成する場合！）、代わりにcaddy startを使用してCaddyを起動し、バックグラウンドで実行することもできます

caddy start

これにより、ターミナルを再び使用できるようになります。これは、一部の対話型ヘッドレス環境で便利です。

その後、Ctrl+Cでは停止しないため、自分でプロセスを停止する必要があります

caddy stop

または、APIの/stopエンドポイントを使用します。

設定の再読み込み

サーバーは、ダウンタイムなしで設定の再読み込み/変更を実行できます。

構成をロードまたは変更するすべてのAPIエンドポイントは、ダウンタイムなしで正常に実行されます。

ただし、コマンドラインを使用する場合は、Ctrl+Cを使用してサーバーを停止し、新しい構成を取得するために再度再起動したくなる可能性があります。これはしないでください。サーバーの停止と起動は設定の変更とは直交しており、ダウンタイムが発生します。

代わりに、caddy reloadコマンドを使用して、正常に設定を変更します

caddy reload

これは実際には内部でAPIを使用しているだけです。設定ファイルをロードし、必要に応じてJSONに適合させ、ダウンタイムなしでアクティブな構成を正常に置き換えます。

新しい構成のロード中にエラーが発生した場合、Caddyは最後に動作した構成にロールバックします。