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

投稿日: 2019-11-08 2022-04-20
タグ: apache, Initial Server Setup, Let's Encrypt, Miscellaneous, nginx, Security, ubuntu, Ubuntu 16.04

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

著者はウィキメディア財団を選択し、 Write forDOnationsプログラムの一環として200ドルの寄付を受け取りました。

序章

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を構成し、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のソースコードをフェッチし、コンパイルできることを確認します。 CaddyはGoで記述されているため、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

次に、git tagコマンドを使用して、Caddyの以前のすべてのリリースを表示します。

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コマンドを使用します。 -bオプションは、バージョンv0.10.12からadding_pluginsという名前の新しいブランチを作成するようにGitに指示します。 adding_pluginsをブランチに名前を付けたい名前に置き換え、v0.10.12を以前に特定した最新の安定バージョンに置き換えます。

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

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

この時点で、go installツールを使用してソースコードをバイナリにコンパイルすることにより、Caddyをビルドする準備が整いました。コマンド構文は、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には、systemdがCaddyサービスの管理に使用できるcaddy.serviceファイルがインストールされています。このサービスファイルは、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はポート: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証明書を格納するディレクトリを作成し、/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というファイルを介して構成されます。これは、Apacheのhttpd.confまたはNginxsites-available構成ディレクトリに似ていると考えると役立つ場合があります。 Caddyのsystemdサービスは、このファイルが/etc/caddyに保存されることを想定しているため、touchを使用してCaddyfileを作成します。

sudo touch /etc/caddy/Caddyfile

Caddyサービスをインストールするには、systemdユニットファイルをCaddyソースコードからsystemdサービスの場所である/etc/systemd/systemにコピーします。そうすることで、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

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

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はサーバーのホスト名を設定します—キャディではこれは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ディレクティブには、/var/wwwという1つの引数があります。このディレクティブは、Caddyが提供するファイルが配置されるディレクトリを設定します。ただし、ディレクティブに引数を指定する必要はありません。たとえば、引数なしでgzipディレクティブを追加して、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を使用して、Caddyサービスを開始します。

sudo systemctl start caddy

次に、systemctl statusを実行して、Caddyサービスのステータスに関する情報を検索します。

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)
)
. . .

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

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がログであなたを識別できるように、名前とメールアドレスを設定する必要があります。 git configコマンドを使用すると、これらのオプションを設定できます。--globalフラグは、将来作業する可能性のあるすべてのリポジトリにオプションを適用します。コードをGitHubなどの公開リポジトリにプッシュしない限り、これらの詳細は公開されません。

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

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

git add -A .

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

git commit -m "Added minify plugin"

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

go get ./...

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

go installコマンドを使用して、Caddyをコンパイルします。

go install github.com/mholt/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は現在実行中であり、以前に作成したindex.htmlファイルを含め、Caddyが提供するすべてのファイルを縮小します。 Webリクエストを行うためのコマンドラインツールであるcURLを使用して、作業中の「縮小」を観察できます。オプションやフラグを指定せずにcurlを実行すると、Webページのコンテンツがフェッチされ、ターミナルに表示されます。次のコマンドを実行して、Caddyに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 Caddyプラグインをインストールすることもできます。このプラグインは、代わりにDNS-01検証方法を使用します。このプラグインは、ドメインの新しい「TXT」DNSレコードを追加することにより、Let’s Encryptで認証されます。これは、Webサイトの機能に影響を与えません。これは、DNSを制御するためにDigitalOceanのAPIを使用します。これにより、サーバーが一般公開されていない場合でも、証明書を柔軟に取得できます。さまざまなタイプのDNSレコードの詳細については、 DigitalOceanDNSの概要を参照してください。

tls.dns.digitalocean Caddyプラグインのインストール方法は、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が停止していることを確認してから、新しくビルドした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タブに移動し、新しいトークンの生成を選択します。

The DigitalOcean Applications & API page

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

Creating a Personal Access Token

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

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

[Service]セクションでEnvironment=で始まる行を見つけます。この行は、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:で始まる行に注意してください。 loadedステータスは、サービス構成への変更が成功したことを示します。 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経由でリクエストを処理します。 tlsディレクティブは、TLSを使用するときのCaddyの動作を構成し、dnsサブディレクティブは、CaddyがHTTP-01ではなくDNS-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

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

git checkout adding_plugins

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

git fetch origin

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

git tag

以前と同様に、最新バージョンが見つかるまでリストを参照します。 Gitには、git mergeという2つの異なるコードブランチをマージするためのツールが含まれています。次のように入力して、最新バージョンからの変更を作業ブランチにマージします。必ず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を使用して、Caddyサービスを再開します。

sudo systemctl start caddy

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

結論

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

getdocs

13036