النشر على السحابة

طريقان إلى نفس الفكرة

قبل أن تبدأ

الفكرة الجوهرية

1فحص الصحة

المنصة تسأل /health كل بضع ثوانٍ. لو فشل لا ترسل زوارًا، أو تعيد التشغيل. الفحص الجيد يتأكد من الاعتماديات الأساسية لا أن الخادم يرد فقط:

def check_database():
    return True

def check_cache():
    raise TimeoutError("redis did not answer in 1s")

CHECKS = {"database": check_database, "cache": check_cache}

def health():
    results = {}
    for name, check in CHECKS.items():
        try:
            results[name] = "ok" if check() else "fail"
        except Exception as e:
            results[name] = f"fail: {e}"
    healthy = all(v == "ok" for v in results.values())
    return (200 if healthy else 503), results

status, body = health()
print(status, body)

2نشر على منصة مُدارة

أغلب المنصات تقرأ Dockerfile، وتطلب الأسرار في لوحتها، ومسار فحص الصحة. مثال عام بخطوات واجهة سطر الأوامر:

# build and tag with the version, never "latest"
docker build -t registry.example.com/cafe-api:1.4.0 .
docker push registry.example.com/cafe-api:1.4.0

# run migrations as a one-off job before switching traffic
<platform> run --image cafe-api:1.4.0 -- alembic upgrade head

# deploy; the platform waits for /health before sending traffic
<platform> deploy --image cafe-api:1.4.0 --health-path /health

# something wrong? redeploy the previous tag
<platform> deploy --image cafe-api:1.3.2

3خادم افتراضي مع Caddy

على VPS، Caddy أمام التطبيق يحصل على شهادة HTTPS ويجدّدها تلقائيًا. ملف إعداد من ثلاثة أسطر:

# Caddyfile
cafe.example.com {
    reverse_proxy api:8000
}

مثال محلول

المسألة: إصدار جديد يحذف عمود phone ويعيد تسميته mobile. أثناء النشر، النسخة القديمة ما زالت تعمل وتطلب phone فتنهار. الحل بثلاث مراحل: (1) أضف mobile وانسخ البيانات، والكود يكتب في الاثنين. (2) انشر كودًا يقرأ mobile فقط. (3) احذف phone في إصدار لاحق. كل مرحلة متوافقة مع النسخة التي قبلها.

خرافة مقابل حقيقة

أين تقابله في العمل

اختبر فهمك

بطاقات مراجعة سريعة

تحقق من فهمك