GNU/Linux >> Tutoriels Linux >  >> Panels >> Docker

Un guide pour débutants sur LXD :Configuration d'un proxy inverse pour héberger plusieurs sites Web

Introduction

LXD (prononcé « Lex-Dee ») est un gestionnaire de conteneurs système construit au-dessus des conteneurs Linux (LXC) pris en charge par Canonical. L'objectif de LXD est de fournir une expérience similaire à une machine virtuelle mais via la conteneurisation plutôt que la virtualisation matérielle. Comparé à Docker pour la livraison d'applications, LXD offre une fonctionnalité de système d'exploitation presque complète avec des fonctionnalités supplémentaires telles que des instantanés, des migrations en direct et la gestion du stockage.

Un proxy inverse est un serveur situé entre les applications internes et les clients externes, transmettant les demandes des clients au serveur approprié. Alors que de nombreuses applications courantes, telles que Node.js, peuvent fonctionner comme des serveurs par elles-mêmes, il se peut qu'elles manquent d'un certain nombre de fonctionnalités avancées d'équilibrage de charge, de sécurité et d'accélération.

Ce guide explique la création d'un proxy inverse dans un conteneur LXD afin d'héberger plusieurs sites Web, chacun dans leurs propres conteneurs supplémentaires. Vous utiliserez les serveurs Web NGINX et Apache, tout en vous appuyant également sur NGINX en tant que proxy inverse.

Veuillez vous référer au schéma suivant pour comprendre le proxy inverse créé dans ce guide.

Dans ce guide, vous allez :

  • Installez et configurez des conteneurs pour les serveurs Web NGINX et Apache.

  • Découvrez comment installer et configurer un proxy inverse dans un conteneur.

  • Bénéficiez de la prise en charge SSL/TLS via les certificats Let's Encrypt avec renouvellement automatisé des certificats.

  • Dépannage des erreurs courantes.

Remarque Pour simplifier, le terme conteneur est utilisé tout au long de ce guide pour décrire les conteneurs du système LXD.

Avant de commencer

  1. CompleteA Beginner's Guide to LXD:Setting Up an Apache Web Server In a Container. Le guide vous demande de créer un conteneur appelé web avec le serveur Web Apache à des fins de test. Supprimez ce conteneur en exécutant les commandes suivantes.

    lxc stop web
lxc delete web
    Remarque

    Pour ce guide, LXD version 3.3 ou ultérieure est nécessaire. Vérifiez la version avec la commande suivante :

    lxd --version

    Si la version n'est pas 3.3 ou ultérieure, mettez à jour vers la dernière version en installant le package snap comme indiqué dansA Beginner's Guide to LXD:Setting Up an Apache Webserver In a Container et utilisez la commande suivante :

    sudo lxd.migrate

  2. Ce guide utilise les noms d'hôtes apache1.example.com et nginx1.example.com pour les deux exemples de sites Web. Remplacez ces noms par des noms d'hôte que vous possédez et configurez leurs entrées DNS pour qu'elles pointent vers l'adresse IP du serveur que vous avez créé. Pour obtenir de l'aide sur le DNS, consultez notre Guide du gestionnaire DNS.

Création des conteneurs

  1. Créez deux conteneurs appelés apache1 et nginx1 , un avec le serveur Web Apache et un autre avec le serveur Web NGINX, respectivement. Pour tout site Web supplémentaire, vous pouvez créer de nouveaux conteneurs avec le logiciel de serveur Web de votre choix.

    lxc launch ubuntu:18.04 apache1
lxc launch ubuntu:18.04 nginx1

  2. Créer le proxy conteneur pour le proxy inverse.

    lxc launch ubuntu:18.04 proxy

  3. Listez les conteneurs avec la commande list.

    lxc list

  4. La sortie ressemble à ce qui suit.

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

    Il y a trois conteneurs, tous dans le RUNNING état - chacun avec sa propre adresse IP privée. Prenez note des adresses IP (à la fois IPv4 et IPv6) pour le conteneur proxy . Vous en aurez besoin pour configurer le proxy conteneur dans une section ultérieure.

    Maintenant que les conteneurs ont été créés, les étapes suivantes détaillent comment configurer le logiciel du serveur Web dans apache1 et nginx1 conteneurs et le proxy conteneur afin que les serveurs Web soient accessibles depuis Internet.

Configuration du conteneur de serveur Web Apache

Lors de l'utilisation d'un proxy inverse devant un serveur Web, le serveur Web ne connaît pas les adresses IP des visiteurs. Le serveur Web ne voit que l'adresse IP du proxy inverse. Cependant, chaque serveur Web a un moyen d'identifier la véritable adresse IP distante d'un visiteur. Pour Apache, ceci est réalisé avec le module Remote IP Apache. Pour que le module fonctionne, le proxy inverse doit être configuré pour transmettre les informations de l'adresse IP distante.

  1. Démarrer un shell dans apache1 conteneur.

    lxc exec apache1 -- sudo --user ubuntu --login

  2. Mettre à jour la liste des packages dans apache1 conteneur.

    sudo apt update

  3. Installez le paquet apache2 dans le conteneur.

    sudo apt install -y apache2

  4. Créez le fichier /etc/apache2/conf-available/remoteip.conf .

    Fichier :remoteip .conf
    1
2

    RemoteIPHeader X-Real-IP
RemoteIPTrustedProxy 10.10.10.28 fd42:67a4:b462:6ae2:216:3eff:fe00:252e

    Vous pouvez utiliser le nano éditeur de texte en exécutant la commande sudo nano /etc/apache2/conf-available/remoteip.conf . Attention, il s'agit des adresses IP du proxy conteneur illustré précédemment, à la fois pour IPv4 et IPv6. Remplacez-les par les IP de votre lxc list sortie.

    Remarque Au lieu de spécifier les adresses IP, vous pouvez également utiliser le nom d'hôte proxy.lxd . Cependant, le module RemoteIP Apache est particulier lorsqu'il utilise le nom d'hôte et n'utilise qu'une des deux adresses IP (IPv4 ou IPv6), ce qui signifie que le serveur Web Apache ne connaît pas la véritable adresse IP source pour certaines connexions. En répertoriant explicitement les adresses IPv4 et IPv6, vous pouvez être certain que RemoteIP accepte avec succès les informations IP source de toutes les connexions du proxy inverse.

  5. Activez le nouveau remoteip.conf configuration.

     sudo a2enconf remoteip

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

  6. Activer le remoteip Module Apache.

     sudo a2enmod remoteip

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

  7. Modifiez la page Web par défaut d'Apache pour indiquer qu'il s'exécute dans un conteneur LXD.

     sudo nano /var/www/html/index.html

    Changez la ligne "Ça marche !" (numéro de ligne 224) à "Cela fonctionne à l'intérieur d'un conteneur LXD !" Enregistrez et quittez.

  8. Redémarrez le serveur Web Apache.

     sudo systemctl reload apache2

  9. Revenez à l'hôte.

     exit

Vous avez créé et configuré le serveur Web Apache, mais le serveur n'est pas encore accessible depuis Internet. Il devient accessible après avoir configuré le proxy conteneur dans une section ultérieure.

Création du conteneur de serveur Web NGINX

Comme Apache, NGINX ne connaît pas les adresses IP des visiteurs lorsqu'il utilise un proxy inverse devant un serveur Web. Il ne voit que l'adresse IP du proxy inverse à la place. Chaque logiciel de serveur Web NGINX peut identifier la véritable adresse IP distante d'un visiteur grâce au module Real IP. Pour que le module fonctionne, le proxy inverse doit être configuré en conséquence pour transmettre les informations concernant les adresses IP distantes.

  1. Démarrer un shell dans le nginx1 conteneur.

    lxc exec nginx1 -- sudo --user ubuntu --login

  2. Mettre à jour la liste des packages dans le nginx1 conteneur.

    sudo apt update

  3. Installez NGINX dans le conteneur.

    sudo apt install -y nginx

  4. Créez le fichier /etc/nginx/conf.d/real-ip.conf .

    Fichier :réel -ip.conf
    1
2

    real_ip_header    X-Real-IP;
set_real_ip_from  proxy.lxd;

    Vous pouvez utiliser le nano éditeur de texte en exécutant la commande sudo nano /etc/nginx/conf.d/real-ip.conf .

    Remarque Vous avez spécifié le nom d'hôte du proxy inverse, proxy.lxd . Chaque conteneur LXD obtient automatiquement un nom d'hôte, qui est le nom du conteneur plus le suffixe .lxd . En spécifiant le set_real_ip_from champ avec proxy.lxd , vous demandez au serveur Web NGINX d'accepter les informations d'adresse IP réelle pour chaque connexion, tant que cette connexion provient de proxy.lxd . Les informations d'adresse IP réelle se trouvent dans l'en-tête HTTP X-Real-IP dans chaque connexion.

  5. Modifiez la page Web par défaut de NGINX pour indiquer qu'il s'exécute dans un conteneur LXD.

     sudo nano /var/www/html/index.nginx-debian.html

    Changez la ligne « Bienvenue dans nginx ! » (ligne numéro 14) à "Bienvenue dans nginx exécuté dans un conteneur système LXD !". Enregistrez et quittez.

  6. Redémarrez le serveur Web NGINX.

     sudo systemctl reload nginx

  7. Revenez à l'hôte.

     exit

Vous avez créé et configuré le serveur Web NGINX, mais le serveur n'est pas encore accessible depuis Internet. Il devient accessible après avoir configuré le proxy conteneur dans la section suivante.

Configuration du proxy inverse

Dans cette section, vous allez configurer le conteneur proxy . Vous allez installer NGINX et le configurer en tant que proxy inverse, puis ajouter le périphérique proxy LXD approprié. afin d'exposer les ports 80 et 443 à Internet.

  1. Ajouter des périphériques proxy LXD pour rediriger les connexions d'Internet vers les ports 80 (HTTP) et 443 (HTTPS) du serveur vers les ports respectifs du proxy conteneur.

     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

    Le lxc config device add la commande prend comme arguments :

    Argument Explication
    proxy Le nom du conteneur.
    myport80 Un nom pour ce périphérique proxy.
    proxy Le type de périphérique LXD (LXD proxy appareil).
    listen=tcp:0.0.0.0:80 Le périphérique proxy écoute sur l'hôte (par défaut) sur le port 80, protocole TCP, sur toutes les interfaces.
    connect=tcp:127.0.0.1:80 Le périphérique proxy se connecte au conteneur sur le port 80, protocole TCP, sur l'interface de bouclage. Dans les versions précédentes de LXD, vous auriez pu spécifier localhost ici. Cependant, dans LXD 3.13 ou plus récent, vous ne pouvez spécifier que des adresses IP.
    proxy_protocol=true Demande d'activation du protocole PROXY afin que le proxy inverse obtienne l'adresse IP d'origine du périphérique proxy.
    Remarque

    Si vous souhaitez supprimer un périphérique proxy, utilisez lxc config device remove . Si vous souhaitez supprimer l'appareil ci-dessus myport80 , exécutez la commande suivante :

    lxc config device remove proxy myport80

    Où proxy est le nom du conteneur et myport80 est le nom de l'appareil.

  2. Démarrer un shell dans le proxy conteneur.

    lxc exec proxy -- sudo --user ubuntu --login

  3. Mettre à jour la liste des packages.

    sudo apt update

  4. Installez NGINX dans le conteneur.

    sudo apt install -y nginx

  5. Déconnectez-vous du conteneur.

    logout

Trafic direct vers le serveur Web Apache à partir du proxy inverse

Le conteneur de proxy inverse est en cours d'exécution et le package NGINX a été installé. Pour fonctionner en tant que proxy inverse, ajoutez la configuration de site Web appropriée afin que NGINX puisse identifier (avec server_name ci-dessous) le nom d'hôte approprié, puis passez (avec proxy_pass ci-dessous) la connexion au conteneur LXD approprié.

  1. Démarrer un shell dans le proxy conteneur.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Créez le fichier apache1.example.com dans /etc/nginx/sites-available/ pour la configuration de votre premier site web.

    Fichier :apache1 .exemple.com
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

    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;
}

    Vous pouvez exécuter sudo nano /etc/nginx/sites-available/apache1.example.com pour ouvrir un éditeur de texte et ajouter la configuration. Remarque, dans ce cas, il vous suffit de modifier le server_name être le nom d'hôte du site Web.

  3. Activer le site Web.

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

  4. Redémarrez le proxy inverse NGINX. En redémarrant le service, NGINX lit et applique les nouvelles instructions du site qui viennent d'être ajoutées à /etc/nginx/sites-enabled .

    sudo systemctl reload nginx

  5. Quittez le conteneur proxy et revenez à l'hôte.

    logout

  6. Depuis votre ordinateur local, visitez l'URL de votre site Web avec votre navigateur Web. Vous devriez voir la page Apache par défaut :

    Remarque Si vous regardez le fichier Apache access.log (fichier par défaut /var/log/apache2/access.log ), il affiche toujours l'adresse IP privée du proxy conteneur au lieu de la véritable adresse IP. Ce problème est spécifique au serveur Web Apache et concerne la manière dont le serveur imprime les journaux. D'autres logiciels sur le serveur Web peuvent utiliser la véritable adresse IP. Pour résoudre ce problème via les journaux Apache, consultez la section Dépannage.

Trafic direct vers le serveur Web NGINX à partir du proxy inverse

Le conteneur de proxy inverse est en cours d'exécution et le NGINX package a été installé. Pour fonctionner en tant que proxy inverse, vous devez ajouter la configuration de site Web appropriée afin que NGINX peut identifier (avec server_name ci-dessous) le nom d'hôte approprié, puis passez (avec proxy_pass ci-dessous) la connexion au conteneur LXD approprié avec le logiciel de serveur Web réel.

  1. Démarrer un shell dans le proxy conteneur.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Créez le fichier nginx1.example.com dans /etc/nginx/sites-available/ pour la configuration de votre deuxième site Web.

    Fichier :nginx1 .exemple.com
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

    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;
}

    Vous pouvez exécuter sudo nano /etc/nginx/sites-available/nginx1.example.com pour créer la configuration. Remarque, vous n'avez qu'à modifier les champs server_name être le nom d'hôte du site Web.

  3. Activer le site Web.

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

  4. Redémarrez le service de proxy inverse NGINX.

    sudo systemctl reload nginx

  5. Quittez le conteneur proxy et revenez à l'hôte.

    logout

  6. Depuis votre ordinateur local, visitez l'URL de votre site Web avec votre navigateur Web. Vous devriez voir la page NGINX par défaut suivante.

Ajout de la prise en charge de HTTPS avec Let's Encrypt

  1. Démarrer un shell dans le proxy conteneur.

    lxc exec proxy -- sudo --user ubuntu --login

  2. Ajouter le référentiel ppa:certbot/certbot en exécutant la commande suivante.

    sudo add-apt-repository ppa:certbot/certbot

  3. La sortie ressemble à ce qui suit.

    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

  4. Installez les deux packages suivants pour a) prendre en charge la création de certificats Let's Encrypt ; et b) configurer automatiquement le proxy inverse NGINX pour utiliser les certificats Let's Encrypt. Les packages sont extraits du référentiel nouvellement créé.

    sudo apt-get install certbot python-certbot-nginx
    Remarque Cela configure le proxy inverse pour qu'il agisse également en tant que proxy de terminaison TLS . Toute configuration HTTPS se trouve uniquement dans le proxy récipient. Ce faisant, il n'est pas nécessaire d'effectuer de tâches à l'intérieur des conteneurs du serveur Web concernant les certificats et Let's Encrypt.

  5. Exécutez certbot en tant que root avec le --nginx paramètre afin d'effectuer l'auto-configuration de Let's Encrypt pour le premier site web. Il vous est demandé de fournir une adresse e-mail valide pour les renouvellements urgents et les avis de sécurité. Vous êtes ensuite invité à accepter les conditions d'utilisation et à indiquer si vous souhaitez être contacté par l'Electronic Frontier Foundation à l'avenir. Ensuite, indiquez le site Web pour lequel vous activez HTTPS. Enfin, vous pouvez choisir de configurer une installation qui redirige automatiquement les connexions HTTP vers les connexions 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

  6. Exécutez certbot en tant que root avec le --nginx paramètre afin d'effectuer l'auto-configuration de Let's Encrypt pour le deuxième site Web. C'est la deuxième fois que nous exécutons certbot , on nous demande donc directement de sélectionner le site web à configurer.

    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

  7. Après avoir ajouté tous les sites Web, effectuez un essai afin de tester le renouvellement des certificats. Vérifiez que tous les sites Web se mettent à jour avec succès pour vous assurer que l'installation automatisée a mis à jour les certificats sans autre effort.

    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.
    Remarque Le certbot le paquet ajoute un temporisateur systemd afin d'activer le renouvellement automatique des certificats Let's Encrypt. Vous pouvez afficher les détails de cette minuterie en exécutant systemctl list-timers .

  8. L'outil certbot édite et modifie les fichiers de configuration NGINX de vos sites Web. Ce faisant, certbot n'obéit pas à l'listen initial directive (listen 80 proxy_protocol; ) et n'ajoute pas le proxy_protocol paramètre au nouveau listen 443 ssl; lignes. Vous devez modifier les fichiers de configuration pour chaque site Web et ajouter "proxy_protocol" à chaque "listen 443 ssl ;" ligne.

     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
    Remarque Chaque fichier de configuration de site Web a deux paires de listen directives :HTTP et HTTPS, respectivement. La première est la paire d'origine pour HTTP qui a été ajoutée dans une section précédente. La deuxième paire a été ajoutée par certbot pour HTTPS. Ce sont des paires car elles couvrent à la fois IPv4 et IPv6. La notation [::] fait référence à IPv6. Lors de l'ajout du paramètre proxy_protocol , ajoutez-le avant le ; sur chaque ligne comme indiqué ci-dessus.

  9. Redémarrez 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 directives. 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 directives. 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 )'
Remarque

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 Etat. 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 récipient. 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

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

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

Plus d'informations

Vous pouvez consulter les ressources suivantes pour plus d'informations sur ce sujet. Bien que ceux-ci soient fournis dans l'espoir qu'ils seront utiles, veuillez noter que nous ne pouvons pas garantir l'exactitude ou l'actualité des documents hébergés en externe.

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

Docker

  1. Configuration du serveur Nginx Reverse Proxy sur Debian Linux

  2. Comment configurer un proxy inverse Nginx

  3. Guide du débutant sur NFS dans CentOS / RHEL

  4. Guide du débutant sur SELinux

  5. Guide du débutant pour la configuration de yum

Un guide pour débutants sur LVM

Définir une adresse IP statique sur Ubuntu :un guide pour les débutants

Un guide du débutant sur les tâches Cron

Comment configurer le proxy inverse Nginx

Guide du débutant sur le monde Docker

Guide du débutant sur la gestion des utilisateurs MySQL