Docker HTTPS-Portal Nginx Webserver mit Ansible installieren - Cloud Server Serie
HTTPS-Portal ist ein Nginx Webserver mit automatischer SSL-Verschlüsselung. Dieses Programm wird installiert, um die Datenübertragung zu schützen.
Dieser Artikel ist Teil einer ganzen Serie über die Installation eines Cloud-Servers mit Ansible, Docker und Portainer.
- Start der Cloud Server Serie - Installation eines Cloud Servers
- Registrierung bei Hetzner
- SSH-Schlüssel erstellen
- Server erstellen - in der Hetzner Cloud-Console
- Mit PuTTY am Server anmelden
- Mehr Details zu PuTTY
- PuTTY Kommandozeilenprogramm Starter-Datei
- Root-Passwort ändern
- Ansible installieren und vorbereiten
- Mit Ansible das Betriebssystem updaten
- SSH-Port mit Ansible ändern
- Docker und Docker-Compose mit Ansible installieren
- DNS-Einträge für den Server
- Internes Docker-Netzwerk mit Ansible erstellen
- Docker HTTPS-Portal mit Ansible installieren
- Docker Portainer mit Ansible installieren
- Baserow - No-Code Datenbank - Docker-Compose mit Portainer installieren
- Ghost - Blog und CMS-System - mit Ansible und eingebettetem Docker-Compose installieren
- WordPress mit Ansible und externem Docker-Compose-File installieren
- Hetzner Cloud Server mit nur einem Ansible-Playbook installieren
- Ansible Umgebung für mehrere Computer einrichten
Das Programm HTTPS-Portal von steveltn
dient als HTTPS-Proxy. Als HTTPS-Proxy kümmert sich dieses Programm um die verschlüsselte Datenübertragung zwischen Browser und den Serverprogrammen. Ich habe zwei mögliche Konfigurationen als Playbooks zusammengestellt. Eines zeigt auf, wie man das HTTPS-Portal installieren könnte. Das zweite Playbook zeigt, wie es bei mir persönlich eingestellt ist.
HTTPS-Portal - Basiskonfiguration
Das hier ist eine einfache Konfiguration des HTTPS-Proxies. Damit wird das Programm funktionieren. Wenn du mehr haben möchtest, siehe dir die Erweiterte Konfiguration (unten) an.
docker_https_portal.yaml:
- hosts: "all"
tasks:
- name: "Init HTTPS-Portal"
docker_container:
name: "https_portal"
image: "steveltn/https-portal:1.21"
restart_policy: "unless-stopped"
restart: "yes"
networks:
- name: "bridge"
- name: "proxynet"
ports:
- "80:80"
- "443:443"
env:
STAGE: "production"
volumes:
- "/home/docker/data/https_portal/data:/var/lib/https-portal"
- "/home/docker/data/https_portal/log:/var/log/nginx"
HTTPS-Portal - Erweiterte Konfiguration
docker_https_portal.yaml:
- hosts: "all"
tasks:
- name: "Init HTTPS-Portal"
docker_container:
name: "https_portal"
image: "steveltn/https-portal:1.21"
log_driver: "journald"
log_options:
tag: "{{ '{{.Name}} ' }}"
restart_policy: "unless-stopped"
restart: "yes"
networks:
- name: "bridge"
- name: "proxynet"
ports:
- "80:80"
- "443:443"
env:
TZ: "Europe/Vienna"
STAGE: "production"
WORKER_CONNECTIONS: 4096
RESOLVER: "127.0.0.11 ipv6=off valid=30s"
DYNAMIC_UPSTREAM: "true"
CLIENT_MAX_BODY_SIZE: "1000M"
WEBSOCKET: "true"
HSTS_MAX_AGE: "31536000"
DOMAINS: >
portainer.demo01.halvar.at -> portainer:9000,
volumes:
- "/etc/timezone:/etc/timezone:ro"
- "/etc/localtime:/etc/localtime:ro"
- "/home/docker/data/https_portal/data:/var/lib/https-portal"
- "/home/docker/data/https_portal/log:/var/log/nginx"
Die erweiterte Konfiguration zeigt auf, wie ich HTTPS-Portal verwende. Es werden mit Umgebungsvariablen noch ein paar Dinge eingestellt, die ich hier ein wenig erklären möchte.
log_driver und log_options
Mit der Option log_driver
kann man Docker dazu bringen, die Ausgabe von STDOUT und STDERR in das Journal des Host-Computers zu schreiben. Mit log_options/tag = {{.Name}}
schreibt man den Namen des Containers mit ins Journal. Macht man das nicht, wird es schwierig, die Log-Meldungen voneinander zu unterscheiden.
TZ, /etc/timezone und /etc/localtime
In einem Docker-Container herrscht die UTC. Manche Programme in Docker-Containern stellen die Zeitzone automatisch auf die mit der Umgebungsvariable TZ
übergebene Zone. Und andere Programme werten die Dateien /etc/timezone und /etc/localtime aus, um die Zeitzone zu ermitteln. Und falls das nicht der Fall ist, schadet es meistens nicht, wenn man diese Einstellungen übergibt.
WORKER_CONNECTIONS
Die Standardeinstellung ist 1024
gleichzeitige Worker-Connections. Siehe http://nginx.org/en/docs/ngx_core_module.html#worker_connections
RESOLVER und DYNAMIC_UPSTREAM
Damit verhindert man das zu lange Cachen der internen IP-Adresse eines anderen Docker-Containers. Startet man einen Docker-Container neu, dann bekommt dieser meist eine neue IP-Adresse zugewiesen. HTTPS-Proxy findet dann den Container nicht mehr, bis der DNS-Cache abgelaufen ist.
RESOLVER: "127.0.0.11 ipv6=off valid=30s"
DYNAMIC_UPSTREAM: "true"
Damit stellt man die maximale Caching-Dauer auf 30 Sekunden. Ein Neustart eines Containers wird also spätestens nach 30 sec. erkannt.
CLIENT_MAX_BODY_SIZE
Möchte man große Dateien vom Browser zum Server übermitteln, muss diese Einstellung angepasst werden, ansonsten wird die Datenübertragung nach 1 MB abgebrochen.
WEBSOCKET
Manche Serverprogramme verwenden das Websocket-Protokoll, um Daten vom Server zum Client zu übermitteln. Um zum Beispiel den Browser über eine Änderung von Daten zu unterrichten. Dafür wird eine ständige Verbindung zwischen Browser und Server aufgebaut. Durch die ständige Verbindung profitieren auch Datenübermittlungen vom Client zum Server. Der Nachteil ist, dass für jede Verbindung Ressourcen vom Server gebunden werden. Um Websockets zu aktivieren, muss WEBSOCKET: "true"
übergeben werden.
HSTS_MAX_AGE
Damit wird dem Browser bekannt gegeben, dass dieser den Server immer per HTTPS erreicht und auf keinen Fall nach HTTP zurückschalten soll. Auch dann nicht, wenn eine HTTP-URL angeklickt wurde. Das ist ein wichtiger Sicherheits-Header, der Umleitungen zu unsicheren Servern verhindern soll.
Ich stelle diesen Header meistens auf ein Jahr ein.
HSTS_MAX_AGE: "31536000"
Siehe: Preise und Leistungen