Ubuntu16.04でCaddyを使用してWebサイトをホストする方法

投稿日: 2022-10-23 2022-10-23
タグ: apache, Initial Server Setup, Let's Encrypt, Miscellaneous, nginx, Security, ubuntu, Ubuntu 16.04

このチュートリアルの以前のバージョンは、 MateuszPapiernikによって作成されました。

序章

Caddy は、シンプルさとセキュリティを中心に設計されたWebサーバーであり、Webサイトのホスティングに役立つ多くの機能が付属しています。たとえば、 Let’s Encrypt からTLS証明書を自動的に取得して管理し、HTTPSを有効にすることができます。HTTP/2のサポートも含まれています。 HTTPSは、ユーザーとサーバー間のトラフィックを保護するためのシステムであり、本番環境で実行されているWebサイトの基本的な期待に急速になりつつあります。HTTPSがないと、ユーザーがログインを送信しようとすると、ChromeとFirefoxはWebサイトが「安全ではない」と警告します。情報。

以前は、Caddyをインストールするための推奨される方法は、CaddyプロジェクトのWebサイトからビルド済みのバイナリをダウンロードすることでした。ただし、Caddyのライセンスの仕組みが最近変更されたため、企業内でCaddyを使用している場合でも、ライセンス料を支払わない限り、これらのビルド済みバイナリを商用目的で使用することはできなくなりました。幸い、Caddyのソースコードはまだ完全にオープンソースであり、ライセンスの問題にぶつからないようにCaddyを自分でビルドできます。

このチュートリアルでは、ソースからCaddyをビルドし、それを使用してHTTPSで保護されたWebサイトをホストします。次に、を使用してキャディを構成します Caddyfile、Caddyプラグインをインストールし、新しいバージョンがリリースされたときにインストールをアップグレードする方法を学びます。

前提条件

このガイドを開始する前に、次のものが必要です。

初期サーバーセットアップガイドに従って構成されたUbuntu16.04サーバー。 SSH経由でサーバーに接続し、sudo権限を持つ非rootユーザーとしてログインし、UFWを使用してファイアウォールを設定できる必要があります。
DigitalOceanのDNS管理を使用するために設定されたドメイン名。任意のドメインレジストラからドメイン名を購入し、ドメインをDigitalOceanネームサーバーにポイントするのガイドに従って、DigitalOceanを介してDNSを管理できます。
ドメインからサーバーを指す「A」レコード。オプションで、IPv6を有効にする場合は「AAAA」レコード。 DigitalOcean を使用したホスト名の設定に関するガイドでは、これを行う方法について説明しています。
サーバーにインストールされているGo言語ツールチェーン。 Go1.6のインストール方法に関するガイドに従ってGoをセットアップします。また、Goコードをコンパイルする方法と go コマンドラインツールの機能。これについては、 Building GoExecutablesのガイドに従ってください。

ステップ1—キャディを構築する

このステップでは、Caddyのソースコードをフェッチし、コンパイルできることを確認します。キャディは囲碁で書かれているので、 go get GitHubからCaddyのソースをフェッチして保存するコマンドラインツール $GOPATH/src/github.com/mholt/caddy:

go get github.com/mholt/caddy/caddy

go get Gitを使用してGitHubからコードを複製します。 Gitはバージョン管理システムです。つまり、変更を加えたときにプロジェクトの状態を記録し、プロジェクトの履歴内の以前の状態に戻すことができます。デフォルトでは、 go get コマンドはソースコードの最新バージョンをダウンロードしますが、リリースの中間になる可能性が高いリポジトリへの最新の追加ではなく、Caddyの最新の安定したリリースを使用することをお勧めします。未リリースのバージョンには、バグや半分実装された壊れた機能が含まれている可能性があります。一方、最新の安定バージョンは、正しくコンパイルおよび実行される可能性が高くなります。

以前のすべてのバージョンを表示するには、最初にCaddyのソースを保存したディレクトリに移動します。

cd $GOPATH/src/github.com/mholt/caddy

次に、を使用してCaddyの以前のすべてのリリースを表示します git tag 指図：

git tag

次のような出力が表示されます。

Outputv0.10.0
v0.10.1
v0.10.10
v0.10.11
v0.10.12
v0.10.2
v0.10.3
v0.10.4
v0.10.5
. . .

Caddyの安定バージョンがリリースされるたびに、作成者はタグを追加することでGitでこれを示します。 Gitを使用して、コードを最後の安定版リリース時の状態に戻すことができます。出力で最大のバージョン番号を見つけます。これを書いている時点では、これは v0.10.12.

一部のプラグインをインストールするために後でソースを変更するため、変更を保存するために新しいブランチを作成します。 Gitでは、ブランチは異なるバージョンのコードを同時に処理する方法です。個人的な変更を加えたバージョンのコードと「公式」バージョンのコードを切り替えることができます。新しいブランチを作成するには、 git checkout ブランチを切り替えるコマンド。 The -b オプションは、Gitに名前で新しいブランチを作成するように指示します adding_plugins バージョンから v0.10.12. 交換 adding_plugins ブランチに名前を付けたいものは何でも v0.10.12 以前に特定した最新の安定バージョンを使用すると、次のようになります。

git checkout -b "adding_plugins" "v0.10.12"

これにより、Caddyソースコードのバージョンが最後の安定バージョンに戻り、コードへの変更を保持できる新しいブランチになります。将来Caddyを更新するときは、変更をこの新しいブランチにマージします。

この時点で、を使用してキャディを構築する準備が整いました。 go install ソースコードをバイナリにコンパイルするためのツール。コマンド構文は、Webサイト（ github.com ）からCaddyをインストールするように見えるかもしれませんが、これは実際には、Gitリポジトリを操作したばかりのサーバー上のローカルパスを参照しています（$GOPATH/src/github.com/mholt/caddy):

go install github.com/mholt/caddy/caddy

ソースコードをコンパイルした後、 caddy サーバーを起動するコマンド。これが正しく機能するためには、Goパスを次のように設定する必要があることに注意してください。 $GOPATH/bin、前提条件で説明されているように：

caddy

このコマンドは、次の出力を生成します。

OutputActivating privacy features... done.
http://:2015
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".

この警告は、Caddyに必要なさまざまな構成ファイルを設定するときに解決するため、当面は無視してかまいません。プレス CTRL+C このコマンドを終了します。

Caddyがソースから構築されていることを示すために、Caddyのソースコードに行を追加して、Caddyの実行時にテキストを出力します。使用する nano または開くための好みのエディタ $GOPATH/src/github.com/mholt/caddy/caddy/caddymain/run.go.:

nano $GOPATH/src/github.com/mholt/caddy/caddy/caddymain/run.go

このファイルは、Caddyコマンドに渡されたオプションを処理し、Caddyを実行するときに最初に実行されるものの1つです。

を見つけます Run() 関数を作成し、強調表示されたテキストを中括弧内の最初の行として追加します。これにより、「Hello fromCaddy！」というテキストが出力されます。サーバーが実行される前：

$ GOPATH / src / github.com / mholt / caddy / caddy / caddymain / run.go

. . .
// Run is Caddy's main() function.
func Run() {
        fmt.Println("Hello from Caddy!")

        flag.Parse()

        caddy.AppName = appName
        . . .
}

プレス CTRL + X, Y、それから ENTER ファイルを保存して閉じます。あなたが実行する場合 go install と caddy コマンドを再度実行すると、追加したメッセージが表示されます。 Run() 出力の上部にある関数：

go install github.com/mholt/caddy/caddy
caddy

Output
Hello from Caddy!
Activating privacy features... done.
http://:2015
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".

これで、ソースからCaddyを正常に構築できました。追加した行をから削除できます $GOPATH/src/github.com/mholt/caddy/caddy/caddymain/run.go 必要に応じて、コードを再コンパイルする必要があります。次のステップでは、Caddyをサービスとしてインストールして、起動時に自動的に起動するようにします。次に、サーバーのセキュリティを確保するために、所有権とアクセス許可の設定を調整します。

ステップ2—キャディをインストールする

Caddyをビルドできることを確認したので、次は systemdサービスを構成して、システムの起動時にCaddyを自動的に起動できるようにします。 Systemdは、Linuxでプロセスを管理するための包括的なソリューションです。キャディには、 caddy.service systemdがCaddyサービスを管理するために使用できるファイル。このサービスファイルは、Caddyが実行される環境についていくつかの仮定を行っているため、インストールする前に変更したいことがいくつかあります。

まず、Caddyバイナリをにコピーします /usr/local/bin、Ubuntuのパッケージマネージャーによって管理されておらず、システム操作の鍵とならないバイナリの標準的な場所：

sudo cp $GOPATH/bin/caddy /usr/local/bin/

次に、Caddyバイナリの所有権をrootユーザーに変更します。 root はCaddyを所有しますが、Caddyに脆弱性がある場合、これは重大なセキュリティ問題になる可能性があるため、rootアカウントでCaddyを実行しないことをお勧めします。ただし、 root がバイナリを所有していると、他のアカウントが設定した権限でバイナリを変更できなくなります。これが望ましいのは、Caddyよりも低い権限を持つ別のプロセスが危険にさらされた場合、Caddyを変更してシステムをより詳細に制御することができないためです。

sudo chown root:root /usr/local/bin/caddy

次に、バイナリのファイル権限をに設定します 755 —これにより、 root にファイルの完全な読み取り/書き込み/実行権限が付与されますが、他のユーザーはファイルの読み取りと実行のみが可能になります。

sudo chmod 755 /usr/local/bin/caddy

Caddyプロセスはrootとして実行されないため、LinuxはCaddyプロセスがポートにバインドされないようにします :80 また :443 （それぞれHTTPとHTTPSの標準ポート）。これらは特権操作であるため。 Webで表示できるようにするには、Caddyをこれらのポートの1つにバインドする必要があります。それ以外の場合、ユーザーは、サーバーが提供するコンテンツを表示するために、ブラウザーでサーバーのURLに特定のポート番号を追加する必要があります。

を使用して setcap コマンドを使用すると、 root として実行せずに、Caddyプロセスを低ポートにバインドできます。 setcap プロセスが完全なスーパーユーザー権限を付与せずに特定の特権操作を実行できるようにする場合に役立ちます。 cap_net_bind_service=+ep プロセスに CAP_NET_BIND_SERVICE 権限。特権ポートへのバインドを有効にします。

sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

Caddyバイナリのアクセス許可を設定したら、Caddyの構成ファイルを保存するディレクトリを作成します。これらは、のサブディレクトリに保持する必要があります /etc/、これは、FilesystemHierarchyStandardが推奨する構成ファイルの場所です。

sudo mkdir /etc/caddy

このディレクトリの所有者をrootに設定し、そのグループをwww-dataに設定します。 www-data は、Webサーバーを実行するための標準ユーザーアカウントであり、Caddyを実行するアカウントです。この方法で所有権を設定すると、（ root アカウントを介して）バイナリへの読み取りおよび書き込みアクセス権が確保され、Caddyプロセスも（として実行されるため）バイナリへの読み取りおよび書き込みが可能になります。 www-data ）ですが、他のユーザーはアクセスできません。一緒に使用する場合 chown、 -R フラグは、内のすべてのサブディレクトリとファイルの所有権を変更します /etc/caddy ディレクトリ自体ではなく、ディレクトリ：

sudo chown -R root:www-data /etc/caddy

後のステップで、このチュートリアルでは、Let’sEncryptを使用して自動TLSを有効にする方法について説明します。その準備として、Caddyが取得するTLS証明書を格納するディレクトリを作成し、Caddyと同じ所有権ルールを付与します。 /etc/caddy ディレクトリ：

sudo mkdir /etc/ssl/caddy
sudo chown -R root:www-data /etc/ssl/caddy

キャディは、要求を暗号化するために、このディレクトリに証明書を書き込み、そこから読み取ることができる必要があります。このため、の権限を変更してください /etc/ssl/caddy rootおよびwww-dataからのみアクセスできるようにディレクトリを作成します。

sudo chmod 0770 /etc/ssl/caddy

次に、Caddyがホストするファイルを保存するディレクトリを作成します。 /var/www/ HTTP経由で提供されるファイルを保存するためのデファクトスタンダードの場所です。

sudo mkdir /var/www

次に、ディレクトリの所有者とグループを www-data に設定します。これは、UbuntuでのWebサーバー操作のデフォルトユーザーです。

sudo chown www-data:www-data /var/www

キャディは、というファイルを介して構成されます Caddyfile; これを次のように考えると役立つ場合があります httpd.conf ApacheまたはNginxで sites-available 構成ディレクトリ。 Caddyのsystemdサービスは、このファイルがに保存されることを期待します /etc/caddy、作成する Caddyfile そこを使用して touch:

sudo touch /etc/caddy/Caddyfile

Caddyサービスをインストールするには、systemdユニットファイルをCaddyソースコードから次の場所にコピーします。 /etc/systemd/system、systemdサービスの場所。そうすることで、systemdはCaddyサービスを検出して制御できるようになります。

sudo cp $GOPATH/src/github.com/mholt/caddy/dist/init/linux-systemd/caddy.service /etc/systemd/system/

サービスファイルのアクセス許可を変更して、所有者rootのみが変更できるようにします。

sudo chmod 644 /etc/systemd/system/caddy.service

次に、 systemctl systemdをリロードするコマンドラインツール。これにより、systemdはCaddyサービスを検出しますが、まだ実行しません。

sudo systemctl daemon-reload

systemdがCaddyサービスを検出したかどうかを実行して確認します systemctl status:

sudo systemctl status caddy

Output● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: https://caddyserver.com/docs

これと同じ出力が表示される場合、Caddyはsystemdによって正しく検出されています。

このインストールプロセスの最後のステップは、Caddyの構成を作成する前に、ファイアウォールを調整することです。サーバーの初期設定ガイドに記載されているように、UFWを使用してファイアウォールを実行している必要があります。ファイアウォールは、サーバーのセキュリティを保護するための重要なツールです。ファイアウォールを使用すると、外部の関係者が接続できるように公開されているポートと、アクセスから保護されているポートを構成できます。サーバー上のポートを公開する他のプロセスがある場合、ファイアウォールはこれらへのアクセスを防ぎ、攻撃者が脆弱なソフトウェアを侵害する機会を減らします。

使用 ufw ポートのファイアウォールを無効にするコマンドラインツール :80 と :443、これにより、CaddyはそれぞれHTTPおよびHTTPSを介して通信できるようになります。

sudo ufw allow 80
sudo ufw allow 443

使用する ufw status 変更が機能したかどうかを確認するには：

sudo ufw status

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

Caddyのインストールは完了しましたが、この時点では何も実行するように設定されていません。次に、このCaddyのクリーンインストールを実行し、Webサイトにサービスを提供するように構成する方法を見ていきます。

ステップ3—キャディの設定

キャディのインストールを機能するWebサーバーとして使用するには、いくつかの設定を変更する必要があります。これらの変更を行う際に、構文を検討します。 Caddyfile 構成、いくつかの構成シナリオの調査、およびHTTPを介したプレースホルダーページの提供。

Caddyの構成を開始するには、Caddyが提供する基本的なHTMLファイルを作成します。 HTMLは、Webページのコンテンツを記述する言語であり、このファイルは、Caddyを使用してWebサイトをホストすることを示すプレースホルダーとして機能します。 Caddyを使用して独自のWebサイトをホストする場合は、このファイルをホストするコンテンツに置き換えます。このファイルを /var/www/ 以前に設定したディレクトリ。名前 index.html これはほとんどのWebサーバーの「デフォルト」ページを指し、ドメインに移動するユーザーには最初にこのファイルが提供されるため、重要です。

sudo touch /var/www/index.html

お好みのエディタで新しいファイルを開きます。

sudo nano /var/www/index.html

次のコンテンツをファイルに追加します。

/var/www/index.html

<!DOCTYPE html>
<html>
  <head>
    <title>Hello from Caddy!</title>
  </head>
  <body>
    <h1 style="font-family: sans-serif">This page is being served via Caddy</h1>
  </body>
</html>

これにより、「このページはCaddy経由で提供されています」というテキストの見出しが表示されます。

ファイルを保存して閉じてから、 Caddyfile 以前に作成した構成ファイル：

sudo nano /etc/caddy/Caddyfile

ファイルを編集して、次のコンテンツを含めます。

/ etc / caddy / Caddyfile

:80 {
    root /var/www
}

最初の行で、 :80 サーバーのホスト名を設定します— Caddyでは、これはlabelと呼ばれます。ホスト名は、Caddyがリクエストに応答するドメイン名です。この場合、次のように設定します :80、ポートを意味します :80 サーバーの。これにより、Caddyはこれを自動的に有効にしようとするため、サーバーがHTTPSを介して実行されるのを防ぎますが、プラグインを介してこれを実行したいと考えています。

デフォルトでは、Caddyは、ファイルのホスティングなど、HTTP経由でリソースを利用できるようにすることで、Let’sEncryptからSSL証明書を取得しようとします。ただし、Caddyを使用して内部サービスを実行する場合は、サーバーをパブリックインターネットに公開したくない場合があります。プラグインを使用すると、Let’sEncryptDNSチャレンジを使用できます。これには、CaddyがDNS「TXT」レコードを作成してサーバーの制御を証明し、外部のHTTP要求を必ずしも受け入れる必要なしに証明書をフェッチできるようにすることが含まれます。これにより、将来的にCaddyを実行する方法についてより多くのオプションが残ります。

後 :80 は、中かっこで囲まれた構成ブロックであり、サイトの構成が含まれます。次の行に、 root ディレクティブ。ディレクティブはCaddyの実際の構成オプションであり、ディレクティブを追加すると、Webサイトを提供するときのCaddyの動作が変更されます。ディレクティブにはargumentsを含めることができます。これは、ディレクティブを有効にする方法のオプションです。この場合、 root ディレクティブには1つの引数があります。 /var/www. このディレクティブは、Caddyが提供するファイルが配置されるディレクトリを設定します。ただし、ディレクティブに引数を指定する必要はありません。たとえば、 gzip クライアントに送信される前にWebページを圧縮する引数のないディレクティブ。これにより、Webページのロードが高速化されます。

/ etc / caddy / Caddyfile

:80 {
    root /var/www
    gzip
}

ディレクティブは、追加機能を提供するサブディレクティブで構成できます。これらは、中括弧を使用して、独自の構成ブロックに配置されます。たとえば、 gzip ディレクティブはそれ自体で機能します。 ext 特定のファイルタイプのみを圧縮するサブディレクティブ、または level 発生する圧縮レベルを制御するサブディレクティブ（1が最低、9が最高）。

/ etc / caddy / Caddyfile

:80 {
    root /var/www
    gzip {
        ext .html .htm .php
        level 6
    }
}

Caddyには、多くのユースケースに対応する膨大な数の異なるディレクティブがあります。たとえば、 fastcgi ディレクティブは、PHPを有効にするのに役立ちます。 markdown ディレクティブを使用すると、Markdownファイルを提供する前に自動的にHTMLに変換できます。これは、単純なブログの作成に役立ちます。

保存して閉じます Caddyfile、すべてが正しく機能していることをテストします。使用する systemctl キャディサービスを開始するには：

sudo systemctl start caddy

次に、実行します systemctl status キャディサービスのステータスに関する情報を見つけるには：

sudo systemctl status caddy

次のように表示されます。

Output● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-01-27 11:37:06 UTC; 7min ago
     Docs: https://caddyserver.com/docs
 Main PID: 2973 (caddy)
    Tasks: 6
   Memory: 3.2M
      CPU: 24ms
   CGroup: /system.slice/caddy.service
           └─2973 /usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp

Jan 27 11:37:06 caddy-tutorial-testing-0 systemd[1]: Started Caddy HTTP/2 web server.
Jan 27 11:37:06 caddy-tutorial-testing-0 caddy[2973]: Activating privacy features... done.
Jan 27 11:37:06 caddy-tutorial-testing-0 caddy[2973]: http://
Jan 27 11:37:06 caddy-tutorial-testing-0 caddy[2973]: 2018/01/27 11:37:06 http://

ドメインを参照すると、Caddyが実行されていることがわかり、サンプルのWebページが表示されます。これを確認した後、 systemctl まだいくつかの変更が必要なため、Caddyサービスを停止します。

sudo systemctl stop caddy

Caddyにはデフォルトで多くのディレクティブが含まれていますが、考えられるすべてのユースケースに対応できるわけではないため、サーバーに機能を追加することをお勧めします。 Caddyが期待どおりにコンテンツを提供していることがわかったので、プラグインを使用してCaddyの機能を拡張する方法について説明します。

ステップ4—プラグインを使用する

プラグインは、Caddyの動作を変更する方法です。これらは通常、特定のユースケースのディレクティブを追加するためにCaddyに挿入できる小さなコードスニペットです。プラグインを理解する最も簡単な方法は、すぐにプラグインを試してみることです。そのため、プラグインをインストールします。 minify プラグイン。このプラグインは、一部のファイルから余分な空白と冗長なコードを削除し、各ファイルのサイズを縮小します。また、読み込み時間を短縮するのに役立ちます。

プラグインをインストールするにはこれを変更する必要があるため、GoがCaddyのソースコードを保存した場所に戻ることから始めます。

cd $GOPATH/src/github.com/mholt/caddy

キャディーズを開く run.go 再度ファイルします。前に述べたように、これはCaddyの最初に実行される部分の1つであり、プラグインがインストールされる場所です。

nano caddy/caddymain/run.go

このファイルには、 import 次のような宣言：

$ GOPATH / src / github.com / mholt / caddy / caddy / caddymain / run.go

. . .
import (
	"errors"
	"flag"
	"fmt"
	"io/ioutil"
	"log"
	"os"
	"runtime"
	"strconv"
	"strings"

	"gopkg.in/natefinch/lumberjack.v2"

	"github.com/xenolf/lego/acmev2"

	"github.com/mholt/caddy"
	// plug in the HTTP server type
	_ "github.com/mholt/caddy/caddyhttp"

	"github.com/mholt/caddy/caddytls"
	// This is where other plugins get plugged in (imported)
)
. . .

プラグインをインストールするには、 _ "github.com/path/to/plugin" これに import 指令。一部のプラグインでは、設定を少し調整する必要がある場合があるため、インストールするプラグインについては、必ずドキュメントをお読みください。人気のあるプラグインのリストは、キャディドキュメントの左側のペインのプラグインの下にあります。

The minify プラグインのGitHubリポジトリはhacdias/ caddy-minify であるため、インポート宣言の下部に次を追加します。

$ GOPATH / github.com / mholt / caddy / caddy / caddymain / run.go

. . .
import (
    . . .
    "github.com/mholt/caddy/caddytls"
    // This is where other plugins get plugged in (imported)

    _ "github.com/hacdias/caddy-minify"
)

新しい更新をマージするときにそれらの変更が失われないように、コードに変更を加えるときにコードをコミットする必要があります。これまでにこのサーバーでコードをコミットしたことがない場合は、Gitがログであなたを識別できるように、名前とメールアドレスを設定する必要があります。 The git config コマンドを使用すると、これらのオプションを設定できます。 --global フラグは、将来作業する可能性のあるすべてのリポジトリにそれらを適用します。コードをGitHubなどの公開リポジトリにプッシュしない限り、これらの詳細は公開されません。

git config --global user.email "[email protected]"
git config --global user.name "Sammy"

ユーザー名とメールアドレスを設定したので、次の手順を実行して、変更したファイルをGitの stage （コミットする前にコードの状態を保存するために使用されるキャッシュ）に追加します。

git add -A .

今すぐ実行 git commit 現在のブランチへの変更を保存します。 The -m オプションを使用すると、コミットメッセージを設定できるため、変更内容をメモできます。このメッセージは、Gitのログを調べることで見つけることができます。

git commit -m "Added minify plugin"

これでコードにプラグインへのパスがありますが、Goが実際にプラグインにアクセスできるようにするには、プラグインをローカルにダウンロードする必要があります。このコマンドを実行すると、Caddyのすべての依存関係が自動的にフェッチされます。 $GOPATH/src/github.com/mholt/caddy ディレクトリ：

go get ./...

新しいプラグインを追加するときはいつでも、Caddyを再構築する必要があります。これは、Goがコンパイルされたプログラミング言語であるためです。つまり、実行前にソースコードがマシンコードに変換されます。インポート宣言を変更するとソースコードが変更されますが、コンパイルされるまでバイナリには影響しません。

使用 go install キャディをコンパイルするコマンド：

go install github.com/mholt/caddy/caddy

Caddyが正常にビルドされた場合、このコマンドは出力なしで終了します。生成されたバイナリをにコピーします /usr/local/bin 以前と同じようにバイナリの権限を設定します。Caddyを再構築するたびにこれらの手順を実行して、機能とセキュリティを確保する必要があります。

sudo cp $GOPATH/bin/caddy /usr/local/bin/
sudo chown root:root /usr/local/bin/caddy
sudo chmod 755 /usr/local/bin/caddy
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

プラグインが正常にインストールされたことを示すには、 Caddyfile.

sudo nano /etc/caddy/Caddyfile

構成ブロックに次の行を追加して、プラグインを有効にします。

/ etc / caddy / Caddyfile

:80 {
    root /var/www
    gzip
    minify
}

次に、を使用してサーバーを起動します systemctl:

sudo systemctl start caddy

Caddyは現在実行中であり、Caddyが提供するすべてのファイルを縮小します。 index.html 以前に作成したファイル。 Webリクエストを行うためのコマンドラインツールであるcURLを使用して、作業中の「縮小」を観察できます。ランニング curl オプションやフラグがない場合、Webページのコンテンツがフェッチされ、ターミナルに表示されます。次のコマンドを実行して、 index.html キャディからのファイル、置換 example.com あなたのドメインで。

curl http://example.com

次の出力が表示されます。不要なスペースがすべて削除されていることに注意してください。 minify プラグインは機能しました。

Output<!doctype html><title>Hello from Caddy!</title><h1 style=font-family:sans-serif>This page is being served via Caddy</h1>

これと同じインストール方法は、他のCaddyプラグインでも機能します。プラグインを追加すると、 tls.dns.digitalocean 保護されたHTTPSトラフィックを自動的に有効にするプラグイン。

ステップ5—Let’sEncryptを使用して自動TLSを有効にする

Caddyは、Let’s Encryptを使用してデフォルトでHTTPSを有効にします。これは、HTTPSの詳細を間違えやすいため便利です。キャディのHTTPSへのアプローチは安全であり、トラフィックを暗号化するために構成を深く掘り下げる必要はありません。ただし、Caddyのデフォルトは HTTP-01 Let’sEncryptを使用して実際にドメインを所有していることを確認する方法。この方法では、特別なファイル（Let’s Encryptによって送信されたチャレンジへの応答を含む）をWebサイトの特定の場所に投稿します。この方法は機能しますが、Webサイトに一般公開されている必要があります。これは、特定のファイアウォール構成で、またはビジネスの内部サービスとしてCaddyを実行している場合に問題になる可能性があります。

別の方法として、 tls.dns.digitalocean キャディプラグイン。 DNS-01 代わりに検証方法。このプラグインは、ドメインの新しい「TXT」DNSレコードを追加することにより、Let’s Encryptで認証されます。これは、Webサイトの機能に影響を与えません。これは、DNSを制御するためにDigitalOceanのAPIを使用します。これにより、サーバーが一般公開されていない場合でも、証明書を柔軟に取得できます。さまざまなタイプのDNSレコードの詳細については、 DigitalOceanDNSの概要を参照してください。

インストール方法 tls.dns.digitalocean キャディプラグインは、インストール方法とほぼ同じです。 minify プラグイン。開始するには、 $GOPATH/src/github.com/mholt/caddy/caddy/caddymain/run.go:

nano $GOPATH/src/github.com/mholt/caddy/caddy/caddymain/run.go

プラグインの場所を追加します。

$ GOPATH / github.com / mholt / caddy / caddy / caddymain / run.go

. . .
import (
    . . .
    "github.com/mholt/caddy/caddytls"
    // This is where other plugins get plugged in (imported)

    _ "github.com/hacdias/caddy-minify"
    _ "github.com/caddyserver/dnsproviders/digitalocean"
)

Caddyを更新するには、Caddyのソースリポジトリに移動し、変更をGitにコミットします。

cd $GOPATH/src/github.com/mholt/caddy
git add -A .
git commit -m "Add DigitalOcean DNS provider"

次に、以前に行ったように、すべての依存関係をインストールしてCaddyをビルドします。

go get ./...
go install github.com/mholt/caddy/caddy

キャディが経由で停止していることを確認します systemctl次に、新しくビルドされたCaddyバイナリをコピーし、所有権と権限をもう一度設定して、プラグインのインストールを完了します。

sudo systemctl stop caddy
sudo cp $GOPATH/bin/caddy /usr/local/bin/
sudo chown root:root /usr/local/bin/caddy
sudo chmod 755 /usr/local/bin/caddy
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

次に、DigitalOceanのAPIと連携してDNSレコードを設定するようにCaddyを構成します。 DigitalOceanアカウントのAPIタブに移動し、新しいトークンの生成を選択します。

トークンにわかりやすい名前を付けます（caddy-dns、たとえば）、書き込み（オプション）が選択されていることを確認します。次に、トークンの生成を押します。

生成されたトークンをクリックしてコピーし、紛失しない場所に記録します。キャディは、DigitalOceanのDNSを構成するために、環境変数としてこのトークンにアクセスする必要があります。 systemdのサービスファイルを使用すると、プロセスの環境に含める環境変数を定義できます。のCaddyサービスファイルを編集します /etc/systemd/system/ Caddy Gitリポジトリのバージョンではなく、ディレクトリ。プライベートトークンをパブリックCaddyリポジトリに誤ってコミットしないように、Gitリポジトリの外部にあるファイルのバージョンにAPIキーを追加します。

sudo nano /etc/systemd/system/caddy.service

で始まる行を検索します Environment= の中に [Service] セクション。この行は、Caddyプロセスに渡す必要のある環境変数を定義します。この行の最後にスペースを追加してから、 DO_AUTH_TOKEN 変数の後に、生成したトークンが続きます。

/etc/systemd/system/caddy.service

[Service]
Restart=on-abnormal

; User and group the process will run as.
User=www-data
Group=www-data

; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy DO_AUTH_TOKEN=your_token_here

このファイルを保存して閉じてから、前に行ったようにsystemdデーモンをリロードして、構成が更新されていることを確認します。

sudo systemctl daemon-reload

走る systemctl status 構成の変更に問題がないことを確認するには：

sudo systemctl status caddy

これにより、次のような出力が生成されます。行頭に細心の注意を払ってください Loaded:. The loaded statusは、サービス構成への変更が成功したことを示します。 systemdサービスの構成中にエラーが発生した場合、この行には代わりに error systemdがサービスファイルを解釈できなかった理由の説明とともにステータス。次の行、始まり Active: サービスが実行されているかどうかを示します。このステップの前半でCaddyを停止したため、これは次のように表示されます。 inactive. キャディを実行すると、これが表示されます enabled また running.

Output● caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: https://caddyserver.com/docs

あなたはあなたにいくつかのわずかな変更を加える必要があります Caddyfile、編集用に開きます。

sudo nano /etc/caddy/Caddyfile

強調表示された行をに追加します Caddyfile、必ず交換してください example.com あなたのドメインで。ホスト名にポートだけでなくドメインを使用すると、CaddyはHTTPS経由でリクエストを処理します。 The tls ディレクティブは、使用時のCaddyの動作を構成します TLS、そしてその dns サブディレクティブは、キャディが使用する必要があることを指定します DNS-01 システムではなく HTTP-01:

/ etc / caddy / Caddyfile

example.com {
    root /var/www
    gzip
    minify
    tls {
        dns digitalocean
    }
}

Webサイトを展開する準備ができました。まず、サーバーを起動します systemctl その後 enable それ。これにより、起動時に起動するようにCaddyが構成されます。

sudo systemctl start caddy
sudo systemctl enable caddy

ドメインを参照すると、HTTPSに自動的にリダイレクトされます。

Caddyのインストールが完了し、保護されています。次に、新しいバージョンがリリースされたときにCaddyを更新する方法を見ていきます。パッケージマネージャーを使用してソフトウェアをインストールする場合、ソフトウェアの更新は通常、単一のコマンドを実行するのと同じくらい簡単であり、多くの場合、オペレーティングシステムはセキュリティ更新プログラムを自動的にインストールできます。ただし、ソースからCaddyを構築したため、プロセスはもう少し複雑になります。更新されたバージョンのソースコードからCaddyを再構築してから、再設定する必要があります。

ステップ6—キャディインストールの更新

古いソフトウェアには脆弱性があることが多いため、ソフトウェアを最新の状態に保つことは重要なセキュリティ慣行です。最新バージョンのCaddyを実行すると、古いバージョンに存在する可能性のある脆弱性によってサーバーのセキュリティが危険にさらされるのを防ぐことができます。このステップでは、新しいバージョンがリリースされたときにCaddyのインストールを更新する方法を見ていきます。この手順は、Caddyの新しいリリースがCaddyGitHubリポジトリにプッシュされた場合にのみ実行する必要があります。

Gitを使用してソースコードの状態を更新します。まず、に変更します caddy ソースディレクトリ：

cd $GOPATH/src/github.com/mholt/caddy

手順1で作成したブランチにいることを確認します。 git checkout:

git checkout adding_plugins

次に、 git fetch リモートリポジトリから変更をプルします。 GitがCaddyリポジトリのクローンを作成するとき、変更が発生する中央の場所であるアップストリームリポジトリへのリンクを維持します。 Gitはアップストリームリポジトリを名前で参照します origin、したがって、オリジンからフェッチする必要があります。

git fetch origin

これで、リポジトリへの変更がシステムに存在し、別のブランチに保存されます。使用する git tag リリース間のコードではなく、リリースされたバージョンのCaddyを引き続き使用する必要があるため、最新のリリースを確認するには、次のようにします。

git tag

以前と同様に、最新バージョンが見つかるまでリストを参照します。 Gitには、2つの異なるコードブランチをマージするためのツールが含まれています— git merge. 次のように入力して、最新バージョンからの変更を作業ブランチにマージします。必ず交換してください adding_plugins ブランチの名前と、識別した最新のバージョン番号を使用します。

git merge adding_plugins v0.10.13

保存して閉じてマージを完了することができるエディターが表示されます。ただし、Gitが2つの異なるバージョンのコードをどのように組み合わせるかを判断できない場合、マージの競合が発生する可能性があります。これが発生した場合、Gitは通知します。競合するファイルを手動で編集してから、競合を解決するためにコミットする必要があります。

マージの競合がないと仮定して、このチュートリアル全体で実行したのと同じプロセスを使用してCaddyを再インストールします。まず、 go install バイナリを再構築するには：

go install github.com/mholt/caddy/caddy

次に、Caddyサービスを停止し、新しいバイナリをコピーします。

sudo systemctl stop caddy
sudo cp $GOPATH/bin/caddy /usr/local/bin/

バイナリの権限を設定します。

sudo chown root:root /usr/local/bin/caddy
sudo chmod 755 /usr/local/bin/caddy
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

最後に、 systemctl キャディサービスを再開するには：

sudo systemctl start caddy

キャディは無効にされていないため、今後も起動時に起動し続けます。これにより、Caddyは最新バージョンに正常に更新され、少なくとも次のリリースまで、中断することなく動作し続けるはずです。

結論

このチュートリアルに従うことで、Caddyを使用してWebサイトを正常に展開できました。次の良いステップは、Caddyの新しいバージョンがリリースされたときに通知を受ける方法を見つけることです。たとえば、Caddyリリース用の Atomフィード、またはSibbellなどの専用サービスを使用できます。サーバーの更新プロセスを自動化するスクリプトを作成することもお勧めします。2つを組み合わせて、新しいリリースがあるときにCaddyを自動的に再構築するビルドツールを作成することもできます。それ以外の場合は、キャディのドキュメントを調べて、ニーズに合わせてカスタマイズするのに最適な方法を見つけることができます。

getdocs

13036