Ich persönlich finde S3 Speicher sehr angenehm und versuche ihn für verschiedene Anwendungsbereiche zu verwenden. Heute habe ich mir wieder einen extra Server installiert und möchte den Prozess hiermit quasi dokumentieren. Mit dieser Anleitung installieren wirMinio (externer Link) auf einem Debian 12 (Bookworm) System. Dazu verwenden wir direkt nginx als Reverse Proxy und sichern das mittels Let’s encrypt Zertifikaten ab, sodass immer eine gesicherte Verbindung aufgebaut werden kann.

Was ist S3 Speicher?

S3-Speicher bezieht sich auf Amazon Simple Storage Service, kurz Amazon S3. Es handelt sich dabei um einen skalierbaren Cloud-Speicherdienst von Amazon Web Services (AWS). S3 ermöglicht es Benutzern, große Datenmengen sicher und kostengünstig in der Cloud zu speichern. Ein Objektspeicher ist eine Art von Datenspeicher, der darauf ausgelegt ist, große Mengen unstrukturierter Daten in Form von Objekten zu speichern. Jedes Objekt besteht aus Daten, Metadaten und einem eindeutigen Identifikator. Im Fall von S3 werden diese Objekte in sogenannten “Buckets” organisiert, die als virtuelle Container dienen, um die Objekte zu gruppieren.

Installation von Minio

Anlegen des Nutzers und Gruppe

Mittlerweile gibt es extra Paket fürDebian (externer Link) und Ubuntu sodass sich die Installation etwas mehr vereinfacht. Minio sollte natürlich nicht im Kontext des root-Nutzers laufen. Best practise ist hier, sich einen eigenen Nutzer anzulegen. Du kannst natürlich auch gerne schon einen vorhanden verwenden.

groupadd -r minio-useruseradd -M -r -g minio-user minio-user

Wie geschrieben kannst du die Parameter auch entsprechend anpassen. Bedenke aber, dass die Anleitung davon ausgeht, dass du die Nutzer und Gruppe genau so genannt wurden.

Datenverzeichnis vorbereiten

Als nächstes solltest du dir noch Gedanken machen wohin auf deinem System die Daten abgelegt werden sollen. In meinem Fall lege dich diese nach/opt ab. Zuerst wird das Verzeichnis angelegt und anschließend bekommt unser Minio Nutzerminio-user das Verzeichnis als Besitzer zugeordnet.

mkdir -p /opt/miniochown minio-user:minio-user /opt/minio

Minio Paket installieren

Glücklicherweise gibt es Minio mittlerweile auch als fertiges Paket, sodass wir uns um diverse Dinge keine Gedanken machen müssen. Dies beinhaltet nämlich mittlerweile auch einensystemd Skript um das Programm sauber darüber starte und stoppen zu können. Zuerst laden wir uns das Paket erst einmal runter. Sehr wahrscheinlich ist die verlinkte Version schon veraltet wenn du dieses Tutorial liest. Schaue als bitter malhier (externer Link) welche die aktuelle Version ist und ersetze die Versionnummer.

wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio_20240217011557.0.0_amd64.deb -O minio.deb

Sollte dein System aus irgendwelchen Gründen den Befehlwget nicht kennen kannst du den mittels

apt install wget -y

installieren.

Nun brauchen wir nur noch Minio zu installieren und haben schon einen großen Teil erledigt.

dpkg -i minio.deb

Nach ein paar Sekunden ist das ganze auch schon fertig und wir können anfangen das Programm zu konfigurieren.

Standardkonfiguration für Minio anlegen

Wir nutzen in diesem Tutorial eine recht einfache Konfiguration. Diese kannst du natürlich immer noch nach weiterem belieben erweitern wenn du möchtest. Wir legen uns also die Default Konfiguration an

touch /etc/default/minio

und bearbeiten diese. Ich verwende immervim als Editor. Du kannst natürlich auch gernenano verwenden wenn dir das lieber ist.

vim /etc/default/minio

Darin kopieren wir jetzt folgende Zeilen

# Definition des Admin Accounts
MINIO_ROOT_USER=myminioadmin
MINIO_ROOT_PASSWORD=minio-secret-key-change-me
# MINIO_VOLUMES setzt das Verzeichnis in dem unsere Daten gespeichert werden
MINIO_VOLUMES="/opt/minio"
# Damit wir auch die Konsole bzw. Webfrontend verwenden können, müssen wir das natürlich noch setzen
MINIO_OPTS="--console-address :9001"

Bitte pass entsprechendMINIO_ROOT_USER undMINIO_ROOT_PASSWORD an und lasse die Werte nicht auf default setzen. Auch wenn du das System nicht nach außen hin veröffentlichst, sollten niemals Standardzugangsdaten verwendet werden.

Minio starten und Login

Nun starten wir Minio erst einmal um zu sehen ob alles funktioniert. Zudem sollten wir uns auch einmal anmelden um auch das gegengetestet zu haben.

systemctl enable miniosystemctl start minio

Nun öffnen wir einen Browser und navigieren zu{HOSTIP}:9001 und sollten anschließend so ein Bild sehen. Bitte anschließend einmal einloggen um zu sehen, dass auch deine Zugangsdaten korrekt funktionieren.

nginx als Rervse Proxy mit Zertifkat einrichten

Ich verwende in dem TutorialCerbot zum generieren des Let’s encrypt Zertifikates. Zudem wird mein öffentliches DNS meiner Domain von Cloudflare betrieben. Entsprechend verwende ich hier diedns-challenge mit Cloudflare und API Token.

Cloudflare API Token generieren

Auf der Cloudflare Profilseite gibt es den PunktAPI Tokens (externer Link) (Generischer Link dorthin). Dort legen wir uns rechts oben ein neuen Token an und verwenden das TemplateEdit Zone DNS. Du solltest nun ungefähr dieses Bild hier sehen. Den Bereich Permissions lassen wir so wie er ist. Im BereichZone Resources müssen wir im letzten drop down Feld in der Reihe nur noch die entsprechende Domain auswählen. Den Rest können wir mitContinue to summary ebenfalls auslassen. Auf der nächsten Seite bestätigen wir mitCreate Token und nun wird uns unser Token angezeigt. Ich empfehle diesen sicher abzuspeichern falls du den später noch mal für andere Dinge verwenden möchtest.

Pakete installieren

Nun zurück zu unserer Linux Maschine. Wir können hier nun endlich alle benötigten Pakete installieren die wir brauchen.

apt install nginx certbot python3-certbot-dns-cloudflare

Dies benötigt ein paar Sekunden und wir können weiter machen uns unser Zertifikat zu besorgen.

Let’s encrypt Zertifikat mit Certbot beantragen

Zuerst richten wir noch die Punkte für die DNS Challenge zu Cloudflare ein. Dazu erstellen wir uns ein Verzeichnis

mkdir -p /etc/certbot

und legen uns dort eine Datei an

touch /etc/certbot/credentials

in diese kommt nun unser Cloudflare Token. Also editieren wir die Datei

vim /etc/certbot/credentials

und kopieren folgendes dort rein

dns_cloudflare_api_token={DEIN_CLOUDFLARE_API_TOKEN}

Damit die Datei nicht von jedem Nutzer auf dem System gelesen werden kann, passen wir noch die Berechtigungen mittels

chmod600 /etc/certbot/credentials

an. Nun haben wir den Grundstock gelegt um das Zertifikat beantragen zu können. Beachte jetzt, dass du die Domain entsprechend an deine Domain anpassen musst.

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/certbot/credentials -d minio.example.com -d s3.example.com

nginx einrichten

Nun können wir uns mit dem Thema nginx als reverse proxy für minio beschäftigen. Die Software wurde bereits oben schon installiert, also können wir direkt mit der Konfiguration der Seite beginnen. Dazu wechseln wir in das Konfigurationsverzeichnis für die Webseiten

cd /etc/nginx/sites-available

Dort legen wir dann die Seitenkonfiguration an

touch minio.conf

und können dann auch diese im Anschluss bearbeiten

vim minio.conf

Dort kannst du dann folgendes rein kopieren:

## API End Point
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name s3.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 300;
# Default is HTTP/1, keepalive is only enabled in HTTP/1.1
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9000;
}
# Nginx Logging
access_log /var/log/nginx/s3.example.com-access.log;
error_log /var/log/nginx/s3.example.com-error.log warn;
}
###################### Console ######################
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name minio.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_connect_timeout 300;
# To support websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9001;
}
# Nginx Logging
access_log /var/log/nginx/minio.example.com-access.log;
error_log /var/log/nginx/minio.example.com-error.log warn;
}

Bitte beachte, dass du überall dasexample.com durch deine eigene Domain austauschst. Die Konfiguration habe ich vonhier (externer Link) übernommen und ein wenig angepasst.

Jetzt legen wir noch den symlink an

ln /etc/nginx/site-available/minio.conf /etc/nginx/site-enabled/

und sollten testen ob wir auch kein Fehler gemacht haben. Das können wir am einfachsten mittels

nginx -t

Hier sollte keine Ausgabe erscheinen. Andernfalls müstest du die angezeigten Fehler noch verbessern. Zu guter letzt können wir nginx neu starten

systemctl restart nginx

Jetzt kannst du auch Minio über https über deine Domainnamen erreichen. Solltest du Minio nur im lokalen Netzwerk verwenden, denk daran, dass noch im DNS entsprechend zu hinterlegen.

Optional: Minio Admin Cli installieren

Gegebenenfalls brauchst du zu einem späteren Zeitpunkt mal die Admin CLI von Minio. Also solltest du diese direkt mit installieren. Diese ist ein einfaches binary das wir nur auf das System kopieren müssen.

curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/sbin/mc

Allerdings wird es ohne Execute Rechte nicht ausgeführt werden können, also fügen wir diese noch hinzu

chmod +x /usr/local/sbin/mc

Anschließend könntest du mittelsmc den Minio Server auch via CLI administrieren.

Fazit

In meinemKubernetes Cluster (externer Link) verwende ich Minio um daraufBackups abzulegen die mittelsvolsync (externer Link) erstellt wurden. Ebenso verwendet Thanos den S3 Speicher als Langzeitspeicher um die Prometheus Daten lange aufzuheben.

Solltest du Fragen zu dem Tutorial haben, kannst du mich gerne über eine der im Blog angegebenen Netzwerke erreichen.

Mit diesem Traefik letsencrypt Tutorial möchte ich dir helfen einfach und sauber Zertifikate via freier CA Let’s Encrypt zu beantragen und zu verwalten. In diesem Tutorial gehe ich auf die Punkte http-challenge, dns-challenge sowie weiteres Zertifikatsmanagement ein. Sollte Dir ein Punkt fehlen, schreibe mir dazu gerne in Kommentare.

Solltest Du auf dieses Tutorial gestoßen sein, weil du Docker nutzt, kann ich dir meinedocker-compose Sammlung auf GitHub (externer Link) sehr ans Herz legen. Dort sind gerade für das ThemaHomelab sehr viele Softwareprodukte hinterlegt die eine direkteTraefik (externer Link) Anbindung realisieren. Sicherlich ist auch meine Traefik Konfiguration ein guter Startpunkt für ein gutes Gelingen.

Traefik Grundkonfiguration

Traefik lässt sich über mehrere Wege konfigurieren. Hierbei spielt es keine Rolle ob man sämtliche Befehle und Konfigurationen direkt in die docker-compose Datei oder in separate Dateien packt. Ich für meinen Teil verwende dedizierte um eine einfachere und übersichtliche Konfiguration zu haben. Solltest du einen anderen Weg bevorzugen ist dies für dieses Traefikletsencrypt (externer Link) Tutorial nicht wichtig. Du musst natürlich nur die Einstellungen adaptieren.

Das ist ist meine Docker Compose Beispielkonfiguration welche ich normalerweise einsetze. Je nach Umgebung kann diese aber natürlich ein wenig variieren. Ich gebe auch immer http3 mit aus, einfach weil ich es mag neue Standard direkt mit zu implentieren.

---services:traefik:image:traefik:v3container_name:traefikvolumes:-/etc/localtime:/etc/localtime:ro-/etc/timezone:/etc/timezone:ro-/var/run/docker.sock:/var/run/docker.sock-/var/log/auth.log:/var/log/auth.log:ro-/var/log/traefik:/var/log/traefik-./config:/etc/traefiknetworks:-traefik_proxy-defaultports:-target:80published:80protocol:tcpmode:host-target:443published:443protocol:tcpmode:host-target:443published:443protocol:udpmode:hostrestart:unless-stoppednetworks:traefik_proxy:external:truedefault:driver:bridge

Anschließend brauchen wir natürlich noch die zwei Dateien die wir oben als Volume angegeben haben. Starten wir mit dertraefik.yaml Diese beinhaltet alle notwenigen Eigenschaften umTraefik sauber ans laufen zu bekommen.

---log:level:"INFO"filePath:"/var/log/traefik/traefik.log"accessLog:filePath:"/var/log/traefik/access.log"bufferingSize:100providers:docker:endpoint:"unix:///var/run/docker.sock"exposedByDefault:falsenetwork:"traefik_proxy"file:filename:"/etc/traefik/dynamic.yml"watch:trueapi:dashboard:falseentryPoints:ping:address:':88'web:address:':80'http:redirections:entryPoint:to:websecurescheme:httpswebsecure:address:':443'http3:proxyProtocol:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16forwardedHeaders:trustedIPs:-10.0.0.0/8-172.16.0.0/12-192.168.0.0/16certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"httpChallenge:entryPoint:webtls_resolver:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"tlsChallenge:{}

Gehen wir die Punkt einmal durch:

[log]

Das Loglevel sollte für den produktiven Betrieb so gewählt werden, dass nach Möglichkeit nicht die Festplatte voll läuft. Für den Beginn ist es evtl. ratsam hier aufDEBUG umzustellen um mehr zu sehen und um Fehler leichter erkennen zu können.

[providers]

Wir nutzen für diese Beispielkonfiguration Docker. Wir möchten allerdings nicht, dass grundsätzlich alleDocker Container via Traefik veröffentlicht werden (exposedByDefault = false) und setzen die jeweiligen Anpassungen für jeden Container dediziert. Traefik lassen wir auf den Docker Socket hören um zu wissen was Traefik so machen muss. Gegebenenfalls musst du den Parameter „network“ anpassen. Ich nutze hierfür immer „traefik_proxy“ als Netzwerk. Möchtest du das ebenfalls nutzen musst du

docker network create traefik_proxy

ausführen und das Netzwerk anzulegen.

[api]

Das Dashboard brauchen wir hierfür nicht, wird also deaktiviert

[entryPoints]

Die entryPoints sind die Ports und Protokolle auf die Traefik hört. Stand jetzt kann Traefik nur HTTP/HTTPS Traffic. Weitere Protokolle sollen in Zukunft kommen. Wir lauschen natürlich auch auf Port 80 (HTTP) und machen eine direkte Weiterleitung auf Port 443 (HTTPS). Unverschlüsselte Kommunikation sollte nur in Ausnahmefällen noch erlaubt sein.

Wie du siehst binden wir auch eine dynamic.yml Datei ein. Diese hat folgenden Aufbau

---tls:options:default:minVersion:VersionTLS12cipherSuites:-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256-TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384-TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305-TLS_AES_128_GCM_SHA256-TLS_AES_256_GCM_SHA384-TLS_CHACHA20_POLY1305_SHA256curvePreferences:-CurveP521-CurveP384sniStrict:truehttp:middlewares:default:chain:middlewares:-default-security-headers-gzipdefault-security-headers:headers:browserXssFilter:truecontentTypeNosniff:trueforceSTSHeader:trueframeDeny:truestsIncludeSubdomains:truestsPreload:truestsSeconds:31536000customFrameOptionsValue:"SAMEORIGIN"gzip:compress:{}

Die dynamic.yml ist zur Konfiguration aller Sicherheitsmerkmale gedacht. Bitte passe diese nach den aktuellen Gegebenheiten an, da sich gerade die Cipher Suites häufig ändern können! Die restlichen Werte sind nach langjähriger Erfahrung von mir so zusammen getragen und müssen nicht dem aktuellen Sicherheitsstandards entsprechend. Für Tipps bin ich aber dankbar und passe die Datei dann gerne an.

Traefik letsencrypt tlsChallenge

Mit der tlsChallange ist es wahrscheinlich die einfachste Variante Zertifikate via Let’s encrypt zu beantragen. Hier kann Traefik direkt so konfiguriert, bzw. über die Docker Konfiguration so eingerichtet werden, dass nur Port 443, also HTTPS, veröffentlicht werden muss. Möchte man nur ein paar wenige Zertifikate beantragen ist das meiner Meinung die empfehlenswerte Version.

Die Konfiguration der tlsChallenge ist ziemlich einfach. Man fügt in der traefik.toml Datei folgende Zeilen am Ende ein:

certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"

Email-Adresse ist für die Benachrichtigung von Let’s encrypt an dich gedacht. Entsprechend empfehle ich hier eine valide Email-Adresse anzugeben. Die Storage Angabe ist der Speicherort der Zertifikate. Entsprechend muss in der Docker Konfiguration auch das beachtet werden.

Traefik letsencrypt httpChallenge

Die httpChallenge ist quasi das gleich wie die tlsChallenge, allerdings via Port 80 anstatt 443. Hier muss als in der Docker Konfiguration auch Port 80 veröffentlicht werden. So ergibt sich daraus folgender Inhalt für die traefik.toml:

certificatesResolvers:default:acme:email:"deine@email-adresse.example"#Email Adresse hier anpassenstorage:"/etc/traefik/ACME/acme.json"httpChallenge:entryPoint:web

Traefik letsencrypt dnsChallenge (am Beispiel Cloudflare)

Die dnsChallenge ist quasi die Königsdisziplin. Allerdings nur wirklich dann sinnvoll wenn man z. B. Wildcard Zertifikate benötig oder wenn man viele Subdomainzertifikate benötigt. Entsprechend muss man hier auch ein wenig mehr konfigurieren und vor allen Dingen benötigt man einen DNS Provider der von Let’s encrypt unterstützt wird. Ich empfehle hier Cloudflare.

certificatesResolvers:default:acme:email:"mail@teqqy.de"storage:"/etc/traefik/ACME/acme.json"dnsChallenge:provider:"cloudflare"resolvers:-"1.1.1.1:53"-"1.0.0.1:53"

Hinzu kommt, dass wir in derdocker-compose.yaml noch den API Token für die Cloudflare API hinzufügen. Dazu einfach noch folgende Zeilen einfügen:

environment:CF_DNS_API_TOKEN:"{STRENGGEHEIMERAPIKEY}"

Zertifikate löschen

Zertifikate werden in deracme.json Datei gespeichert und könnten dort heraus gelöscht werden. Zu jedem Zertifikat gibt es einecertificate undkey Definition. Man kann also die Datei entsprechend editieren und die Zeichenketten entsprechend heraus löschen.

 {"domain": {"main":"teqqy.de","sans": ["www.teqqy.de" ] },"certificate":"<Zeichenkette>","key":"<Zeichenkette>","Store":"default" },

Notwendig ist dies aber nur dann, wenn bei der Erstellung ein Fehler aufgetreten ist oder Let’s Encrypt Zertifikate wg. Fehlern zurückruft. Andernfalls laufen die Zertifikate automatisch nach 90 Tagen ab. Ein manuelles Aufräumen ist nicht notwendig.

In allen meiner Tutorials verwende ich Traefik alsReverse Proxy für Docker Container, so natürlich auch auf meinemYouTube Kanal (externer Link) . Im Laufe der Zeit fragen immer wieder Leser und Zuschauer ob ich ihnen bei ihrem Problem helfen kann. Dies mache ich natürlich gerne. Für ein gewisse Selbsthilfe möchte ich dir allerdings diesen Traefik Troubleshooting Guide an die Hand geben.

Vorbereitende Maßnahmen

Um mit einem guten Troubeshooting zu beginnen möchte ich zwei Maßnahmen vorweg greifen. Diese helfen dir ein paar Dinge auszuschließen bzw. eventuell schnell selbst auf eine Lösung zu kommen.

Container richtig neu starten

Wenn ihr Änderungen am Container von Traefik oder gar an den Konfigurationsdateien vornimmt, muss Traefik komplett neu gestartet werden. Ein stoppen des jeweiligen ist nicht ausreichend. Beimeinen Compose Dateien (externer Link) verwende also bitte nach dem stoppen noch ein

docker-compose rm

um diesen komplett zu löschen. Anschließend kannst du den Container wieder starten und eine neue Konfiguration ist übernommen.

Erhöhen des Log Levels

Zum Traefik Troubleshooting gehört auf jeden Fall auch das betrachten der Log Dateien. In meiner Vorlage steht das Logging auf einer sehr kleinen Stufe um nicht unnötig Speicherplatz zu benötigen. Wenn du mit Traefik startest empfehle ich dir, dieses auf debug zu stellen.

Hierzu einfach die traefik.toml Datei anpassen:

[log]
level = "DEBUG"

Fehlerlösungen

Die Webseite wird als nicht sicher angezeigt

Dieser Fehler entsteht zumeist wenn Traefik keinLet’s Encrypt (externer Link) Zertifikat abrufen konnte. Leider kann das mehrere Ursachen haben:

Zu häufiges Abrufen von Zertifikaten

Im Log steht hier meist, dass die Anzahl der Möglichen Erstellversuche von Zertifikaten erreicht ist. LE lässt es nur zu 10 Versuche binnen 24 Stunden auf ein SSL-Zertifikat zu erstellen. Wenn du eine eigene Domain hast, versuche es mit einer anderen Subdomain erneut. Andernfalls hilft nur warten.

Ein anderer Container hört auf Port 80

Let’s Encrypt nutzt bei der ersten Kommunikation zwischen Server und Client auch HTTP (Port 80). Wenn dieser Port also noch durch einen anderen Container geblockt ist kann keine Verbindung aufgebaut werden. Ebenso könnte es sein, dass dein NAT in deinem Router Port 80 noch nicht weiter leitet.

Eine 404-Seite wird angezeigt

Jetzt wird es spannend. Sobald eine 404-Seite angezeigt wird, gibts nämlich ein Problem mit dem Routing zu den Containern. Folgende Dinge kannst du hier prüfen:

• Wird der korrekte Port weiter geleitet?
• Stimmen alle Middlewere-Configs überein?

Da mir dieses „ständige“ ändern der TXT-Records im DNS einfach zu mühsam ist, habe ich meine Homelab Domain zu Cloudflare als DNS-Provider umgezogen. Normalerweise betreibe ich ja alle anderen Domains unter eigenen Nameservern allerdings ist mir ein direktes Plugins für PowerDNS nicht bekannt.

Für einen Umzug der Nameserver ist dies entsprechend bei dem Unternehmen umzusetzen bei dem ihr auch eure Domain gehostet habt. In meinem Fall ist dasNetcup (externer Link) (übrigens sehr zu empfehlen). Bis die Umstellung schlussendlich vollzogen ist, kann es bis zu 48 Stunden dauern. Geduld ist also hier gefragt.

Mein reverse Proxy läuft unterDebian 9 (alias Stretch). Auf diesem installieren wir als erstesNGINX (externer Link) aus den offiziellen Paketquellen. Die Debian Pakete sind meist etwas veraltet und ich hätte gerne bei solchen Anwendungen immer die neusten Sicherheitsupdates eingespielt. Zudem arbeite ich in diesem Fall als root, solltet ihr als „normaler“ User arbeiten, ist vor die Befehle ein sudo zu setzen.

NGINX Installation

wget http://nginx.org/keys/nginx_signing.keyapt-key add nginx_signing.key

Die Paketquellen müssen noch in eine apt-Datei hinzugefügt werden. Ich lege mir, der Übersichtlichkeit halber, eine neue an und editiere nicht die vorhandenen.

nano /etc/apt/sources.list.d/nginx.list

Dort fügt ihr folgende Zeilen ein:

deb http://nginx.org/packages/debian/ stretch nginxdeb-src http://nginx.org/packages/debian/ stretch nginx

Anschließend aktuallisieren wir die Paketquellen und installierenNGINX (externer Link) .

apt update&& apt install nginx -y

Da wir es später eh noch brauchen, werden wir direkt noch dieDeffie Hellmann (externer Link) Signatur anlegen. Hierzu wechseln wir ins SSL Verzeichnis des Systems

cd /etc/ssl/certs

Anschließend erstellen wir die PEM-Datei

openssl dhparam -out dhparams.pem2048

Let’s Encrypt Zertifikate

Um die Let’s encrypt Zertifikate auch anfordern zu können, werden wir noch Certbot installieren. Hier bedienen wir uns der Backports Paketquellen von Debian. Diese müssen ebenfalls noch hinzugefügt werden. Ich nehme hierfür die backports.list

deb http://ftp.debian.org/debian stretch-backports main

Auch jetzt aktuallisieren wir wieder die Paketquellen und installieren die notwendigen Pakete

apt install python-certbot-nginx python-certbot-dns-cloudflare -y -t stretch-backports

Die Authentifizierung gegen Cloudflare erfolgt mittels Email-Adresse und API-Key. Letzteren bekommt ihr in eurer Accountverwaltung von Cloudflare. Wir legen uns einen Ordner an in dem wir dann schlussendlich eine Datei setzen werden die unsere Zugangsdaten beherbergt.

mkdir -p ~/.secrets/certbot

In diesem Ordner erstellen wir dann die Datei cloudflare.ini in die folgender Inhalt kommt:

# Cloudflare API credentials used by Certbotdns_cloudflare_email = cloudflare@example.comdns_cloudflare_api_key = 0123456789abcdef0123456789abcdef01234567

Natürlich müsst ihr die zwei Werte entsprechend euren Zugangsdaten anpassen. Anschließend schrenken wir noch die Rechte auf die Datei ein

chmod600 ~/.secrets/certbot/cloudflare.ini

Wenn eure Domain vollständig umgezogen ist, könnt ihr mit folgendem Befehl nun ein Wildcard Zertifikat von Let’s encrypt anfordern

certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini -i nginx -d"*.example.com" -d example.com --server https://acme-v02.api.letsencrypt.org/directory

Natürlich müsst ihr noch die Domain auf eure gewählte umschreiben. Ist alles richtig konfiguriert und hat Cloudflare das DNS Setup schon vollständig übernommen, wird nun das Zertifikat ausgestellt.

NGINX Reverse Proxy

Als letztes kümmern wir uns darum die Weiterleitung einer Anfrage an den externen Webserver weiter zu reichen. Unter der aktuellen Debian Version speichertNGINX (externer Link) seine Konfigurationsdateien unter

/etc/nginx/conf.d

Entsprechend legen wir dort eine neue Datei an. Ich benennen diese Dateien immer nach der eigentlichen Domain, sodass für mich eine schnelle Zuordnung der Konfigurationsdateien möglich ist.

Die Konfiguration im Detail ist nicht von mir, sondern von diesem GIST aus abgeleitet. Ich habe nur ein paar Abänderungen vorgenommen, dass diese auf mein System passen.

server {
listen 80;
server_name www.example.com example.com;
return 301 https://$host$request_uri;
}
# SSL configuration
server {
listen 443 ssl;
server_name www.example.com example.com;
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
# Improve HTTPS performance with session resumption
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
# Enable server-side protection against BEAST attacks
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
# Disable SSLv3
ssl_protocols TLSv1.2;
# Diffie-Hellman parameter for DHE ciphersuites
# $ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
ssl_dhparam /etc/ssl/certs/dhparams.pem;
# Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
# Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s; # Required for LE certificate enrollment using certbot
location '/.well-known/acme-challenge' {
default_type "text/plain";
root /var/www/html;
}
location / {
proxy_pass http://{IPDEINESWEBSERVERS};
}
}

Anschließend testen wir die Konfiguration mittels

nginx -t

Sollte alles in Ordnung sein, starten wirNGINX neu und gehen somit mit unserer neuen Konfiguration live.

systemctl restart nginx

Wenn alles korrekt gelaufen ist, könnt ihr nun eure Webseite, geschützt durch das Zertifikat, erreichen. Sollte das nicht der Fall sein, könnt ihr im error.log entsprechende Fehler finden und diese bereinigen.

Um mehrere Webseiten unter einer IP und einer Domain zu veröffentlichen, ist es am einfachsten, wenn man sich ein sogenannten reverse proxy einrichtet. Die wohl bekannte Variante dazu ist von NGINX. Hierfür gibt es auch diverse Tutorials im Internet.

Meine ganzen Services, die ich extern verfügbar machen möchte, laufen allerdings alsDocker (externer Link) Container. Entsprechend bietet es sich an, auch den reverse proxy Traefik unter Docker als Container laufen zu lassen.

Auch hier gibt es für NGINX – auch in Kombination mit Let’s encrypt Zertifikaten – reichlich Tutorials. Ich hatte mich damals allerdings für einen anderen Weg entscheiden undTraefik (externer Link) als reverse proxy genommen.

Wichtig ist natürlich, dass ihr in eurer Firewall bzw. Router ein NAT auf euren Docker Host einstellt. Port 80 (HTTP) und 443 (HTTPS) sollten entsprechend reichen.

Docker Container mittels Compose

Ich gehe erst mal davon aus, dass ihr Docker in einer der letzten Versionen installiert habt und eure Services, zumindest intern, vollständig funktionieren. Zudem nutze ich Docker Compose zum Verwalten meiner Container. Eine Adaption zu einem docker run command sollte kein Problem darstellen.

---version:'3'services:traefik:image:traefik:latestcontainer_name:traefikrestart:alwaysports:-80:80-443:443-8080:8080volumes:-/var/run/docker.sock:/var/run/docker.sock-./traefik:/etc/traefikenvironment:-"TZ=Europe/Berlin"networks:-traefik_proxy-defaultnetworks:traefik_proxy:external:truedefault:driver:bridge

Ports 80 und 443 werden benötigt, um die entsprechenden Seiten dann auch weiterzuleiten. Port 8080 verwenden wir für das Webfrontend von Traefik. Ihr müsst also aufpassen, dass keine anderen Container diese Ports verwenden. Den Traefik Webport könnt ihr auch durch einen anderen ersetzen.

Zudem mounten wir als Volumes den Docker Socket, um Zugriff auf die laufenden Container zu haben. Als zweites Volume nutzen wir für die Konfigurationsdateien für Traefik.

Netzwerke legen wir an, um Traefik von außen erreichbar zu machen (default Netzwerk) und für das interne Routing zu Containern (traefik_proxy).

Traefik Konfiguration

Im Verzeichnis traefik legen wir nun noch die Datei traefik.toml an, welche folgenden Inhalt bekommt:

logLevel ="INFO"defaultEntryPoints = ["http","https"][web] address =":8080"[docker] domain ="example.com" watch =true exposedbydefault =false# Force HTTPS[entryPoints] [entryPoints.http] address =":80" [entryPoints.http.redirect] entryPoint ="https" [entryPoints.https] address =":443" [entryPoints.https.tls]# Let's encrypt configuration[acme] email="youremail.address@example.com" storage="/etc/traefik/acme/acme.json" entryPoint="https" acmeLogging=true OnHostRule=true [acme.httpChallenge] entryPoint ="http"

Wichtig ist, dass ihr eure Domain unter [docker] und eure Email Adresse unter [acme] richtig anpasst. Die Email Adresse wird für dieLet’s encrypt Zertifikate benötigt.

Im Grundsätzlichen war es das schon für das Setup. Um jetzt Docker Container auch dazu zu bringen, auf die entsprechenden Domains zu hören, müssen wir die Konfiguration der einzelnen Container auch anpassen. Hier mal ein Beispiel von „The Lounge“ (einem IRC Frontend)

---version:'3'services:thelounge:image:thelounge/lounge:latestcontainer_name:theloungevolumes:-/var/docker/thelounge:/home/lounge/datalabels:-"traefik.backend=thelounge"-"traefik.enable=true"-"traefik.frontend.rule=Host:subdomain.example.com"-"traefik.port=9000"-"traefik.docker.network=traefik_proxy"networks:-traefik_proxynetworks:traefik_proxy:external:truedefault:driver:bridge

Folgende Werte müsst ihr pro Container anpassen:

• traefik.backend (Name des Backends – könnt ihr frei vergeben)
• traefik.frontend.rule (die URL, auf dem der Service hören soll)
• traefik.port (der Port, auf dem eure Anwendung hört)

Der Rest kann jeweils übernommen werden. Sollte ihr euren Container schon gestartet haben, solltet ihr diesen beenden, evtl. den Container löschen und neu starten. Ein paar Sekunden später ist der Service dann extern verfügbar.

Ich hatte mir für dieses Jahr fest vorgenommen ein Wildcard Zeritifkat zu kaufen. Die Erstellung von einzelnen Zertifikaten ist nämlich sehr unpraktisch. Glücklicherweise hatLet’s Encrypt (externer Link) vor einiger Zeit Wildcard Zertfiakte entwickelt und der Öffentlichkeit frei gegeben.

Mit ein paar kleinen Anpassungen am DNS konnte ich schon das erste Zertifikat mit Certbot erstellen. Natürlich sollte hier immer die neuste Version genommen werden.

Die Anpassung derNGINX (externer Link) Konfigurationsdateien war ein Kinderspiel, zumal meist nur die Subdomain im Dateinamen des Zertifikates entfernt werden musste. EinmalNGINX neu geladen und mittels SSLLabs getestet: Alles Super!

Anschließend konnte ich auch die alten Zertifikate revoken. Das ist einfach sauberer als sie auslaufen zu lassen. Man weiß ja nie…

Im Laufe der letzten Tage sind dann immer mehr Dienste hinzugekommen, welche ich nun mittels einer sauberen URL zugänglich gemacht habe. Viele Dinge müssen nicht unbedingt von extern erreichbar sein, macht sich allerdings spätestens dann bezahlt, wenn ich einmal von extern ohneVPN Anschluss daheim etwas erledigen möchte – auch wenn es nur bugfixing ist.

Ich empfehle jedem der mehrere Einzelzertifikate mit Let’s encrypt nutzt diese umzustellen. Es ist viel angenehmer wenn man einen neuen Service einrichtet und diesen von außen zugänglich machen möchte.