Ubuntu 16.04でCaddyを使用してWebサイトをホストする方法

_このチュートリアルの以前のバージョンはhttps://www.digitalocean.com/community/users/mati[Mateusz Papiernik]によって作成されました。

著者はhttps://www.brightfunds.org/organizations/wikimedia-foundation-inc [ウィキメディア財団]を選択して、https://do.co/w4do-cta [寄付のために書く]の一環として200ドルの寄付を受け取りましたプログラム。

前書き

Caddyは、シンプルさとセキュリティを中心に設計されたWebサーバーであり、Webサイトのホスティングに役立つ多くの機能を備えています。 たとえば、https://letsencrypt.org/ [Let’s Encrypt]からTLS証明書を自動的に取得して管理し、HTTPSを有効にしたり、HTTP / 2をサポートしたりできます。 HTTPSは、ユーザーとサーバー間のトラフィックを保護するためのシステムであり、実稼働で実行されているWebサイトの基本的な期待になりつつあります。情報。

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

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

前提条件

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

  • https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [初期サーバー設定ガイド]に従って構成されたUbuntu 16.04サーバー。 SSH経由でサーバーに接続し、sudo特権を持つ非rootユーザーとしてログインし、UFWを使用してファイアウォールを設定できるようにする必要があります。

  • DigitalOceanのDNS管理を使用するように設定されたドメイン名。 任意のドメインレジストラからドメイン名を購入し、https://www.digitalocean.com/community/tutorials/how-to-point-to-digitalocean-nameservers-from-common-domain-registrarsのガイドに従ってください[ポインティングDigitalOceanネームサーバーへのドメイン]。DigitalOceanを介してDNSを管理します。

  • ドメインからサーバーを指す「A」レコード、およびオプションで、IPv6を有効にする場合は「AAAA」レコード。 DigitalOceanを使用したホスト名の設定のガイドでは、これを行う。

  • サーバーにインストールされているhttps://golang.org/[Go言語]ツールチェーン。 Go 1.6のインストール方法のガイドに従ってGoをセットアップします。 また、Goコードのコンパイル方法と、 `+ go +`コマンドラインツールの機能についてもある程度理解している必要があります。 これについては、https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04 [Building Go Executables]のガイドに従ってください。 。

ステップ1-キャディの作成

この手順では、Caddyのソースコードを取得し、コンパイルできることを確認します。 CaddyはGoで記述されているため、GitHubからCaddyのソースを取得し、 + $ GOPATH / src / github.com / mholt / caddy`に保存するには、 + go get`コマンドラインツールを使用します。

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 +`です。

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

git checkout -b "" ""

これにより、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 from Caddy!」というテキストが出力されます。

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

. . .
// Run is Caddy's main() function.
func Run() {


       flag.Parse()

       caddy.AppName = appName
       . . .
}

ファイルを保存して閉じるには、「+ CTRL + X 」、「 Y 」、次に「 ENTER 」を押します。 ` go install `および ` caddy `コマンドを再度実行すると、出力の上部にある ` Run()+`関数に追加したメッセージが表示されます。

go install github.com/mholt/caddy/caddy
caddy
Output
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のインストール

Caddyをビルドできることを確認したら、https://www.digitalocean.com/community/tutorials/systemd-essentials-working-with-services-units-and-the-journal [configureシステムの起動時にCaddyを自動的に起動できるようにするための_systemd_サービス]。 Systemdは、Linuxでプロセスを管理するための包括的なソリューションです。 Caddyには、システムがCaddyサービスの管理に使用できる「+ caddy.service」ファイルがインストールされています。 このサービスファイルは、Caddyが実行される環境についていくつかの仮定をしているので、インストールする前に変更したいことがいくつかあります。

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

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

次に、Caddyバイナリの所有権を* root ユーザーに変更します。 * root *はCaddyを所有しますが、 root アカウントでCaddyを実行しないでください。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をこれらのポートのいずれかにバインドする必要があります。 それ以外の場合、ユーザーはブラウザでサーバーのURLに特定のポート番号を追加して、提供するコンテンツを表示する必要があります。

`+ setcap `コマンドを使用すると、Caddyプロセスを* root *として実行せずに低いポートにバインドできます。 ` setcap `は、プロセスに完全なスーパーユーザー権限を与えずに特定の特権操作を実行できるようにするのに役立ちます。 ` cap_net_bind_service = + ep `は、プロセスに ` CAP_NET_BIND_SERVICE +`パーミッションを付与することを指定します。これにより、特権ポートへのバインドが可能になります。

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

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

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’s Encryptで自動TLSを有効にする方法について説明します。 その準備として、Caddyが取得するTLS証明書を格納するディレクトリを作成し、 `+ / etc / caddy +`ディレクトリと同じ所有権ルールを付与します。

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

Caddyは、要求を暗号化するために、このディレクトリに証明書を書き込み、そこから読み取ることができる必要があります。 このため、 `+ / etc / ssl / caddy +`ディレクトリのアクセス許可を変更して、* root および www-data *のみがアクセスできるようにします。

sudo chmod 0770 /etc/ssl/caddy

次に、Caddyがホストするファイルを保存するディレクトリを作成します。 `+ / var / www / +`は、HTTP経由で提供されるファイルを格納するための事実上の標準の場所です。

sudo mkdir /var/www

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

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

Caddyは + Caddyfile +`というファイルを介して設定されます。これは、Apacheの `+ httpd.conf +`またはNginxの `+ sites-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`を実行して、システムが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-キャディーの構成

Caddyインストールを機能的なWebサーバーとして使用するには、いくつかの設定を変更する必要があります。 これらの変更を行う際に、 `+ Caddyfile +`設定の構文を検討し、いくつかの設定シナリオを調べ、HTTP経由でプレースホルダーページを提供します。

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>

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

ファイルを保存して閉じ、先ほど作成した `+ Caddyfile +`設定ファイルを開きます:

sudo nano /etc/caddy/Caddyfile

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

/ etc / caddy / Caddyfile

:80 {
   root /var/www
}

最初の行では、 `:80 +`はサーバーのホスト名を設定します-Caddyではこれは_label_と呼ばれます。 ホスト名は、Caddyがリクエストに応答するドメイン名です。 この場合、サーバーのポート「:80+」を意味する「:80」に設定します。 Caddyはこれを自動的に有効にしようとしますが、プラグインを介してこれを行いたいため、これにより、サーバーが現在HTTPS経由で実行されなくなります。

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

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

/ etc / caddy / Caddyfile

:80 {
   root /var/www

}

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

/ etc / caddy / Caddyfile

:80 {
   root /var/www
   gzip



}

Caddyには、多くのユースケース向けの膨大な数の異なるディレクティブがあります。 たとえば、https://caddyserver.com/docs/fastcgi [+ fastcgi +]ディレクティブは、PHPを有効にするのに役立ちます。 https://caddyserver.com/docs/markdown [+ 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:  (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

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 "+`を追加します。 一部のプラグインには若干の設定の微調整が必​​要な場合があるため、インストールするプラグインのドキュメントを必ずお読みください。 人気のあるプラグインのリストは、https://caddyserver.com/docs [Caddy documentation]の左ペインの* Plugins *にあります。

`+ minify +`プラグインのGitHubリポジトリはhttps://github.com/hacdias/caddy-minify[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)


)

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

git config --global user.email ""
git config --global user.name ""

ユーザー名とメールアドレスを設定したら、次のコマンドを実行して、変更したファイルを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

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

}

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

sudo systemctl start caddy

Caddyは現在実行中であり、以前に作成した + index.html +`ファイルを含む、提供するファイルをすべて縮小します。 Web要求を行うためのコマンドラインツールであるcURLを使用して、職場での「縮小」を観察できます。 オプションやフラグを指定せずに `+ curl +`を実行すると、Webページのコンテンツが取得され、ターミナルに表示されます。 次のコマンドを実行して、Caddyの `+ index.html`ファイルをリクエストし、 ++ `をドメインに置き換えます。

curl http://

次の出力が表示されます。 不要なスペースがすべて削除され、 `+ minify +`プラグインが機能していることがわかります。

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

この同じインストール方法は、他のCaddyプラグインでも機能します。 安全なHTTPSトラフィックを自動的に有効にするために、 `+ tls.dns.digitalocean +`プラグインをインストールすることにより、プラグインを追加することで、さらに練習を積むことができます。

ステップ5-Let’s Encryptで自動TLSを有効にする

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

別の方法として、 + tls.dns.digitalocean + Caddyプラグインをインストールできます。これは、代わりに `+ DNS-01 +`検証メソッドを使用します。 このプラグインは、ドメインの新しい「TXT」DNSレコードを追加してLet’s Encryptで認証しますが、これはウェブサイトの機能に影響しません。 DNSを制御するためにDigitalOceanのAPIを使用します。これにより、サーバーが公開されていない場合でも証明書を取得する柔軟性が得られます。 DNSレコードのさまざまなタイプの詳細については、https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean#txt-records [はじめにDigitalOcean DNSへ]。

+ 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"

)

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タブ]に移動して、* Generate New Token *:を選択します。

image:https://assets.digitalocean.com/articles/securely_deploy_caddy_ubuntu_16_04/caddy_spaces_api.png [DigitalOcean Applications&APIページ]

トークンにわかりやすい名前(たとえば、「++」)を付け、* Write(optional)が選択されていることを確認します。 次に、 Generate Token *を押します。

image:https://assets.digitalocean.com/articles/securely_deploy_caddy_ubuntu_16_04/caddy_personal_token.png [個人アクセストークンの作成]

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

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

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

sudo systemctl daemon-reload

`+ systemctl status +`を実行して、設定の変更に問題がないことを確認します。

sudo systemctl status caddy

これにより、次のような出力が生成されます。 `+ Loaded:`で始まる行に注意してください。 ` loaded `ステータスは、サービス設定への変更が成功したことを示します。 systemdサービスの設定中にエラーが発生した場合、この行には、代わりに「 error 」ステータスとsystemdがサービスファイルを解釈できなかった理由の説明が表示されます。 ` Active:`で始まる次の行は、サービスが実行されているかどうかを示します。 このステップの早い段階でCaddyを停止したため、これは ` inactive `を表示します。 Daddyを実行すると、「 enabled」または「+ running」が表示されます。

Output● caddy.service - Caddy HTTP/2 web server
  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 `に追加し、 `+`をドメインに置き換えてください。 ホスト名のポートではなくドメインを使用すると、CaddyはHTTPS経由でリクエストを処理します。 `+ tls `ディレクティブは ` TLS `を使用する場合のCaddyの動作を設定し、 ` dns `サブディレクティブはCaddyが ` HTTP-01 `ではなく ` DNS-01 +`システムを使用することを指定します。

/ etc / caddy / Caddyfile

{
   root /var/www
   gzip
   minify



}

Webサイトを展開する準備ができました。 最初に、 `+ systemctl `でサーバーを起動してから、 ` enable +`で起動します。 これにより、Caddyが起動時に起動するように構成されます。

sudo systemctl start caddy
sudo systemctl enable caddy

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

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

ステップ6-Caddyインストールの更新

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

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

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

`+ git checkout +`を使用して、ステップ1で作成したブランチにいることを確認します。

git checkout

次に、 `+ git fetch `を使用して、リモートリポジトリから変更を取得します。 GitがCaddyリポジトリのクローンを作成すると、_upstreamリポジトリ_-変更が発生する中心的な場所へのリンクが維持されます。 Gitは上流リポジトリを ` origin +`という名前で参照するため、originから取得する必要があります。

git fetch origin

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

git tag

前と同様に、最新バージョンが見つかるまでリストを参照します。 Gitには、2つの異なるコードブランチをマージするためのツール「+ git merge」が含まれています。 次を入力して、最新バージョンからの変更を作業ブランチにマージします。 必ず「++」をブランチの名前に、バージョン番号を特定したばかりの最新のものに置き換えてください。

git merge

保存して閉じてマージを完了することができるエディターが表示されます。 ただし、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は最新バージョンに正常に更新され、少なくとも次のリリースまで中断することなく動作し続けるはずです。

結論

このチュートリアルに従うことで、Caddyを使用してWebサイトを正常にデプロイできました。 次の良いステップは、Caddyの新しいバージョンがリリースされたときに通知を受ける方法を見つけることです。 たとえば、https://github.com/mholt/caddy/releases.atom [キャディーリリースのAtomフィード]、またはhttps://about.sibbell.com/[Sibbell]などの専用サービスを使用できます。 サーバーを更新するプロセスを自動化するスクリプトを作成することもお勧めです。2つを組み合わせて、新しいリリースがあったときにCaddyを自動的に再構築するビルドツールを作成することもできます。 それ以外の場合は、https://caddyserver.com/docs [Caddy’s documentation]を調べて、ニーズに合わせてカスタマイズする最善の方法を見つけてください。

Related