Utilisation de Docker pour configurer le proxy inverse Nginx avec la génération SSL automatique

Qu'est-ce que le proxy inverse ? Quels sont ses avantages ?

Qu'est-ce qu'un proxy inverse ? Le proxy inverse est une sorte de serveur qui se trouve devant de nombreux autres serveurs et transmet les demandes des clients aux serveurs appropriés. La réponse du serveur est alors également reçue et transmise par le serveur proxy au client.

Pourquoi utiliseriez-vous une telle configuration ? Il y a plusieurs bonnes raisons à cela. Cette configuration peut être utilisée pour configurer un équilibreur de charge, une mise en cache ou une protection contre les attaques.

Je ne rentre pas dans les détails ici. Au lieu de cela, je vais vous montrer comment vous pouvez utiliser le concept de proxy inverse pour configurer plusieurs services sur le même serveur.

Prenez la même image que celle que vous avez vue ci-dessus. Ce que vous pouvez faire, c'est exécuter un serveur Ngnix dans un conteneur Docker en mode proxy inverse. D'autres services Web peuvent également être exécutés dans leurs propres conteneurs respectifs.

Le conteneur Nginx sera configuré de manière à savoir quel service Web s'exécute dans quel conteneur.

C'est un bon moyen de réduire les coûts d'hébergement de chaque service sur un serveur différent. Vous pouvez avoir plusieurs services exécutés sur le même serveur Linux grâce au serveur proxy inverse.

Configuration de Nginx en tant que proxy inverse pour déployer plusieurs services sur le même serveur avec Docker

Laissez-moi vous montrer comment configurer la configuration mentionnée ci-dessus.

Avec ces étapes, vous pouvez installer plusieurs conteneurs d'applications Web fonctionnant sous Nginx, chaque conteneur autonome correspondant à son propre domaine ou sous-domaine respectif.

Voyons d'abord ce dont vous avez besoin pour suivre ce tutoriel.

Prérequis

Vous aurez besoin des connaissances suivantes pour démarrer facilement avec ce didacticiel. Bien que vous puissiez également vous en passer.

Un système/serveur Linux. Vous pouvez facilement déployer un serveur Linux en quelques minutes à l'aide du service cloud Linode.
Connaissance des commandes et du terminal Linux
Connaissance de base de Docker
Docker et Docker Compose doivent être installés sur votre serveur Linux. Veuillez lire notre guide sur l'installation de Docker et Docker Compose sur CentOS.
Vous devez également posséder un domaine (afin de pouvoir configurer des services sur des sous-domaines).

J'ai utilisé domain.com comme exemple de nom de domaine dans le tutoriel. Assurez-vous de le modifier en fonction de vos propres domaines ou sous-domaines.

Outre ce qui précède, veuillez également vous assurer des éléments suivants :

Modifier les enregistrements DNS de votre domaine

Dans le panneau d'enregistrement A/AAAA ou CNAME de votre fournisseur de nom de domaine, assurez-vous que le domaine et les sous-domaines (y compris www) pointent vers l'adresse IP de votre serveur.

Ceci est un exemple pour votre référence :

Nom d'hôte	Adresse IP	TTL
domaine.com	172.105.50.178	Par défaut
*	172.105.50.178	Par défaut
sub0.domain.com	172.105.50.178	Par défaut
sub1.domain.com	172.105.50.178	Par défaut

Echange d'espace

Pour vous assurer que toutes vos applications de conteneur sont à l'aise et ne manquent jamais de mémoire après leur déploiement, vous devez disposer de l'espace d'échange nécessaire sur votre système.

Vous pouvez toujours ajuster le swap en fonction de la RAM disponible sur votre système. Vous pouvez décider de l'espace d'échange en fonction du groupe de conteneurs d'applications sur le serveur unique et en estimant leur utilisation cumulative de la RAM.

Étape 1 :Configurer le conteneur de proxy inverse Nginx

Commencez par configurer votre proxy inverse nginx. Créez un répertoire nommé "reverse-proxy" et basculez-y :

mkdir reverse-proxy && cd reverse-proxy

Créez un fichier nommé docker-compose.yml , ouvrez-le dans votre éditeur de texte basé sur un terminal préféré comme Vim ou Nano.

Pour le proxy inverse nginx, j'utiliserai l'image jwilder/nginx-proxy. Copiez et collez ce qui suit dans le fichier docker-compose.yml :

version: "3.7"

services:

    reverse-proxy:
        image: "jwilder/nginx-proxy:latest"
        container_name: "reverse-proxy"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        restart: "always"
        networks: 
            - "net"
        ports:
            - "80:80"
            - "443:443"

Passons maintenant en revue les parties importantes du fichier de composition :

Vous avez déclaré quatre volumes, html, dhparam, vhost et certs. Ce sont des données persistantes que vous voudriez certainement conserver même après l'arrêt du conteneur. Le html &vhost les volumes seront très importants dans le prochain déploiement du conteneur Let's Encrypt. Ils sont conçus pour fonctionner ensemble.
Le Docker Socker est monté en lecture seule à l'intérieur du conteneur. Celui-ci est nécessaire pour que le conteneur de proxy inverse génère les fichiers de configuration de nginx, détecte d'autres conteneurs avec une variable d'environnement spécifique.
La politique de redémarrage de Docker est définie sur always . Les autres options incluent on-failure et unless-stopped . Dans ce cas, semblait toujours plus approprié.
Les ports 80 et 443 sont liés à l'hôte pour http et https respectivement.
Enfin, il utilise un réseau différent, pas le réseau de pont par défaut.

L'utilisation d'un réseau défini par l'utilisateur est très importante. Cela aidera à isoler tous les conteneurs qui doivent être mandatés, tout en permettant au conteneur de proxy inverse de transférer les clients vers leurs conteneurs souhaités/prévus et de laisser également les conteneurs communiquer entre eux (ce qui n'est pas possible avec le réseau de pont par défaut sauf si icc est défini sur true pour le démon).

Gardez à l'esprit que YML est très pointilleux sur les tabulations et l'indentation.

Étape 2 :Configurer un conteneur pour la génération automatique de certificats SSL

Pour cela, vous pouvez utiliser l'image de conteneur jrcs/letsencrypt-nginx-proxy-companion.

Sur le même docker-compose.yml fichier que vous avez utilisé auparavant, ajoutez les lignes suivantes :

    letsencrypt:
        image: "jrcs/letsencrypt-nginx-proxy-companion:latest"
        container_name: "letsencrypt-helper"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/var/run/docker.sock:ro"
        environment:
            NGINX_PROXY_CONTAINER: "reverse-proxy"
            DEFAULT_EMAIL: "[email protected]"
        restart: "always"
        depends_on:
            - "reverse-proxy"
        networks: 
            - "net"

Dans cette définition de service :

Vous utilisez exactement les mêmes volumes que ceux que vous avez utilisés pour le conteneur de proxy inverse. Le html et vhost le partage de volumes est nécessaire pour que le challenge ACME de letsencrypt soit un succès. Ce conteneur générera les certificats dans /etc/nginx/certs , dans le récipient. C'est pourquoi vous partagez ce volume avec votre conteneur de proxy inverse. Le dhparam volume contiendra le fichier dhparam. Le socket est monté pour détecter d'autres conteneurs avec une variable d'environnement spécifique.
Ici, vous avez défini deux variables d'environnement. Le NGINX_PROXY_CONTAINER la variable pointe vers le conteneur de proxy inverse. Définissez-le sur le nom du conteneur. Le DEFAULT_EMAIL est l'e-mail qui sera utilisé lors de la génération des certificats pour chaque domaine/sous-domaine.
Le depends_on est définie de sorte que ce service attende que le proxy inverse démarre en premier, puis et seulement ensuite, cela démarrera.
Enfin, ce conteneur partage également le même réseau. Ceci est nécessaire pour que les deux conteneurs communiquent.

Étape 3 :finaliser le fichier de composition docker

Une fois les définitions de services faites, complétez le fichier docker-compose avec les lignes suivantes :

volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  net:
    external: true

Le réseau net est défini sur externe car les conteneurs mandatés devront également utiliser ce réseau. Et si nous quittons le réseau pour être créés par docker-comspose , le nom du réseau dépendra du répertoire courant. Cela créera un réseau au nom bizarre.

En dehors de cela, d'autres conteneurs devront de toute façon définir ce réseau comme externe, sinon ces fichiers de composition devront également résider dans ce même répertoire, dont aucun n'est idéal.

Par conséquent, créez le réseau à l'aide de

 docker network create net

Ce qui suit est l'intégralité du contenu du docker-compose.yml fichier.

version: "3.7"

services:

    reverse-proxy:
        image: "jwilder/nginx-proxy:latest"
        container_name: "reverse-proxy"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        restart: "always"
        networks: 
            - "net"
        ports:
            - "80:80"
            - "443:443"
    letsencrypt:
        image: "jrcs/letsencrypt-nginx-proxy-companion:latest"
        container_name: "letsencrypt-helper"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/var/run/docker.sock:ro"
        environment:
            NGINX_PROXY_CONTAINER: "reverse-proxy"
            DEFAULT_EMAIL: "[email protected]"
        restart: "always"
        depends_on:
            - "reverse-proxy"
        networks: 
            - "net"
volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  net:
    external: true

Enfin, vous pouvez déployer ces deux conteneurs (Ngnix et Let's Encrypt) à l'aide de la commande suivante :

docker-compose up -d

Étape 4 :Vérifiez que le proxy inverse Ngnix fonctionne

Le conteneur qui servira le frontend devra définir deux variables d'environnement.

VIRTUAL_HOST :pour générer la configuration du proxy inverse

LETSENCRYPT_HOST :pour générer les certificats nécessaires

Assurez-vous que vous avez des valeurs correctes pour ces deux variables. Vous pouvez exécuter l'image nginx-dummy avec un proxy inverse comme ceci :

docker run --rm --name nginx-dummy -e VIRTUAL_HOST=sub.domain.com -e LETSENCRYPT_HOST=sub.domain.com -e VIRTUAL_PORT=80 --network net -d nginx:latest

Maintenant, si vous accédez à votre sous-domaine utilisé dans la commande précédente, vous devriez voir un message du serveur Ngnix.

Une fois que vous l'avez testé avec succès, vous pouvez arrêter le conteneur Docker en cours d'exécution :

docker stop nginx-dummy

Vous pouvez également arrêter le proxy inverse Ngnix si vous ne comptez pas l'utiliser :

docker-compose down

Étape 5 :Exécuter d'autres conteneurs de services avec un proxy inverse

Le processus de configuration d'autres conteneurs afin qu'ils puissent être proxy est TRÈS simple.

Je vais le montrer avec deux instances de déploiement Nextcloud dans un instant. Laissez-moi d'abord vous dire ce que vous faites ici.

Ne se lie à aucun port

Le conteneur peut laisser de côté le port qui dessert le frontend. Le conteneur de proxy inverse le détectera automatiquement.

(FACULTATIF) Définir VIRTUAL_PORT

Si le conteneur de proxy inverse ne parvient pas à détecter le port, vous pouvez définir une autre variable d'environnement nommée VIRTUAL_PORT avec le port desservant l'interface ou le service auquel vous souhaitez faire appel, comme "80" ou "7765".

Définir les e-mails Let's Encrypt spécifiques à un conteneur

Vous pouvez remplacer le DEFAULT_EMAIL variable et définissez une adresse e-mail spécifique pour un ou plusieurs certificats de domaine/sous-domaine d'un conteneur/service Web spécifique, en définissant l'identifiant de l'e-mail sur la variable d'environnement LETSENCRYPT_EMAIL . Cela fonctionne par conteneur.

Maintenant que vous savez tout cela, laissez-moi vous montrer la commande qui déploie une instance Nextcloud qui sera mandatée à l'aide du conteneur de proxy nginx et qui aura TLS (SSL/HTTPS) activé.

Ceci n'est PAS UN déploiement IDÉAL. La commande suivante est utilisée à des fins de démonstration uniquement.

docker run --name nextcloud --network net -e VIRTUAL_HOST="sub0.domain.com" -e LETSENCRYPT_HOST="sub0.domain.com" -d nextcloud:19.0.2

Dans l'exemple, vous avez utilisé le même réseau que les conteneurs de proxy inverse, défini les deux variables d'environnement, avec les sous-domaines appropriés (définissez le vôtre en conséquence). Après quelques minutes, vous devriez voir Nextcloud s'exécuter sur sub0.domain.com. Ouvrez-le dans un navigateur pour vérifier.

Vous pouvez déployer une autre instance Nextcloud comme celle-ci, sur un sous-domaine différent, comme suit :

docker run --name anothernextcloud --network net -e VIRTUAL_HOST="sub1.domain.com" -e LETSENCRYPT_HOST="sub1.domain.com" -d nextcloud:19.0.2

Vous devriez maintenant voir une instance Nextcloud différente s'exécutant sur un sous-domaine différent sur le même serveur.

Avec cette méthode, vous pouvez déployer différentes applications Web sur le même serveur servi sous différents sous-domaines, ce qui est très pratique.

Suivre

Maintenant que vous avez cette configuration, vous pouvez continuer et l'utiliser dans des déploiements réels avec les exemples suivants :

Installer Matrix Synapse Homeserver à l'aide de Docker
Installer plusieurs conteneurs Discourse sur le même serveur

Pour plus d'articles comme ceux-ci, abonnez-vous à notre newsletter ou envisagez de devenir membre. Pour toute question, n'hésitez pas à commenter ci-dessous.