סביבה
- מערכת הפעלה
- Ubuntu 24.04.5 LTS (GitHub Actions ubuntu-24.04 runner, image 20261004.327.1)
- רץ על
- GitHub Actions hosted runner
- גרסאות
- Docker Engine 28.0.4Docker Compose 2.38.2Open WebUI v0.11.4Ollama 0.40.2
הגרסאות הן אלה שנרשמו בהרצה 38256885780. ההרצה שנכשלה, 38210088287, הריצה את אותו workflow על אותה תווית runner.
תסמין
בהרצה 38210088287 של runtime-verify, ה-target open-webui__default__caddy נכשל עם up-wait-failed: הפקודה docker compose up --wait החזירה שגיאה כי ה-container של open-webui היה unhealthy. חמש אפליקציות אחרות באותה הרצה עברו.
ה-container עצמו המשיך לרוץ ועבר ל-healthy ברגע שהאפליקציה ענתה, כך שהכשל היה זמני.
שורש הבעיה
ה-image של Open WebUI (v0.11.4) מגדיר HEALTHCHECK משלו עם ברירות המחדל של Docker: מרווח של 30 שניות, 3 ניסיונות ובלי תקופת התחלה. הפעלה ראשונה על volume ריק (migrations של מסד הנתונים, מודל ה-embedding) יכולה להימשך יותר מכ-90 שניות, ולכן שלוש בדיקות שנכשלו מסמנות את ה-container כ-unhealthy לפני שהאפליקציה עלתה.
הפקודה docker compose up --wait מחכה שכל service יהיה running או healthy, ומתייחסת ל-unhealthy ככשל.
תיקון
לתת ל-HEALTHCHECK של ה-image תקופת התחלה בלי להחליף את הבדיקה שלו: בלוק healthcheck ב-Compose עם start_period בלבד. Docker שומר את הבדיקה, המרווח, ה-timeout ומספר הניסיונות של ה-image. בדיקות שנכשלות בתקופת ההתחלה לא נספרות, ובדיקה שעוברת מוקדם יותר מסמנת את ה-container כ-healthy מיד.
התבנית של Open WebUI ב-ANAROQ מגדירה start_period: 120s מגרסת פרופיל 1.2.0. בהרצה 38256885780 כל שמונה ההרצות של Open WebUI הגיעו ל-healthy תוך כ-30 שניות, כולל default__caddy.
פקודות
services:
open-webui:
image: ghcr.io/open-webui/open-webui:v0.11.4
healthcheck:
start_period: 120sdocker compose up -d --waitdocker inspect --format '{{json .State.Health}}' <container>ראיה
open-webui__default__caddy up-wait-failed (open-webui: unhealthy)open-webui 8 runs (default, extra-model-true × 4 exposure modes) 8/8 passed profileVersion 1.2.0כלים ועמודים קשורים
מקורות
איך נבנים פרופילים וקובצי Compose מאומתים מתואר במתודולוגיה. למתודולוגיה