ansible-devcontainer

Gemeinsames Ansible-Image für PyloNet (ansible/site-pylonet) und UMG (umg/ansible): ansible-core + ansible-lint (ansible-dev-tools) in einem venv, git/openssh, Shell-Skel und ein Entry-Point, der die Container- Benutzerdaten auf die Host-UID umschreibt und die Collections der Umgebung zur Laufzeit installiert.

Was drin ist / was nicht

• drin: Toolchain (venv unter /opt/ansible-tools), Basis-Pakete, Shell-Skel, Entry-Point
• nicht drin: Ansible-Collections — die installiert der Entry-Point beim Start aus der requirements.yml des consuming-Repos (liegt gemountet unter /appdata) nach /home/appuser/.ansible/collections (Ansible-Default-Suchpfad, daher keine ansible.cfg-Anpassung in den consuming-Repos nötig). Fehlt die requirements.yml (z. B. in Collection-Repos), werden stattdessen die dependencies: der galaxy.yml als Installationsliste verwendet — niemals beide gleichzeitig. Private pylonet.*-Abhängigkeiten kommen dabei per SSH (ssh-agent) vom master-Branch des jeweiligen ansible/<X>-collection-Repos (die Versionsangabe wird ignoriert — master ist der letzte Release-Stand); alle übrigen Abhängigkeiten kommen von den Galaxy-Servern. Bereits installierte Pins werden übersprungen (No-Op; Git-Quellen sind die Ausnahme, die bei jedem Start neu geklont werden). Am Ende des Setups schreibt der Entry-Point Ich habe fertig in die Container-Logs — ist die Zeile da, sind alle Collections installiert. Git-Collections: Primär per Token — GALAXY_ACCESS_TOKEN aus der .env des consuming-Repos kommt 1:1 als ENV rein, der Entry-Point schreibt die git@-Pins daraus auf https://x:<token>@<host>/ um (kein ssh-agent nötig — der Weg für UMG, wo die Kollegen keinen PyloNet-Key haben). Ohne Token: git@-Pins laufen über den eingebundenen ssh-agent.
• nicht drin: Inventar, Plays, Secrets — die gehören in die consuming-Repos.

Das Image baut ausschließlich aus öffentlichen Paketen (kein BuildKit-Secret, kein Token im Build), ist daher öffentlich.

Nutzung (docker-compose im consuming-Repo)

services:
  ansible:
    image: gitlab.pylo.net/public/ansible-devcontainer:latest  # oder getaggt
    pull_policy: always
    working_dir: /appdata
    environment:
      - DOCKER_UID=${DOCKER_UID:-}
      - DOCKER_GID=${DOCKER_GID:-}
      # Token fuer die pylonet.*-Git-Collections (.env des consuming-
      # Repos, Scope read:repository); leer = ssh-agent-Rueckfall.
      - GALAXY_ACCESS_TOKEN=${GALAXY_ACCESS_TOKEN:-}
      - SSH_AUTH_SOCK=/run/ssh-agent.sock
      - TZ=Europe/Berlin
    volumes:
      - ./:/appdata
      - ${SSH_AUTH_SOCK:-/dev/null}:/run/ssh-agent.sock
    command: ["sleep", "infinity"]
    stdin_open: true
    tty: true

DOCKER_UID/DOCKER_GID sind Pflicht (z. B. $(id -u)/$(id -g)); ohne Werte oder mit 0 stoppt der Start bewusst hart. appuser läuft im Image mit UID 0, der Entry-Point biegt die Container-Passe auf die Ziel-IDs um und droppt die Privilegien — kein root-Prozess, kein user: in der Compose.

VS Code Remote-Container: eine devcontainer.json im consuming-Repo weist per dockerComposeFile auf die Compose-Datei (Service ansible).

Build & Versionierung

Build läuft in der CI nur auf Tags (v*) und pusht gitlab.pylo.net/public/ansible-devcontainer:<tag> + :latest (Registry-Secret REGISTRY_TOKEN, Org ansible). Manueller Build ohne CI: docker build -t ansible-devcontainer:test . (funktioniert, der Build braucht keine Secrets).

latest = letzter getaggter Stand; consuming-Repos können :latest ziehen oder ein Tag pinnen (empfohlen für reproduzierbare Umgebung).