تحويل واجهة النموذج إلى حاوية Docker

يضع Docker واجهة API الخاصة بكم وإصدار Python وجميع التبعيات في صورة واحدة محمولة تعمل بالطريقة نفسها على أي جهاز. وينهي ذلك مشكلات «يعمل على جهازي» ويُعد الطريقة القياسية لشحن خدمات تعلّم الآلة.

إن Dockerfile وصفة تتكون من خطوات بناء. وتنشئ كل تعليمة طبقة مخزنة مؤقتًا، ولذلك يؤدي ترتيب الخطوات جيدًا إلى تسريع عمليات إعادة البناء.

يختار السطر FROM الصورة الأساسية. وتُعد python:3.11-slim صورة Debian صغيرة تحتوي على Python مثبتًا مسبقًا، وهي أخف بكثير من الصورة الكاملة، مما يقلل الحجم النهائي ومساحة الهجوم.

يحدّد WORKDIR دليل العمل داخل الحاوية؛ وتعمل أوامر COPY وRUN اللاحقة بالنسبة إليه، مما يحافظ على تنظيم المسارات.

انسخوا requirements.txt وحده قبل الشيفرة المصدرية. وبفضل تخزين Docker للطبقات مؤقتًا، لا يُعاد تثبيت التبعيات إلا عند تغيير المتطلبات، وليس عند كل تعديل على الشيفرة، مما يسرّع عمليات إعادة البناء بدرجة كبيرة.

ينفّذ RUN أمر بناء. ويتجاوز --no-cache-dir ذاكرة التخزين المؤقت لتنزيلات pip، مما يحافظ على صغر حجم الصورة؛ إذ لا فائدة من ذاكرة التخزين المؤقت داخل الصورة على أي حال.

انسخوا الآن بقية تطبيقكم. ويعني إجراء ذلك بعد تثبيت pip أن تعديل الشيفرة لا يؤدي إلى إبطال طبقة التبعيات المخزنة مؤقتًا.

يوثّق EXPOSE المنفذ الذي تستمع إليه الحاوية. ولا ينشر المنفذ بنفسه؛ إذ تنفذون ذلك وقت التشغيل باستخدام -p، لكنه يوضح النية للقرّاء والأدوات.

يحدد CMD الأمر الافتراضي الذي يُشغّل عند بدء الحاوية. ونشغّل هنا uvicorn مع الربط بالعنوان 0.0.0.0 حتى يمكن الوصول إليه من خارج الحاوية.

جميع المكوّنات بالترتيب الصحيح الملائم للتخزين المؤقت:

ابنوا الصورة مع وسم، ثم شغّلوها مع تعيين منفذ الحاوية إلى منفذ المضيف باستخدام -p.

اختبروا معرفتكم بـ Docker.

وضعتم واجهة API في Docker: FROM python:3.11-slim، وWORKDIR /app، ونسخ requirements.txt أولًا، وRUN pip install --no-cache-dir، ونسخ الشيفرة المصدرية، وEXPOSE 8000، ثم CMD لتشغيل uvicorn. ويساعد ترتيب الخطوات للاستفادة من التخزين المؤقت للطبقات على إبقاء عمليات إعادة البناء سريعة. وبهذا يكتمل مقرر تقديم الخدمات باستخدام FastAPI وهذه الدفعة من المحتوى.