torben
18ae28f918
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki: raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren Grenzen in Code durchgesetzt sind statt im Prompt. Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44 Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist. Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs. Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte. Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet - siehe NOTICE.
137 lines
4.4 KiB
Markdown
137 lines
4.4 KiB
Markdown
---
|
|
type: types/entity.md
|
|
entity_type: technology
|
|
tags: [containers, containerization, docker, runtime]
|
|
created: 2026-07-25
|
|
modified: 2026-09-01
|
|
related: [Act Runner, Gitea Actions]
|
|
sources: [Source - Docker Cheatsheet]
|
|
confidence: 0.95
|
|
confidence_base: 0.95
|
|
provenance: sourced
|
|
summary: Container-Plattform als Industriestandard für CI/CD-Infrastruktur, mit BuildKit-Daemon und entfernter Docker-Verwaltung über SSH.
|
|
---
|
|
# Docker
|
|
|
|
**Typ:** Technology (Container Platform)
|
|
|
|
## Beschreibung
|
|
|
|
Docker ist die Industrie-Standard-Container-Plattform, die in der gesamten CI/CD-Infrastruktur für Container-Laufzeit, Build-Ausführung und Service-Bereitstellung verwendet wird. Sie bietet die Grundlage für die Ausführung von Containern auf `ci-runner.example.net` und `docker-host.example.net`.
|
|
|
|
## Kerndaten
|
|
|
|
- **Typ:** Container-Plattform
|
|
- **Status:** Aktiv
|
|
- **Zweck:** Container-Laufzeit und Build-Ausführung
|
|
- **Lizenz:** Apache 2.0
|
|
- **Geschrieben in:** Go
|
|
|
|
## Architektur in der Infrastruktur
|
|
|
|
### Auf ci-runner.example.net
|
|
- **Docker-Daemon:** Docker-Service auf Host-Ebene
|
|
- **Runner-Container:** `act_runner` läuft als Docker-Container
|
|
- **BuildKit-Daemon:** `moby/buildkitd` läuft als Docker-Container auf Port 1234
|
|
- **Job-Container:** Kurzlebige Container pro CI-Job in isolierten Bridge-Netzen
|
|
|
|
### Auf dem Docker-Host
|
|
- **Legacy-Container:** Werden von `ci-runner.example.net` aus remote verwaltet
|
|
- **Docker-Daemon:** Standard Docker-Service
|
|
- **Zugriff:** Via SSH aus CI-Workflows
|
|
|
|
## Konfigurationsdetails
|
|
|
|
### Docker-Socket-Anbindung
|
|
- **Ort:** `/var/run/docker.sock`
|
|
- **Angebunden an:** `act_runner`-Container (für BuildKit-Verwaltung)
|
|
- **NICHT angebunden an:** Job-Container (Sicherheit: vermeidet DinD-Risiken)
|
|
|
|
### Network-Modi
|
|
- **Runner:** `host`-Network-Modus für Cache-Anbindung
|
|
- **Jobs:** Isolierte temporäre Bridge-Netze (leeres `container.network`)
|
|
- **BuildKit:** `bridge`-Netz mit Port 1234 freigegeben
|
|
|
|
## Fernverwaltung
|
|
|
|
### SSH-basierte Docker-Kontrolle
|
|
CI-Workflows auf `ci-runner.example.net` verwalten Docker auf `docker-host.example.net`:
|
|
|
|
```bash
|
|
# Set Docker host to remote via SSH
|
|
export DOCKER_HOST=ssh://ci@192.0.2.10
|
|
|
|
# Execute Docker commands remotely
|
|
docker ps
|
|
docker-compose up -d
|
|
```
|
|
|
|
### Authentifizierung
|
|
- **SSH-Schlüssel:** Ed25519-Schlüssel aus 1Password "CI-CD"-Vault
|
|
- **Benutzer:** ci
|
|
- **Methode:** Standard-SSH-Authentifizierung
|
|
|
|
## Sicherheitsaspekte
|
|
|
|
### Docker-in-Docker (DinD) - Vermeidung
|
|
Traditioneller DinD-Ansatz:
|
|
```bash
|
|
# NOT USED - Security risk
|
|
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
|
|
```
|
|
|
|
**Stattdessen:**
|
|
- BuildKit-Daemon läuft separat
|
|
- Job-Container verbinden sich via TCP
|
|
- Kein Zugriff auf Host Docker-Socket in Jobs
|
|
|
|
### Vorteile
|
|
- **Isolation:** Job-Container können nicht auf Host Docker zugreifen
|
|
- **Sicherheit:** Reduzierte Angriffsfläche
|
|
- **Kontrolle:** Zentralisierte Build-Infrastruktur
|
|
|
|
## Beziehungen
|
|
|
|
- **Verwendet von:** [[Act Runner]], [[Gitea Actions]]
|
|
- **Teil von:** Kerninfrastruktur
|
|
|
|
## Version und Kompatibilität
|
|
|
|
### Kompatibilitätshinweise
|
|
- **Debian 13:** Exzellente Docker-Unterstützung (Referenzplattform)
|
|
- **Arch Linux:** Gute Docker-Unterstützung für Build-Szenarien
|
|
- **Alpine Linux:** Unterstützt, aber eingeschränkt durch musl libc für einige Tools
|
|
|
|
### 1Password CLI-Kompatibilität
|
|
- **Funktioniert:** glibc-basierte Distributionen (Debian, Arch)
|
|
- **Funktioniert nicht:** musl libc-basierte Distributionen (Alpine) mit Exitcode 127
|
|
- **Auswirkung:** Container-Build-Jobs verwenden `debian:trixie-slim` anstelle von Alpine
|
|
|
|
## Volume-Verwaltung und Fehlerbehebung
|
|
|
|
### Overlay-FS-Auflösung
|
|
Bei der Fehlerbehebung von Backup-Problemen, gesperrten Dateien oder Berechtigungsproblemen können Sie Overlay-Dateisystem-Verzeichnisse ihren Containern zuordnen:
|
|
|
|
```bash
|
|
for container in $(docker ps --all --quiet --format '{{ .Names }}'); do
|
|
echo "$(docker inspect $container --format '{{.GraphDriver.Data.MergedDir }}' | grep -Po '^.+?(?=/merged)' ) = $container"
|
|
done
|
|
```
|
|
|
|
**Ausgabe:** Listet alle Overlay-Verzeichnisse unter `/var/lib/docker/overlay2/` mit ihren entsprechenden Container-Namen auf.
|
|
|
|
**Anwendungsfall:** Identifiziert, welcher Container ein bestimmtes Overlay-Verzeichnis besitzt (z. B. `/var/lib/docker/overlay2/768... = starwars`).
|
|
|
|
## Siehe auch
|
|
|
|
- Primärer Docker-Host
|
|
- Legacy Docker-Host
|
|
- Build-System mit Docker
|
|
- [[Act Runner]] - Docker-Container
|
|
- [[Gitea Actions]] - CI/CD mit Docker
|
|
- Verwendet Docker als Laufzeit
|
|
concept
|
|
concept
|
|
- [[Source - Docker Cheatsheet]]
|
|
|