0Pricing
DevOps Bootcamp · 강의

상태 프로브, 준비 게이트 및 대기 루프

컨테이너화된 서비스가 안정적으로 시작되도록 의존성 대기 루프와 활성 상태 프로브를 구현합니다.

상태 프로브, 준비 게이트 및 대기 루프은(는) CoddyKit의 무료 DevOps Bootcamp 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 DevOps Bootcamp 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

서비스가 시작 시 실패하는 이유

컨테이너화된 환경에서 서비스는 단독으로 시작되는 경우가 드뭅니다. 웹 애플리케이션에는 준비된 데이터베이스가 필요하고, 마이크로서비스에는 사용 가능한 메시지 중개 서비스가 필요하며, 작업 처리기는 작업을 처리하기 전에 캐시가 채워져 있어야 합니다.

조정이 없으면 컨테이너가 병렬로 시작되고 의존성이 정상 상태가 되기 전에 첫 요청이 도착합니다. 그 결과 연결 거부 오류, 널 포인터 예외, 손상된 시작 상태가 발생하여 수동으로 다시 시작해야 합니다.

  • 활성 상태 프로브 — 프로세스가 계속 실행 중이며 교착 상태가 아닌지 확인합니다.
  • 준비 상태 프로브 — 서비스가 트래픽을 받을 준비가 되었는지 확인합니다.
  • 대기 반복문 — 의존성에 연결할 수 있을 때까지 시작을 차단하는 스크립트입니다.

Kubernetes는 프로브 메커니즘을 기본으로 제공하지만, initContainers, entrypoint.sh 래퍼, 독립 실행형 상태 점검을 구동하는 셸 스크립트는 Bash로 작성됩니다. 이러한 스크립트를 능숙하게 다루는 것은 핵심 DevOps 기술입니다.

대기 패턴

가장 단순한 의존성 대기 반복문은 고정된 간격으로 대상을 반복 조회하여 연결할 수 있게 될 때까지 기다립니다. 표준적인 형태는 while 반복문과 nc(넷캣) 또는 curl을 사용하여 TCP 포트나 HTTP 엔드포인트를 확인합니다.

핵심 설계 결정 사항:

  • 제한 시간 — 고장 난 의존성 때문에 파드가 영원히 멈추지 않도록 N초 후 중단합니다.
  • 재시도 간격 — 복구 중인 서비스를 과도하게 반복 호출하지 않도록 프로브 사이에 대기합니다.
  • 종료 코드 — 제한 시간이 초과되면 1로 종료하여 컨테이너가 다시 시작되거나 초기화 컨테이너가 명확하게 실패하도록 합니다.

아래 코드 조각은 주 프로세스를 시작하기 전에 TCP 포트가 연결을 수락할 때까지 최대 60초 동안 기다립니다.

#!/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을 사용한 HTTP 준비 상태 프로브

TCP 연결은 포트가 열려 있다는 것만 알려 줄 뿐, 그 뒤의 애플리케이션이 요청을 처리할 준비가 되었다는 것은 알려 주지 않습니다. 많은 서비스는 모든 내부 하위 시스템이 초기화되었을 때만 HTTP 200을 반환하는 전용 /health 또는 /readyz 엔드포인트를 제공합니다.

curl --fail --silent --output /dev/null을 사용하여 HTTP 준비 상태 엔드포인트를 확인합니다. --fail 플래그를 사용하면 4xx/5xx 응답에서 curl이 22번 코드로 종료되므로 재시도 로직을 깔끔하게 실행할 수 있습니다.

알아 두어야 할 주요 플래그:

  • --fail — HTTP 오류를 curl 오류로 처리합니다(0이 아닌 종료 상태).
  • --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는 해당 프로브의 종료 코드를 수집합니다. 어느 프로브라도 실패하면 진입점이 0이 아닌 종료 상태로 끝나 컨테이너가 다시 시작됩니다.

핵심 기법은 $!을 사용해 백그라운드 프로세스 ID를 저장하고, 이를 명시적으로 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을 반환하는지 확인). 활성 상태 프로브가 실패하면 컨테이너가 종료된 후 다시 시작됩니다.
  • 준비 상태 프로브 — 이 파드가 트래픽을 받아야 하는가?라는 질문에 답합니다. 하위 의존성을 확인할 수도 있습니다. 준비 상태 프로브가 실패하면 파드가 서비스 로드 밸런서에서 제거되지만 파드 자체는 다시 시작되지 않습니다.

활성 상태 프로브에 느린 의존성 확인을 넣지 마세요. 짧은 데이터베이스 장애로 인해 모든 애플리케이션 파드가 잘못 다시 시작되면 문제가 더 악화될 수 있습니다.

#!/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 사양 예:

# 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 상태 확인 스크립트는 printf 또는 jq를 사용하여 JSON 출력을 직접 만들 수 있습니다. 종료 코드는 여전히 자동화를 제어하고, JSON 본문은 운영자와 모니터링 시스템을 위한 것입니다.

일반적인 규칙은 정상일 때 {"status":"ok"}와 함께 HTTP 200을 반환하고, 정상이 아닐 때 {"status":"degraded", "checks":{...}}와 함께 HTTP 503을 반환하는 것입니다. 아래 스크립트는 socat과 같은 가벼운 HTTP 래퍼를 통해 제공하거나 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

기한 패턴을 사용하는 제한 시간 도구

GNU의 timeout 명령은 지정된 기간 안에 완료되지 않는 명령을 감싸고 해당 명령을 종료합니다. 백그라운드 작업을 직접 관리하지 않고도 대기 반복문이나 상태 프로브에 엄격한 기한을 적용하는 가장 깔끔한 방법입니다.

timeout DURATION COMMAND [ARGS...]

timeout의 종료 코드:

  • 0 — 명령이 기한 안에 성공했습니다.
  • 명령의 종료 코드 — 명령이 실행되었지만 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 "$@"

순수 Bash로 구현한 독립형 wait-for-it

많은 최소 구성 컨테이너 이미지에는 nc(넷캣)가 없습니다. 순수 Bash에서는 /dev/tcp에 대한 프로세스 치환을 사용하여 TCP 연결을 열 수 있습니다. 이는 표준에는 포함되지 않지만 널리 지원되는 Bash 내장 기능으로, 외부 도구가 전혀 필요하지 않습니다.

구문: /dev/tcp/HOST/PORT — 이 경로로 또는 이 경로에서 리디렉션하면 Bash가 TCP 연결을 엽니다. 연결이 거부되거나 제한 시간이 초과되면 오류(0이 아닌 종료 상태)를 발생시킵니다.

이는 많은 Docker Compose 구성에 포함된 인기 있는 wait-for-it.sh 스크립트에서 사용하는 기법입니다. 아래 스크립트는 어떤 Dockerfile에도 COPY할 수 있는 완전한 독립 실행형 구현입니다.

#!/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에 프로브 통합하기

진입점 패턴은 대기 반복문, 환경 검증, 프로세스 시작을 유지 관리하기 쉬운 하나의 스크립트로 결합하는 표준 방식입니다. Docker의 ENTRYPOINT가 이 스크립트를 호출하고, 스크립트는 exec "$@"로 끝나 동일한 PID로 CMD에 제어권을 넘깁니다(신호를 깔끔하게 전달할 수 있습니다).

프로덕션 수준의 entrypoint.sh는 일반적으로 다음 작업을 수행합니다.

  • 필수 환경 변수를 조기에 검증합니다(즉시 실패).
  • 의존성 대기 반복문을 실행합니다.
  • 데이터베이스 마이그레이션을 수행합니다(해당하는 경우).
  • 최종 자체 점검을 실행합니다.
  • exec "$@"로 제어권을 넘깁니다.

exec를 사용하는 것은 매우 중요합니다. 셸 프로세스를 교체하여 애플리케이션이 PID 1이 되게 하고, Docker/Kubernetes의 정상 종료 과정에서 SIGTERM을 직접 받게 하기 때문입니다.

#!/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 도구 모음을 구축했습니다. 다음 내용을 다뤘습니다.

  • 대기 패턴 — 엄격한 제한 시간과 경과 시간 검사를 포함한 until nc -z HOST PORT 반복문으로 인해 문제가 있는 의존성 때문에 무한히 차단되는 것을 방지합니다.
  • HTTP 준비 상태 프로브 — curl --fail --max-time으로 포트가 열려 있기만 한 것이 아니라 애플리케이션이 실제로 준비되었는지 확인합니다.
  • 지수형 지연 — 재시도 사이의 대기 간격을 두 배로 늘려 동시 요청 폭주 부하를 줄이고 복구 중인 서비스가 안정화되도록 합니다.
  • 병렬 의존성 확인 — &로 프로브를 백그라운드에서 실행하고 wait $PID로 결과를 수집하여 여러 의존성이 있을 때 시작 지연 시간을 줄입니다.
  • 활성 상태와 준비 상태 비교 — 활성 상태 프로브는 빠르고 로컬 상태만 확인해야 하며, 준비 상태 프로브는 하위 시스템을 확인할 수 있습니다. 두 프로브를 절대 혼동하지 마세요.
  • startupProbe — 초기화 중 느리게 시작하는 애플리케이션이 잘못된 활성 상태 실패를 일으키지 않도록 보호합니다.
  • /dev/tcp 프로브 — 순수 Bash TCP 확인에는 외부 도구가 필요하지 않으므로 최소 구성 컨테이너 이미지에 적합합니다.
  • entrypoint.sh — 환경 검증, 대기 반복문, 마이그레이션, exec "$@"가 표준 컨테이너화 서비스 시작 패턴을 구성합니다.

이러한 패턴은 Docker Compose, Kubernetes, ECS 전반에서 자체 복구 기능을 갖춘 프로덕션 수준 컨테이너 배포의 토대를 이룹니다.

자주 묻는 질문

“상태 프로브, 준비 게이트 및 대기 루프” 강의는 무료인가요?

네 — “상태 프로브, 준비 게이트 및 대기 루프” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 DevOps Bootcamp 강의 전체를 잠금 해제할 수 있습니다. DevOps Bootcamp 강의에는 총 4개의 강의가 포함되어 있습니다.

“상태 프로브, 준비 게이트 및 대기 루프”에서 뭘 배우나요?

컨테이너화된 서비스가 안정적으로 시작되도록 의존성 대기 루프와 활성 상태 프로브를 구현합니다. 브라우저에서 직접 실행하는 실습 코드로 DevOps Bootcamp을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

DevOps Bootcamp을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 DevOps Bootcamp은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“상태 프로브, 준비 게이트 및 대기 루프” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 DevOps Bootcamp 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 DevOps Bootcamp 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 간결한 Dockerfile 및 셸 엔트리포인트 작성
  2. envsubst와 heredoc으로 구성 템플릿 만들기
  3. CLI와 jq를 활용한 클라우드 리소스 스크립팅
  4. 상태 프로브, 준비 게이트 및 대기 루프
← DevOps Bootcamp(으)로 돌아가기