0Pricing
DevOps Bootcamp · Pelajaran

Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu

Implementasikan loop tunggu dependensi dan probe liveness agar layanan dalam container dapat dimulai dengan andal.

Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu adalah pelajaran DevOps Bootcamp gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar DevOps Bootcamp, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus DevOps Bootcamp mencakup 4 pelajaran total.

Mengapa Layanan Gagal Saat Memulai

Di lingkungan berbasis kontainer, layanan jarang dimulai secara terpisah. Aplikasi web memerlukan basis datanya agar siap, layanan mikro memerlukan perantara pesannya agar tersedia, dan pekerja memerlukan cache yang sudah terisi sebelum dapat memproses pekerjaan.

Tanpa koordinasi, kontainer dimulai secara paralel dan permintaan pertama tiba sebelum dependensinya sehat. Akibatnya adalah kesalahan koneksi ditolak, pengecualian penunjuk null, dan status awal yang rusak sehingga memerlukan pemulaian ulang secara manual.

  • Pemeriksaan keaktifan — apakah proses masih berjalan dan tidak mengalami kebuntuan?
  • Pemeriksaan kesiapan — apakah layanan siap menerima lalu lintas?
  • Perulangan tunggu — skrip inisialisasi yang menahan proses hingga dependensi dapat dijangkau

Kubernetes menyediakan mekanisme pemeriksaan bawaan, tetapi skrip shell yang menjalankan initContainers, pembungkus entrypoint.sh, dan pemeriksaan kesehatan mandiri ditulis dalam Bash. Menguasainya merupakan keterampilan inti DevOps.

Pola Tunggu hingga Tersedia

Perulangan tunggu dependensi yang paling sederhana memeriksa target pada interval tetap hingga target tersebut dapat dijangkau. Bentuk umumnya menggunakan perulangan while dengan nc (netcat) atau curl untuk memeriksa port TCP atau titik akhir HTTP.

Keputusan desain utama:

  • Batas waktu — hentikan proses setelah N detik agar dependensi yang rusak tidak membuat pod menunggu selamanya
  • Interval jeda — tunggu di antara pemeriksaan agar tidak membebani layanan yang sedang pulih
  • Kode keluar — keluar dengan kode 1 saat batas waktu tercapai agar kontainer dimulai ulang (atau kontainer inisialisasi gagal secara jelas)

Cuplikan di bawah menunggu hingga 60 detik agar port TCP menerima koneksi sebelum meluncurkan proses utama.

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

Pemeriksaan Kesiapan HTTP dengan curl

Koneksi TCP hanya memberi tahu Anda bahwa port terbuka — bukan bahwa aplikasi di baliknya siap melayani permintaan. Banyak layanan menyediakan titik akhir khusus seperti /health atau /readyz yang hanya mengembalikan HTTP 200 jika semua subsistem internal telah diinisialisasi.

Gunakan curl --fail --silent --output /dev/null untuk memeriksa titik akhir kesiapan HTTP. Opsi --fail membuat curl keluar dengan kode 22 untuk respons 4xx/5xx, sehingga logika percobaan ulang dapat berjalan dengan baik.

Opsi penting yang perlu diketahui:

  • --fail — perlakukan kesalahan HTTP sebagai kesalahan curl (keluar dengan nilai bukan nol)
  • --silent — sembunyikan keluaran kemajuan
  • --max-time N — batas waktu per permintaan dalam detik
  • --retry N --retry-delay S — lapisan percobaan ulang bawaan curl (berguna untuk kasus sederhana)
#!/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 "$@"

Jeda Eksponensial dalam Perulangan Tunggu

Perulangan percobaan ulang dengan interval tetap membebani layanan yang sedang pulih pada laju konstan. Jeda eksponensial menggandakan waktu tunggu pada setiap percobaan, sehingga mengurangi beban selama pemulihan sekaligus tetap cepat mencapai kondisi stabil ketika layanan segera aktif.

Rumus standarnya adalah: sleep_time = min(base * 2^attempt, max_sleep). Komponen variasi acak mencegah masalah lonjakan serentak ketika banyak kontainer dimulai ulang secara bersamaan.

Pola ini digunakan oleh alat produksi seperti wait-for-it, percobaan ulang AWS SDK, dan perulangan rekonsiliasi pengendali 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

Memeriksa Beberapa Dependensi

Aplikasi nyata memiliki banyak dependensi: basis data, cache, perantara pesan, dan mungkin API eksternal. Memeriksanya secara berurutan membuang waktu saat memulai. Pendekatan yang lebih baik adalah memeriksa semua dependensi secara paralel dan menunggu hingga semuanya berhasil.

Operator Bash & menjalankan setiap pemeriksaan di latar belakang, sedangkan wait mengumpulkan kode keluarnya. Jika salah satu pemeriksaan gagal, titik masuk akan keluar dengan nilai bukan nol sehingga memicu pemulaian ulang kontainer.

Teknik utama: tangkap PID latar belakang dengan $! dan teruskan PID tersebut secara eksplisit ke wait agar Anda dapat memeriksa kode keluar masing-masing.

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

Keaktifan vs Kesiapan: Skrip Berbeda untuk Pemeriksaan yang Berbeda

Kubernetes membedakan pemeriksaan keaktifan dan pemeriksaan kesiapan, dan keduanya harus melakukan hal yang berbeda:

  • Pemeriksaan keaktifan — menjawab: apakah proses masih aktif dan tidak mengalami kebuntuan? Pemeriksaan ini harus cepat dan hanya memeriksa status internal, misalnya berkas PID proses ada atau titik akhir kesehatan lokal mengembalikan 200. Pemeriksaan keaktifan yang gagal akan menghentikan dan memulai ulang kontainer.
  • Pemeriksaan kesiapan — menjawab: apakah pod ini seharusnya menerima lalu lintas? Pemeriksaan ini dapat memeriksa dependensi hilir. Pemeriksaan kesiapan yang gagal menghapus pod dari penyeimbang beban Service, tetapi tidak memulainya ulang.

Jangan pernah menempatkan pemeriksaan dependensi yang lambat dalam pemeriksaan keaktifan. Gangguan basis data singkat akan memulai ulang semua pod aplikasi secara keliru dan memperparah masalah.

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

Pemeriksaan Saat Memulai dan initContainers

Kubernetes menyediakan jenis pemeriksaan ketiga: startupProbe. Pemeriksaan ini berjalan sebagai pengganti pemeriksaan keaktifan atau kesiapan hingga berhasil sekali, sehingga aplikasi yang memerlukan waktu lama untuk memulai (pemanasan JVM, migrasi basis data) memiliki waktu untuk diinisialisasi tanpa memicu kegagalan pemeriksaan keaktifan palsu.

Untuk menunggu dependensi, initContainers sering kali lebih rapi daripada skrip titik masuk. Kontainer tersebut berjalan sebelum kontainer aplikasi dimulai, dan Kubernetes menangani logika percobaan ulang atau pemulaian ulang secara otomatis. Citra kontainer inisialisasi hanya memerlukan sh, nc, atau curl — Anda dapat menggunakan citra busybox atau alpine yang minimal.

Contoh spesifikasi initContainer dalam manifes 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

Skrip Pemeriksaan Kesehatan dengan Keluaran JSON

Sistem produksi sering menggabungkan status kesehatan dari berbagai subsistem dan menyajikannya sebagai muatan JSON terstruktur. Data ini digunakan oleh penyeimbang beban, orkestrator, dan dasbor pemantauan.

Skrip pemeriksaan kesehatan Bash dapat membuat keluaran JSON secara langsung menggunakan printf atau jq. Kode keluar tetap mengendalikan otomatisasi; isi JSON ditujukan untuk operator manusia dan sistem pemantauan.

Konvensinya: kembalikan HTTP 200 dengan {"status":"ok"} saat sehat, dan HTTP 503 dengan {"status":"degraded", "checks":{...}} saat tidak sehat. Skrip di bawah ini dimaksudkan untuk disajikan oleh pembungkus HTTP ringan seperti socat atau dipanggil langsung oleh pemeriksaan 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

Utilitas Batas Waktu dengan Pola Tenggat Waktu

Perintah GNU timeout membungkus perintah apa pun dan menghentikannya jika tidak selesai dalam durasi yang ditentukan. Ini adalah cara paling rapi untuk menerapkan tenggat tegas pada perulangan tunggu atau pemeriksaan kesehatan tanpa mengelola pekerjaan latar belakang secara manual.

timeout DURATION COMMAND [ARGS...]

Kode keluar dari timeout:

  • 0 — perintah berhasil dalam batas waktu
  • Kode keluar perintah — perintah berjalan tetapi mengembalikan nilai bukan nol
  • 124 — batas waktu perintah tercapai (SIGTERM dikirim)
  • 137 — perintah dihentikan dengan SIGKILL (setelah --kill-after)

Mendeteksi kode keluar 124 memungkinkan Anda mencetak pesan batas waktu yang jelas, bukan kesalahan umum.

#!/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-it Mandiri dalam Bash Murni

Banyak citra kontainer minimal tidak menyertakan nc (netcat). Bash murni dapat membuka koneksi TCP menggunakan substitusi proses ke /dev/tcp, fitur bawaan Bash yang tidak standar tetapi didukung secara luas dan tidak memerlukan alat eksternal apa pun.

Sintaks: /dev/tcp/HOST/PORT — Bash membuka koneksi TCP saat Anda mengalihkan keluaran ke atau masukan dari jalur ini. Bash menghasilkan kesalahan (keluar dengan nilai bukan nol) jika koneksi ditolak atau melewati batas waktu.

Teknik ini digunakan oleh skrip wait-for-it.sh populer yang disertakan dalam banyak penyiapan Docker Compose. Skrip di bawah ini merupakan implementasi lengkap dan mandiri yang dapat Anda COPY ke Dockerfile mana pun.

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

Mengintegrasikan Pemeriksaan ke dalam entrypoint.sh

Pola titik masuk adalah cara standar untuk menggabungkan perulangan tunggu, validasi lingkungan, dan pemulaian proses dalam satu skrip yang mudah dipelihara. ENTRYPOINT Docker memanggil skrip ini, dan skrip tersebut diakhiri dengan exec "$@" untuk menyerahkan kendali ke CMD dengan PID yang sama (sehingga penerusan sinyal dapat dilakukan dengan bersih).

entrypoint.sh berstandar produksi biasanya:

  • Memvalidasi variabel lingkungan wajib sejak awal (gagal lebih awal)
  • Menjalankan perulangan tunggu dependensi
  • Menjalankan migrasi basis data (bila berlaku)
  • Menjalankan pemeriksaan mandiri terakhir
  • Menyerahkan kendali dengan exec "$@"

Penggunaan exec sangat penting — perintah ini menggantikan proses shell sehingga aplikasi menjadi PID 1 dan menerima SIGTERM langsung dari Docker/Kubernetes saat penghentian bertahap.

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

Pemeriksaan Pengetahuan: Pemeriksaan Keaktifan vs Kesiapan

Uji pemahaman Anda tentang konsep-konsep utama yang dibahas dalam pelajaran ini.

Ringkasan: Pemeriksaan Kesehatan, Gerbang Kesiapan, dan Perulangan Tunggu

Dalam pelajaran ini, Anda membangun perangkat kerja Bash untuk koordinasi pemulaian kontainer yang andal. Berikut hal-hal yang telah Anda pelajari:

  • Pola tunggu hingga tersedia — perulangan until nc -z HOST PORT dengan batas waktu tegas dan pengaman waktu berlalu mencegah penantian tanpa akhir pada dependensi yang rusak.
  • Pemeriksaan kesiapan HTTP — curl --fail --max-time memvalidasi bahwa aplikasi benar-benar siap, bukan sekadar portnya terbuka.
  • Jeda eksponensial — menggandakan interval tidur di antara percobaan ulang mengurangi beban akibat lonjakan serentak dan memungkinkan layanan yang sedang pulih menjadi stabil.
  • Pemeriksaan dependensi secara paralel — menjalankan pemeriksaan di latar belakang dengan & dan mengumpulkan hasil dengan wait $PID mengurangi latensi pemulaian ketika terdapat banyak dependensi.
  • Keaktifan vs Kesiapan — pemeriksaan keaktifan harus cepat dan hanya memeriksa sistem lokal; pemeriksaan kesiapan dapat memeriksa sistem hilir. Jangan pernah mencampuradukkannya.
  • startupProbe — melindungi aplikasi yang lambat memulai dari kegagalan pemeriksaan keaktifan palsu selama inisialisasi.
  • Pemeriksaan /dev/tcp — pemeriksaan TCP dengan Bash murni tidak memerlukan alat eksternal, sehingga ideal untuk citra kontainer minimal.
  • entrypoint.sh — validasi lingkungan, perulangan tunggu, migrasi, dan exec "$@" membentuk pola standar pemulaian layanan berbasis kontainer.

Pola-pola ini membentuk dasar penerapan kontainer berstandar produksi yang dapat memulihkan dirinya sendiri di Docker Compose, Kubernetes, dan ECS.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu” gratis?

Ya — teks lengkap “Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus DevOps Bootcamp, upgrade ke CoddyKit PRO. Kursus DevOps Bootcamp mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu”?

Implementasikan loop tunggu dependensi dan probe liveness agar layanan dalam container dapat dimulai dengan andal. Kamu berlatih DevOps Bootcamp dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai DevOps Bootcamp?

Tidak diperlukan pengalaman sebelumnya. DevOps Bootcamp di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.

Berapa lama pelajaran “Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran DevOps Bootcamp ini?

Ya. Setiap pelajaran DevOps Bootcamp menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Menulis Dockerfile dan Entrypoint Shell yang Ringkas
  2. Membuat Template Konfigurasi dengan envsubst dan heredoc
  3. Membuat Skrip Resource Cloud dengan CLI dan jq
  4. Probe Kesehatan, Gerbang Kesiapan, dan Loop Tunggu
← Kembali ke DevOps Bootcamp