انتشار blue/green با Docker Compose؛ از healthcheck تا برگشت مسیر

Compose می‌تونه برای موفق‌شدن healthcheck صبر کنه، ولی این کار نه مسیر reverse proxy رو عوض می‌کنه و نه درست‌کارکردن نسخه برای کاربر رو ثابت می‌کنه. در یک ماشین آزمایشی، دو نسخهٔ کوچک و بدون state رو در دو پروژهٔ Compose می‌گذاریم؛ یعنی خود نسخه‌ها داده یا نشست ماندگارِ برنامه تولید نمی‌کنن. هرکدوم شبکهٔ bridge و پورت آزمایش loopback خودش رو داره. پراکسی داخل پروژهٔ blue به هر دو شبکه وصل می‌شه و پورت سوم رو می‌گیره؛ مسیرش رو صریحاً به green می‌بریم و بعد به blue برمی‌گردونیم.

دو نسخه فقط متن کوتاه متفاوتی رو با یک Nginx ثابت‌شده به digest ارائه می‌دن. موضوع این تمرین جداسازی نسخه‌ها، شرط سلامت و اثبات مسیر ترافیکه، نه ساخت image برنامه. پایگاه داده، migration، دادهٔ مشترکِ قابل‌تغییر، ترافیک کاربر واقعی و TLS نداریم. تا پایان مهلت برگشت، هر دو نسخه روشن می‌مونن.

اینجا وعدهٔ انتشار بدون قطعی نمی‌دیم. بعد از reload ممکنه workerهای تازه و قدیمی مدتی کنار هم باشن؛ اتصال طولانی، کار پس‌زمینه، cache و سازگاری schema به طراحی جداگانهٔ برنامه نیاز دارن. یک probe محلیِ موفق روی green اون رفتارها رو تأیید نمی‌کنه.

فرم مقادیر نمونه رو باز کن و یک پیشوند تازه با حروف کوچک، مسیر کاملِ پوشهٔ تازه و سه پورت TCP متفاوت بالاتر از ۱۰۲۳ رو اعمال کن. نام پروژه‌ها با پسوندهای -blue و -green ساخته می‌شن. آدرس همهٔ پورت‌های منتشرشده روی 127.0.0.1 ثابت می‌مونه؛ این آموزش فیلدی برای بازکردن سرویس روی اینترنت نداره.

مقدارها در همین تب و آموزش و زبان و محیط انتخاب‌شده می‌مونن. تغییر نامعتبر یا اعمال‌نشده تا زمان اعمال یا بازنشانی، کپی رو متوقف می‌کنه. رمز رجیستری و secret برنامه رو وارد نکن. بررسی پایین پروژه و پوشهٔ از قبل موجود رو رد می‌کنه، ولی ممکنه بعدش فرایند دیگری پورت رو بگیره؛ خطای bind در مرحلهٔ بعد یعنی توقف، نه اجازهٔ کشتن اون فرایند.

نسخهٔ blue و پراکسی در یک پروژه هستن، ولی فقط پراکسی به شبکهٔ خارجیِ پروژهٔ green هم وصل می‌شه. نام مشخص blue-app جلوی اشتباه‌گرفتن سرویس‌های هم‌نام در چند شبکه رو می‌گیره. healthcheck پراکسی فقط می‌گه خود Nginx مسیر آمادگی محلیش رو پاسخ می‌ده؛ وابستگی به سلامت blue هم شرط شروعه، نه کنترل دائمیِ مسیر ترافیک.

هر پوشهٔ bindشده فقط در اختیار یک کانتینره و در حالت فعال SELinux برچسب خصوصی Z می‌گیره. پوشه‌ای بین دو نسخه مشترک نیست. Z رو روی پوشه‌های سیستم یا محتوای موجود اعمال نکن. انتشار پورت Docker حتی با bind روی loopback می‌تونه در قواعد فایروال میزبان اثر بذاره؛ از daemon آزمایشیِ مصوب استفاده کن و تنظیم مدیر فایروالش رو دست نزن.

services:
  blue:
    image: nginx:stable-alpine@sha256:0e52bd054126cdc040b1276c0af347aeb02a41b9cfe305d6094767ac30e97949
    restart: "no"
    ports:
      - "127.0.0.1:18081:80"
    volumes:
      - ./blue:/usr/share/nginx/html:ro,Z
    healthcheck:
      test: ["CMD-SHELL", "wget -q -O - http://127.0.0.1/healthz | grep -qx BLUE_READY"]
      interval: 2s
      timeout: 2s
      retries: 10
    networks:
      default:
        aliases: [blue-app]
  gateway:
    image: nginx:stable-alpine@sha256:0e52bd054126cdc040b1276c0af347aeb02a41b9cfe305d6094767ac30e97949
    restart: "no"
    ports:
      - "127.0.0.1:18080:80"
    volumes:
      - ./proxy:/etc/nginx/conf.d:ro,Z
    depends_on:
      blue:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "wget -q -O - http://127.0.0.1/gateway-ready | grep -qx PROXY_READY"]
      interval: 2s
      timeout: 2s
      retries: 10
    networks: [default, green]
networks:
  default: {}
  green:
    external: true
    name: academybg-green_default

green پروژهٔ Compose، شبکهٔ bridge، پوشهٔ محتوا و پورت loopback جدا داره. healthcheck همون endpoint کوچکِ محلی رو می‌خونه، نه مسیر ورودیِ پراکسی رو. بین این دو پروژه depends_on نداریم؛ بعداً سلامت green رو صریحاً هم از میزبان و هم از شبکهٔ پراکسی می‌سنجیم.

اول با create پروژه و شبکه رو آماده می‌کنیم، بدون اینکه green شروع بشه. این‌طوری پراکسیِ blue می‌تونه به شبکهٔ خارجی وصل بشه، در حالی که هنوز blue پاسخ می‌ده. create نه پایگاه داده راه می‌ندازه و نه مسیر ترافیک رو عوض می‌کنه.

services:
  green:
    image: nginx:stable-alpine@sha256:0e52bd054126cdc040b1276c0af347aeb02a41b9cfe305d6094767ac30e97949
    restart: "no"
    ports:
      - "127.0.0.1:18082:80"
    volumes:
      - ./green:/usr/share/nginx/html:ro,Z
    healthcheck:
      test: ["CMD-SHELL", "wget -q -O - http://127.0.0.1/healthz | grep -qx GREEN_READY"]
      interval: 2s
      timeout: 2s
      retries: 10
    networks:
      default:
        aliases: [green-app]
networks:
  default: {}

فایل فعال اول از این قالب میاد. هدر مسیر نشون می‌ده کدوم تنظیم پراکسی انتخاب شده و پاسخ /release نسخهٔ backend رو مشخص می‌کنه. هیچ‌کدوم تراکنش واقعیِ برنامه نیستن. نام upstream موقع بارگذاری تنظیم Nginx به آدرس تبدیل می‌شه؛ اگر بعداً IP کانتینر عوض بشه، ممکنه reload کنترل‌شدهٔ دیگری لازم باشه.

upstream demo_release {
    server blue-app:80;
}
server {
    listen 80;
    location = /gateway-ready {
        default_type text/plain;
        return 200 "PROXY_READY\n";
    }
    location / {
        proxy_pass http://demo_release;
        proxy_set_header Host $host;
        proxy_connect_timeout 2s;
        proxy_read_timeout 5s;
        add_header X-Demo-Route blue always;
    }
}

فقط upstream و برچسب نمایشیِ مسیر فرق دارن. قالب‌ها با پسوند .route داخل versions می‌مونن و وارد الگوی *.conf سطح بالای Nginx نمی‌شن. فایل server دوم یا فایل پشتیبان ویرایشگر با پسوند .conf در پوشهٔ بارگذاری‌شده نگذار.

upstream demo_release {
    server green-app:80;
}
server {
    listen 80;
    location = /gateway-ready {
        default_type text/plain;
        return 200 "PROXY_READY\n";
    }
    location / {
        proxy_pass http://demo_release;
        proxy_set_header Host $host;
        proxy_connect_timeout 2s;
        proxy_read_timeout 5s;
        add_header X-Demo-Route green always;
    }
}