0Pricing
DevOps Bootcamp · Ders

Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri

Konteynerleştirilmiş hizmetlerin güvenilir biçimde başlamasını sağlayan bağımlılık bekleme döngülerini ve canlılık yoklamalarını uygulayın.

Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri, CoddyKit'te ücretsiz bir DevOps Bootcamp dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, DevOps Bootcamp öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. DevOps Bootcamp kursu toplamda 4 dersten oluşur.

Hizmetler Başlangıçta Neden Başarısız Olur

Kapsayıcı tabanlı ortamlarda hizmetler nadiren yalıtılmış olarak başlar. Bir web uygulamasının veritabanının hazır olması, bir mikro hizmetin mesaj aracısına erişebilmesi ve bir çalışanın işleri işleyebilmesi için önbelleğinin doldurulmuş olması gerekir.

Koordinasyon olmadığında kapsayıcılar paralel olarak başlar ve ilk istekler bağımlılıklar sağlıklı hale gelmeden ulaşır. Sonuç olarak bağlantı reddedildi hataları, boş işaretçi istisnaları ve el ile yeniden başlatma gerektiren bozulmuş başlangıç durumu ortaya çıkar.

  • Canlılık yoklaması — süreç hâlâ çalışıyor mu ve kilitlenmiş değil mi?
  • Hazır olma yoklaması — hizmet trafiği kabul etmeye hazır mı?
  • Bekleme döngüsü — bağımlılıklara erişilebilene kadar engelleyen bir başlangıç betiği

Kubernetes yerleşik yoklama mekanizmaları sağlar; ancak initContainers, entrypoint.sh sarmalayıcıları ve bağımsız sağlık denetimlerini çalıştıran kabuk betikleri Bash ile yazılır. Bunlarda uzmanlaşmak temel bir DevOps becerisidir.

Bağımlılık Bekleme Kalıbı

En basit bağımlılık bekleme döngüsü, hedef erişilebilir hale gelene kadar sabit aralıklarla yoklama yapar. Klasik biçim, TCP portunu veya HTTP uç noktasını denetlemek için while döngüsü ile nc (netcat) ya da curl kullanır.

Temel tasarım kararları:

  • Zaman aşımı — bozuk bir bağımlılığın pod'u sonsuza dek askıda bırakmaması için N saniye sonra çıkın
  • Geri çekilme aralığı — toparlanmaya çalışan bir hizmeti sürekli sorgularla yüklememek için yoklamalar arasında bekleyin
  • Çıkış kodu — zaman aşımında 1 ile çıkın; böylece kapsayıcı yeniden başlatılır (veya başlatma kapsayıcısı hatayı açıkça bildirir)

Aşağıdaki kod parçası, ana süreci başlatmadan önce bir TCP portunun bağlantıları kabul etmesi için en fazla 60 saniye bekler.

#!/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 "$@"

curl ile HTTP Hazır Olma Yoklamaları

Bir TCP bağlantısı yalnızca portun açık olduğunu gösterir; arkasındaki uygulamanın isteklere yanıt vermeye hazır olduğunu göstermez. Birçok hizmet, tüm dahili alt sistemler başlatıldığında yalnızca HTTP 200 döndüren özel bir /health veya /readyz uç noktası sunar.

Bir HTTP hazır olma uç noktasını yoklamak için curl --fail --silent --output /dev/null kullanın. --fail seçeneği, 4xx/5xx yanıtlarında curl'un 22 koduyla çıkmasını sağlar; bu da yeniden deneme mantığını temiz biçimde yönlendirir.

Bilinmesi gereken önemli seçenekler:

  • --fail — HTTP hatalarını curl hatası olarak değerlendirir (sıfır olmayan çıkış)
  • --silent — ilerleme çıktısını gizler
  • --max-time N — istek başına saniye cinsinden zaman aşımı
  • --retry N --retry-delay S — curl'un kendi yeniden deneme katmanı (basit durumlarda kullanışlıdır)
#!/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 "$@"

Bekleme Döngülerinde Üstel Geri Çekilme

Sabit aralıklı bir yeniden deneme döngüsü, toparlanmaya çalışan bir hizmeti sabit bir hızla sürekli yoklar. Üstel geri çekilme, her denemede bekleme süresini iki katına çıkarır; böylece toparlanma sırasında yükü azaltırken hizmet hızlı başlatıldığında kısa sürede sonuca ulaşır.

Standart formül şöyledir: sleep_time = min(base * 2^attempt, max_sleep). Bir dalgalanma bileşeni (rastgele kesirli sapma), çok sayıda kapsayıcı aynı anda yeniden başlatıldığında sürü hücumu sorunlarını önler.

Bu kalıp, wait-for-it, AWS SDK yeniden denemeleri ve Kubernetes denetleyicilerinin uzlaştırma döngüleri gibi üretim ortamı araçlarında kullanılır.

#!/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

Birden Çok Bağımlılığı Yoklama

Gerçek uygulamaların birden çok bağımlılığı vardır: bir veritabanı, bir önbellek, bir mesaj aracısı ve belki de harici bir API. Bunları sırayla yoklamak başlangıç süresini boşa harcar. Daha iyi bir yaklaşım, tüm bağımlılıkları paralel olarak yoklamak ve hepsinin başarılı olmasını beklemektir.

Bash'teki & işleci her yoklamayı arka plana alır, wait ise çıkış kodlarını toplar. Herhangi bir yoklama başarısız olursa giriş noktası betiği sıfır olmayan bir kodla çıkar ve kapsayıcı yeniden başlatılır.

Temel teknik: arka planda çalışan süreçlerin PID değerlerini $! ile yakalayın ve her birinin çıkış kodunu denetleyebilmek için bunları açıkça wait'e aktarın.

#!/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 "$@"

Canlılık ve Hazır Olma: Farklı Yoklamalar İçin Farklı Betikler

Kubernetes, canlılık ve hazır olma yoklamalarını birbirinden ayırır; bunlar farklı işler yapmalıdır:

  • Canlılık yoklaması — şu soruyu yanıtlar: süreç hâlâ canlı mı ve kilitlenmiş değil mi? Hızlı olmalı ve yalnızca dahili durumu denetlemelidir (örneğin süreç PID dosyasının var olması veya yerel bir sağlık uç noktasının 200 döndürmesi). Başarısız bir canlılık yoklaması kapsayıcıyı sonlandırır ve yeniden başlatır.
  • Hazır olma yoklaması — şu soruyu yanıtlar: bu pod trafiği almalı mı? Aşağı akıştaki bağımlılıkları denetleyebilir. Başarısız bir hazır olma yoklaması pod'u Service yük dengeleyicisinden çıkarır, ancak pod'u yeniden başlatmaz.

Yavaş bağımlılık denetimlerini canlılık yoklamalarına asla koymayın. Kısa süreli bir veritabanı kesintisi, tüm uygulama pod'larınızın yanlışlıkla yeniden başlatılmasına ve sorunun büyümesine neden olur.

#!/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

Başlangıç Yoklamaları ve initContainers

Kubernetes üçüncü bir yoklama türü sunar: startupProbe. Bir kez başarılı olana kadar canlılık ve hazır olma yoklamaları yerine çalışır; böylece yavaş başlayan uygulamalar (JVM'nin ısınması veya veritabanı geçişleri), yanlış canlılık hataları tetiklemeden başlatılmak için zaman kazanır.

Bağımlılıkları beklemek için initContainers çoğu zaman giriş noktası betiklerinden daha temiz bir çözümdür. Bunlar uygulama kapsayıcıları başlamadan önce çalışır ve Kubernetes yeniden deneme ile yeniden başlatma mantığını otomatik olarak yönetir. Başlatma kapsayıcısı imajının yalnızca sh, nc veya curl'a ihtiyacı vardır; minimal bir busybox ya da alpine imajı kullanabilirsiniz.

Bir Pod bildirimindeki örnek initContainer belirtimi:

# 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 Çıktılı Sağlık Denetimi Betiği

Üretim sistemleri çoğu zaman birden çok alt sistemin sağlık durumunu bir araya getirir ve bunu yapılandırılmış bir JSON veri yükü olarak sunar. Bu veri yükü, yük dengeleyiciler, düzenleyiciler ve izleme panoları tarafından kullanılır.

Bir Bash sağlık denetimi betiği, printf veya jq kullanarak JSON çıktısını doğrudan oluşturabilir. Çıkış kodu otomasyonu yönlendirmeye devam eder; JSON gövdesi ise insan operatörler ve izleme sistemleri içindir.

Yaygın kural: sağlık durumu iyi olduğunda {"status":"ok"} ile HTTP 200, sağlık durumu bozulduğunda {"status":"degraded", "checks":{...}} ile HTTP 503 döndürün. Aşağıdaki betik, socat gibi hafif bir HTTP sarmalayıcı tarafından sunulmak veya Kubernetes'in komut çalıştırma yoklamaları tarafından doğrudan çağrılmak üzere tasarlanmıştır.

#!/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

Süre Aşımı Yardımcı Aracı ve Süre Sınırı Kalıbı

GNU timeout komutu, herhangi bir komutu sarar ve belirtilen süre içinde tamamlanmazsa sonlandırır. Arka plan işlerini el ile yönetmeden bir bekleme döngüsü veya sağlık yoklaması için kesin bir süre sınırı uygulamanın en temiz yoludur.

timeout DURATION COMMAND [ARGS...]

timeout komutunun çıkış kodları:

  • 0 — komut süre sınırı içinde başarıyla tamamlandı
  • Komutun çıkış kodu — komut çalıştı ancak sıfır olmayan bir kod döndürdü
  • 124 — komutun süresi doldu (SIGTERM gönderildi)
  • 137 — komut SIGKILL ile sonlandırıldı (--kill-after sonrasında)

124 çıkış kodunu saptamak, genel bir hata yerine anlaşılır bir zaman aşımı iletisi yazdırmanızı sağlar.

#!/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 "$@"

Salt Bash ile Kendi Kendine Yeterli Bekleme Betiği

Birçok minimal kapsayıcı imajında nc (netcat) bulunmaz. Salt Bash, /dev/tcp'ye işlem ikamesi kullanarak TCP bağlantıları açabilir; bu, standart olmayan ancak geniş ölçüde desteklenen ve hiç harici araç gerektirmeyen bir Bash yerleşik özelliğidir.

Sözdizimi: /dev/tcp/HOST/PORT — bu yola yönlendirme yaptığınızda Bash bir TCP bağlantısı açar. Bağlantı reddedilir veya zaman aşımına uğrarsa hata verir (sıfır olmayan çıkış).

Bu teknik, birçok Docker Compose kurulumuyla birlikte gelen popüler wait-for-it.sh betiğinde kullanılır. Aşağıdaki betik, herhangi bir Dockerfile'a COPY edebileceğiniz eksiksiz ve bağımsız bir uygulamadır.

#!/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'ye Yoklamaları Entegre Etme

Giriş noktası kalıbı, bekleme döngülerini, ortam doğrulamasını ve süreç başlatmayı tek bir bakımı kolay betikte birleştirmenin standart yoludur. Docker'ın ENTRYPOINT'i bu betiği çağırır ve betik, aynı PID ile CMD'ye devretmek için exec "$@" ile sona erer (sinyallerin temiz biçimde iletilmesini sağlar).

Üretim düzeyinde bir entrypoint.sh genellikle şunları yapar:

  • Gerekli ortam değişkenlerini erkenden doğrular (hızlı başarısız olur)
  • Bağımlılık bekleme döngülerini çalıştırır
  • Uygunsa veritabanı geçişlerini çalıştırır
  • Son bir öz denetim gerçekleştirir
  • exec "$@" ile denetimi devreder

exec kullanmak kritik öneme sahiptir; kabuk sürecinin yerine geçer, böylece uygulama PID 1 olur ve düzgün kapatma sırasında Docker/Kubernetes'ten SIGTERM sinyalini doğrudan alır.

#!/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 "$@"

Bilgi Kontrolü: Canlılık ve Hazır Olma Yoklamaları

Bu derste ele alınan temel kavramları anlayışınızı sınayın.

Özet: Sağlık Yoklamaları, Hazır Olma Kapıları ve Bekleme Döngüleri

Bu derste güvenilir kapsayıcı başlangıç koordinasyonu için Bash araç setini oluşturdunuz. Ele aldıklarınız:

  • Bekleme kalıbı — kesin zaman aşımı ve geçen süre koruması içeren bir until nc -z HOST PORT döngüsü, bozuk bağımlılıklar nedeniyle sonsuza dek engellenmeyi önler.
  • HTTP hazır olma yoklamaları — curl --fail --max-time, yalnızca portun açık olduğunu değil, uygulamanın gerçekten hazır olduğunu doğrular.
  • Üstel geri çekilme — yeniden denemeler arasındaki bekleme aralığını iki katına çıkarmak, sürü hücumu yükünü azaltır ve toparlanan hizmetlerin kararlı hale gelmesini sağlar.
  • Paralel bağımlılık yoklaması — yoklamaları & ile arka plana almak ve sonuçları wait $PID ile toplamak, birden çok bağımlılık olduğunda başlangıç gecikmesini azaltır.
  • Canlılık ve hazır olma — canlılık yoklamaları hızlı olmalı ve yalnızca yerel durumu denetlemelidir; hazır olma yoklamaları aşağı akıştaki sistemleri denetleyebilir. Bunları asla birbirine karıştırmayın.
  • startupProbe — yavaş başlayan uygulamaları başlatma sırasında ortaya çıkan yanlış canlılık hatalarından korur.
  • /dev/tcp yoklaması — salt Bash ile yapılan TCP denetimi harici araç gerektirmez; minimal kapsayıcı imajları için idealdir.
  • entrypoint.sh — ortam doğrulaması, bekleme döngüleri, geçişler ve exec "$@", kapsayıcı tabanlı hizmet başlangıcı için standart kalıbı oluşturur.

Bu kalıplar Docker Compose, Kubernetes ve ECS genelinde kendi kendini iyileştiren, üretim düzeyinde kapsayıcı dağıtımlarının temelini oluşturur.

Sıkça Sorulan Sorular

“Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri” dersi ücretsiz mi?

Evet — “Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve DevOps Bootcamp kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. DevOps Bootcamp kursu toplamda 4 dersten oluşur.

“Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri” dersinde ne öğreneceğim?

Konteynerleştirilmiş hizmetlerin güvenilir biçimde başlamasını sağlayan bağımlılık bekleme döngülerini ve canlılık yoklamalarını uygulayın. DevOps Bootcamp ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

DevOps Bootcamp öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te DevOps Bootcamp, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu DevOps Bootcamp dersinde kod yazıp çalıştırabilir miyim?

Evet. Her DevOps Bootcamp dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Yalın Dockerfile'lar ve Kabuk Giriş Noktaları Yazma
  2. envsubst ve heredoc'larla Yapılandırma Şablonlama
  3. CLI ve jq ile Bulut Kaynaklarını Betikleme
  4. Sağlık Yoklamaları, Hazırlık Kapıları ve Bekleme Döngüleri
← DevOps Bootcamp Sayfasına Dön