torben/chemenu

Fork 0

Files

T

torben 18ae28f918

CI / verify (push) Failing after 32s

Details

Release / release (push) Successful in 38s

Details

Chemenu 2.1.0 - deterministischer Wissenskompiler

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.

2026-09-01 16:26:14 +02:00

4.4 KiB

Raw Blame History

type, entity_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type

entity_type

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:

# 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:

# 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:

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

4.4 KiB Raw Blame History