Container, einfach erklärt.

Container #

Ein laufender, abgeschotteter Prozess, der alles mitbringt, was er braucht: PHP, die Extensions, die Systembibliotheken und die Konfiguration. Er teilt sich den Kernel mit dem Host, startet deshalb in Millisekunden und braucht viel weniger Speicher als eine virtuelle Maschine. Stell ihn dir vor wie deine Anwendung samt eigenem, kleinem Server-Setup in einem Paket.

Bei customcontainer Jedes Image, das du hier baust, läuft als Container in Docker, Podman, Kubernetes oder jedem anderen Standard-Tool.

Siehe auch: Image, Container-Engine

Image #

Container-Image, Docker-Image, Abbild

Die schreibgeschützte Vorlage, aus der ein Container gestartet wird — ein Schnappschuss eines Dateisystems plus ein paar Metadaten, etwa welches Programm laufen soll. Das Image ist der Bauplan, der Container das Haus, das daraus entsteht. Aus einem Image startest du beliebig viele Container.

Bei customcontainer Wir setzen dein Image aus PHP-Version, Architektur und den Extensions zusammen, die deine composer.lock braucht — sonst nichts.

Siehe auch: Layer, Tag, Registry

Layer #

Image-Layer, Schicht

Ein Image ist keine große Datei, sondern ein Stapel aus Layern: Jeder Layer ist ein Satz Dateien, der auf dem darunter aufliegt. Layer werden einzeln gespeichert und geladen. Teilen sich zwei Images einen Layer, wird er nur einmal geholt — und ändert sich ein Layer, muss nur dieser eine neu geladen werden.

Bei customcontainer Jede PHP-Extension liegt in einem eigenen Layer. Bekommt eine Extension einen Fix, ändert sich nur ihr Layer, und deine Server und CI-Runner ziehen nur die Differenz.

Siehe auch: Image, Digest Mehr dazu →

Container-Engine #

Container-Runtime, Docker, Podman

Das Programm, das Images herunterlädt und Container daraus startet. Docker ist das bekannteste, Podman eine kompatible Alternative, die ohne Hintergrunddienst auskommt. Beide verstehen dieselben Images und fast dieselben Befehle — docker run und podman run machen das Gleiche.

Bei customcontainer Der Konfigurator zeigt jeden Pull- und Run-Befehl für beide, umschaltbar mit einem Klick.

Siehe auch: Container, Pull & Push

Dockerfile #

Containerfile, docker build

Eine Textdatei mit Bauanweisungen: Starte von diesem Base Image, installiere diese Pakete, kopiere diese Dateien. docker build arbeitet sie Schritt für Schritt ab und erzeugt ein Image. Der klassische Weg, Images zu bauen — und die Stelle, an der sich über die Jahre Extension-Installationen, Compiler-Pakete und Workarounds stapeln.

Bei customcontainer Für ein PHP-Image von uns brauchst du keins. Willst du deinen Code mit einbacken, reicht ein Zweizeiler, der FROM dein Image startet und deinen Code per COPY hineinlegt.

Siehe auch: Base Image, Container-Definition

Base Image #

Basis-Image, Parent Image, FROM

Das Image, von dem ein Dockerfile mit seiner FROM-Zeile startet, zum Beispiel php:8.4-fpm von Docker Hub. Alles aus dem Base Image landet in deinem Image — auch Tools und Bibliotheken, die deine Anwendung nie benutzt, die aber trotzdem Updates brauchen und trotzdem zur Angriffsfläche zählen.

Bei customcontainer Dein customcontainer-Image taugt als schlankes Base Image für dein eigenes Dockerfile.

Siehe auch: Dockerfile, Angriffsfläche Mehr dazu →

OCI #

Open Container Initiative, OCI-Image

Die Open Container Initiative pflegt die offenen Standards für Image-Formate und Registries. Weil Docker, Podman, Kubernetes und die großen Cloud-Anbieter sie alle umsetzen, läuft ein Image aus einem Tool auch mit allen anderen. „OCI-Image“ heißt also schlicht: ein Standard-Image, das an keinen Hersteller gebunden ist.

Bei customcontainer Unsere Images und unsere Registry sind reines OCI — kein proprietärer Client, kein Plugin, kein Lock-in.

Siehe auch: Image, Registry

Registry #

Container-Registry, Image-Registry, Docker Hub

Ein Server, der Images speichert und auf Anfrage ausliefert — vergleichbar mit Packagist für Composer-Pakete, nur eben für Images. Docker Hub ist die bekannteste öffentliche Registry; Firmen betreiben für ihre eigenen Images oft private Registries.

Bei customcontainer Jeder Account bekommt seinen eigenen Registry-Endpunkt. Deine Images werden von dort ausgeliefert und von nirgendwo sonst.

Siehe auch: Pull & Push, Registry-Endpunkt

Pull & Push #

docker pull, podman pull, docker push, herunterladen

pull lädt ein Image aus einer Registry auf deinen Rechner, push lädt eins hoch. Übertragen werden nur Layer, die du noch nicht hast — deshalb ist der zweite Pull eines ähnlichen Images viel schneller als der erste.

Bei customcontainer Du pullst nur: Wir bauen das Image und legen es in deine Registry, pushen musst du nichts.

Siehe auch: Registry, Tag, Registry Pull Key

Tag #

Image-Tag, latest

Der Teil nach dem Doppelpunkt im Image-Namen, wie in php:8.4. Ein Tag ist ein verschiebbares Etikett: Derselbe Tag kann morgen auf ein anderes Image zeigen. latest ist nur der Standard-Tag und heißt „was zuletzt veröffentlicht wurde“, nicht „die neueste stabile Version“.

Bei customcontainer Jeder Build bekommt einen festen Versions-Tag wie 1.4.2, der sich nie bewegt, plus latest, der immer auf den neuesten Build zeigt.

Siehe auch: Digest, Release & Version

Digest #

sha256, Image-Digest, Hash, Prüfsumme

Ein Fingerabdruck, berechnet aus dem Inhalt, geschrieben als sha256: plus 64 Zeichen. Anders als ein Tag kann er nie auf etwas anderes zeigen: Ändert sich ein einziges Byte, ändert sich der Digest. Per Digest zu pullen ist der strengste Weg, genau das Image zu bekommen, das du getestet hast.

Siehe auch: Tag, Manifest

Manifest #

Image-Manifest

Das Inhaltsverzeichnis eines Images: welche Layer dazugehören, in welcher Reihenfolge und welche Konfiguration dazu passt — jeweils über ihren Digest referenziert. Die Container-Engine liest zuerst das Manifest und holt dann die Layer, die ihr noch fehlen.

Siehe auch: Layer, Digest, Architektur

Architektur #

x86_64, amd64, aarch64, arm64, CPU-Architektur, Apple Silicon

Die Prozessorfamilie, für die ein Image gebaut ist. x86_64 (auch amd64) läuft auf den meisten Servern und Intel/AMD-Rechnern, aarch64 (arm64) auf Apple-Silicon-Macs, AWS Graviton und anderen ARM-Servern. Ein Image für die falsche Architektur startet entweder gar nicht oder läuft langsam in der Emulation.

Bei customcontainer Du wählst x86_64 oder ARM im Dropdown und bekommst ein nativ gebautes Image dafür — gleiche PHP-Version, gleiche Extensions.

Siehe auch: Manifest Mehr dazu →

PHP-Extension #

Erweiterung, ext-, Modul, intl, gd, pdo_mysql, redis

Ein kompiliertes Add-on, das PHP zusätzliche Fähigkeiten gibt, etwa pdo_mysql für MySQL, intl für Internationalisierung oder gd für Bilder. Pakete in deiner composer.json deklarieren als ext-…-Requirement, welche sie brauchen. Manche Extensions sind fest in PHP eingebaut, andere kommen separat dazu.

Bei customcontainer Wir lesen die benötigten Extensions aus deiner composer.lock, und du kannst jede per Klick hinzufügen oder entfernen. Jede Extension, die du weglässt, ist eine weniger zum Patchen.

Siehe auch: Shared Library, Angriffsfläche, composer.lock Mehr dazu →

PHP CLI #

Kommandozeile, php-Binary

PHP auf der Kommandozeile: php script.php, php artisan, bin/console, Composer, PHPUnit oder ein Queue-Worker. Ein CLI-Container führt einen Befehl aus und endet, wenn der Befehl endet.

Bei customcontainer Hak „CLI Package“ an, und das Image startet standardmäßig php — genau richtig für Worker, Cronjobs und CI.

Siehe auch: PHP-FPM, Container-Definition

PHP-FPM #

FastCGI Process Manager, FPM, php-fpm

Der Prozessmanager, der PHP für Web-Requests ausführt. Ein Webserver wie nginx, Caddy oder Apache nimmt den HTTP-Request an und reicht ihn per FastCGI an PHP-FPM weiter. In Container-Setups laufen Webserver und PHP-FPM meist in zwei getrennten Containern.

Bei customcontainer Hak „FPM Package“ an, und das Image startet php-fpm und lauscht auf Port 9000 auf deinen Webserver.

Siehe auch: PHP CLI, Port-Mapping

composer.lock #

Lock-Datei, composer.json

Die Datei, in der Composer die exakte Version jedes installierten Pakets festhält. Sie listet auch, welche PHP-Extensions diese Pakete voraussetzen — und ist damit die verlässlichste Beschreibung dessen, was deine Anwendung zum Laufen braucht.

Bei customcontainer Paste sie auf der Startseite rein, und wir leiten die Extension-Liste daraus ab — kein Raten, kein vergessenes ext--Requirement.

Siehe auch: PHP-Extension, Container-Definition

Distribution #

Distro, Linux-Distribution, Rocky Linux, Debian, Alpine

Die Linux-Variante, aus der die Dateien in einem Image stammen — Debian, Alpine, Rocky Linux und so weiter. Sie bestimmt, woher die Systembibliotheken kommen, wie schnell sie Security-Fixes bekommen und wie lange ein Release unterstützt wird.

Bei customcontainer Unsere Images bauen wir derzeit auf Rocky Linux 9, einer Enterprise-Distribution mit langen Support-Zyklen. Paketmanager und Tools der Distribution sind nicht drin — nur die Dateien, die PHP tatsächlich benutzt.

Siehe auch: RPM-Paket, Base Image

RPM-Paket #

Paket, rpm, dnf

Das Paketformat von Red-Hat-artigen Distributionen wie Rocky Linux. Jede Bibliothek und jede PHP-Extension kommt als Paket mit Name, Version und Release-Nummer — damit lässt sich exakt sagen, was installiert ist und wann es sich geändert hat.

Bei customcontainer Jeder Build hält die exakten Paketversionen fest, die er enthält. Daraus speisen sich deine Build-Historie und der Update-Feed.

Siehe auch: Distribution, Update-Feed

Shared Library #

Systembibliothek, Bibliothek, .so-Datei, libxml2, OpenSSL, ImageMagick

Code, den sich mehrere Programme teilen, statt dass jedes seine eigene Kopie mitbringt — OpenSSL für Verschlüsselung, libxml2 für XML, ImageMagick für Bilder. Viele PHP-Extensions sind nur eine dünne Hülle um so eine Bibliothek. Eine Sicherheitslücke in der Bibliothek ist damit eine Sicherheitslücke in deiner PHP-Anwendung.

Bei customcontainer Der Layer einer Extension enthält die Bibliotheken, gegen die sie gelinkt ist. Lässt du die Extension weg, verschwinden ihre Bibliotheken mit.

Siehe auch: PHP-Extension, CVE

Locale #

glibc-Locale, setlocale, de_DE, Spracheinstellungen, Gebietsschema

Sprach- und Regionaleinstellungen auf Systemebene: wie Datum, Zahlen und Währungen formatiert werden und wie Text sortiert wird. PHP-Funktionen wie setlocale() oder strftime() funktionieren nur mit Locales, die im Image tatsächlich installiert sind.

Bei customcontainer Jedes Image enthält C.utf8. Weitere Locales, etwa Deutsch oder Französisch, fügst du im Konfigurator hinzu.

Siehe auch: Zeitzonendaten

Zeitzonendaten #

tzdata, Zeitzone, timezone, date.timezone

Die Datenbank der Zeitzonen der Welt samt ihrer Sommerzeitregeln. Ohne sie kennt ein Container nur UTC, und die Umrechnung eines Zeitstempels nach „Europe/Berlin“ auf Systemebene geht schief.

Bei customcontainer Optional: Hak „Include timezones“ an, dann kommt der tzdata-Layer dazu.

Siehe auch: Locale

Shell #

sh, bash, BusyBox, docker exec, Kommandozeile

Eine Kommandozeile im Container — das, was du mit docker exec -it … sh bekommst. Praktisch zum Debuggen, in Produktion aber genauso praktisch für einen Angreifer. Viele minimale Images kommen deshalb ohne.

Bei customcontainer Optional: Hak „Include shell“ an, dann kommt BusyBox dazu — ein einzelnes kleines Programm, das sh und die üblichen Grundbefehle mitbringt.

Siehe auch: Angriffsfläche, Container

Container-Definition #

Container-Konfiguration, Konfigurator

Das, was du im Konfigurator einstellst: PHP-Version, Architektur, Distribution, CLI und/oder FPM, die Extensions und die optionalen Extras wie Shell, Zeitzonendaten und Locales. Eine Definition kannst du mit deinem ganzen Team teilen — Entwicklung, CI und Produktion nutzen dann dasselbe Image.

Bei customcontainer Im kostenlosen Account speicherst du bis zu vier Definitionen.

Siehe auch: composer.lock, Release & Version

Core-Layer #

Basis-Layer

Der eine Layer, den jedes Image bekommt: das Grund-Dateisystem, System-User, CA-Zertifikate für HTTPS-Verbindungen, die Standard-php.ini und die Systembibliotheken, auf denen alles andere aufbaut. Alle anderen Layer liegen darauf.

Siehe auch: Layer, Shared Library Mehr dazu →

Release & Version #

SemVer, Semantic Versioning, Major, Minor, Patch, Versionsnummer

Jeder Build deines Containers bekommt eine Versionsnummer nach Semantic Versioning, MAJOR.MINOR.PATCH. Die Nummer sagt dir, was für eine Änderung dich erwartet: Patch bei einem automatischen Security- oder Bugfix-Rebuild, Minor, wenn du eine Extension hinzugefügt hast, Major, wenn du eine entfernt oder PHP-Version bzw. Architektur gewechselt hast.

Bei customcontainer Jede Version ist als eigener Tag pullbar — du kannst also 2.3.1 pinnen und nachziehen, wann es dir passt.

Siehe auch: Tag, Build-Historie, Webhook

Build-Historie #

Diff, Audit Trail, Changelog, Verlauf

Die Liste aller Versionen eines Containers mit den Paketen, Versionen und Layern, die jeweils drin waren. Wähl zwei beliebige Versionen und vergleich sie — du siehst, was hinzugekommen, weggefallen oder aktualisiert worden ist.

Bei customcontainer Steht auf der Detailseite jedes Containers — nützlich vor einem Deploy und wenn ein Auditor wissen will, was im März lief.

Siehe auch: Release & Version, SBOM Mehr dazu →

Registry-Endpunkt #

Registry-URL, Registry-Adresse

Die Adresse, von der du deine Images pullst. Dein Account hat einen eigenen, nach dem Muster <id>.registry.customcontainer.io/<container-name>, und er spricht das Standard-Registry-Protokoll — Docker, Podman, Kubernetes und CI-Systeme nutzen ihn ohne zusätzliches Setup.

Siehe auch: Registry, Registry Pull Key

Registry Pull Key #

Registry-Token, Registry-Passwort, docker login, private Registry, Zugangsschlüssel

Das Passwort für deine private Registry. Du loggst dich einmal mit docker login (oder podman login) ein, mit deiner Account-E-Mail als Benutzername und dem Pull Key als Passwort; danach funktionieren Pulls einfach.

Bei customcontainer Den Key findest du in deinem Profil. Ändern lässt er sich nicht — wenn er leakt, generierst du einen neuen, und der alte ist ab dann ungültig.

Siehe auch: Registry-Endpunkt, Pull & Push

Webhook #

Benachrichtigung, Callback-URL

Eine URL von dir, die wir aufrufen, sobald etwas passiert — hier: sobald eine neue Version deines Containers zum Pullen bereitsteht. So erfährt deine CI-Pipeline oder dein Team-Chat von einem Update, ohne dass jemand nachsehen muss.

Bei customcontainer Stellst du pro Container im Konfigurator ein, optional mit Bearer-Token, und kannst dort direkt einen Testaufruf schicken.

Siehe auch: Release & Version, CI/CD-Pipeline

Update-Feed #

Updates, Changelog, Aktualisierungen

Die öffentliche Liste der Extension- und Library-Updates, die unsere Build-Pipeline zuletzt übernommen hat. Sie zeigt, was sich wann geändert hat, unabhängig vom Container eines einzelnen Kunden.

Siehe auch: Release & Version, CVE Mehr dazu →

CVE #

Common Vulnerabilities and Exposures, Sicherheitslücke, Schwachstelle, Security Advisory

Eine öffentlich katalogisierte Sicherheitslücke mit einer ID wie CVE-2024-4577. Security-Scanner gleichen die Pakete in einem Image mit diesen Listen ab und melden jeden Treffer — deshalb produzieren Images voller ungenutzter Pakete so lange Reports.

Siehe auch: Angriffsfläche, Update-Feed Mehr dazu →

Angriffsfläche #

Attack Surface, minimales Image, Hardening, Härtung

Alles in einem System, was ein Angreifer auszunutzen versuchen kann. Jede Extension, jede Bibliothek und jedes Tool in einem Image zählt dazu — egal, ob deine Anwendung es benutzt oder nicht. Die kleinste Angriffsfläche ist schlicht die Software, die gar nicht erst da ist.

Bei customcontainer Genau das ist die Grundidee von customcontainer: Ins Image kommt nur, was deine Anwendung tatsächlich benutzt.

Siehe auch: CVE, PHP-Extension Mehr dazu →

End of Life (EOL) #

Security-Support, Supportende, veraltete PHP-Version

Das Datum, ab dem eine Softwareversion keine Fixes mehr bekommt. php.net unterstützt jede PHP-Version für einen festen Zeitraum — derzeit vier Jahre. Danach bleiben Sicherheitslücken in den offiziellen Releases offen.

Bei customcontainer Wir bauen und patchen Images auch für PHP-Versionen jenseits ihres php.net-Supportendes, etwa 7.4.

Siehe auch: CVE, Release & Version Mehr dazu →

CI/CD-Pipeline #

Continuous Integration, Continuous Delivery, GitLab CI, GitHub Actions

Automatisierte Schritte, die bei jedem Push laufen: Abhängigkeiten installieren, Tests ausführen, bauen, deployen. Jeder Job startet meist in einem frischen Container — welches Image er zieht und wie groß es ist, bestimmt also direkt, wie lange jeder Pipeline-Lauf dauert.

Bei customcontainer Dein Image taugt als CI-Job-Image — PHP und die richtigen Extensions sind schon drin, pro Job gibt es nichts zu installieren. In GitLab CI ergänzt du entrypoint: [""], weil das Image standardmäßig PHP startet.

Siehe auch: Webhook, Layer Mehr dazu →

Docker Compose #

compose.yaml, docker-compose.yml, podman-compose

Eine YAML-Datei, die mehrere zusammengehörige Container beschreibt — etwa nginx, PHP-FPM und MariaDB — samt Ports, Volumes und Umgebungsvariablen. docker compose up startet alle auf einmal. Der übliche Weg, einen PHP-Stack lokal laufen zu lassen.

Siehe auch: Volume & Bind Mount, Port-Mapping, Umgebungsvariable

Kubernetes #

k8s, Pod, Cluster

Eine Plattform, die Container über einen Cluster aus Servern hinweg betreibt: Sie startet sie, startet sie nach einem Absturz neu, skaliert sie und leitet Traffic zu ihnen. Kubernetes pullt Images aus Registries genau wie Docker.

Siehe auch: Docker Compose, Registry

Volume & Bind Mount #

Mount, -v, persistenter Speicher, Speicher

Das eigene Dateisystem eines Containers ist weg, sobald der Container entfernt wird. Um Daten zu behalten oder deinen Quellcode während der Entwicklung im Container sichtbar zu machen, mountest du ein Verzeichnis hinein — zum Beispiel -v $(pwd):/app.

Siehe auch: Container, Docker Compose

Port-Mapping #

Port-Weiterleitung, -p, expose

Verbindet einen Port auf deinem Rechner mit einem Port im Container, zum Beispiel -p 8080:80. Container im selben Compose-Setup oder Netzwerk erreichen sich direkt; das Mapping brauchst du nur für den Zugriff von außen.

Siehe auch: PHP-FPM, Docker Compose

Umgebungsvariable #

Environment Variable, env var, .env, -e, getenv

Schlüssel-Wert-Einstellungen, die einem Container beim Start mitgegeben werden, etwa -e APP_ENV=production. Der übliche Weg, dasselbe Image für Entwicklung, Staging und Produktion unterschiedlich zu konfigurieren, ohne für jede Umgebung ein eigenes Image zu bauen.

Siehe auch: Docker Compose

SBOM #

Software Bill of Materials, Software-Stückliste, Inventar, Compliance

Eine maschinenlesbare Liste aller Softwarekomponenten eines Produkts samt Versionen. Wird zunehmend von Kunden, Auditoren und Regulierung wie dem EU Cyber Resilience Act verlangt.

Bei customcontainer Deine Build-Historie hält jedes Paket in jedem Image fest, das wir für dich gebaut haben — die Container-Seite eines solchen Inventars. Deine eigenen Composer-Abhängigkeiten deckt sie nicht ab.

Siehe auch: Build-Historie, CVE Mehr dazu →