<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker on Yanis Gramitzky - Infrastructure &amp; Automation</title><link>https://ygramitzky.de/posts/docker/</link><description>Recent content in Docker on Yanis Gramitzky - Infrastructure &amp; Automation</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 19 Mar 2026 09:00:00 +0100</lastBuildDate><atom:link href="https://ygramitzky.de/posts/docker/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker Compose Deep Dive: Every Option Explained</title><link>https://ygramitzky.de/posts/docker/docker_compose/</link><pubDate>Thu, 19 Mar 2026 09:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/docker_compose/</guid><description>&lt;h2 id="what-is-docker-compose"&gt;What Is Docker Compose?&lt;/h2&gt;
&lt;p&gt;Docker Compose is a tool for defining and running &lt;strong&gt;multi-container applications&lt;/strong&gt;. Instead of typing long &lt;code&gt;docker run&lt;/code&gt; commands with dozens of flags, you describe your entire stack — services, networks, volumes, secrets — in a single YAML file. One command (&lt;code&gt;docker compose up&lt;/code&gt;) brings everything to life.&lt;/p&gt;
&lt;p&gt;Compose is the standard way to run local development environments, CI pipelines, and even lightweight production workloads. Understanding its full vocabulary gives you precise control over how your containers behave.&lt;/p&gt;</description></item><item><title>Grafana &amp; Prometheus – Monitoring Stack für Docker und Proxmox</title><link>https://ygramitzky.de/posts/docker/grafana-monitoring/</link><pubDate>Thu, 09 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/grafana-monitoring/</guid><description>&lt;h2 id="wie-spielen-die-akteure-zusammen"&gt;Wie spielen die Akteure zusammen?&lt;/h2&gt;
&lt;p&gt;Monitoring in diesem Stack basiert auf einem klaren Pull-Prinzip: Prometheus fragt aktiv bei den Datenquellen an – nicht umgekehrt. Jede Komponente hat eine klar definierte Rolle.&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;┌─────────────────────────────────────────────────────────────────┐
│ monitoring network │
│ │
│ ┌──────────────┐ scrape ┌─────────────────────────┐ │
│ │ Prometheus │◄────────────────│ cAdvisor :8080 │ │
│ │ :9090 │◄────────────────│ pve-exporter :9221 │ │
│ │ │◄────────────────│ traefik :8899 │ │
│ │ │◄────────────────│ prometheus :9090 │ │
│ └──────┬───────┘ └─────────────────────────┘ │
│ │ query (PromQL) │
│ ┌──────▼───────┐ ┌─────────────────────────┐ │
│ │ Grafana │ │ Redis │ │
│ │ :3000 │ │ (cAdvisor session) │ │
│ └──────────────┘ └─────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
│ proxy network
┌────▼─────┐
│ Traefik │ → grafana.example.com (Authentik-geschützt)
└──────────┘
Außerhalb des monitoring network:
┌─────────────────────────────────┐
│ Proxmox VE 192.168.100.21 │
│ pve-exporter liest PVE API │
└─────────────────────────────────┘
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;strong&gt;Prometheus&lt;/strong&gt; ist die Zentrale. Es scraped alle Datenquellen in regelmäßigen Intervallen, speichert die Zeitreihendaten in seiner eigenen TSDB und beantwortet PromQL-Abfragen von Grafana.&lt;/p&gt;</description></item><item><title>Gluetun – Container sicher über VPN anbinden</title><link>https://ygramitzky.de/posts/docker/gluten-vpn/</link><pubDate>Tue, 07 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/gluten-vpn/</guid><description>&lt;h2 id="container-im-rechenzentrum--sicher-erreichbar"&gt;Container im Rechenzentrum – sicher erreichbar&lt;/h2&gt;
&lt;p&gt;Eine Applikation läuft im Rechenzentrum. Sie enthält sensible Daten: Kundendaten, interne Systeme, Produktionsdatenbanken. Direkt über das öffentliche Internet erreichbar zu sein ist keine Option – zu groß das Angriffspotential, zu hoch die Compliance-Anforderungen.&lt;/p&gt;
&lt;p&gt;Die klassische Lösung: ein VPN-Tunnel zwischen dem Rechenzentrum und dem eigenen Netzwerk. Jede Verbindung zu den Applikationen läuft verschlüsselt durch diesen Tunnel – von außen ist nichts sichtbar, kein Port offen, keine Angriffsfläche.&lt;/p&gt;</description></item><item><title>Beszel – Leichtgewichtiges Server-Monitoring für den Homelab</title><link>https://ygramitzky.de/posts/docker/breszel/</link><pubDate>Mon, 06 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/breszel/</guid><description>&lt;h2 id="server-im-blick-behalten--ohne-overhead"&gt;Server im Blick behalten – ohne Overhead&lt;/h2&gt;
&lt;p&gt;Grafana, Prometheus, Netdata alle leistungsfähig, alle aufwendig. Wer einfach wissen möchte ob ein Server noch läuft, wie viel RAM ein Container verbraucht und eine E-Mail bekommt wenn die Disk voll wird, braucht keinen Monitoring-Stack mit stundenlanger Konfiguration.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Beszel&lt;/strong&gt; ist ein Open-Source-Monitoring-Tool, geschrieben in Go, mit einem schlanken PocketBase-Dashboard. Der Agent benötigt nur 6 MB RAM, der Hub etwa 23 MB – ein Bruchteil dessen, was Netdata oder ein Prometheus-Stack verbrauchen.&lt;/p&gt;</description></item><item><title>Traefik – Der Reverse Proxy für Docker</title><link>https://ygramitzky.de/posts/docker/traefik/</link><pubDate>Sun, 05 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/traefik/</guid><description>&lt;h2 id="das-problem-mit-vielen-diensten-auf-einem-server"&gt;Das Problem mit vielen Diensten auf einem Server&lt;/h2&gt;
&lt;p&gt;Ein Server, viele Dienste. Immich auf Port 2283, Portainer auf 9443, Mailcow auf 8030, Stirling-PDF auf 8088. Jeder Dienst hat seinen eigenen Port – und der Nutzer muss sich alle merken, Zertifikate manuell verwalten und Ports in der Firewall freigeben.&lt;/p&gt;
&lt;p&gt;Das skaliert nicht. Die Lösung ist ein &lt;strong&gt;Reverse Proxy&lt;/strong&gt; – ein vorgelagerter Dienst, der eingehende Anfragen anhand der Domain auf den richtigen Container weiterleitet. Nur Port 80 und 443 müssen offen sein. Alle anderen Ports bleiben intern.&lt;/p&gt;</description></item><item><title>Portainer – Docker mit einer Weboberfläche verwalten</title><link>https://ygramitzky.de/posts/docker/portainer/</link><pubDate>Sat, 04 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/portainer/</guid><description>&lt;h2 id="docker-auf-der-kommandozeile--und-eine-alternative"&gt;Docker auf der Kommandozeile – und eine Alternative&lt;/h2&gt;
&lt;p&gt;Wer Docker im Alltag betreibt, kennt die üblichen Befehle: &lt;code&gt;docker ps&lt;/code&gt;, &lt;code&gt;docker logs&lt;/code&gt;, &lt;code&gt;docker compose up&lt;/code&gt;. Das funktioniert – ist aber nicht immer komfortabel, besonders wenn mehrere Container, Volumes und Netzwerke gleichzeitig im Blick behalten werden müssen.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Portainer&lt;/strong&gt; ist eine Web-Oberfläche für Docker. Container starten, stoppen, Logs lesen, Images verwalten, Volumes inspizieren – alles im Browser, ohne Terminal.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;💡 &lt;strong&gt;Niveau:&lt;/strong&gt; Einsteigerfreundlich. Ein laufender Docker-Host wird vorausgesetzt.&lt;/p&gt;</description></item><item><title>Immich – Selbstgehostete Fotoverwaltung als Google Photos Alternative</title><link>https://ygramitzky.de/posts/docker/immich/</link><pubDate>Thu, 02 Jan 2025 00:00:00 +0100</pubDate><guid>https://ygramitzky.de/posts/docker/immich/</guid><description>&lt;h2 id="wem-gehören-die-eigenen-fotos"&gt;Wem gehören die eigenen Fotos?&lt;/h2&gt;
&lt;p&gt;Google Photos, iCloud, Amazon Photos – sie alle bieten bequemen Speicher, smarte Suche und automatische Sortierung. Der Preis dafür ist nur selten in Euro. Meistens zahlt man mit Daten, mit Abhängigkeit, mit dem stillen Einverständnis, dass ein Konzern die eigenen Erinnerungen verwaltet.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Immich&lt;/strong&gt; ist die Antwort darauf – eine selbstgehostete Foto- und Video-Bibliothek, die sich anfühlt wie Google Photos, aber auf dem eigenen Server läuft.&lt;/p&gt;</description></item><item><title>Stirling-PDF – Ein vollständiges PDF-Werkzeug, selbst gehostet</title><link>https://ygramitzky.de/posts/docker/stirlingpdf/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ygramitzky.de/posts/docker/stirlingpdf/</guid><description>&lt;h2 id="das-problem-mit-pdf-tools"&gt;Das Problem mit PDF-Tools&lt;/h2&gt;
&lt;p&gt;Das Internet ist voll von PDF-Tools – und fast alle haben einen Haken. Zwei PDFs zusammenfügen? Kreditkarte hinterlegen. Eine Seite drehen? Nur mit Wasserzeichen. Text aus einem Scan extrahieren? Premium-Funktion.&lt;/p&gt;
&lt;p&gt;Neben den Kosten gibt es ein weiteres Problem: Die Dokumente landen auf fremden Servern. Gehaltsabrechnungen, Verträge, Arztbriefe – einfach hochgeladen, weil es gerade praktisch war.&lt;/p&gt;
&lt;p&gt;Stirling-PDF löst beides.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="was-ist-stirling-pdf"&gt;Was ist Stirling-PDF?&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Stirling-PDF&lt;/strong&gt; ist eine selbstgehostete Web-Anwendung mit über 50 PDF-Funktionen. Alles läuft lokal, in einem einzigen Docker-Container, ohne Cloud-Anbindung:&lt;/p&gt;</description></item><item><title>Mailcow – Ein vollständiger Mailserver auf eigenem Docker-Host</title><link>https://ygramitzky.de/posts/docker/mailcow/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ygramitzky.de/posts/docker/mailcow/</guid><description>&lt;h2 id="warum-ein-eigener-mailserver"&gt;Warum ein eigener Mailserver?&lt;/h2&gt;
&lt;p&gt;E-Mail ist die älteste und verlässlichste digitale Kommunikationsform – und gleichzeitig die am stärksten zentralisierte. Google, Microsoft und ein Handvoll weiterer Anbieter verarbeiten den Großteil des globalen E-Mail-Verkehrs. Wer seine eigene Domain betreibt, gibt die Kontrolle über das Herzstück seiner digitalen Identität meist trotzdem ab.&lt;/p&gt;
&lt;p&gt;Mailcow ändert das. Ein vollständiger Mailserver mit Webmail, Kalender, Kontakten, Spamfilter, Virenschutz und Zwei-Faktor-Authentifizierung – containerisiert, wartbar, erweiterbar.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;⚠️ &lt;strong&gt;Niveau:&lt;/strong&gt; Fortgeschritten. Grundkenntnisse in Docker, DNS und Linux werden vorausgesetzt. Ein Mailserver ist kein Lernprojekt für den Einstieg – Fehlkonfigurationen haben direkte Auswirkungen auf Zustellbarkeit und Sicherheit.&lt;/p&gt;</description></item></channel></rss>