README.md 2.4 KB

Nginx Reverse-Proxy

Ce repo contient les fichiers et répertoires de base pour nginx reverse-proxy dockerizé. Ce projet est un simple reverse-proxy permettant facilement et automatiquement de générer des confs + certificats LE sur simple démarrage de containers (Avec les variable env correctes)

Démarrer

Prérequis

La stack utilise un réseau privé spécifique, dans lequel doivent se trouver les container pour

  1. Déclencher la création d'une config particulière
  2. Être joignable par le reverse pour qu'ils soit atteignable depuis l'extérieur

Il faut donc d'abord créer ce réseau :

docker network create reverse-proxy

Il faut aussi s'assurer qu'aucun autre container ou service n'utilise les ports 80 et 443

Installation

Il suffit de cloner le repo et de s'assurer que les fichiers nginx.tmpl et docker-compose.yml sont bien présents.

git clone https://git.caliko.net/dtokarz/docker-reverse-proxy.git

S'assurer également que les répertoires suivants sont présents :

certs conf.d html vhost.d

Démarrage

Une fois les fichiers présents, il suffit de lancer la stack

docker-compose up -d

Si tout est correct, trois conteneurs seront up

reverse reverse-gen reverse-letsencrypt

Reverse-proxiser un conteneur

Pour que le reverse ait la connaissance d'un conteneur à proxiser, il faut que ce dernier ait certaines variables d'environnement associées.

Dans un docker-compose, par exemple :

---
version: "2.1"
services:
  unifi-controller:
    image: lscr.io/linuxserver/unifi-controller
    container_name: unifi-controller
    environment:
      - PUID=1000
      - PGID=1000
      - VIRTUAL_HOST=unifi.example.com
      - VIRTUAL_PORT=8443
      - VIRTUAL_PROTO=https
      - LETSENCRYPT_HOST=unifi.example.com
      - LETSENCRYPT_EMAIL=your.name@email.com
    volumes:
      - ./data:/config
    ports:
      - 8443:8443
    restart: unless-stopped

networks:
  default:
    external:
      name: reverse-proxy

Les variables

VIRTUAL_HOST VIRTUAL_PORT LETSENCRYPT_HOST LETSENCRYPT_EMAIL

sont importantes, elles définissent quels services sont à exposer au travers du reverse-proxy. La variable VIRTUAL_PROTO n'est importante que pour signifier que le backend est en HTTPS

Le bloc networks: permet de connecter les containers au réseau du reverse-proxy pour que ce dernier puisse les joindre.