LXDの初心者向けガイド：複数のWebサイトをホストするためのリバースプロキシの設定

はじめに

LXD（「Lex-Dee」と発音）は、CanonicalがサポートするLinux Containers（LXC）上に構築されたシステムコンテナーマネージャーです。 LXDの目標は、仮想マシンと同様のエクスペリエンスを提供することですが、ハードウェア仮想化ではなくコンテナー化を通じて提供します。 LXDは、アプリケーションを提供するためのDockerと比較して、スナップショット、ライブマイグレーション、ストレージ管理などの追加機能を備えたほぼ完全なオペレーティングシステム機能を提供します。

リバースプロキシは、内部アプリケーションと外部クライアントの間に位置し、クライアント要求を適切なサーバーに転送するサーバーです。 Node.jsなどの多くの一般的なアプリケーションは、それ自体でサーバーとして機能できますが、高度な負荷分散、セキュリティ、アクセラレーション機能が不足している可能性があります。

このガイドでは、それぞれが独自の追加コンテナで複数のWebサイトをホストするために、LXDコンテナでリバースプロキシを作成する方法について説明します。リバースプロキシとしてNGINXに依存しながら、NGINXおよびApacheWebサーバーを利用します。

このガイドで作成されたリバースプロキシを理解するには、次の図を参照してください。

このガイドでは、次のことを行います。

NGINXとApacheの両方のWebサーバーのコンテナーをインストールして構成します。
コンテナにリバースプロキシをインストールして設定する方法を学びます。
自動証明書更新を使用してLet’sEncrypt証明書を使用してSSL/TLSサポートを取得します。
一般的なエラーのトラブルシューティング。

注簡単にするために、コンテナという用語このガイド全体で、LXDシステムコンテナを説明するために使用されます。

始める前に

CompleteA LXDビギナーズガイド：コンテナ内でのApacheWebサーバーのセットアップ。このガイドでは、webというコンテナを作成するように指示されていますテスト目的でApacheWebサーバーを使用します。次のコマンドを実行して、このコンテナを削除します。
```
lxc stop web
lxc delete web
```
注
このガイドでは、LXDバージョン3.3以降が必要です。次のコマンドでバージョンを確認します。
```
lxd --version
```
バージョンが3.3以降でない場合は、LXDビギナーズガイド：コンテナでのApache Webサーバーのセットアップの手順に従って、スナップパッケージをインストールし、次のコマンドを使用して最新バージョンに更新します。
```
sudo lxd.migrate
```
このガイドでは、ホスト名apache1.example.comを使用しますおよびnginx1.example.com 2つのサンプルWebサイトの場合。これらの名前を所有しているホスト名に置き換え、作成したサーバーのIPアドレスを指すようにDNSエントリを設定します。 DNSのヘルプについては、DNSマネージャーガイドを参照してください。

コンテナの作成

apache1という2つのコンテナを作成しますおよびnginx1 、1つはApache Webサーバーを使用し、もう1つはNGINXWebサーバーを使用します。追加のWebサイトについては、選択したWebサーバーソフトウェアを使用して新しいコンテナを作成できます。
```
lxc launch ubuntu:18.04 apache1
lxc launch ubuntu:18.04 nginx1
```
proxyを作成しますリバースプロキシのコンテナ。
```
lxc launch ubuntu:18.04 proxy
```
listコマンドを使用してコンテナを一覧表示します。
```
lxc list
```

出力は次のようになります。

+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
|  NAME   |  STATE  |        IPV4         |                     IPV6                      |    TYPE    | SNAPSHOTS |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| apache1 | RUNNING | 10.10.10.204 (eth0) | fd42:67a4:b462:6ae2:216:3eff:fe01:1a4e (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| nginx1  | RUNNING | 10.10.10.251 (eth0) | fd42:67a4:b462:6ae2:216:3eff:febd:67e3 (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+
| proxy   | RUNNING | 10.10.10.28 (eth0)  | fd42:67a4:b462:6ae2:216:3eff:fe00:252e (eth0) | PERSISTENT |           |
+---------+---------+---------------------+-----------------------------------------------+------------+-----------+

3つのコンテナがあり、すべて RUNNING 状態–それぞれに独自のプライベートIPアドレスがあります。コンテナproxyのIPアドレス（IPv4とIPv6の両方）をメモします。 proxyを設定するためにそれらが必要になります後のセクションのコンテナ。

コンテナが作成されたので、次の手順では、apache1でWebサーバーソフトウェアを設定する方法について詳しく説明します。およびnginx1 コンテナ、およびproxy インターネットからWebサーバーにアクセスできるようにするためのコンテナ。

ApacheWebサーバーコンテナの設定

Webサーバーの前でリバースプロキシを使用する場合、Webサーバーは訪問者のIPアドレスを認識しません。 Webサーバーは、リバースプロキシのIPアドレスのみを認識します。ただし、各Webサーバーには、訪問者の実際のリモートIPアドレスを識別する方法があります。 Apacheの場合、これはリモートIPApacheモジュールを使用して実行されます。モジュールが機能するには、リモートIPアドレスの情報を渡すようにリバースプロキシを構成する必要があります。

apache1でシェルを起動しますコンテナ。
```
lxc exec apache1 -- sudo --user ubuntu --login
```
apache1のパッケージリストを更新しますコンテナ。
```
sudo apt update
```
パッケージをインストールしますapache2 コンテナ内。
```
sudo apt install -y apache2
```
ファイル/etc/apache2/conf-available/remoteip.confを作成します。
ファイル：remoteip .conf
1 2

RemoteIPHeader X-Real-IP RemoteIPTrustedProxy 10.10.10.28 fd42:67a4:b462:6ae2:216:3eff:fe00:252e
nanoを使用できますコマンドsudo nano /etc/apache2/conf-available/remoteip.confを実行してテキストエディタ。これらはproxyのIPアドレスであることに注意してください IPv4とIPv6の両方について、前に示したコンテナ。これらをlxc listのIPに置き換えます出力。

注 IPアドレスを指定する代わりに、ホスト名proxy.lxdを使用することもできます。。ただし、RemoteIP Apacheモジュールは、ホスト名を使用する場合に特有であり、2つのIPアドレス（IPv4またはIPv6）のいずれか1つのみを使用します。つまり、ApacheWebサーバーは一部の接続の実際の送信元IPアドレスを認識しません。 IPv4アドレスとIPv6アドレスの両方を明示的にリストすることにより、RemoteIPがリバースプロキシのすべての接続からソースIP情報を正常に受け入れることを確認できます。

新しいremoteip.confを有効にします構成。

 sudo a2enconf remoteip

Enabling conf remoteip.
To activate the new configuration, you need to run:
systemctl reload apache2

remoteipを有効にします Apacheモジュール。

 sudo a2enmod remoteip

Enabling module remoteip.
To activate the new configuration, you need to run:
systemctl restart apache2

ApacheのデフォルトのWebページを編集して、LXDコンテナ内で実行される参照を作成します。
```
 sudo nano /var/www/html/index.html
```
「動作します！」という行を変更します。（行番号224）から「LXDコンテナ内で動作します！」保存して終了します。
ApacheWebサーバーを再起動します。
```
 sudo systemctl reload apache2
```
終了してホストに戻ります。
```
 exit
```

Apache Webサーバーを作成して構成しましたが、サーバーにはまだインターネットからアクセスできません。 proxyを設定するとアクセス可能になります後のセクションのコンテナ。

NGINXWebサーバーコンテナの作成

Apacheと同様に、NGINXは、Webサーバーの前でリバースプロキシを使用する場合、訪問者のIPアドレスを認識しません。代わりに、リバースプロキシのIPアドレスのみが表示されます。各NGINXWebサーバーソフトウェアは、RealIPモジュールを使用して訪問者の実際のリモートIPアドレスを識別できます。モジュールが機能するには、リモートIPアドレスに関する情報を渡すようにリバースプロキシを適切に構成する必要があります。

nginx1でシェルを起動しますコンテナ。
```
lxc exec nginx1 -- sudo --user ubuntu --login
```
nginx1のパッケージリストを更新しますコンテナ。
```
sudo apt update
```
NGINXをインストールしますコンテナ内。
```
sudo apt install -y nginx
```
ファイル/etc/nginx/conf.d/real-ip.confを作成します。
ファイル：実数-ip.conf
1 2

real_ip_header X-Real-IP; set_real_ip_from proxy.lxd;
nanoを使用できますコマンドsudo nano /etc/nginx/conf.d/real-ip.confを実行してテキストエディタ。

注リバースプロキシのホスト名proxy.lxdを指定しました。各LXDコンテナは、コンテナの名前にサフィックス.lxdを加えたホスト名を自動的に取得します。。 set_real_ip_fromを指定する proxy.lxdのフィールド、接続がproxy.lxdから発信されている限り、各接続の実際のIPアドレス情報を受け入れるようにNGINXWebサーバーに指示しています。。実際のIPアドレス情報は、HTTPヘッダーX-Real-IPにあります。各接続で。
NGINXのデフォルトのWebページを編集して、LXDコンテナー内で実行される参照を作成します。
```
 sudo nano /var/www/html/index.nginx-debian.html
```
「Welcometonginx！」の行を変更します。（行番号14）「LXDシステムコンテナで実行されているnginxへようこそ！」保存して終了します。
NGINXWebサーバーを再起動します。
```
sudo systemctl reload nginx
```
終了してホストに戻ります。
```
 exit
```

NGINX Webサーバーを作成して構成しましたが、インターネットからサーバーにまだアクセスできません。 proxyを設定するとアクセス可能になります次のセクションのコンテナ。

リバースプロキシの設定

このセクションでは、コンテナのproxyを設定します。 NGINXをインストールしてリバースプロキシとして設定してから、適切なLXDプロキシデバイスを追加しますポート80と443の両方をインターネットに公開するため。

LXDプロキシデバイスを追加しますインターネットからサーバー上のポート80（HTTP）および443（HTTPS）への接続を、proxyのそれぞれのポートにリダイレクトします。コンテナ。

 lxc config device add proxy myport80 proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80 proxy_protocol=true
 lxc config device add proxy myport443 proxy listen=tcp:0.0.0.0:443 connect=tcp:127.0.0.1:443 proxy_protocol=true

Device myport80 added to proxy
Device myport443 added to proxy

lxc config device add コマンドは引数を取ります：

引数	説明
`proxy`	コンテナの名前。
`myport80`	このプロキシデバイスの名前。
`proxy`	LXDデバイスのタイプ（LXDプロキシデバイス）。
`listen=tcp:0.0.0.0:80`	プロキシデバイスは、ホスト（デフォルト）のポート80、プロトコルTCP、すべてのインターフェイスでリッスンします。
`connect=tcp:127.0.0.1:80`	プロキシデバイスは、ループバックインターフェイスのポート80、プロトコルTCPでコンテナに接続します。以前のバージョンのLXDでは、`localhost`を指定できました。ここ。ただし、LXD 3.13以降では、IPアドレスのみを指定できます。
`proxy_protocol=true`	リバースプロキシがプロキシデバイスから発信元IPアドレスを取得できるように、PROXYプロトコルを有効にするように要求します。

注
プロキシデバイスを削除する場合は、lxc config device removeを使用します。上記のデバイスを削除する場合myport80 、次のコマンドを実行します：

lxc config device remove proxy myport80

ここで、proxyはコンテナの名前であり、myport80はデバイスの名前です。

proxyでシェルを起動しますコンテナ。
```
lxc exec proxy -- sudo --user ubuntu --login
```
パッケージリストを更新します。
```
sudo apt update
```
コンテナにNGINXをインストールします。
```
sudo apt install -y nginx
```
コンテナからログアウトします。
```
logout
```

リバースプロキシからApacheWebサーバーへの直接トラフィック

リバースプロキシコンテナが実行されており、NGINXパッケージがインストールされています。リバースプロキシとして機能するには、適切なWebサイト構成を追加して、NGINXが（server_nameを使用して）識別できるようにします。以下）適切なホスト名を指定してから、（proxy_passを使用して）渡します以下）適切なLXDコンテナへの接続。

proxyでシェルを起動しますコンテナ。
```
lxc exec proxy -- sudo --user ubuntu --login
```

ファイルapache1.example.comを作成します /etc/nginx/sites-available/にあります最初のWebサイトの構成用。

ファイル：apache1 .example.com

server {
        listen 80 proxy_protocol;
        listen [::]:80 proxy_protocol;

        server_name apache1.example.com;

        location / {
                include /etc/nginx/proxy_params;

                proxy_pass http://apache1.lxd;
        }

        real_ip_header proxy_protocol;
        set_real_ip_from 127.0.0.1;
}

sudo nano /etc/nginx/sites-available/apache1.example.comを実行できますテキストエディタを開き、構成を追加します。この場合、編集する必要があるのはserver_nameだけであることに注意してください。 Webサイトのホスト名になります。

Webサイトを有効にします。

sudo ln -s /etc/nginx/sites-available/apache1.example.com /etc/nginx/sites-enabled/

NGINXリバースプロキシを再起動します。サービスを再起動することで、NGINXは/etc/nginx/sites-enabledに追加されたばかりの新しいサイトの指示を読み取って適用します。
```
sudo systemctl reload nginx
```
プロキシコンテナを終了し、ホストに戻ります。
```
logout
```
ローカルコンピュータから、Webブラウザを使用してWebサイトのURLにアクセスします。デフォルトのApacheページが表示されます：

注 Apache access.logファイル（デフォルトファイル/var/log/apache2/access.log）を見ると）、proxyのプライベートIPアドレスは引き続き表示されます実際のIPアドレスの代わりにコンテナ。この問題はApacheWebサーバーに固有であり、サーバーがログを印刷する方法に関係しています。 Webサーバー上の他のソフトウェアは、実際のIPを使用できます。 Apacheログでこれを修正するには、トラブルシューティングのセクションを参照してください。

リバースプロキシからNGINXWebサーバーへの直接トラフィック

リバースプロキシコンテナが実行されており、NGINX パッケージがインストールされました。リバースプロキシとして機能するには、適切なWebサイト構成を追加して、NGINXを追加する必要があります。識別できます（server_nameを使用）以下）適切なホスト名を指定してから、（proxy_passを使用して）渡します以下）実際のWebサーバーソフトウェアを使用した適切なLXDコンテナへの接続。

proxyでシェルを起動しますコンテナ。
```
lxc exec proxy -- sudo --user ubuntu --login
```

ファイルnginx1.example.comを作成します /etc/nginx/sites-available/にあります 2番目のWebサイトの構成用。

ファイル：nginx1 .example.com

server {
        listen 80 proxy_protocol;
        listen [::]:80 proxy_protocol;

        server_name nginx1.example.com;

        location / {
                include /etc/nginx/proxy_params;

                proxy_pass http://nginx1.lxd;
        }

        real_ip_header proxy_protocol;
        set_real_ip_from 127.0.0.1;
}

sudo nano /etc/nginx/sites-available/nginx1.example.comを実行できます構成を作成します。 server_nameフィールドのみを編集する必要があることに注意してください。 Webサイトのホスト名になります。

Webサイトを有効にします。

sudo ln -s /etc/nginx/sites-available/nginx1.example.com /etc/nginx/sites-enabled/

NGINXリバースプロキシサービスを再起動します。
```
sudo systemctl reload nginx
```
プロキシコンテナを終了し、ホストに戻ります。
```
logout
```
ローカルコンピュータから、Webブラウザを使用してWebサイトのURLにアクセスします。次のデフォルトのNGINXページが表示されます。

Let’sEncryptを使用したHTTPSのサポートの追加

proxyでシェルを起動しますコンテナ。
```
lxc exec proxy -- sudo --user ubuntu --login
```
リポジトリを追加しますppa:certbot/certbot 次のコマンドを実行します。
```
sudo add-apt-repository ppa:certbot/certbot
```

出力は次のようになります。

This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s).
      More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot
     Press [ENTER] to continue or Ctrl-c to cancel adding it.

     Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
     ...
     Fetched 3360 kB in 2s (2018 kB/s)
     Reading package lists... Done

次の2つのパッケージをインストールして、a）Let’sEncrypt証明書の作成をサポートします。 b）Let’sEncrypt証明書を使用するようにNGINXリバースプロキシを自動構成します。パッケージは、新しく作成されたリポジトリから取得されます。
```
sudo apt-get install certbot python-certbot-nginx
```
注これにより、リバースプロキシがTLSターミネーションプロキシとしても機能するように構成されます。。 HTTPS構成は、proxyでのみ見つかります容器。そうすることで、証明書とLet’sEncryptに関連するWebサーバーコンテナ内のタスクを実行する必要がなくなります。

certbotを実行します --nginxを使用してルートとして最初のWebサイトのLet’sEncryptの自動構成を実行するためのパラメーター。緊急の更新およびセキュリティ通知のために、有効な電子メールアドレスを提供するように求められます。次に、利用規約に同意し、将来的に電子フロンティア財団からの連絡を希望するかどうかを尋ねられます。次に、HTTPSをアクティブ化するWebサイトを提供します。最後に、HTTP接続をHTTPS接続に自動的にリダイレクトする機能を設定することを選択できます。

sudo certbot --nginx

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): [email protected]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: apache1.example.com
2: nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for apache1.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/apache1.example.com

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/apache1.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://apache1.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=apache1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/apache1.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/apache1.example.com/privkey.pem
   Your cert will expire on 2019-10-07. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

certbotを実行します --nginxを使用してルートとして 2番目のWebサイトのLet’sEncryptの自動構成を実行するためのパラメーター。 certbotを実行するのはこれが2回目ですしたがって、構成するWebサイトを直接選択するように求められます。

sudo certbot --nginx

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: apache1.example.com
2: nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 2
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for nginx1.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/nginx1.example.com

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/nginx1.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://nginx1.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=nginx1.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/nginx1.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/nginx1.example.com/privkey.pem
   Your cert will expire on 2019-10-07. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

すべてのWebサイトを追加した後、証明書の更新をテストするためにドライランを実行します。自動化された機能がそれ以上の努力なしに証明書を更新したことを確認するために、すべてのWebサイトが正常に更新されていることを確認してください。

sudo certbot renew --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/apache1.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for apache1.example.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/apache1.example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/nginx1.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for nginx1.example.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/nginx1.example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/apache1.example.com/fullchain.pem (success)
  /etc/letsencrypt/live/nginx1.example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

注 certbot パッケージはsystemdタイマーを追加します Let’sEncrypt証明書の自動更新をアクティブ化するため。 systemctl list-timersを実行すると、このタイマーの詳細を表示できます。。

certbotツールは、WebサイトのNGINX構成ファイルを編集および変更します。そうすることで、certbotは最初のlistenに従わなくなりますディレクティブ（listen 80 proxy_protocol; ）、proxy_protocolを追加しません新しく追加されたlisten 443 ssl;のパラメータ行。各Webサイトの構成ファイルを編集し、各「listen443ssl;」に「proxy_protocol」を追加する必要があります。行。
```
 sudo nano /etc/nginx/sites-enabled/apache1.example.com
 sudo nano /etc/nginx/sites-enabled/nginx1.example.com
```
```
listen 443 ssl proxy_protocol; # managed by Certbot
listen [::]:443 ssl proxy_protocol; # managed by Certbot
```
注各Webサイト構成ファイルには、2組のlistenがあります。ディレクティブ：それぞれHTTPとHTTPS。 1つ目は、前のセクションで追加されたHTTPの元のペアです。 2番目のペアは、HTTPS用のcertbotによって追加されました。これらは、IPv4とIPv6の両方をカバーしているため、ペアです。表記[::] IPv6を指します。パラメータproxy_protocolを追加する場合、;の前に追加します上記のように各行に。
NGINXを再起動します。
```
sudo systemctl restart nginx
```

Troubleshooting

Browser Error “SSL_ERROR_RX_RECORD_TOO_LONG”

You have configured Certbot and created the appropriate Let’s Encrypt configuration for each website. But when you access the website from your browser, you get the following error.

Secure Connection Failed

An error occurred during a connection to apache1.example.com. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

This error is caused when the NGINX reverse proxy in the proxy container does not have the proxy_protocol parameter in the listen 443 ディレクティブ。 Without the parameter, the reverse proxy does not consume the PROXY protocol information before it performs the HTTPS work. It mistakenly passes the PROXY protocol information to the HTTPS module, hence the record too long error.

Follow the instructions in the previous section and add proxy_protocol to all listen 443 ディレクティブ。 Finally, restart NGINX.

Error “Unable to connect” or “This site can’t be reached”

When you attempt to connect to the website from your local computer and receive Unable to connect or This site can’t be reached errors, it is likely the proxy devices have not been configured.

Run the following command on the host to verify whether LXD is listening and is able to accept connections to ports 80 (HTTP) and 443 (HTTPS).

sudo ss -ltp '( sport = :http || sport = :https )'

注
The ss command is similar to netstat and lsof 。 It shows information about network connections. In this case, we use it to verify whether there is a service on ports 80 and 443, and which service it is.

-l , to display the listening sockets,

-t , to display only TCP sockets,

-p , to show which processes use those sockets,

( sport = :http || sport = :https ) , to show only ports 80 and 443 (HTTP and HTTPS, respectively).

In the following output we can verify that both ports 80 and 443 (HTTP and HTTPS, respectively) are in the LISTEN 州。 In the last column we verify that the process listening is lxd itself.

State     Recv-Q  Send-Q   Local Address:Port   Peer Address:Port
LISTEN    0       128                  *:http              *:*       users:(("lxd",pid=1301,fd=7),("lxd",pid=1301,fd=5))
LISTEN    0       128                  *:https             *:*       users:(("lxd",pid=1349,fd=7),("lxd",pid=1349,fd=5))

If you see a process listed other than lxd , stop that service and restart the proxy container. By restarting the proxy container, LXD applies the proxy devices again.

The Apache access.log Shows the IP Address of the Proxy Container

You have set up the apache1 container and verified that it is accessible from the internet. But the logs at /var/log/apache2/access.log still show the private IP address of the proxy container, either the private IPv4 (10.x.x.x ) or the private IPv6 addresses. What went wrong?

The default log formats for printing access logs in Apache only print the IP address of the host of the last hop (i.e. the proxy server). This is the %h format specifier as shown below.

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common

The %h must be manually replaced with the %a format specifier, which prints the value as returned by the real RemoteIP Apache module.

LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common

Run the following command in the apache1 container to edit the configuration file httpd.conf and perform the change from %h to %a 。
```
sudo nano /etc/apache2/apache2.conf
```
Reload the Apache web server service.
```
 sudo systemctl reload apache2
```

Next Steps

You have set up a reverse proxy to host many websites on the same server and installed each website in a separate container. You can install static or dynamic websites in the containers. For dynamic websites, you may need additional configuration; check the respective documentation for setup using a reverse proxy. In addition, you may also use NGINX as a reverse proxy for non-HTTP(S) services.

詳細情報

このトピックの詳細については、次のリソースを参照してください。これらは有用であることを期待して提供されていますが、外部でホストされている資料の正確性や適時性を保証することはできません。

LXD Introduction
LXD support community
Try LXD Online
NGINX Web Server
Apache Web Server
NGINX Reverse Proxy Settings
Proxy Protocol
TLS Termination Proxy