Files
rippy/docker/worker/Dockerfile
T
Hitonabi 29444805a8
Ampel / ampel (push) Successful in 28s
fix(build): der MakeMKV-Fallback der VM war seit Monaten tot - Kette jetzt dreistufig
Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026):

    https://www.makemkv.com/download        HTTP 200   <- Repo-Standard
    https://www.makemkv.com/download/old    HTTP 525   (Cloudflare)
    web.archive.org-Schnappschuss           HTTP 404   <- stand in der VM-.env

Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort
die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird.
Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die
Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe
teuer, weil sie erst beim Fremden zuschlaegt.

## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM)

.env.sicherung-vor-aufraeumen-20260725 angelegt, dann:
- MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert.
  Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download
- JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos.

## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe)

Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und
die hier ins Leere zeigte. Jetzt eine automatische Kette:

  1. vendor/-Tarballs        (braucht kein Netz, zuverlaessigster Weg)
  2. MAKEMKV_URL_BASE
  3. MAKEMKV_URL_FALLBACK    (NEU, wird automatisch versucht wenn 2 versagt)

Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite
Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere
schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat
(Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt.

Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die
FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen.

## Geprueft, beide Zweige

- vendor-Pfad:   Bau durch, 828 MB
- Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB,
  makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird
  korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht.

docker compose config validiert. README und .env.example nennen die gemessenen
HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:50:54 +02:00

156 lines
7.1 KiB
Docker

# Worker-Image: MakeMKV (verlustfrei, Etappe 10) + abcde/cdparanoia (CD→FLAC).
#
# Multi-Stage: makemkv-oss wird aus Quellen gebaut (GPL-Teil), makemkv-bin ist
# das proprietäre Binärpaket (EULA wird per tmp/eula_accepted akzeptiert —
# Standard-Mechanismus des Makefiles für nicht-interaktive Builds).
# Beide Stages sind auf bookworm gepinnt, damit die libavcodec-Version passt.
#
# Vorher stand hier `makepkg` (ein Arch-Linux-Werkzeug, existiert in Debian
# nicht) — das Image war seit dem 23.07. gar nicht mehr baubar. Und es fehlte
# schlicht JEDES Ripping-Werkzeug: weder HandBrake noch abcde noch MakeMKV
# waren installiert.
FROM python:3.12-slim-bookworm AS makemkv-build
# Zurück auf die AKTUELLE Version (24.07.2026): 1.17.7 war wegen des
# 1.18er-Laufwerks-Scan-Hängers (Forum t=38128) und der Flash-Fähigkeit
# gepinnt. Beides erledigt: der Scan wird überall mit --noscan umgangen
# (info-Lauf mit 1.18.4 auf der BU40N sauber durchgelaufen, 24.07.), und
# das Laufwerk ist geflasht (LibreDrive v06.3 bestätigt).
# Richtigstellung 25.07.2026: Hier stand, die aktuelle Version zähle, weil sie
# "die neueste AACS-Schlüssel-Datenbank mitbringt". Das ist widerlegt — MakeMKV
# bringt gar keine Disc-Schlüssel mit, und der Online-Kanal liefert nichts mehr
# (Messungen im Modul-Kopf von makemkv_daten.py). Aktuell bleiben lohnt sich
# trotzdem: Laufwerks-Unterstützung und Fehlerbehebungen. Schlüssel für neue
# UHD-Pressungen kommen ausschließlich aus der KEYDB.cfg im Datenverzeichnis.
# MAKEMKV_URL_BASE ist übersteuerbar (Build-Arg): /download hat nur die
# aktuelle Version, /download/old die älteren. Wenn Cloudflare BuildKit-
# Downloads drosselt (24.07.: außerhalb des Builds ging alles, im Build
# konsequent HTTP-Fehler), Tarballs von Hand laden und lokal servieren:
# mkdir ~/makemkv-mirror && curl -o … && docker run -d --name makemkv-mirror \
# -p 8099:80 -v ~/makemkv-mirror:/usr/share/nginx/html:ro nginx:alpine
# docker compose build --build-arg MAKEMKV_URL_BASE=http://<host-ip>:8099 worker
ARG MAKEMKV_VERSION=1.18.4
ARG MAKEMKV_URL_BASE=https://www.makemkv.com/download
# Zweite Quelle, die bei einem Fehlschlag der ersten AUTOMATISCH probiert wird.
# Absichtlich LEER: Am 25.07.2026 nachgemessen, welche Quellen wirklich liefern —
# https://www.makemkv.com/download HTTP 200 (der Standard oben)
# https://www.makemkv.com/download/old HTTP 525 (Cloudflare)
# web.archive.org-Schnappschuss HTTP 404
# Es gibt derzeit also keine belegbare zweite Quelle. Eine hier einzutragen, die
# nicht liefert, wäre schlimmer als keine: der Build scheitert dann später und
# die Konfiguration sieht trotzdem gesund aus — genau das war auf der Rippy-VM
# der Fall (dort stand die 404-Adresse, und nur die vendor-Tarballs retteten
# jeden Build, ohne dass es auffiel).
# Wer eine eigene Quelle hat (Spiegel im LAN, eigener Webserver), traegt sie ein:
# docker compose build --build-arg MAKEMKV_URL_FALLBACK=http://<host>:8099 worker
ARG MAKEMKV_URL_FALLBACK=
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential \
pkg-config \
ca-certificates \
curl \
libssl-dev \
libexpat1-dev \
libavcodec-dev \
zlib1g-dev \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /build
# Download mit DREIFACHEM Netz (Cloudflare drosselt BuildKit-Downloads
# hartnäckig — 24.07. viermal, auch MIT --retry-all-errors):
# 1. Liegen die Tarballs lokal in docker/worker/vendor/ (untracked), werden
# SIE genutzt — einmal von Hand hinlegen, nie wieder Download-Roulette.
# 2. Sonst curl mit Retries gegen MAKEMKV_URL_BASE.
# 3. Scheitert das, wird MAKEMKV_URL_FALLBACK versucht, falls gesetzt.
# Und wenn alles scheitert, sagt die Meldung, welche Wege es gibt — statt nur
# einen curl-Rückgabewert zu hinterlassen.
COPY docker/worker/vendor/ ./vendor/
RUN set -e; \
hole() { \
ziel="$1"; datei="$2"; \
if curl -fsSL --retry 5 --retry-delay 15 --retry-all-errors \
-o "$ziel" "${MAKEMKV_URL_BASE}/${datei}"; then \
return 0; \
fi; \
if [ -n "${MAKEMKV_URL_FALLBACK}" ]; then \
echo "Erste Quelle lieferte nicht — versuche MAKEMKV_URL_FALLBACK"; \
curl -fsSL --retry 3 --retry-delay 10 --retry-all-errors \
-o "$ziel" "${MAKEMKV_URL_FALLBACK}/${datei}" && return 0; \
fi; \
echo "FEHLER: ${datei} war von keiner Quelle zu holen." >&2; \
echo " Geprueft: ${MAKEMKV_URL_BASE}${MAKEMKV_URL_FALLBACK:+ und ${MAKEMKV_URL_FALLBACK}}" >&2; \
echo " Sicherster Weg: Tarballs von makemkv.com/download herunterladen" >&2; \
echo " und nach docker/worker/vendor/ legen, dann erneut bauen." >&2; \
echo " Alternativ eine eigene Quelle angeben:" >&2; \
echo " docker compose build --build-arg MAKEMKV_URL_FALLBACK=http://<host>:8099 worker" >&2; \
return 1; \
}; \
if [ -s "vendor/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" ] \
&& [ -s "vendor/makemkv-bin-${MAKEMKV_VERSION}.tar.gz" ]; then \
echo "Nutze lokale Tarballs aus vendor/"; \
cp "vendor/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" oss.tar.gz; \
cp "vendor/makemkv-bin-${MAKEMKV_VERSION}.tar.gz" bin.tar.gz; \
else \
hole oss.tar.gz "makemkv-oss-${MAKEMKV_VERSION}.tar.gz"; \
hole bin.tar.gz "makemkv-bin-${MAKEMKV_VERSION}.tar.gz"; \
fi; \
sha256sum oss.tar.gz bin.tar.gz; \
tar xzf oss.tar.gz; \
tar xzf bin.tar.gz
RUN cd "makemkv-oss-${MAKEMKV_VERSION}" \
&& ./configure --disable-gui --prefix=/usr/local \
&& make -j"$(nproc)" \
&& make install
# PREFIX explizit: makemkv-bin installiert sonst nach /usr — und das COPY der
# Final-Stage nimmt nur /usr/local mit (Deploy 23.07.: makemkvcon fehlte im Image).
# Das abschließende test -x lässt den Build laut scheitern statt still lückenhaft.
RUN cd "makemkv-bin-${MAKEMKV_VERSION}" \
&& mkdir -p tmp \
&& touch tmp/eula_accepted \
&& make PREFIX=/usr/local \
&& make install PREFIX=/usr/local \
&& test -x /usr/local/bin/makemkvcon
FROM python:3.12-slim-bookworm
# handbrake-cli: Kompressions-Stufe NACH dem verlustfreien MakeMKV-Rip
# (Commander-Entscheid 23.07.: 40-GB-Rohdateien sind nicht arbeitsfähig).
RUN apt-get update && apt-get install -y --no-install-recommends \
libssl3 \
libexpat1 \
zlib1g \
libavcodec59 \
abcde \
cdparanoia \
cd-discid \
flac \
handbrake-cli \
&& rm -rf /var/lib/apt/lists/*
COPY --from=makemkv-build /usr/local /usr/local
RUN ldconfig
# Version fürs UI sichtbar machen (Einstellungen → System): makemkvcon hat
# keinen --version-Schalter, also kommt die Wahrheit aus dem Build selbst.
ARG MAKEMKV_VERSION=1.18.4
ENV MAKEMKV_VERSION=${MAKEMKV_VERSION}
WORKDIR /app
COPY docker/worker/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY docker/worker/ .
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]
# Der lokale Worker bedient BEIDE Queues (rip + transcode). Ein optionaler
# Remote-GPU-Worker startet dasselbe Image nur mit "-Q transcode".
CMD ["celery", "-A", "celery_app", "worker", "--loglevel=info", "-Q", "celery,transcode"]