Dorian Tokarz dd1167b707 modif readme | 2 gadi atpakaļ | |
---|---|---|
certs | 2 gadi atpakaļ | |
conf.d | 2 gadi atpakaļ | |
html | 2 gadi atpakaļ | |
vhost.d | 2 gadi atpakaļ | |
README.md | 2 gadi atpakaļ | |
docker-compose.yml | 2 gadi atpakaļ | |
nginx.tmpl | 2 gadi atpakaļ |
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)
La stack utilise un réseau privé spécifique, dans lequel doivent se trouver les container pour
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
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
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
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.