Фінальний проєкт і failure drill

Фінальний drill об’єднує quorum, reconciliation, routing mesh, reverse proxy, observability і recovery: втрачаються manager та додатковий service instance під traffic.

• зафіксувати success conditions
• провести overlapping failures
• отримати нуль HTTP errors
• повернути baseline

Є три manager nodes з workloads, три replicas, два surviving voters, щонайменше один healthy task і Traefik з active health checks та трьома retry attempts.

Результат стосується цих умов та idempotent GET. Retry не є безпечним для кожного non-idempotent request без application semantics.

Stop Engine на manager-1 прибирає voter і local instance. Kill task на manager-2 створює другу втрату instance, поки manager-1 недоступний. Manager-2 і manager-3 зберігають quorum.

Успіх: 180 requests, 0 non-200, service 3/3, managers Ready/Active, temporary files видалені.

Контрольний прогін без retry дав 3 відповіді 502 із 180: health check ще не виключив endpoint. Retry повторює connection failure через healthy backend і закриває це вікно.

Retry доповнює health checks, capacity, readiness і timeouts. Retries та 5xx потрібно спостерігати.

• Починайте з 3/3 і quorum
• Підготуйте recovery
• Traffic запускайте до fault
• Не stop другий manager
• Фіксуйте history та exit 137
• Перевіряйте числовий criterion

Перевірте baseline, route, health checks, retry та HTTPS.

ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls
ssh swarm-manager-3 docker service ps swarm-ingress-demo
sed -n '1,80p' /home/goreckii_ai/traefik/dynamic/swarm.yaml
curl --fail --show-error --output /dev/null https://swarm-demo.goretskiy.pro/

Запустіть 180 requests, втратьте manager-1 і завершіть task на manager-2. Поверніть node та виконайте rollout.

rm -f /tmp/swarm-m24-http.log
started=$(date +%s)
( for n in $(seq 1 180); do code=$(curl --connect-timeout 2 --max-time 5 -sS -o /dev/null -w '%{http_code}' https://swarm-demo.goretskiy.pro/ || printf 000); printf '%s %s\n' "$n" "$code"; sleep 0.2; done ) > /tmp/swarm-m24-http.log &
load_pid=$!
sleep 2
ssh swarm-manager-1 sudo systemctl stop docker
sleep 5
ssh swarm-manager-2 'id=$(docker ps -q --filter label=com.docker.swarm.service.name=swarm-ingress-demo | head -1); test -n "$id"; docker kill "$id"'
sleep 8
ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ps --no-trunc swarm-ingress-demo
ssh swarm-manager-1 sudo systemctl start docker
sleep 18
ssh swarm-manager-3 docker service update --detach=false --force swarm-ingress-demo
wait "$load_pid"

Report має requests=180 і failures=0. Порожній awk означає відсутність non-200.

ended=$(date +%s)
total=$(wc -l < /tmp/swarm-m24-http.log)
failed=$(awk '$2 != 200 {count++} END {print count+0}' /tmp/swarm-m24-http.log)
printf 'requests=%s failures=%s duration_seconds=%s\n' "$total" "$failed" "$((ended-started))"
awk '$2 != 200 {print}' /tmp/swarm-m24-http.log
test "$total" -eq 180
test "$failed" -eq 0
ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls
curl --fail --show-error --output /dev/null https://swarm-demo.goretskiy.pro/

• 502 — health interval, retry, endpoints
• немає quorum — поверніть voter
• не 3/3 — capacity, constraints, image, logs
• exit 137 — kill або OOM
• manager Down — Engine, time, 2377/TCP
• HTTP 200 у degraded state — recovery триває

• Які failures перекриваються?
• Чому quorum є?
• Що гарантує retry?
• Навіщо перевіряти 3/3?
• Які evidence потрібні?
• Як зміниться drill із workers?

Курс засвоєно, якщо ви пояснюєте architecture, виконуєте drill без errors у заявлених умовах і повертаєте managers та replicas. Cleanup видаляє traffic log і повертає manager-1 у started/Active.

rm -f /tmp/swarm-m24-http.log
ssh swarm-manager-1 sudo systemctl start docker
ssh swarm-manager-3 docker node update --availability active swarm-manager-1
ssh swarm-manager-3 docker node ls
ssh swarm-manager-3 docker service ls