Linux Command Line & Bash Scripting Mastery · درس

فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار

نفّذ حلقات انتظار التبعيات وفحوصات الحيوية التي تضمن بدء الخدمات المستضافة في حاويات بشكل موثوق

فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار درس مجاني في Linux Command Line & Bash Scripting Mastery على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Linux Command Line & Bash Scripting Mastery، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Linux Command Line & Bash Scripting Mastery 4 دروس في المجموع.

لماذا تفشل الخدمات عند بدء التشغيل

في البيئات التي تستخدم الحاويات، نادرًا ما تبدأ الخدمات بمعزل عن غيرها. إذ يحتاج تطبيق الويب إلى أن تكون قاعدة بياناته جاهزة، وتحتاج الخدمة المصغّرة إلى توفّر وسيط الرسائل، كما يحتاج العامل إلى تهيئة ذاكرة التخزين المؤقت قبل أن يتمكن من معالجة المهام.

من دون تنسيق، تبدأ الحاويات بالتوازي، وتصل الطلبات الأولى قبل أن تصبح التبعيات سليمة. والنتيجة هي: أخطاء رفض الاتصال واستثناءات المؤشر الفارغ وحالة بدء تشغيل تالفة تتطلب إعادة تشغيل يدوية.

فحص الحيوية — هل ما تزال العملية قيد التشغيل ولم تدخل في حالة جمود؟
فحص الجاهزية — هل أصبحت الخدمة جاهزة لقبول حركة المرور؟
حلقة الانتظار — سكربت بدء تشغيل يحظر التنفيذ حتى تصبح التبعيات قابلة للوصول

يوفر Kubernetes آليات مدمجة للفحوصات، لكن سكربتات الصدفة التي تشغّل initContainers وأغلفة entrypoint.sh وفحوصات الصحة المستقلة تُكتب باستخدام Bash. وإتقانها مهارة أساسية في DevOps.

نمط wait-for

تستطلع أبسط حلقات انتظار التبعيات هدفًا على فاصل زمني ثابت إلى أن يصبح قابلًا للوصول. ويستخدم الشكل المعياري حلقة while مع nc (netcat) أو curl لفحص منفذ TCP أو نقطة نهاية HTTP.

قرارات التصميم الأساسية:

المهلة الزمنية — أوقف التنفيذ بعد N ثانية حتى لا تؤدي تبعية معطّلة إلى تعليق الحاوية إلى الأبد
فاصل التراجع — انتظر بين الفحوصات لتجنب الضغط المتكرر على خدمة تتعافى
رمز الخروج — اخرج بالرمز 1 عند انتهاء المهلة حتى تُعاد تشغيل الحاوية أو يفشل مكوّن التهيئة بوضوح

ينتظر المقتطف أدناه مدة تصل إلى 60 ثانية حتى يقبل منفذ TCP الاتصالات، ثم يطلق العملية الرئيسية.

#!/usr/bin/env bash
set -euo pipefail

HOST="${DB_HOST:-postgres}"
PORT="${DB_PORT:-5432}"
TIMEOUT=60
INTERVAL=2
ELAPSED=0

echo "[wait-for] Waiting for ${HOST}:${PORT}..."

until nc -z "$HOST" "$PORT" 2>/dev/null; do
  if (( ELAPSED >= TIMEOUT )); then
    echo "[wait-for] Timed out after ${TIMEOUT}s waiting for ${HOST}:${PORT}" >&2
    exit 1
  fi
  echo "[wait-for] ${HOST}:${PORT} not ready — retrying in ${INTERVAL}s (${ELAPSED}s elapsed)"
  sleep "$INTERVAL"
  (( ELAPSED += INTERVAL ))
done

echo "[wait-for] ${HOST}:${PORT} is up — continuing"
exec "$@"

فحوصات جاهزية HTTP باستخدام curl

يخبرك اتصال TCP بأن المنفذ مفتوح فقط، ولا يخبرك بأن التطبيق الذي يستجيب من خلاله جاهز لتقديم الطلبات. وتوفر خدمات كثيرة نقطة نهاية مخصصة مثل /health أو /readyz، لا تُرجع HTTP 200 إلا بعد تهيئة جميع الأنظمة الفرعية الداخلية.

استخدم curl --fail --silent --output /dev/null لفحص نقطة نهاية جاهزية HTTP. يجعل الخيار --fail curl يخرج بالرمز 22 عند استلام استجابات 4xx أو 5xx، مما يوجّه منطق إعادة المحاولة بسلاسة.

خيارات مهمة ينبغي معرفتها:

--fail — يعامل أخطاء HTTP كأخطاء curl، أي بخروج برمز غير صفري
--silent — يمنع عرض معلومات التقدم
--max-time N — المهلة الزمنية لكل طلب بالثواني
--retry N --retry-delay S — طبقة إعادة المحاولة الخاصة بـcurl، وهي مفيدة في الحالات البسيطة

#!/usr/bin/env bash
set -euo pipefail

HEALTH_URL="${HEALTH_URL:-http://localhost:8080/healthz}"
TIMEOUT=90
INTERVAL=3
ELAPSED=0

echo "[probe] Polling readiness at ${HEALTH_URL}"

until curl --fail --silent --output /dev/null \
           --max-time 2 "${HEALTH_URL}"; do
  if (( ELAPSED >= TIMEOUT )); then
    echo "[probe] Service not ready after ${TIMEOUT}s" >&2
    exit 1
  fi
  printf '[probe] Not ready yet (%ds elapsed)\n' "$ELAPSED"
  sleep "$INTERVAL"
  (( ELAPSED += INTERVAL ))
done

echo "[probe] Service is ready"
exec "$@"

التراجع الأسي في حلقات الانتظار

تضغط حلقة إعادة المحاولة ذات الفاصل الثابت على الخدمة المتعافية بمعدل ثابت. ويضاعف التراجع الأسي مدة الانتظار في كل محاولة، مما يقلل الحمل أثناء التعافي مع الاستمرار في الوصول إلى النتيجة بسرعة عندما تبدأ الخدمة سريعًا.

الصيغة القياسية هي: sleep_time = min(base * 2^attempt, max_sleep). ويمنع مكوّن التباين العشوائي، أي الإزاحة الكسرية العشوائية، مشكلات القطيع الهائج عند إعادة تشغيل حاويات كثيرة في الوقت نفسه.

يُستخدم هذا النمط في أدوات جاهزة للإنتاج مثل wait-for-it وإعادات المحاولة في AWS SDK وحلقات المصالحة في وحدات التحكم لدى Kubernetes.

#!/usr/bin/env bash
set -euo pipefail

HOST="${HOST:-redis}"
PORT="${PORT:-6379}"
MAX_ATTEMPTS=8
BASE_SLEEP=1
MAX_SLEEP=30

for attempt in $(seq 1 "$MAX_ATTEMPTS"); do
  if nc -z "$HOST" "$PORT" 2>/dev/null; then
    echo "[backoff] Connected to ${HOST}:${PORT} on attempt ${attempt}"
    exec "$@"
  fi

  # Exponential backoff with jitter
  raw=$(( BASE_SLEEP * (2 ** (attempt - 1)) ))
  capped=$(( raw < MAX_SLEEP ? raw : MAX_SLEEP ))
  jitter=$(( RANDOM % 3 ))
  sleep_time=$(( capped + jitter ))

  echo "[backoff] Attempt ${attempt}/${MAX_ATTEMPTS} failed — sleeping ${sleep_time}s"
  sleep "$sleep_time"
done

echo "[backoff] ${HOST}:${PORT} unreachable after ${MAX_ATTEMPTS} attempts" >&2
exit 1

فحص تبعيات متعددة

تتضمن التطبيقات الحقيقية تبعيات متعددة: قاعدة بيانات وذاكرة تخزين مؤقت ووسيط رسائل وربما واجهة API خارجية. ويؤدي فحصها بالتسلسل إلى إهدار وقت بدء التشغيل. أما النهج الأفضل فيفحص جميع التبعيات بالتوازي وينتظر نجاحها كلها.

يشغّل عامل & في Bash كل فحص في الخلفية، بينما يجمع wait رموز الخروج الخاصة بها. وإذا فشل أي فحص، ينهي برنامج الدخول عمله برمز غير صفري، مما يؤدي إلى إعادة تشغيل الحاوية.

التقنية الأساسية: التقط معرّفات العمليات في الخلفية باستخدام $! ومرّرها صراحةً إلى wait حتى تتمكن من التحقق من رموز الخروج الفردية.

#!/usr/bin/env bash
set -euo pipefail

wait_tcp() {
  local host="$1" port="$2" timeout="${3:-30}"
  local elapsed=0
  until nc -z "$host" "$port" 2>/dev/null; do
    (( elapsed >= timeout )) && { echo "TIMEOUT ${host}:${port}" >&2; return 1; }
    sleep 2; (( elapsed += 2 ))
  done
  echo "[ok] ${host}:${port}"
}

# Launch all probes in parallel
wait_tcp postgres 5432 60 &  PID_PG=$!
wait_tcp redis    6379 30 &  PID_RD=$!
wait_tcp rabbitmq 5672 45 &  PID_RQ=$!

# Collect results — fail fast if any probe failed
FAILED=0
for pid in $PID_PG $PID_RD $PID_RQ; do
  wait "$pid" || (( FAILED++ ))
done

if (( FAILED > 0 )); then
  echo "[entrypoint] ${FAILED} dependency probe(s) failed — aborting" >&2
  exit 1
fi

echo "[entrypoint] All dependencies ready"
exec "$@"

الحيوية مقابل الجاهزية: سكربتات مختلفة لفحوصات مختلفة

يميّز Kubernetes بين فحوصات الحيوية وفحوصات الجاهزية، وينبغي أن تؤدي كل منهما وظيفة مختلفة:

فحص الحيوية — يجيب عن السؤال: هل ما تزال العملية حية ولم تدخل في حالة جمود؟ ينبغي أن يكون سريعًا وأن يتحقق من الحالة الداخلية فقط، مثل وجود ملف PID للعملية أو إرجاع نقطة نهاية صحة محلية للرمز 200. ويؤدي فشل فحص الحيوية إلى إنهاء الحاوية وإعادة تشغيلها.
فحص الجاهزية — يجيب عن السؤال: هل ينبغي أن تستقبل هذه الـpod حركة المرور؟ ويمكنه التحقق من التبعيات اللاحقة. ويزيل فشل فحص الجاهزية الـpod من موازن تحميل Service، لكنه لا يعيد تشغيلها.

لا تضع أبدًا فحوصات التبعيات البطيئة في فحوصات الحيوية. فقد يؤدي انقطاع قصير في قاعدة البيانات إلى إعادة تشغيل جميع حاويات التطبيق بشكل غير صحيح، مما يفاقم المشكلة.

#!/usr/bin/env bash
# liveness.sh — fast local-only check
# Used in: livenessProbe.exec.command
set -euo pipefail

PID_FILE="/var/run/app/app.pid"
HEALTH_URL="http://127.0.0.1:8080/internal/live"

# Check 1: process is running
[[ -f "$PID_FILE" ]] || { echo "PID file missing" >&2; exit 1; }
kill -0 "$(cat "$PID_FILE")" 2>/dev/null || { echo "Process dead" >&2; exit 1; }

# Check 2: local endpoint responds (2s timeout — never block)
curl --fail --silent --max-time 2 --output /dev/null "$HEALTH_URL" || {
  echo "Liveness endpoint unresponsive" >&2
  exit 1
}

echo "live"
exit 0

فحوصات بدء التشغيل وinitContainers

يوفر Kubernetes نوعًا ثالثًا من الفحوصات: startupProbe. ويعمل بدلًا من فحوصات الحيوية والجاهزية إلى أن ينجح مرة واحدة، مما يمنح التطبيقات بطيئة البدء، مثل التطبيقات التي تحتاج إلى تهيئة JVM أو ترحيل قاعدة البيانات، وقتًا للتهيئة دون التسبب في إخفاقات حيوية زائفة.

عند انتظار التبعيات، تكون initContainers غالبًا أنظف من سكربتات برنامج الدخول. فهي تعمل قبل بدء حاويات التطبيق، ويتولى Kubernetes تلقائيًا منطق إعادة المحاولة وإعادة التشغيل. ولا تحتاج صورة حاوية التهيئة إلا إلى sh أو nc أو curl؛ ويمكنك استخدام صورة busybox أو alpine صغيرة.

مثال على مواصفة initContainer في بيان Pod:

# kubernetes/pod-with-init.yaml (illustrative — not runnable as bash)
# initContainers run sequentially before app containers
initContainers:
  - name: wait-for-postgres
    image: busybox:1.36
    command:
      - sh
      - -c
      - |
        set -e
        echo 'Waiting for postgres...'
        until nc -z postgres 5432; do
          echo 'postgres not ready — sleeping 2s'
          sleep 2
        done
        echo 'postgres is up'

  - name: run-migrations
    image: myapp:latest
    command: ['python', 'manage.py', 'migrate', '--noinput']
    envFrom:
      - secretRef:
          name: app-secrets

سكربت فحص الصحة مع مخرجات JSON

غالبًا ما تجمع أنظمة الإنتاج حالة الصحة عبر أنظمة فرعية متعددة وتعرضها في حمولة JSON منظمة. وتستهلك موازنات التحميل والمنسّقات ولوحات المراقبة هذه الحمولة.

يمكن لسكربت فحص صحة مكتوب باستخدام Bash إنشاء مخرجات JSON مباشرةً باستخدام printf أو jq. ويظل رمز الخروج هو الذي يوجّه الأتمتة، بينما يكون نص JSON مخصصًا للمشغّلين البشريين وأنظمة المراقبة.

الاصطلاح المتبع: أعد HTTP 200 مع {"status":"ok"} عند سلامة النظام، وHTTP 503 مع {"status":"degraded", "checks":{...}} عند وجود خلل. والسكربت أدناه مخصص لتقديمه عبر غلاف HTTP خفيف مثل socat أو لاستدعائه مباشرةً بواسطة فحوصات exec في Kubernetes.

#!/usr/bin/env bash
# health_check.sh — composite health with JSON output
set -uo pipefail

check_postgres() {
  pg_isready -h "${DB_HOST:-postgres}" -p "${DB_PORT:-5432}" \
             -U "${DB_USER:-app}" -t 2 &>/dev/null
}

check_redis() {
  redis-cli -h "${REDIS_HOST:-redis}" -p "${REDIS_PORT:-6379}" \
             PING 2>/dev/null | grep -q PONG
}

check_disk() {
  local usage
  usage=$(df / | awk 'NR==2{gsub(/%/,"",$5); print $5}')
  (( usage < 90 ))
}

PG_OK=0; RD_OK=0; DSK_OK=0
check_postgres && PG_OK=1
check_redis    && RD_OK=1
check_disk     && DSK_OK=1

OVERALL=$(( PG_OK && RD_OK && DSK_OK ))
STATUS=$( (( OVERALL )) && echo 'ok' || echo 'degraded' )

printf '{"status":"%s","checks":{"postgres":%s,"redis":%s,"disk":%s}}\n' \
  "$STATUS" "$PG_OK" "$RD_OK" "$DSK_OK"

(( OVERALL )) && exit 0 || exit 1

أداة timeout باستخدام نمط deadline

يلف الأمر GNU timeout أي أمر وينهيه إذا لم يكتمل خلال المدة المحددة. وهذه أنظف طريقة لفرض مهلة نهائية صارمة على حلقة انتظار أو فحص صحة دون إدارة مهام في الخلفية يدويًا.

timeout DURATION COMMAND [ARGS...]

رموز الخروج من timeout:

0 — نجح الأمر ضمن المهلة النهائية
رمز خروج الأمر — نُفّذ الأمر لكنه أعاد رمزًا غير صفري
124 — انتهت مهلة الأمر، وأُرسل SIGTERM
137 — أُنهي الأمر باستخدام SIGKILL بعد --kill-after

يتيح لك اكتشاف رمز الخروج 124 طباعة رسالة واضحة عن انتهاء المهلة بدلًا من رسالة خطأ عامة.

#!/usr/bin/env bash
set -euo pipefail

HOST="${DB_HOST:-postgres}"
PORT="${DB_PORT:-5432}"
DEADLINE=60  # seconds

# Inline poll loop, wrapped by timeout
timeout "$DEADLINE" bash -c "
  until nc -z '$HOST' '$PORT' 2>/dev/null; do
    echo '[wait] ${HOST}:${PORT} not ready...'
    sleep 2
  done
" && echo "[wait] ${HOST}:${PORT} is up" || {
  code=$?
  if (( code == 124 )); then
    echo "[wait] Timed out after ${DEADLINE}s waiting for ${HOST}:${PORT}" >&2
  else
    echo "[wait] Probe failed with exit code ${code}" >&2
  fi
  exit "$code"
}

exec "$@"

wait-for مستقل بذاته باستخدام Bash فقط

تفتقر كثير من صور الحاويات الصغيرة إلى nc (netcat). ويمكن لـBash فقط فتح اتصالات TCP باستخدام استبدال العمليات إلى /dev/tcp، وهي ميزة مدمجة في Bash غير قياسية لكنها مدعومة على نطاق واسع ولا تتطلب أي أدوات خارجية.

الصيغة: /dev/tcp/HOST/PORT — يفتح Bash اتصال TCP عند إعادة التوجيه إلى هذا المسار أو منه. ويُصدر خطأً، أي خروجًا برمز غير صفري، إذا رُفض الاتصال أو انتهت مهلته.

هذه هي التقنية المستخدمة في السكربت الشائع wait-for-it.sh الذي يأتي مع العديد من إعدادات Docker Compose. والسكربت أدناه تطبيق كامل ومستقل يمكنك COPY إلى أي Dockerfile.

#!/usr/bin/env bash
# wait-for-it.sh (pure bash, no nc/curl required)
set -uo pipefail

usage() { echo "Usage: $0 HOST:PORT [-t TIMEOUT] [-- COMMAND]"; exit 1; }

parse_hostport() {
  HOST="${1%%:*}"
  PORT="${1##*:}"
  [[ -n "$HOST" && "$PORT" =~ ^[0-9]+$ ]] || usage
}

[[ $# -ge 1 ]] || usage
parse_hostport "$1"; shift

TIMEOUT=30
[[ "${1:-}" == "-t" ]] && { TIMEOUT="$2"; shift 2; }
[[ "${1:-}" == "--" ]] && shift

wait_for() {
  local elapsed=0
  while (( elapsed < TIMEOUT )); do
    # Pure bash TCP probe — no nc, no curl
    if (exec 3<>"/dev/tcp/${HOST}/${PORT}") 2>/dev/null; then
      exec 3>&-
      return 0
    fi
    sleep 1
    (( elapsed++ ))
  done
  return 1
}

echo "Waiting for ${HOST}:${PORT} (timeout ${TIMEOUT}s)..."
if wait_for; then
  echo "${HOST}:${PORT} is available"
  [[ $# -gt 0 ]] && exec "$@"
else
  echo "Timed out waiting for ${HOST}:${PORT}" >&2
  exit 1
fi

دمج الفحوصات في entrypoint.sh

يُعد نمط برنامج الدخول الطريقة القياسية للجمع بين حلقات الانتظار والتحقق من البيئة وبدء العملية في سكربت واحد سهل الصيانة. ويستدعي ENTRYPOINT في Docker هذا السكربت، وينتهي السكربت بـexec "$@" لتسليم التنفيذ إلى CMD باستخدام معرّف العملية نفسه، مما يتيح تمرير الإشارات بطريقة سليمة.

يتولى entrypoint.sh بمستوى جاهز للإنتاج عادةً ما يلي:

التحقق مبكرًا من متغيرات البيئة المطلوبة، أي الفشل السريع
تشغيل حلقات انتظار التبعيات
تنفيذ عمليات ترحيل قاعدة البيانات، عند الحاجة
إجراء فحص ذاتي نهائي
نقل التحكم باستخدام exec "$@"

يُعد استخدام exec أمرًا بالغ الأهمية؛ فهو يستبدل عملية الصدفة، وبذلك يصبح التطبيق PID 1 ويتلقى SIGTERM مباشرةً من Docker أو Kubernetes عند الإيقاف السلس.

#!/usr/bin/env bash
# docker/entrypoint.sh
set -euo pipefail

# ── 1. Validate required env vars ────────────────────────────────────
for var in DATABASE_URL REDIS_URL SECRET_KEY; do
  [[ -n "${!var:-}" ]] || { echo "FATAL: ${var} is not set" >&2; exit 1; }
done

# ── 2. Parse DB host/port from DATABASE_URL ──────────────────────────
DB_HOST=$(echo "$DATABASE_URL" | sed -E 's|.*@([^:/]+).*|\1|')
DB_PORT=$(echo "$DATABASE_URL" | sed -E 's|.*:([0-9]+)/.*|\1|')

# ── 3. Wait for dependencies ─────────────────────────────────────────
timeout 60 bash -c "
  until nc -z '${DB_HOST}' '${DB_PORT}' 2>/dev/null; do sleep 2; done
" || { echo "Database unreachable" >&2; exit 1; }

# ── 4. Run migrations ────────────────────────────────────────────────
echo "[entrypoint] Running migrations..."
python manage.py migrate --noinput

# ── 5. Hand off to CMD (exec preserves PID 1 for signal handling) ────
echo "[entrypoint] Starting application: $*"
exec "$@"

فحص المعرفة: فحوصات الحيوية مقابل الجاهزية

اختبر مدى فهمك للمفاهيم الأساسية التي غطاها هذا الدرس.

مراجعة: فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار

أنشأت في هذا الدرس مجموعة أدوات Bash اللازمة لتنسيق بدء تشغيل الحاويات بشكل موثوق. إليك ما غطيته:

نمط wait-for — تمنع حلقة until nc -z HOST PORT ذات المهلة النهائية الصارمة وحارس الوقت المنقضي الحظر اللانهائي بسبب التبعيات المعطّلة.
فحوصات جاهزية HTTP — يتحقق curl --fail --max-time من أن التطبيق جاهز فعلًا، لا من أن المنفذ مفتوح فحسب.
التراجع الأسي — يقلل مضاعفة فاصل الانتظار بين عمليات إعادة المحاولة من حمل القطيع الهائج، ويتيح للخدمات المتعافية الاستقرار.
فحص التبعيات بالتوازي — يؤدي تشغيل الفحوصات في الخلفية باستخدام & وجمع النتائج باستخدام wait $PID إلى تقليل زمن بدء التشغيل عند وجود تبعيات متعددة.
الحيوية مقابل الجاهزية — يجب أن تكون فحوصات الحيوية سريعة ومحلية فقط، بينما يمكن لفحوصات الجاهزية التحقق من الأنظمة اللاحقة. لا تخلط بينهما أبدًا.
startupProbe — يحمي التطبيقات بطيئة البدء من إخفاقات الحيوية الزائفة أثناء التهيئة.
فحص /dev/tcp — لا يتطلب فحص TCP باستخدام Bash فقط أي أدوات خارجية، مما يجعله مثاليًا لصور الحاويات الصغيرة.
entrypoint.sh — يشكل التحقق من البيئة وحلقات الانتظار وعمليات الترحيل وexec "$@" نمط بدء تشغيل الخدمة داخل الحاوية القياسي.

تشكل هذه الأنماط أساس عمليات نشر الحاويات ذاتية الإصلاح وبمستوى جاهز للإنتاج عبر Docker Compose وKubernetes وECS.

الأسئلة الشائعة

هل درس «فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار» مجاني؟

نعم — نص درس «فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Linux Command Line & Bash Scripting Mastery، انتقل إلى CoddyKit PRO. تتضمن دورة Linux Command Line & Bash Scripting Mastery 4 دروس في المجموع.

ماذا ستتعلم في «فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار»؟

نفّذ حلقات انتظار التبعيات وفحوصات الحيوية التي تضمن بدء الخدمات المستضافة في حاويات بشكل موثوق تتمرن على Linux Command Line & Bash Scripting Mastery مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Linux Command Line & Bash Scripting Mastery؟

لا تُشترط خبرة سابقة. Linux Command Line & Bash Scripting Mastery على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Linux Command Line & Bash Scripting Mastery هذا؟

نعم. كل درس في Linux Command Line & Bash Scripting Mastery يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

كتابة Dockerfiles خفيفة ونقاط دخول Shell
إنشاء قوالب الإعدادات باستخدام envsubst وheredocs
برمجة موارد السحابة باستخدام CLI وjq
فحوصات الصحة وبوابات الجاهزية وحلقات الانتظار

← العودة إلى Linux Command Line & Bash Scripting Mastery