Conversation
When rc != 0, the JSON response now includes:
- error: the fatal/FAILED line from Ansible output
- log_multiline: last 10 lines for context
Previously returned only {rc: 2, result: []} with no explanation.
Now returns {rc: 2, result: [], error: "...", log_multiline: [...]}
The CORS regex env var gets mangled by systemd EnvironmentFile backslash parsing. Adding the lab subnet to the hardcoded default avoids that issue entirely.
…api.json - Dockerfile: rewrite to two-stage build (builder → runtime) using python:3.13-bookworm / python:3.13-slim-bookworm; venv installed to /opt/venv in builder and copied to runtime stage; Ansible collections copied from /usr/share/ansible/collections; correct ANSIBLE_COLLECTIONS_PATH env var for ansible-core 2.19.1 - docker-compose.yml: production-oriented; no source bind-mounts; image tag driven by IMAGE_NAME env var (default ghcr.io/range42/range42-backend-api:latest) - openapi.json: export current API spec for Kong gateway bootstrap - README.md: add Docker Build & Publish section with GHCR login, build, tag and push commands; add openapi.json regeneration snippet - .dockerignore: exclude openapi.json from build context Closes #64
…ce, compose fixes - Dockerfile: add ARG UID/GID (default 1000) and non-root user `range42`; chown /app to range42; set HOME=/home/range42; add USER directive before EXPOSE/HEALTHCHECK/CMD - docker-compose.yml: pass UID/GID build args; update SSH key volume mount path to /home/range42/.ssh; restore API_BACKEND_PUBLIC_PLAYBOOKS_DIR default to /app/ (regression fix); add commented inventory bind-mount override; annotate VAULT_PASSWORD as dev-only - README.md: document non-root user, UID/GID build args, SSH known_hosts requirement, and VAULT_PASSWORD_FILE as the production vault secret pattern
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #64
Delivers all four artifacts required by the issue:
builder→runtime) on Debian Bookworm (python:3.13-bookworm/python:3.13-slim-bookworm). Stage 1 installs the Python virtualenv at/opt/venvand Ansible collections at/usr/share/ansible/collections. Stage 2 copies both into a slim runtime image and runs uvicorn.IMAGE_NAMEenv var (defaultghcr.io/range42/range42-backend-api:latest).Why Debian Bookworm instead of Ubuntu Server LTS
Benjamin's original spec called for Ubuntu Server LTS. We diverged deliberately, using
python:3.13-bookworm— the Docker Official Image, which uses upstream CPython compiled from source and does not ship theEXTERNALLY-MANAGEDmarker. Dependencies are installed into a virtualenv (/opt/venv), which bypasses PEP 668 on any distro.Clarification: Debian 12 itself also enforces PEP 668 on its apt-installed Python, same as Ubuntu. The image works correctly because of the Docker Official Image base and the virtualenv, not because Debian avoids PEP 668. The preference for Debian is that the official Python Docker images are Debian-based, making it the more predictable and well-tested foundation.
Test plan
docker compose buildcompletes without errorsdocker compose upstarts the container;curl http://localhost:8000/docs/openapi.jsonreturns HTTP 200openapi.jsonat repo root matches/docs/openapi.jsonserved by the running containerIMAGE_NAME=ghcr.io/range42/range42-backend-api:dev docker compose push