إعداد Django مع PostgreSQL و Nginx و Gunicorn على Ubuntu 20.04

Django هو إطار عمل تطبيقات ويب مجاني ومفتوح المصدر مبني بلغة Python البرمجية. Django سريع للغاية، وآمن، وقابل للتوسع بشكل كبير. على يد مطور ماهر، يمكن لـ Django إنشاء موقع ويب قوي بسرعة. ويمكنه التكامل بسلاسة مع خوادم الويب الشهيرة (Apache, Nginx)، وقواعد البيانات (MySQL, MariaDB, PostgreSQL, Oracle، و SQLite)، وما إلى ذلك. يدعم Django بعضًا من أكبر مواقع الويب في العالم مثل Instagram و Mozilla و NASA. يوضح هذا الدليل إعداد الأساس لتطبيق ويب بمساعدة Django مع PostgreSQL و Nginx و Gunicorn على Ubuntu 20.04.

المتطلبات الأساسية

يتطلب هذا الدليل أن تقوم بتشغيل خادم Ubuntu 20.04 مهيأ بجدار حماية أساسي ومستخدم غير جذر (non-root) يتمتع بامتيازات sudo. راجع هذا الدليل التفصيلي حول كيفية إعداد خادم Ubuntu. اتبع هذا البرنامج التعليمي لـ تهيئة مستخدم غير جذر بامتيازات sudo. يمكنك أيضًا تهيئة جدار حماية Iptables باتباع خطوات هذا الدليل.

سنقوم بتثبيت Django داخل بيئة افتراضية. تتيح البيئة الخاصة بالمشروع إدارة أسهل لمشاريع متعددة من نفس الخادم. بمجرد إعداد قواعد البيانات والتطبيقات، سنقوم بنشر خادم تطبيقات Gunicorn. سيكون Gunicorn هو واجهة التطبيق التي تترجم طلبات العميل من HTTP إلى استدعاءات Python التي يمكن لتطبيقنا الاستفادة منها. بعد ذلك، سنقوم بنشر Nginx أمام Gunicorn للتعامل مع الاتصالات بأداء سريع وميزات أمان سهلة التنفيذ.

تثبيت الحزم اللازمة

أولاً، ابدأ بتثبيت جميع الحزم اللازمة. لحسن الحظ، تتوفر كل هذه الحزم مباشرة من مستودعات حزم Ubuntu الرسمية. افتح الطرفية، وقم بتحديث ذاكرة التخزين المؤقت لحزم APT :

تعتمد قائمة الحزم على ما إذا كان تطبيق الويب سيستخدم Python 2 أو Python 3. قم بتشغيل الأمر التالي لتثبيت Django مع Python 3:

إصدار Django 1.11 LTS هو آخر إصدار من Django يدعم Python 2. إذا كنت تنوي استخدام Django مع Python 2، فقم بتثبيت الحزم التالية:

قاعدة بيانات ومستخدم PostgreSQL

أما بالنسبة لحل قاعدة البيانات، فسنستخدم PostgreSQL. إنه نظام قوي ومفتوح المصدر لإدارة قواعد البيانات الكائنية-العلائقية. يوفر PostgreSQL الموثوقية والمتانة والأداء. للحصول على خطوات تفصيلية حول إعداد PostgreSQL، راجع هذا الدليل حول إعداد PostgreSQL على خادم Ubuntu. بالنسبة للدليل الحالي، سنقوم بإعداد قاعدة بيانات ومستخدم مخصصين لتطبيق Django الخاص بنا.

بشكل افتراضي، يطبق PostgreSQL "مصادقة النظير" (peer authentication) كمخطط مصادقة للاتصالات المحلية. باختصار، ستقوم "مصادقة النظير" بمصادقة تسجيل الدخول إذا كان اسم مستخدم نظام التشغيل الخاص بالمستخدم يطابق اسم مستخدم PostgreSQL صالح. أثناء التثبيت، قام PostgreSQL بتهيئة مستخدم نظام تشغيل باسم postgres ليتوافق مع مستخدم إدارة postgres لـ PostgreSQL. قم بتسجيل الدخول إلى جلسة واجهة تفاعلية لـ PostgreSQL كـ postgres باستخدام الأمر التالي:

ستصل إلى محث PostgreSQL. الخطوة الأولى هي إنشاء قاعدة بيانات مخصصة للمشروع. للتوضيح، سيتم تسمية قاعدة البيانات viktor_project:

الخطوة التالية هي إنشاء مستخدم مخصص لقاعدة بيانات المشروع. يجب أن يكون للمستخدم اسم مستخدم قوي. للتوضيح، سيكون اسم المستخدم viktor_project_user:

الآن، سنقوم بتعديل بعض المعلمات:

• معلمات اتصال معينة. باختصار، لن يكون من الضروري الاستعلام عن القيم الصحيحة وتعيينها في كل مرة يتم فيها إنشاء اتصال. هذا يحسن أداء قاعدة البيانات بشكل كبير.
• الترميز الافتراضي إلى UTF-8. وهو ترميز عالمي ويتوقعه Django.
• مخطط عزل المعاملات الافتراضي إلى “read committed”. وهو يمنع القراءة من المعاملات غير المؤكدة.
• المنطقة الزمنية إلى UTC.

يوصى بجميع تغييرات المعلمات هذه من قِبل مشروع Django نفسه. لتنفيذ هذه التغييرات، قم بتشغيل الأوامر التالية. لا تنسَ تغيير اسم مستخدم قاعدة البيانات إلى الاسم الصحيح:

تغيير مسؤول قاعدة البيانات إلى مستخدم قاعدة البيانات المخصص:

لقد انتهى عملنا مع PostgreSQL في الوقت الحالي. اخرج من واجهة تفاعل PostgreSQL التفاعلية:

بيئة Python الافتراضية

بعد إعداد قاعدة البيانات، يمكننا الآن التركيز على تلبية بقية متطلبات المشروع. لتسهيل الإدارة، سنقوم بإنشاء بيئة افتراضية وتثبيت جميع متطلبات Python هناك. لإنشاء بيئة افتراضية، نحتاج إلى virtualenv. ويمكن تثبيته بسهولة باستخدام pip.

ستقوم الأوامر التالية بترقية pip وتثبيت virtualenv. بالنسبة لـ Python 3، قم بتشغيل الأوامر التالية:

بالنسبة لـ Python 2، قم بتشغيل الأوامر التالية بدلاً من ذلك:

بمجرد تثبيت virtualenv، يحين الوقت لإنشاء بيئة افتراضية. بعد ذلك، قم بإنشاء دليل مخصص للبيئة الافتراضية:

بعد ذلك، قم بتغيير الدليل النشط الحالي إلى الدليل المخصص للبيئة الافتراضية:

داخل الدليل، قم بتشغيل الأمر التالي. ستقوم أداة virtualenv بإنشاء بيئة افتراضية باسم المشروع:

سيؤدي ذلك إلى إنشاء دليل فرعي باسم المشروع. سيحتوي الدليل الفرعي على نسخة محلية من Python و pip. وهو يوفر المرونة لتثبيت وتكوين بيئة Python معزولة للمشروع.

سيقوم الأمر التالي بتنشيط البيئة الافتراضية:

ستتغير مطالبة الطرفية للإشارة إلى أنك تعمل داخل بيئة Python افتراضية. الآن بعد أن أصبحنا داخل البيئة الافتراضية، سنقوم بتثبيت متطلبات Python اللازمة. نحن بحاجة إلى Django و Gunicorn و psycopg2 (مهايئ PostgreSQL). سيأمر الأمر التالي أداة pip المحلية بتثبيت المكونات:

حتى لو كنت تستخدم Python 3، فإن pip هو الأمر الصحيح. وذلك لأنه داخل البيئة الافتراضية، يتم تغيير اسم pip3 إلى pip.

مشروع Django جديد

مع وجود مكونات Python في مكانها، يمكننا البدء في العمل مع ملفات مشروع Django الفعلية.

• إنشاء مشروع Django

تم إنشاء دليل المشروع بالفعل. سنخبر Django بتثبيت ملفاته هناك. ستنشئ هذه العملية دليلاً من المستوى الثاني يحتوي على الأكواد الفعلية. سيحتوي الدليل أيضًا على نص برمجى للإدارة. المفتاح هو أننا نخبر Django بالدليل المستهدف صراحةً بدلاً من تركه يقرر الدليل بالنسبة للدليل الحالي:

سيقوم Django بإنشاء المشروع وفقًا لذلك. إليك بعض الملفات والأدلة المهمة التي سنركز عليها. يتم استخدام أسماء الأدلة والملفات وفقًا للتوضيح.

• ~/viktor_project/manage.py: نص إدارة المشروع بواسطة Django.
• ~/viktor_project/viktor_project/: إنها الحزمة التي تحتوي على مشروع Django. يجب أن تحتوي على الملفات __init__.py و settings.py و urls.py و asgi.py و wsgi.py.

• ضبط إعدادات المشروع

بعد إنشاء المشروع، أول شيء يجب فعله هو ضبط تكوينه. افتح settings.py في محرر نصوص:

التوجيه الأول الذي نبحث عنه هو ALLOWED_HOSTS. وهو يحدد الخوادم أو أسماء النطاقات التي يمكنها الاتصال بمثيل Django. إذا كان أي طلب وارد يحتوي على رأس Host لا يطابق قائمة ALLOWED_HOSTS، فسيؤدي ذلك إلى حدوث استثناء. يوصى بذلك من قِبل Django لتجنب أنواع معينة من الثغرات الأمنية:

القسم التالي الذي سنركز عليه هو DATABASE. وهو يدير الوصول إلى قاعدة البيانات. بشكل افتراضي، يحتوي على تكوين لمحرك قاعدة بيانات SQLite. ومع ذلك، سنستخدم قاعدة بيانات PostgreSQL للمشروع. سيستخدم Django محول psycopg2 للاتصال بـ PostgreSQL:

الآن، انتقل إلى أسفل الملف. أضف الأسطر التالية للإشارة إلى موقع الملفات الثابتة. يساعد هذا Nginx في معالجة الطلبات الخاصة بهذه العناصر:

عملنا مع settings.py قد انتهى في الوقت الحالي. احفظ الملف وأغلق المحرر.

• إنهاء إعداد المشروع الأولي

يمكننا الآن ترحيل مخطط قاعدة البيانات الأولي إلى قاعدة بيانات PostgreSQL المخصصة. قم بتشغيل الأمر التالي:

بعد ذلك، نحتاج إلى إنشاء مستخدم متميز للمشروع. لإنشاء مستخدم متميز، قم بتشغيل الأمر التالي:

اجمع كل الملفات الثابتة في الموقع الذي حددناه في settings.py. سيتم جمع الملفات الثابتة في دليل منفصل يسمى “static” تحت دليل المشروع:

الآن، نحتاج إلى تعديل جدار حماية الخادم. إذا اتبعت دليل تكوين الخادم، فسيكون لديك بالفعل UFW مكونًا ومفعلًا. سنقوم بإنشاء استثناء للمنفذ 8000. هذا هو المنفذ الافتراضي الذي يستخدمه Django. تحقق من هذا الدليل لمعرفة المزيد حول أساسيات جدار حماية UFW واستخدامه.

بعد ذلك، تحقق من الإجراء:

أخيرًا، يمكننا اختبار الخادم أثناء العمل. ابدأ تشغيل خادم تطوير Django:

إذا تمت عملية التكوين بنجاح، فيجب أن يبدأ خادم تطوير Django ويقبل الطلبات الواردة. افتح متصفحًا وانتقل إلى عنوان IP/النطاق الخاص بخادمك على المنفذ 8000:

يجب أن تصل إلى صفحة الفهرس الافتراضية لـ Django. للوصول إلى لوحة الإدارة، أضف /admin إلى عنوان URL. لا يمكن الوصول إلى لوحة الإدارة إلا من خلال المستخدم المتميز الذي أنشأناه مسبقًا:

بعد تسجيل الدخول، ستصل إلى واجهة إدارة Django الافتراضية:

لقد انتهينا من الاختبار في الوقت الحالي. لإيقاف الخادم، اضغط على “Ctrl + C” من نافذة الطرفية.

• اختبار Gunicorn

قبل مغادرة البيئة الافتراضية، نريد التأكد من أن Gunicorn يمكنه خدمة التطبيقات. طريقة اختبار ذلك هي استخدام Gunicorn لتحميل وحدة WSGI الخاصة بالمشروع.

يقع أمر Gunicorn داخل دليل المشروع:

سيؤدي هذا إلى تشغيل Gunicorn على نفس الواجهة التي كان يعمل عليها Django. يمكننا اختبار التطبيق مرة أخرى من متصفح ويب عادي. لاحظ أن واجهة الإدارة لن يتم تطبيق أي تنسيق عليها لأن Gunicorn لا يزال لا يعرف كيفية العثور على محتويات CSS الثابتة:

عند الانتهاء، اضغط على “Ctrl + C” من نافذة الطرفية لإيقاف خادم Gunicorn.

• الخروج من البيئة الافتراضية

تم الانتهاء من تكوين تطبيق Django. قم بتشغيل الأمر التالي للخروج من البيئة الافتراضية:

ملفات مقبس وخدمة Gunicorn

لقد تحققنا من أن Gunicorn يمكنه التفاعل مع تطبيق Django. ومع ذلك، نحتاج إلى طريقة أكثر قوة لإدارة خادم التطبيق. وهنا يأتي دور systemd. يعد Systemd أحد أكثر أنظمة التهيئة (init) شيوعًا المتاحة على Linux. إليك دليل مفصل حول كيفية إدارة خدمات ووحدات systemd.

يمكننا إنشاء ملفات مقبس (socket) وخدمة لـ Gunicorn للسماح لـ systemd بإدارته كما لو كان خدمة. عند بدء التشغيل، سيتم إنشاء مقبس Gunicorn. سيستمع المقبس للاتصالات الواردة. وعند حدوث اتصال، سيقوم systemd ببدء عمليات Gunicorn لمعالجة الاتصال.

• مقبس Gunicorn

لنبدأ بإنشاء مقبس Gunicorn. يجب إنشاء الملف بامتيازات sudo:

أدخل الكود التالي داخل الملف:

كما ترى، هناك ثلاثة أقسام في الكود.

• [Unit]: يصف هذا القسم المقبس.
• [Socket]: يحدد موقع المقبس.
• [Install]: يضمن هذا الجزء أن يقوم systemd بإنشاء المقبس في الوقت المناسب.

احفظ الملف وأغلق المحرر.

• خدمة Gunicorn

بعد ذلك، سننشئ ملف خدمة لـ Gunicorn. على غرار ملف المقبس، يجب أيضًا إنشاؤه بامتيازات sudo:

أدخل الكود التالي:

يحتوي الكود على أقسام متعددة:

• [Unit]: يحدد هذا القسم البيانات الوصفية والتبعيات. كما يصف البدء فقط بعد الوصول إلى هدف الشبكة (network target).
• [Service]: يحدد هذا القسم المستخدم والمجموعة التي ستعمل العملية تحتها. تم تعيين ملكية المجموعة إلى “www-data” حتى يتمكن Nginx من الاتصال بـ Gunicorn. كما أنه يحدد أدلة العمل ويحدد أوامر البدء.
• [Install]: يخبر هذا القسم systemd بما يجب ربط هذه الخدمة به إذا تم تمكينها عند بدء التشغيل. يجب أن تبدأ بعد بدء تشغيل نظام المستخدمين المتعددين العادي.

بعد ذلك، احفظ الملف وأغلق المحرر.

• تمكين مقبس Gunicorn

مقبس Gunicorn جاهز للاستخدام. لذلك، يمكنك تشغيل الأوامر التالية. سيؤدي ذلك إلى بدء تشغيل المقبس وتمكينه. سيتم إنشاء ملف المقبس في /run/gunicorn.sock عند بدء التشغيل. عند إجراء اتصال بالمقبس، سيقوم systemd ببدء خدمة Gunicorn للتعامل معه:

تحقق من حالة مقبس Gunicorn:

الآن، تحقق من وجود ملف المقبس:

إذا كانت الحالة من systemctl تشير إلى وجود خطأ أو لم يتم العثور على ملف gunicorn.sock، فهذا يشير إلى أنه لم يتم إنشاء المقبس بشكل صحيح. تحقق من السجل التفصيلي للحصول على أدلة:

لا تنسَ إلقاء نظرة أخرى على ملف gunicorn.socket بحثًا عن الأخطاء المحتملة.

• تنشيط المقبس

لقد قمنا ببدء تشغيل gunicorn.socket حتى الآن. ومع ذلك، بدون أي طلب اتصال، لن يتم تنشيط gunicorn.service. بعد ذلك، تحقق من حالة Gunicorn:

يمكننا اختبار آلية تنشيط المقبس عن طريق إرسال طلب اتصال باستخدام curl:

يجب أن تحصل على مخرجات HTML من التطبيق. يشير هذا إلى أن Gunicorn بدأ بنجاح وكان قادرًا على خدمة تطبيق Django. تحقق من الحالة الحالية لخدمة Gunicorn:

إذا كان هناك أي سلوك أو مخرجات غير متوقعة (تشير إلى وجود خطأ)، فتحقق من السجلات التفصيلية للحصول على أدلة:

إذا تم إجراء تغييرات على ملف gunicorn.service، فستحتاج إلى إعادة تحميل البرنامج الخفي (daemon) لإعادة قراءة تعريف الخدمة. يتطلب ذلك أيضًا إعادة تشغيل خدمة Gunicorn:

تكوين Nginx

الآن، سنقوم بتكوين Nginx لتمرير حركة المرور الواردة إلى العملية. أولاً، قم بإنشاء كتلة خادم (server block) جديدة في Nginx:

ثم أدخل الكود التالي:

 

فيما يلي كتل متعددة في التكوين:

• service: تحدد هذه الكتلة أن الخادم يجب أن يستمع بشكل طبيعي على المنفذ 80 ويجب أن يستجيب لاسم مجال الخادم أو عنوان IP الخاص به.
• location: هذا هو إدخال الموقع (location) الأول. وهو يحدد مكان العثور على الأصول الثابتة.
• location: هذا هو إدخال الموقع (location) الثاني. تحدد هذه الكتلة معلمات الوكيل القياسية وكيفية تمرير حركة المرور إلى مقبس Gunicorn.

احفظ الملف وأغلق المحرر. اربط الملف بدليل “sites-enabled” لتنشيطه:

بعد ذلك، اختبر ما إذا كان هناك أي خطأ في بناء الجملة في تكوين Nginx:

إذا لم تجد أي خطأ، فأعد تشغيل Nginx لتطبيق التغيير:

نحتاج إلى تعديل قواعد UFW مرة أخرى. لم نعد بحاجة إلى الوصول إلى خادم التطوير، لذا يمكننا إزالة الاستثناء للمنفذ 8000. بالإضافة إلى ذلك، نريد فتح المنفذ 80 لحركة المرور العادية:

تحقق من تغييرات قواعد جدار الحماية هذه:

يجب أن يكون الخادم الآن متاحًا للوصول من متصفح ويب عادي.

إجراءات استكشاف الأخطاء وإصلاحها

إذا تم اتباع جميع الخطوات بشكل صحيح، فيجب أن يكون تطبيق Django متاحًا عبر الإنترنت. وإذا لم يكن كذلك، فهذا يشير إلى أن التثبيت لم يجرِ كما هو مخطط له. نحتاج إلى استكشاف الأخطاء وإصلاحها لمعرفة مصدر المشكلة.

• Nginx يعرض الصفحة الافتراضية

إذا كان Nginx يعرض الصفحة الافتراضية بدلاً من وكيل التطبيق، فهذا يعني عادةً أن server_name تم تكوينه بشكل خاطئ في كتلة الخادم.

في هذا المثال، يتم تخزين كتلة الخادم في الموقع التالي:

إن إدخال server_name يحدد كتلة الخادم التي سيستخدمها Nginx للاستجابة للطلبات. إذا كانت الصفحة الافتراضية تظهر، فمن المحتمل أن Nginx لم يتمكن من مطابقة الطلب مع كتلة خادم صريحة، لذلك يتراجع إلى الكتلة الافتراضية بدلاً من ذلك:

تحقق مما إذا كانت كتلة الخادم لمشروع Django الخاص بك تحتوي على server_name.

• 502 Bad Gateway

يشير الخطأ 502 إلى أن Nginx لم يتمكن من توكيل الطلب بنجاح. هناك مجموعة واسعة من مشكلات التكوين المحتملة التي يمكن أن تؤدي إلى الخطأ 502، لذلك نحتاج إلى أدلة لاستكشاف الأخطاء وإصلاحها بشكل صحيح.

المصدر الرئيسي للأدلة هو سجلات أخطاء Nginx. بشكل عام، ستشير إلى الظروف التي تسببت في حدوث المشكلات أثناء التوكيل. تحقق من سجل أخطاء Nginx باستخدام الأمر التالي:

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

• connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

يشير هذا إلى أن Nginx لم يتمكن من العثور على gunicorn.sock في الموقع المحدد في التكوين. يتم وصف الموقع بواسطة توجيه proxy_pass ضمن كتلة الموقع. تحقق مما إذا كان proxy_pass يشير إلى الموقع الصحيح لـ gunicorn.sock الذي تم إنشاؤه بواسطة وحدة systemd لـ gunicorn.socket:

إذا لم يتم العثور على gunicorn.sock تحت الدليل /run، فهذا يعني أن systemd لم يتمكن من إنشائه. يجب عليك إعادة التحقق من خطوات تكوين ملف مقبس Gunicorn.

• connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

يشير هذا إلى أن Nginx لم يتمكن من الاتصال بمقبس Gunicorn بسبب مشكلات في الأذونات. يمكن أن يحدث هذا إذا تم تنفيذ العملية كمستخدم root بدلاً من مستخدم sudo . على الرغم من أن systemd قام بإنشاء gunicorn.sock بنجاح، إلا أن Nginx غير قادر على استخدامه.

أحد الأسباب المحتملة قد يكون الأذونات المحدودة بين الدليل الجذري (/) وملف gunicorn.sock . تحقق من الإذن والملكية لملف المقبس وكل من أدلته الأبوية:

يصف العمود الأول أذونات الملف. ويصف العمود الثاني المستخدم المالك، والعمود الثالث المجموعة المالكة. إذا كان أي من الأدلة المؤدية إلى gunicorn.sock لا يمتلك أذونات القراءة والتنفيذ المناسبة، فسيفشل Nginx في الوصول إلى المقبس.

• Django يعرض "could not connect to the server: Connection refused"

يشير هذا إلى أن Django فشل في الاتصال بخادم PostgreSQL. تأكد من أن خادم PostgreSQL يعمل ونشط:

إذا لم يكن قيد التشغيل، فقم بتشغيل الأوامر التالية لبدء تشغيله وتمكينه:

إذا كنت لا تزال تواجه هذا الخطأ، فتأكد من تحديد بيانات اعتماد قاعدة البيانات بشكل صحيح ضمن settings.py:

المزيد من استكشاف الأخطاء وإصلاحها

لمزيد من استكشاف الأخطاء وإصلاحها، هناك سجلات مختلفة تم إعدادها. يمكن أن تساعد هذه السجلات في تضييق نطاق مصادر المشكلات.

إليك قائمة بالسجلات التي يمكن أن تساعد:

• سجلات Nginx

• سجلات الوصول - Nginx

• سجلات الأخطاء - Nginx

•  سجلات التطبيق - Gunicorn

•  سجلات المقبس - Gunicorn

بعد إجراء أي تحديث على التكوين أو التطبيق، قد يتعين عليك إعادة تشغيل العمليات لتطبيق التغييرات. إذا تم تحديث تطبيق Django، فأعد تشغيل عملية Gunicorn لتطبيق التغييرات:
في حالة إجراء تغييرات على ملفات مقبس أو خدمة Gunicorn، قم بإعادة تحميل الـ daemon وإعادة تشغيل العمليات:
إذا تم إجراء تغييرات على تكوين كتلة خادم Nginx، فيجب اختبارها قبل وضعها قيد التشغيل. يتطلب ذلك أيضًا إعادة تشغيل Nginx:

أفكار نهائية

يوضح هذا الدليل بنجاح كيفية وضع الأساس لـ Django. يوفر Django العديد من المكونات الشائعة لتطبيقات الويب، مما يتيح لك التركيز على العناصر الفريدة. سيعمل مشروع Django داخل البيئة الافتراضية. يدير Gunicorn الاتصال بين طلبات العملاء وDjango. وأخيرًا، يعمل Nginx كوكيل عكسي للتعامل مع اتصالات العملاء.

حوسبة سعيدة!