WordPress עם ניטור זמינות: WordPress, ‏MariaDB ו-Uptime Kuma

אתר WordPress עם מסד הנתונים MariaDB ומוניטור Uptime Kuma על אותו שרת, מאחורי Caddy. שתי בדיקות מבדילות בין proxy או תעודה שבורים לבין אתר שבור.

נבדק 14 באוקטובר 2026

למה האפליקציות האלה יחד

עסק קטן או בלוג מריצים WordPress משלהם ורוצים לדעת על השבתה לפני שהמבקרים יודעים, בלי שירות ניטור בתשלום לבדיקות הראשונות.

כל דף אפליקציה מפרס את האפליקציה שלו לבד. כשהן רצות יחד מאחורי Caddy, ‏Uptime Kuma יכול לבדוק את WordPress פעמיים: דרך הכתובת הציבורית, כמו שהמבקרים מגיעים (DNS, תעודה, Caddy, ‏WordPress), וישירות ב-container דרך הרשת ש-Caddy חולק עם שתיהן. כשרק הבדיקה הראשונה נכשלת, הבעיה נמצאת לפני WordPress. הדף נותן את שתי הכתובות ומפרט מה מוניטור על אותו שרת לא יכול לראות.

האפליקציות בסטאק

אפליקציההתפקיד בסטאקרמת עומסתמיכת Compose
WordPressהאתר, עם MariaDB כמסד הנתונים שלו.קלנבדק בהרצה
Uptime Kumaבודק את האתר כל דקה ושולח את ההתראות.קלנבדק בהרצה

איך האפליקציות מתחברות

Uptime Kuma אל WordPress: http://wordpress:80
מוניטור HTTP על ה-container של WordPress עצמו, דרך רשת ה-edge של Caddy: הוא עונה אם WordPress ומסד הנתונים שלו מגיבים, בלי קשר למה ש-Caddy עושה.
Uptime Kuma אל WordPress: https://<WORDPRESS_DOMAIN>
מוניטור HTTP(s) על הכתובת הציבורית מ-.env: המסלול שהמבקרים עוברים, דרך DNS ציבורי, התעודה ו-Caddy.

משאבים לשרת כולו

מחושב במנוע של ה-Stack Sizer לאפליקציות ולרמות העומס האלה: מה שהאפליקציות צריכות, בסיס המערכת ומרווח הביטחון. אותו קלט ב-Stack Sizer נותן את אותם מספרים.

רכיבvCPURAM ‏(GiB)דיסק (GiB)
WordPress20.6257
Uptime Kuma0.50.51.7
בסיס המערכת0.11.258.4
מרווח ביטחון0.520.4752.565
סה"כ מומלץ3.122.8519.665

‏Caddy לא כלול בחישוב המשאבים של ה-Stack Sizer וה-Deployment Spec.

לפתוח את האפליקציות האלה ב-Stack Sizer

קבצים מה-Compose Generator

docker-compose.yml
# Generated by the ANAROQ Compose Generator: https://anaroq.com/tools/compose-generator
# Engine @anaroq/compose 1.0.0, catalog 2026.10.10, exposure caddy.
# Apps: wordpress 1.1.0, uptime-kuma 1.1.0 (supported, not run-tested).
# No secrets in this file: copy .env.example to .env and fill it in before `docker compose up -d`.

services:
  wordpress:
    image: "wordpress:7.1.3-php8.4-apache"
    restart: "unless-stopped"
    environment:
      WORDPRESS_DB_HOST: "wordpress-mariadb"
      WORDPRESS_DB_USER: "wordpress"
      WORDPRESS_DB_PASSWORD: "${WORDPRESS_DB_PASSWORD:?set WORDPRESS_DB_PASSWORD in .env}"
      WORDPRESS_DB_NAME: "wordpress"
    volumes:
      - "wordpress-data:/var/www/html"
    networks:
      - "wordpress-internal"
      - "edge"
    depends_on:
      wordpress-mariadb:
        condition: "service_healthy"
  wordpress-mariadb:
    image: "mariadb:12.3.3"
    restart: "unless-stopped"
    environment:
      MARIADB_DATABASE: "wordpress"
      MARIADB_USER: "wordpress"
      MARIADB_PASSWORD: "${WORDPRESS_DB_PASSWORD:?set WORDPRESS_DB_PASSWORD in .env}"
      MARIADB_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - "wordpress-mariadb-data:/var/lib/mysql"
    networks:
      - "wordpress-internal"
    healthcheck:
      test:
        - "CMD"
        - "healthcheck.sh"
        - "--connect"
        - "--innodb_initialized"
      interval: "10s"
      timeout: "5s"
      retries: 3
      start_period: "10s"
  uptime-kuma:
    image: "louislam/uptime-kuma:2.5.6"
    restart: "unless-stopped"
    environment:
      UPTIME_KUMA_DB_TYPE: "sqlite"
    volumes:
      - "uptime-kuma-data:/app/data"
    networks:
      - "uptime-kuma-internal"
      - "edge"
  caddy:
    image: "caddy:2.11.7-alpine"
    restart: "unless-stopped"
    environment:
      WORDPRESS_DOMAIN: "${WORDPRESS_DOMAIN:?set WORDPRESS_DOMAIN in .env}"
      UPTIME_KUMA_DOMAIN: "${UPTIME_KUMA_DOMAIN:?set UPTIME_KUMA_DOMAIN in .env}"
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile:ro"
      - "caddy-data:/data"
      - "caddy-config:/config"
    networks:
      - "edge"
networks:
  wordpress-internal: {}
  uptime-kuma-internal: {}
  edge: {}
volumes:
  wordpress-data: {}
  wordpress-mariadb-data: {}
  uptime-kuma-data: {}
  caddy-data: {}
  caddy-config: {}
.env.example
# Generated by the ANAROQ Compose Generator: https://anaroq.com/tools/compose-generator
# Engine @anaroq/compose 1.0.0, catalog 2026.10.10, exposure caddy.
# Copy this file to .env and fill in every value. Never commit .env.
# ANAROQ does not create passwords or keys: generate them on your own machine.

# --- wordpress ---
# Password of the WordPress MariaDB user (MARIADB_PASSWORD and WORDPRESS_DB_PASSWORD).
# Secret, required. For example: openssl rand -hex 24
WORDPRESS_DB_PASSWORD=
# Public host name of the site behind the reverse proxy, for example blog.example.com.
# Required.
WORDPRESS_DOMAIN=

# --- uptime-kuma ---
# Public host name of Uptime Kuma behind the reverse proxy, for example status.example.com (a subdirectory is not supported).
# Required.
UPTIME_KUMA_DOMAIN=
Caddyfile
# Generated by the ANAROQ Compose Generator: https://anaroq.com/tools/compose-generator
# Engine @anaroq/compose 1.0.0, catalog 2026.10.10, exposure caddy.
# Each site address comes from .env through the Caddy container's environment.

{$WORDPRESS_DOMAIN} {
	reverse_proxy wordpress:80
}

{$UPTIME_KUMA_DOMAIN} {
	reverse_proxy uptime-kuma:3001
}

נוצרו במנוע של ה-Compose Generator לאפליקציות האלה מאחורי Caddy. אין סודות בקבצים: העתיקו את ‎.env.example ל-‎.env ומלאו אותו.

תוצאת ה-Compose Analyzer

שגיאה0
גבוהה0
בינונית0
נמוכה10
מידע0

10 ממצאים: 0 שגיאה, 0 גבוהה, 0 בינונית, 10 נמוכה, 0 מידע.

נמוכה10

  1. נמוכהAQ-HLTH-002שורה 8, עמודה 5services.wordpress

    ל-wordpress אין healthcheck.

    תיקון: הוסיפו healthcheck, כדי ש-Compose ואתם תדעו מתי השירות מוכן.

  2. נמוכהAQ-HLTH-005שורה 8, עמודה 5services.wordpress

    ‏wordpress לא מגביל את גודל הלוגים שלו (logging.options.max-size).

    תיקון: הגבילו את גודל הלוגים כדי שלא ימלאו את הדיסק.

  3. נמוכהAQ-SEC-005שורה 11, עמודה 7services.wordpress.environment

    ‏wordpress מעביר סודות דרך environment ‏(WORDPRESS_DB_PASSWORD).

    תיקון: כשה-image תומך בזה, השתמשו ב-secrets: או במשתנה _FILE במקום.

  4. נמוכהAQ-HLTH-005שורה 24, עמודה 5services.wordpress-mariadb

    ‏wordpress-mariadb לא מגביל את גודל הלוגים שלו (logging.options.max-size).

    תיקון: הגבילו את גודל הלוגים כדי שלא ימלאו את הדיסק.

  5. נמוכהAQ-SEC-005שורה 27, עמודה 7services.wordpress-mariadb.environment

    ‏wordpress-mariadb מעביר סודות דרך environment ‏(MARIADB_PASSWORD, MARIADB_RANDOM_ROOT_PASSWORD).

    תיקון: כשה-image תומך בזה, השתמשו ב-secrets: או במשתנה _FILE במקום.

  6. נמוכהAQ-HLTH-005שורה 46, עמודה 5services.uptime-kuma

    ‏uptime-kuma לא מגביל את גודל הלוגים שלו (logging.options.max-size).

    תיקון: הגבילו את גודל הלוגים כדי שלא ימלאו את הדיסק.

  7. נמוכהAQ-HLTH-002שורה 56, עמודה 5services.caddy

    ל-caddy אין healthcheck.

    תיקון: הוסיפו healthcheck, כדי ש-Compose ואתם תדעו מתי השירות מוכן.

  8. נמוכהAQ-HLTH-005שורה 56, עמודה 5services.caddy

    ‏caddy לא מגביל את גודל הלוגים שלו (logging.options.max-size).

    תיקון: הגבילו את גודל הלוגים כדי שלא ימלאו את הדיסק.

  9. נמוכהAQ-PORT-005שורה 62, עמודה 9services.caddy.ports.0

    הקובץ מפרסם 3 מיפויי פורטים. ‏Docker מפרסם פורטים בלי לעבור דרך כללי ufw.

    תיקון: סננו אותם בשרשרת DOCKER-USER או בחומת האש של הספק, או אל תפרסמו אותם.

  10. נמוכהAQ-VOL-005שורה 66, עמודה 9services.caddy.volumes.0

    ‏caddy מחבר את הנתיב היחסי ./Caddyfile.

    תיקון: זה עובד, אבל הנתונים נמצאים בתיקייה שממנה מריצים את Compose: גבו אותה.

ה-Compose Analyzer ‏(ruleset 1.0.0) בדק את docker-compose.yml: 0 שגיאה, 0 גבוה, 0 בינוני ו-10 נמוך. מתכון מתפרסם רק בלי ממצאי שגיאה וגבוה.

להמשיך בכלים

הקישור פותח את ה-Compose Generator עם האפליקציות, האפשרויות והחשיפה האלה, ועם ה-Deployment Spec של הערכת המשאבים הזו, כך ש-cloud-init וה-Runbook מתחילים מאותו מצב.

לפתוח במסע

Runbook

לפני ההפעלה הראשונה

  1. העתיקו את .env.example ל-.env ליד docker-compose.yml ומלאו כל ערך. ‏Compose נעצר עם שגיאה כל עוד ערך חובה חסר.
  2. צרו את WORDPRESS_DB_PASSWORD במחשב שלכם, למשל עם openssl rand -hex 24. ‏ANAROQ אף פעם לא יוצר סיסמאות או מפתחות.
  3. השאירו את Caddyfile ליד docker-compose.yml; קונטיינר Caddy מחבר אותו לקריאה בלבד.
  4. פורטים 80 ו-443 (TCP, ו-443/UDP ל-HTTP/3) חייבים להיות נגישים מהאינטרנט כדי ש-HTTPS האוטומטי של Caddy יעבוד.
  5. לפני ההפעלה, כוונו את רשומות A/AAAA של הדומיין שב-WORDPRESS_DOMAIN ‏(wordpress) לשרת הזה; ‏Caddy מבקש את התעודה שלו בהפעלה הראשונה.
  6. לפני ההפעלה, כוונו את רשומות A/AAAA של הדומיין שב-UPTIME_KUMA_DOMAIN ‏(uptime-kuma) לשרת הזה; ‏Caddy מבקש את התעודה שלו בהפעלה הראשונה.
  7. הפעילו את ה-stack עם docker compose up -d ועקבו אחריו עם docker compose ps.

אחרי ההפעלה הראשונה

  1. ליצור את מנהל Uptime Kuma

    פתחו את שם המארח של Uptime Kuma מ-.env וצרו את חשבון המנהל במסך הראשון.

  2. לנטר את ה-container

    הוסיפו מוניטור HTTP(s) עם הכתובת הפנימית שלמטה. הוא נשאר תקין כל עוד WordPress ו-MariaDB עונים, גם אם Caddy או התעודה נכשלים.

    http://wordpress:80
  3. לנטר את הכתובת הציבורית

    הוסיפו מוניטור HTTP(s) שני עם https://‎ ושם המארח של WordPress מ-.env, וחברו התראה (דוא"ל, צ'אט) לשני המוניטורים.

מה האפליקציות חולקות

  • מוניטור על אותו שרת נופל יחד איתו: הפסקת חשמל, רשת או ספק משתיקה את שניהם. השאירו בדיקה חיצונית אחת, או Uptime Kuma שני במקום אחר, עבור השרת עצמו.
  • ‏Uptime Kuma מקבל שם מארח ציבורי משלו דרך Caddy. צרו את חשבון המנהל שלו מיד אחרי ההפעלה הראשונה, לפני שמישהו אחר יכול להגיע לדף.
  • גבו את הקבצים ומסד הנתונים של WordPress ואת ה-volume של הנתונים של Uptime Kuma: המוניטורים וההיסטוריה שלהם נמצאים שם.

חלופות

  • שירות זמינות מתארח בודק מבחוץ ורואה גם השבתה של השרת; הוא משלים את הבדיקה הפנימית ולא מחליף אותה.
  • ‏Uptime Kuma לבד, על שרת אחר, בודק את האתר הזה מבחוץ: הדף שלו מעריך את המשאבים. Uptime Kuma

בסיס

קטלוג
2026.10.10
מדיניות הערכת משאבים
2026.10.0
מנוע Compose
@anaroq/compose 1.0.0
ruleset של ה-Analyzer
1.0.0

מקורות

איך נבנים הפרופילים, הערכות המשאבים וקבצי ה-Compose מתואר במתודולוגיה. לקריאת המתודולוגיה

כל האפליקציות ל-self-hosting