پرش به محتویات

شب ۱۴: به‌روزرسانی و بازگشت در Swarm

بخش ۱۴ از مجموعهٔ آموزش Traefik در ۳۰ شب؛ هر جلسه برای ۶۰ تا ۹۰ دقیقه مطالعه، تمرین عملی، بررسی نتیجه و تمرین رفع خرابی طراحی شده است. مثال‌ها مطابق منبع با Traefik Proxy v3.7 نوشته شده‌اند؛ برای محیط عملیاتی نسخهٔ اصلاحی آزموده‌شده یا digest مشخصی را ثابت کنید. تمرین‌ها را روی میزبان یا کلاستر آزمایشگاهی اجرا کنید.

فهرست کامل دورهٔ ترافیک در ۳۰ شب

هدف‌های یادگیری

  • کنترل هم‌زمانی به‌روزرسانی، پایش سلامت و بازگشت خودکار.
  • مشاهدهٔ همگرایی و جداسازی تغییر مسیر از جایگزینی task.
  • بازیابی stack سالم شناخته‌شده پس از به‌روزرسانی ناموفق.

تمرین عملی: تعریف رفتار امن به‌روزرسانی

services:
  traefik:
    stop_grace_period: 45s
    deploy:
      update_config:
        parallelism: 1
        delay: 10s
        monitor: 30s
        failure_action: rollback
        max_failure_ratio: 0
        order: stop-first
      rollback_config:
        parallelism: 1
        monitor: 30s
        order: stop-first
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3

فقط وقتی از start-first استفاده کنید که محدودیت‌های جانمایی و پورت منتشرشده اجازهٔ هم‌زیستی task قدیمی و جدید را بدهند. سپس به‌روزرسانی کنترل‌شدهٔ آزمایشگاهی اجرا کنید:

docker stack config -c swarm.yml > release-rendered.yml
docker service inspect edge_traefik > before-service.json
docker service update --image traefik:v3.7 edge_traefik
watch docker service ps edge_traefik
docker service inspect edge_traefik --format '{{json .UpdateStatus}}'
docker service logs --since 10m edge_traefik
curl -fsS --resolve whoami.swarm.example.test:80:127.0.0.1 \
  http://whoami.swarm.example.test/

تمرین خرابی: در آزمایشگاه موقت tag ایمیج ناموجود یا بررسی سلامت ناموفق قرار دهید، UpdateStatus را ببینید و اجازه دهید اقدام تعریف‌شدهٔ شکست بازگردانی کند، یا اجرا کنید:

docker service rollback edge_traefik
docker service ps edge_traefik --no-trunc
docker service inspect edge_traefik --format '{{.PreviousSpec.TaskTemplate.ContainerSpec.Image}}'

برای انتشار آزمایشی برنامه، سرویس‌های وزن‌دار ارائه‌دهندهٔ فایل می‌توانند ترافیک را میان سرویس‌های جداگانهٔ stable و canary در Swarm تقسیم کنند:

http:
  services:
    app-split:
      weighted:
        services:
          - {name: app-stable@swarm, weight: 95}
          - {name: app-canary@swarm, weight: 5}

برای ارزیابی وزن کم، از متریک و تعداد کافی درخواست استفاده کنید؛ آزمون پنج‌درخواستی اثبات آماری محسوب نمی‌شود.

فهرست بهره‌برداری

  • digest ایمیج فعلی و قبلی و stack تولیدشده را ثبت کنید.
  • موفقیت مبتنی بر سلامت و موفقیت آزمایشی صفحهٔ داده را تعریف کنید.
  • وضعیت task، UpdateStatus، لاگ، متریک و بررسی سلامت خارجی را پایش کنید.
  • با عبور از آستانه‌ها متوقف شوید یا برگردید؛ هنگام خرابی تصمیم بداهه نگیرید.
  • تا پایان پنجرهٔ بازگشت، دسترس‌پذیری configها و secretهای قبلی را تأیید کنید.

نکته‌های عیب‌یابی

  • وضعیت rollback_started است اما قطعی ادامه دارد: مشخصات قبلی واقعاً سالم نیست یا وضعیت خارجی تغییر کرده است.
  • به‌روزرسانی متوقف شده است: خطاهای task ردشده یا شکست‌خورده را با --no-trunc بررسی کنید.
  • سرویس وزن‌دار resolve نمی‌شود: نام همراه ارائه‌دهنده با نام واقعی تولیدشده تفاوت دارد؛ API را بررسی کنید.
  • استقرار مجدد stack اصلاح CLI را برمی‌گرداند: تغییر در YAML مطلوب ثبت نشده؛ فوراً Git را هماهنگ کنید.

خودآزمایی

  1. monitor چه چیزی را کنترل می‌کند؟ مدتی که Swarm هر task به‌روزشده را برای تشخیص شکست پایش می‌کند.
  2. چرا تغییر CLI می‌تواند خطرناک باشد؟ استقرار بعدی stack اختلافی را که در وضعیت مطلوب ثبت نشده بازنویسی می‌کند.
  3. بازگشت علاوه بر ایمیج چه چیزهایی را باید برگرداند؟ تنظیمات سازگار، ارجاع secretها، برچسب‌ها، شبکه‌ها و وابستگی‌های خارجی.
  4. اثبات کنید: به‌روزرسانی ناموفق ایجاد کنید، UpdateStatus را ثبت کنید و دوباره درخواست آزمایشی موفق بگیرید.