marcel/familienarchiv
1
0
Fork 0
Code Issues 119 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

docker compose config fails on merged prod stack — duplicate ocr-service security_opt #764

New Issue
Open
opened 2026-06-06 20:20:36 +02:00 by marcel · 0 comments
marcel commented 2026-06-06 20:20:36 +02:00
Owner
Copy Link

Found while validating #759 (Ollama prod compose). Pre-existing on main, unrelated to that PR.

Symptom

$ IMPORT_HOST_DIR=/tmp/x docker compose -f docker-compose.yml -f docker-compose.prod.yml config
validating .../docker-compose.prod.yml: services.ocr-service.security_opt items at 0 and 1 are equal
# exit 1

The merged prod config fails to validate. The dev file alone (-f docker-compose.yml config) validates fine (exit 0).

Root cause

Both the base docker-compose.yml and the prod overlay docker-compose.prod.yml define the same single-item security_opt for the ocr-service:

security_opt:
  - no-new-privileges:true

Compose appends list values across files rather than replacing them, so the merged ocr-service.security_opt becomes [no-new-privileges:true, no-new-privileges:true]. A recent Docker Compose version now rejects identical list items as a validation error (older versions silently deduped/accepted, which is why the PR #759 author's local docker compose config passed).

Impact

  • Anyone running docker compose -f docker-compose.yml -f docker-compose.prod.yml config (or up) with a current compose version hits a hard validation failure on the prod stack.
  • It is not Ollama-specific — ocr-service is the offending block; other services with overlay-duplicated list keys may have the same latent issue.

Fix options

  1. Remove the redundant security_opt from docker-compose.prod.yml for ocr-service (and any other service that already inherits an identical security_opt from the base file). Lowest-churn.
  2. Audit all services for list keys duplicated between base and overlay (security_opt, cap_drop, tmpfs, …) and remove the redundant overlay entries.

Notes

This is exactly the class of breakage the proposed CI compose-lint step (Sara/Felix on #759) would catch on every PR — worth pairing this fix with filing that CI step.

Found while validating #759 (Ollama prod compose). Pre-existing on `main`, unrelated to that PR. ## Symptom ``` $ IMPORT_HOST_DIR=/tmp/x docker compose -f docker-compose.yml -f docker-compose.prod.yml config validating .../docker-compose.prod.yml: services.ocr-service.security_opt items at 0 and 1 are equal # exit 1 ``` The **merged** prod config fails to validate. The dev file alone (`-f docker-compose.yml config`) validates fine (exit 0). ## Root cause Both the base `docker-compose.yml` and the prod overlay `docker-compose.prod.yml` define the same single-item `security_opt` for the `ocr-service`: ```yaml security_opt: - no-new-privileges:true ``` Compose **appends** list values across files rather than replacing them, so the merged `ocr-service.security_opt` becomes `[no-new-privileges:true, no-new-privileges:true]`. A recent Docker Compose version now rejects identical list items as a validation error (older versions silently deduped/accepted, which is why the PR #759 author's local `docker compose config` passed). ## Impact - Anyone running `docker compose -f docker-compose.yml -f docker-compose.prod.yml config` (or `up`) with a current compose version hits a hard validation failure on the prod stack. - It is **not** Ollama-specific — `ocr-service` is the offending block; other services with overlay-duplicated list keys may have the same latent issue. ## Fix options 1. **Remove the redundant `security_opt` from `docker-compose.prod.yml`** for `ocr-service` (and any other service that already inherits an identical `security_opt` from the base file). Lowest-churn. 2. Audit all services for list keys duplicated between base and overlay (`security_opt`, `cap_drop`, `tmpfs`, …) and remove the redundant overlay entries. ## Notes This is exactly the class of breakage the proposed **CI compose-lint** step (Sara/Felix on #759) would catch on every PR — worth pairing this fix with filing that CI step.
marcel added the P1-highbugdevops labels 2026-06-06 20:20:45 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 needs-discussion
Has an open decision or design question that must be resolved before implementation can start.
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label P1-high bug devops
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#764
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?