Utilizzo di Docker per configurare il proxy inverso Nginx con la generazione SSL automatica

Cos'è il proxy inverso? Quali sono i suoi vantaggi?

Che cos'è un proxy inverso? Il proxy inverso è una specie di server che si trova davanti a molti altri server e inoltra le richieste del client ai server appropriati. La risposta dal server viene quindi ricevuta e inoltrata anche dal server proxy al client.

Perché dovresti usare una configurazione del genere? Ci sono diverse buone ragioni per questo. Questa configurazione può essere utilizzata per configurare un bilanciamento del carico, la memorizzazione nella cache o per la protezione dagli attacchi.

Non entro nei dettagli qui. Ti mostrerò invece come utilizzare il concetto di proxy inverso per configurare più servizi sullo stesso server.

Prendi la stessa immagine di quella che hai visto sopra. Quello che puoi fare è eseguire un server Ngnix in un contenitore mobile in modalità proxy inverso. Altri servizi Web possono essere eseguiti anche nei rispettivi contenitori.

Il contenitore Nginx verrà configurato in modo da sapere quale servizio Web è in esecuzione in quale contenitore.

Questo è un buon modo per risparmiare sui costi di hosting di ciascun servizio in un server diverso. Puoi avere più servizi in esecuzione sullo stesso server Linux grazie al server proxy inverso.

Configurazione di Nginx come proxy inverso per distribuire più servizi su stesso server utilizzando Docker

Lascia che ti mostri come procedere per configurare la configurazione sopra menzionata.

Con questi passaggi, puoi installare più contenitori di applicazioni basate sul Web in esecuzione in Nginx con ciascun contenitore autonomo corrispondente al rispettivo dominio o sottodominio.

Per prima cosa, vediamo di cosa hai bisogno per seguire questo tutorial.

Prerequisiti

Avrai bisogno delle seguenti conoscenze per iniziare facilmente con questo tutorial. Tuttavia, puoi cavartela anche senza di loro.

• Un sistema/server Linux. Puoi distribuire facilmente un server Linux in pochi minuti utilizzando il servizio cloud Linode.
• Familiarità con i comandi e il terminale Linux.
• Conoscenza di base di Docker.
• Dovresti avere Docker e Docker Compose installati sul tuo server Linux. Leggi la nostra guida sull'installazione di Docker e Docker Compose su CentOS.
• Dovresti anche possedere un dominio (in modo da poter configurare servizi sui sottodomini).

Ho usato domain.com come nome di dominio di esempio nel tutorial. Assicurati di modificarlo in base ai tuoi domini o sottodomini.

Oltre a quanto sopra, assicurati anche delle seguenti cose:

Modifica i record DNS del tuo dominio

Nel pannello dei record A/AAAA o CNAME del tuo provider di nomi di dominio, assicurati che sia il dominio che i sottodomini (incluso www) puntino all'indirizzo IP del tuo server.

Questo è un esempio di riferimento:

Nome host	Indirizzo IP	TTL
dominio.com	172.105.50.178	Predefinito
*	172.105.50.178	Predefinito
sub0.domain.com	172.105.50.178	Predefinito
sub1.domain.com	172.105.50.178	Predefinito

Scambia spazio

Per assicurarti che tutte le tue app container siano a proprio agio e non esauriscano mai la memoria dopo averle distribuite, devi disporre dello spazio di scambio necessario sul tuo sistema.

Puoi sempre regolare lo scambio in base alla RAM disponibile sul tuo sistema. Puoi decidere lo spazio di scambio in base al pacchetto di contenitori di app sul singolo server e stimando il loro utilizzo cumulativo della RAM.

Passaggio 1:imposta il container proxy inverso Nginx

Inizia con la configurazione del proxy inverso nginx. Crea una directory denominata "reverse-proxy" e passa ad essa:

mkdir reverse-proxy && cd reverse-proxy

Crea un file chiamato docker-compose.yml , aprilo nel tuo editor di testo basato su terminale preferito come Vim o Nano.

Per il proxy inverso nginx, userò l'immagine jwilder/nginx-proxy. Copia e incolla quanto segue nel file 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"

Ora esaminiamo le parti importanti del file di composizione:

• Hai dichiarato quattro volumi, html, dhparam, vhost e certs. Sono dati persistenti che vorresti assolutamente conservare anche dopo che il contenitore è stato inattivo. Il html &vhost i volumi saranno molto importanti nella prossima distribuzione del contenitore Let's Encrypt. Sono progettati per funzionare insieme.
• La finestra mobile socker è montata in sola lettura all'interno del contenitore. Questo è necessario affinché il contenitore del proxy inverso generi i file di configurazione di nginx, rilevi altri contenitori con una specifica variabile di ambiente.
• Il criterio di riavvio di Docker è impostato su always . Altre opzioni includono on-failure e unless-stopped . In questo caso, mi è sempre sembrato più appropriato.
• Le porte 80 e 443 sono associate all'host rispettivamente per http e https.
• Infine, utilizza una rete diversa, non la rete bridge predefinita.

L'uso di una rete definita dall'utente è molto importante. Ciò aiuterà a isolare tutti i contenitori che devono essere inviati tramite proxy, oltre a consentire al contenitore proxy inverso di inoltrare i client ai contenitori desiderati/previsti e inoltre consentire ai contenitori di comunicare tra loro (cosa non possibile con la rete bridge predefinita a meno che icc è impostato su true per il demone).

Tieni presente che YML è molto schizzinoso su tabulazioni e rientri.

Passaggio 2:imposta un contenitore per la generazione automatica di certificati SSL

Per questo, puoi usare l'immagine del contenitore jrcs/letsencrypt-nginx-proxy-companion.

Nello stesso docker-compose.yml file che hai utilizzato in precedenza, aggiungi le seguenti righe:

    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"

In questa definizione di servizio:

• Stai utilizzando gli stessi volumi esatti utilizzati per il contenitore del proxy inverso. Il html e vhost la condivisione dei volumi è necessaria per il successo dell'ACME Challenge diletsencrypt. Questo contenitore genererà i certificati all'interno di /etc/nginx/certs , nel contenitore. Questo è il motivo per cui stai condividendo questo volume con il tuo container proxy inverso. Il dhparam volume conterrà il file dhparam. Il socket è montato per rilevare altri contenitori con una specifica variabile di ambiente.
• Qui hai definito due variabili d'ambiente. Il NGINX_PROXY_CONTAINER la variabile punta al contenitore del proxy inverso. Impostalo sul nome del contenitore. Il DEFAULT_EMAIL è l'e-mail che verrà utilizzata durante la generazione dei certificati per ogni dominio/sottodominio.
• Il depends_on l'opzione è impostata in modo che questo servizio attenda prima l'avvio del proxy inverso, quindi e solo allora questo verrà avviato.
• Infine, anche questo container condivide la stessa rete. Ciò è necessario per la comunicazione tra i due contenitori.

Passaggio 3:finalizzare il file di composizione della finestra mobile

Una volta terminate le definizioni del servizio, completa il file docker-compose con le seguenti righe:

volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  net:
    external: true

La rete net è impostato su esterno perché anche i contenitori proxy dovranno utilizzare questa rete. E se lasciamo la rete per essere creati da docker-comspose , il nome della rete dipenderà dalla directory corrente. Questo creerà una rete con un nome strano.

Oltre a ciò, altri contenitori dovranno comunque impostare quella rete in modo che sia esterna, altrimenti anche i file di composizione dovranno risiedere in questa stessa directory, nessuna delle quali è l'ideale.

Pertanto, crea la rete utilizzando

 docker network create net

Quello che segue è l'intero contenuto di docker-compose.yml file.

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

Infine, puoi distribuire questi due container (Ngnix e Let's Encrypt) usando il seguente comando:

docker-compose up -d

Passaggio 4:verifica che il proxy inverso Ngnix funzioni

Il contenitore che servirà il frontend dovrà definire due variabili di ambiente.

VIRTUAL_HOST :per generare la configurazione del proxy inverso

LETSENCRYPT_HOST :per generare i certificati necessari

Assicurati di avere valori corretti per queste due variabili. Puoi eseguire nginx-dummy image con reverse proxy in questo modo:

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

Ora, se vai al tuo sottodominio utilizzato nel comando precedente, dovresti vedere un messaggio dal server Ngnix.

Dopo averlo testato con successo, puoi interrompere il contenitore Docker in esecuzione:

docker stop nginx-dummy

Puoi anche interrompere il proxy inverso Ngnix se non lo utilizzerai:

docker-compose down

Passaggio 5:esegui altri contenitori di servizi con proxy inverso

Il processo di configurazione di altri contenitori in modo che possano essere inviati tramite proxy è MOLTO semplice.

Lo mostrerò con due istanze della distribuzione di Nextcloud tra un momento. Lascia che ti dica prima cosa stai facendo qui.

Non eseguire il binding a nessuna porta

Il container può omettere la porta che serve il frontend. Il contenitore del proxy inverso lo rileverà automaticamente.

(FACOLTATIVO) Definisci VIRTUAL_PORT

Se il contenitore del proxy inverso non riesce a rilevare la porta, puoi definire un'altra variabile di ambiente denominata VIRTUAL_PORT con la porta che serve il frontend o qualsiasi servizio a cui vuoi ricevere proxy, come "80" o "7765".

Imposta Let's Encrypt email specifiche per un container

Puoi sovrascrivere il DEFAULT_EMAIL e impostare un indirizzo e-mail specifico per il/i certificato/i di dominio/sottodominio di un contenitore/servizio Web specifico, impostando l'ID e-mail sulla variabile di ambiente LETSENCRYPT_EMAIL . Funziona in base al contenitore.

Ora che conosci tutte queste cose, lascia che ti mostri il comando che distribuisce un'istanza Nextcloud che verrà inviata tramite proxy utilizzando il container proxy nginx e avrà TLS(SSL/HTTPS) abilitato.

Questa NON è una distribuzione IDEALE. Il comando seguente viene utilizzato solo a scopo dimostrativo.

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

Nell'esempio, hai utilizzato la stessa rete dei contenitori del proxy inverso, hai definito le due variabili di ambiente, con i sottodomini appropriati (imposta il tuo di conseguenza). Dopo un paio di minuti, dovresti vedere Nextcloud in esecuzione su sub0.domain.com. Aprilo in un browser per verificare.

Puoi distribuire un'altra istanza Nextcloud proprio come questa, su un sottodominio diverso, come il seguente:

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

Ora dovresti vedere un'istanza Nextcloud diversa in esecuzione su un sottodominio diverso sullo stesso server.

Con questo metodo, puoi distribuire diverse app Web sullo stesso server servito in sottodomini diversi, il che è piuttosto utile.

Seguire

Ora che hai impostato questa configurazione, puoi procedere e utilizzarla nelle distribuzioni effettive con i seguenti esempi:

• Installa Matrix Synapse Homeserver utilizzando Docker
• Installa più contenitori di discorsi sullo stesso server

Per altri articoli come questi, iscriviti alla nostra newsletter o considera di diventare un membro. Per qualsiasi domanda, non esitare a commentare qui sotto.