Commit Graph

8 Commits

Author SHA1 Message Date
hsiegeln
13728f9252 fix(docker): expliziter Plattform-Install fuer sharp-Prebuilts
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 3m5s
Finaler Anlauf gegen den arm64-Build-Fehler. Bisher scheiterte
npm daran, @img/sharp-linuxmusl-arm64 unter Docker-Buildx-QEMU zu
installieren, trotz --include=optional. Mehrschichtiger Fix:

1. --cpu=arm64 --os=linux --libc=musl auf npm install: umgeht QEMU-
   bezogene Detection-Bugs (sharp's offiziell empfohlener Fix).
2. Expliziter Zusatz-Install von @img/sharp-linuxmusl-arm64 und
   @img/sharp-libvips-linuxmusl-arm64: zwingt die Prebuilts auf Disk,
   unabhaengig von der Lockfile-Resolution.
3. --ignore-scripts beim Install + npm rebuild danach: loest den Race,
   wo sharp's postinstall laeuft bevor der Prebuilt-Tarball fertig ist.
4. node-addon-api + node-gyp als Runtime-Deps: from-source-Build-
   Fallback falls alle Prebuilt-Pfade scheitern.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:52:55 +02:00
hsiegeln
83f5b88d94 fix(docker): node-addon-api + ignore-scripts/rebuild fuer sharp
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 51s
Drei Schichten Absicherung gegen den arm64-Build-Fehler:

- --ignore-scripts beim npm install verhindert, dass sharp's postinstall
  check.js laeuft, bevor das @img/sharp-linuxmusl-arm64-Paket entpackt
  ist (Race in parallelem Install).
- npm rebuild danach: alle Deps sind jetzt auf Disk, Postinstalls laufen
  sauber in Dependency-Reihenfolge.
- node-addon-api als Runtime-Dep: falls die Prebuilt-Binary im npm-Tree
  nicht landet, kann sharp from-source bauen (vips-dev + python3 + make
  + g++ sind im Dockerfile bereits installiert).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:49:41 +02:00
hsiegeln
cb93725139 fix(docker): npm install statt npm ci fuer sharp-Prebuilts
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 48s
Der vorige Fix (ignore-scripts + rebuild, plus Fresh-ci im Builder) hat
den sharp-Prebuilt trotzdem nicht installiert. Ursache: der Windows-
generierte Lockfile markiert @img/sharp-linuxmusl-arm64 als "dev": true,
sodass npm ci die Prebuilt-Binary konsistent auslaesst — egal ob mit
--include=optional. npm install dagegen resolvt Optional-Deps frisch fuer
die Build-Plattform (linux-arm64-musl im Docker) und findet die Prebuilts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:46:55 +02:00
hsiegeln
80c72b6e5b fix(docker): sharp-Prebuilts beim CI-Build korrekt installieren
Some checks failed
Build & Publish Docker Image / build-and-push (push) Failing after 51s
Zwei Fixes gegen den arm64-Build-Fehler:

1. npm ci mit --ignore-scripts + npm rebuild danach — vermeidet
   eine Race, bei der sharp's postinstall check.js laeuft bevor die
   Plattform-Prebuilt-Binary vollstaendig entpackt ist.

2. Statt npm prune --omit=dev ein Fresh-Install via npm ci
   --omit=dev. Grund: Der Lockfile wird auf Windows generiert und
   markiert die linux-musl-arm64-Prebuilts als "dev": true, obwohl
   sie fuer's Runtime gebraucht werden. Prune wuerde sie kappen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-21 11:44:05 +02:00
hsiegeln
9e3d6e8d01 chore(deps): @google/generative-ai + vips-dev fuer Foto-Rezept-Magie 2026-04-21 10:37:12 +02:00
24058bcb77 fix(docker): healthcheck uses 127.0.0.1, not localhost
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 54s
In the alpine runtime 'localhost' resolves to ::1 (IPv6) first. The
SvelteKit Node adapter binds to 0.0.0.0 which is IPv4-only, so wget to
'localhost:3000' fails with 'Connection refused'. Traefik then filters
the container as unhealthy and no router is registered.

Using 127.0.0.1 makes the probe deterministically hit the bound IPv4
socket.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 16:47:48 +02:00
ec902049c1 fix(docker): tighter healthcheck cadence with start-period
All checks were successful
Build & Publish Docker Image / build-and-push (push) Successful in 53s
Traefik filters containers that are 'unhealthy' or still 'starting'
(no health result yet). The old 30s interval meant kochwas stayed in
'starting' for 30+ seconds after boot, blocking Traefik from routing to it.

New timing:
  --start-period=20s      grace window — failures don't mark unhealthy yet
  --start-interval=2s     fast probes during start-period
  --interval=15s          steady-state cadence after first success
  --timeout=5s, retries=3 unchanged

Container becomes 'healthy' within ~2-5s of the app coming up, so Traefik
picks it up almost immediately after 'docker compose up'.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 16:45:00 +02:00
ddb3419cd9 feat(infra): add production Dockerfile and docker-compose.prod.yml
Multi-stage alpine-based build, healthcheck on /api/health, /data volume.
Verified end-to-end: image builds, container starts, health returns 200.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 15:41:20 +02:00