نشرح في هذا المقال إنشاء تطبيق مكتوب بلغة بايثون Python على كوبرنتس Kubernetes باستخدام منصة أوكتيتو Okteto التي تسهل عملية تطوير تطبيقات كوبرنتس Kubernetes، فهي تسمح للمطورين ببناء التطبيقات واختبارها مباشرة في عناقيد كوبرنتس Kubernetes clusters دون الحاجة لإعداد بيئات تطوير معقدة، كما توّفر منصة Okteto ميزة التحديثات المباشرة live updates للتطبيقات التي تعمل في عناقيد كوبرنتس مما يسمح للمطورين رؤية التعديلات على الشيفرة في الوقت الفعلي دون الحاجة إلى إعادة بناء التطبيقات أو إعادة نشرها.

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

لمتابعة خطوات هذا المقال، سنحتاج إلى ما يلي:

• عنقود كوبرنتس النسخة 1.28، وسنستخدم في مقالنا عنقود من منصة DigitalOcean، يحتوي على 3 عقد على الأقل
• تثبيت واجهة سطر الأوامر kubectl وضبطها للتواصل مع عنقود كوبرنتس
• حساب على مستودع دوكر هب
• تثبيت دوكر Docker على جهازنا المحلي
• مفتاح ترخيص لاستخدام منصة Okteto، ويمكن التسجيل في الإصدار التجريبي المجاني.
• تثبيت مدير الحزم Helm لتطوير التطبيقات ضمن عناقيد Kubernetes، باتباع الخطوة الأولى من المقال التالي.
• نطاق Domain مسجَّل ومربوط مع Load Balancer لإدارة حركة مرور التطبيقات، وإنشاء سجل A record باسم * وعنوان IP موازن الحِمل.

إنشاء تطبيق بايثون

علينا التأكد أولًا بأن بايثون مثبّت على جهاز يعمل بنظام التشغيل أوبنتو بكتابة الأمر التالي في الطرفية:

python3 --version

إذا كانت حزم بايثون مثبّتة على الجهاز فسيعرضالأمر السابق نسختها، وإلّا نستخدم الأمر التالي لتثبيتها:

sudo apt install python3 python3-venv python3-pip -y

بعدها، ننشئ مجلد لتخزين شيفرة البرنامج وإعداداته:

mkdir my-app

ثم ننشئ بيئة افتراضية داخل مجلد التطبيق لوضع اعتماديات المشروع فيها:

cd my-app
python3 -m venv python-env

والآن نفعّل البيئة الافتراضية باستخدام الأمر التالي:

source python-env/bin/activate

ثم ننشئ ملف بايثون لكتابة شيفرة التطبيق فيه:

nano app.py

ونضيف له الشيفرة التالية:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello, This is a simple Python App!"

if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0')

ثم نثبّت إطار عمل فلاسك Flask:

pip install flask

نشغّل التطبيق الآن باستخدام الأمر التالي:

python3 app.py 

سنحصل على هذا الخرج:

Output

* Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5000
 * Running on http://172.20.10.2:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 311-959-468

أصبح إطار فلاسك Flask يعمل على جهازنا المحلي، نتأكّد من ذلك باستخدام الأمر curl:

curl -X GET -H "Content-Type: application/json" http://localhost:5000

سنحصل على الرد التالي من تطبيق فلاسك:

Output
Hello, This is a simple Python App!

يدل هذا الخرج على أن تطبيق فلاسك قد نُفّذ بنجاح دون أخطاء.

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

deactivate

وبهذا تكون أنشأنا تطبيقنا واختبرنا عمله محليًا، وحان وقت الخطوة الثانية لتشغيل هذا التطبيق داخل دوكر Docker.

تشغيل تطبيق بايثون داخل دوكر Docker

يتطلب تشغيل تطبيق بايثون داخل حاوية دوكر إنشاء صورة دوكر Docker image تحتوي على بيئة بايثون والاعتماديات اللازمة لتشغيل التطبيق. ننشئ أولًا ملفًا باسم Dockerfile في المجلد الأساسي للتطبيق:

nano Dockerfile

ثم نضيف عليه التعليمات التالية:

# Use an official Python runtime as a parent image
FROM python:3.8-slim

# Set the working directory in the container
WORKDIR /app

# Copy the current directory contents into the container at /app
ADD . /app

# Install any needed dependencies specified in requirements.txt
RUN pip install flask

# Make port 5000 available to the world outside this container
EXPOSE 5000

# Define environment variable
ENV NAME DockerizedPythonApp

# Run app.py when the container launches
CMD ["python3", "./app.py"]

فيما يلي شرح تعليمات ملف دوكر السابقة:

• تحدد التعليمة FROM python:3.8-slim الصورة الأساسية التي نحتاجها
• تضبط WORKDIR /app المجلد ‎/app مجلدًا للعمل داخل الحاوية container
• تنسخ التعليمة ADD . /app محتوى المجلد الحالي لمجلد حاوية التطبيق ‎/app
• تثبّت RUN pip install flask إطار العمل فلاسك Flask
• تستمع التعليمة EXPOSE 5000 على المنفذ 5000 للسماح بالاتصال
• يحدد CMD ["python3", "app.py"] الأمر الذي سينفذ عند تشغيل الحاوية وهو هنا الأمر app.py

بعدها سنشغّل الأمر التالي لبناء صورة دوكر وفقًا للتعليمات السابقة:

docker build -t my-app .

نستطيع تشغيل التطبيق الآن في الحاوية باستخدام الصورة التي أنشأناها:

docker run -dit -p 5000:5000 my-app:latest

يُشَغّل الأمر السابق حاوية من الصورة my-app ويضبط منفذ الحاوية على المنفذ المضيف 5000. نكتب الأمر التالي للتأكد من عمل الحاوية:

docker ps

وسنحصل على الخرج التالي:

Output
CONTAINER ID   IMAGE           COMMAND              CREATED         STATUS         PORTS                                       NAMES
761c54c77411   my-app:latest   "python3 ./app.py"   3 seconds ago   Up 3 seconds   0.0.0.0:5000->5000/tcp, :::5000->5000/tcp   pedantic_wescoff

نفتح متصفح الويب أو نستعمل موجّه الأوامر curl للوصول إلى التطبيق باستخدام العنوان ‎http://your-server-ip:5000/، وستظهر رسالة Hello, This is a simple Python App!‎ التي تشير لأن التطبيق يعمل داخل حاوية دوكر. وبهذا نكون شغّلنا تطبيق بايثون في حاوية دوكر بنجاح.

رفع صورة تطبيق بايثون إلى سجل DockerHub

لتنفيذ هذه الخطوة يجب أن يكون لدينا حساب على موقع دوكر هب DockerHub، بعدها نستخدم الأمر docker login لتسجيل الدخول، وسيُطلب منا إدخال اسم المستخدم وكلمة المرور.

docker login 

سنحصل على الخرج التالي:

Output
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: username@gmail.com
Password: 
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

يجب وسم الصورة باسم حسابنا ومجلد الاعتمادية المطلوب قبل رفعها push لمستودع دوكر هب:

docker tag my-app yourusername/my-app:latest

يمكن الآن رفع الصورة إلى دوكر هب باستخدام الأمر docker push:

docker push yourusername/my-app:latest

نتأكّد بعدها أن الصورة أصبحت موجودة بالبحث عنها باستخدام طرفية دوكر هب Docker Hub CLI:

docker search yourusername/my-app

وهكذا أصبحت صورة تطبيقنا مرفوعةً على منصة دوكر هب ويمكن للآخرين سحبها أو نشرها في عدّة بيئات.

إنشاء ملف Kubernetes Manifests لنشر التطبيق

علينا الآن إنشاء ملف Kubernetes Manifests باستخدام منصة Okteto لضبط عملية التطوير والخدمات وموارد Ingressللتطبيق. نكتب الأمر التالي لإنشاء الملف:

nano k8s.yaml

ثم نضيف الإعدادات التالية إليه:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: yourusername/my-app
        name: my-app

---

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: ClusterIP
  ports:
  - name: "my-app"
    port: 5000
  selector:
    app: my-app

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    dev.okteto.com/generate-host: my-app
spec:
  rules:
    - http:
        paths:
          - backend:
              service:
                name: my-app
                port:
                  number: 5000
            path: /
            pathType: ImplementationSpecific

سينشر الملف السابق تطبيقنا بالاسم my-app باستخدام منصة Okteto، وسينشره داخليًا عبر خدمة ClusterIP على المنفذ 5000، ثم سيُعدّ مورد Ingress لتوجيه حركة مرور HTTP إلى التطبيق. وهنا استخدمنا التعليقات التوضيحية الخاصة بـمنصة Okteto لتفعيل بعض الميزات التي تقدمها مثل إنشاء اسم المضيف hostname تلقائيًا.

تثبيت Okteto باستخدام مدير الحزم Helm

لتثبيت Okteto باستخدام مدير الحزم Helm علينا أولًا إضافة مستودع Okteto Helm إلى عميل Helm:

helm repo add okteto https://charts.okteto.com

وبعد ذلك علينا تحديث مستودعات مدير الحزم Helm لنضمن أن لدينا معلومات حديثة عن المخططات أو الحزم التي تحتوي على تعريفات موارد Kubernetes اللازمة لتشغيل التطبيق:

helm repo update

ثم ننشئ ملف config.yaml:

nano config.yaml

ونضيف بعدها مفتاح رخصة استخدام Okteto الخاص بنا، والنطاق الفرعي والإعدادات، كما هو موضح أدناه:

license: INSERTYOURKEYHERE
subdomain: okteto.example.com

buildkit:
  persistence:
    enabled: true

registry:
  storage:
    filesystem:
      persistence:
        enabled: true

ثم نثبّت أحدث نسخة من Okteto باستخدام ملف الإعدادات config.yaml:

helm install okteto okteto/okteto -f config.yaml --namespace okteto --create-namespace

سنحصل على الخرج التالي عند انتهاء التثبيت:

Output
NAME: okteto
LAST DEPLOYED: Tue Mar 12 20:27:21 2024
NAMESPACE: okteto
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Congratulations! Okteto is successfully installed!

Follow these steps to complete your domain configuration:

1. Create a wildcard A record "*.okteto.example.com", pointing it to the Okteto NGINX ingress controller External-IP:

   $ kubectl get service -l=app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/component=controller --namespace=okteto

2. Access your Okteto instance at `https://okteto.okteto.example.com/login#token=88f8cc11`

ملاحظة: علينا الاحتفاظ برمز الوصول الشخصي Personal Access Tokens ذو القيمة 88f8cc11 من الشيفرة أعلاه لأننا سنحتاجه لتوثيق حسابنا في Okteto. ننتظر قليلًا ثم نجلب عنوان IP لخادم NGINX Ingress:

kubectl get service -l=app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/component=controller --namespace=okteto

سنحصل على الخرج التالي:

Output
NAME                              TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
okteto-ingress-nginx-controller   LoadBalancer   10.101.31.239   45.76.14.191   80:31150/TCP,443:31793/TCP   3m21s

علينا إضافة العنوان الخارجي EXTERNAL-IP إلى سجل A تحت الاسم * في إعدادات بروتوكول DNS. والآن، نفتح المتصفح للوصول إلى Okteto باستخدام الرابط التالي: https://okteto.okteto.example.com/login#token=88f8cc11.

تثبيت وضبط إعدادات واجهة أوامر Okteto

تُتيح لنا واجهة أوامر Okteto مفتوحة المصدر تطوير التطبيقات مباشرة على Kubernetes. بإمكاننا تثبيت واجهة الأوامر على نظامي لينوكس Linux وماك MacOS باستخدام الأمر curl التالي:

sudo curl https://get.okteto.com -sSfL | sh

نتأكد من تثبيت واجهة أوامر Okteto باستخدام الأمر التالي الذي سيعرض تانسخة المثبّتة على جهازنا

Output
okteto version 2.25.2 

والآن علينا استخدام رمز الوصول الشخصي Personal Access Tokens للمصادقة:

okteto context use https://okteto.okteto.example.com --token 88f8cc11 --insecure-skip-tls-verify

وسنحصل على الخرج التالي:

Output
✓  Using okteto-admin @ okteto.okteto.example.com

نشغّل الأمر التالي للتأكد من إعدادات واجهة الأوامر:

okteto context list

وسنحصل على الخرج التالي:

Output
Name                                      Namespace     Builder                                 Registry
https://okteto.okteto.example.com *      okteto-admin  tcp://buildkit.okteto.example.com:443  registry.okteto.example.com
vke-4b7aaaa6-78fa-4a19-9fb3-cf7b8c1ec678  default       docker                                  -

إنشاء Okteto Manifest

علينا إنشاء ملف Okteto Manifest وضبط إعدادات بيئة التطوير لنتمكن من إنشاء تطبيقات بلغة بايثون. أولًا، ننشئ ملف okteto.yaml مخصص لتطبيق بايثون بسيط.

nano okteto.yaml

ثم نضيف الإعدادات التالية:

deploy:
  - kubectl apply -f k8s.yaml

dev:
  my-app:
    command: bash
    environment:
      - FLASK_ENV=development
    sync:
      - .:/app
    reverse:
      - 9000:9000
    volumes:
      - /root/.cache/pip

فيما يلي شرح الأوامر السابقة:

يتضمن القسم deploy إعدادات النشر. وعند تشغيل الأمر okteto up أو okteto deploy يُنَفَّذ الأمر kubectl apply -f k8s.yaml الذي ينشر موارد Kubernetes الموجودة في الملف k8s.yaml، ويُتيح ذلك فصل إعدادات النشر عن إعدادات التطوير.

يُحدد command: bash الأمر الذي يجب تشغيله عند بدء تشغيل بيئة التطوير ويحدد environment متغيرات البيئة التي يجب أن تكون في بيئة التطوير. وهنا صرّحنا أن متغيرات فلاسك FLASK_ENV يجب أن تكون في بيئة التطوير FLASK_ENV=development.

يحدد القسم sync القسم الملفات التي يجب مزامنتها من جهازنا المحلي مع ملفات بيئة التطوير، إذ يجب مزامنة المجلد (.) مع المجلد /app‎ من بيئة التطوير. ويوّضح  reverse قواعد توجيه المنافذ بين بيئة التطوير وجهازك المحلي. وفي مثالنا، يوجّه المنفذ 9000 من بيئة التطوير إلى المنفذ 9000 على جهازنا المحلي.

أخيرًا يوّضح v وحدات التخزين الإضافية التي ستُضاف إلى بيئة التطوير. وهنا سنضيف المجلد /root/.cache/pip، لنستخدمه لتخزين حزم pip في بيئة التطوير مؤقتًا.

الآن علينا نشر تطبيق بايثون إلى عنقود كوبرنيتس باستخدام الأمر التالي:

okteto deploy

وسنحصل على الخرج التالي عند نجاح عملية النشر:

Output
deployment.apps/my-app created
service/my-app created
ingress.networking.k8s.io/my-app created
 i  There are no available endpoints for 'Okteto'.
    Follow this link to know more about how to create public endpoints for your application:
    https://www.okteto.com/docs/cloud/ssl/
 ✓  Development environment 'Okteto' successfully deployed
 i  Run 'okteto up' to activate your development container

ثم نحدّث لوحة تحكم Okteto من المتصفح لتعاين التطبيق بعد نشره:

كما يمكننا الوصول إلى التطبيق من الرابط التالي: https://my-app-okteto-admin.okteto.example.com.

تطوير تطبيق بايثون في منصة كوبرنتس مباشرة

سنستخدم الأمر okteto up لنشر التطبيق مباشرةً على كوبرنتس، إذ يزامن هذا الأمر الشيفرة المحلية مع بيئة التطوير. وبإمكاننا تعديل الشيفرة باستخدام أي بيئة تطوير أو محرر أكواد على جهازنا، وستجري مزامنة التغييرات تلقائيًا مع بيئة التطوير في كوبرنيتس.

علينا أولًا تشغيل بيئة التطوير باستخدام Okteto:

okteto up

يُنشئ هذا الأمر بيئة تطوير وفقًا للإعدادات الموجودة في ملف okteto.yaml:

Output
i  Using okteto-admin @ okteto.okteto.example.com as context
 i  'Okteto' was already deployed. To redeploy run 'okteto deploy' or 'okteto up --deploy'
 i  Build section is not defined in your okteto manifest
 ✓  Persistent volume successfully attached
 ✓  Images successfully pulled
 ✓  Files synchronized
    Context:   okteto.okteto.example.com
    Namespace: okteto-admin
    Name:      my-app
    Reverse:   9000 <- 9000
root@my-app-okteto-7767588c8d-ndzj7:/app# 

نشغّل بعدها تطبيق بايثون:

python3 app.py 

وسنحصل على الخرج التالي:

* Serving Flask app 'app'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5000
 * Running on http://10.244.97.92:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 126-620-675

ثم نعدّل ملف التطبيق app.py:

nano app.py

وعدّل السطر التالي:

   return "Hello, This is a simple Python App Deployed on Kubernetes"

نحفظ الملف ثم نغلقه، وستٌطبَق التعديلات على الشيفرة البرمجية تلقائيًا في كوبرنتس. ثم نعيد تحميل صفحة التطبيق من متصفح الويب لتعاين التطبيق بعد التعديل.

الخاتمة

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

ترجمة -وبتصرّف- للمقال How to Deploy Python Application on Kubernetes with Okteto لكاتبيه hitjethva وEasha Abid.

اقرأ أيضًا

• إنشاء تطبيق ويب باستخدام إطار عمل فلاسك Flask من لغة بايثون
• نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس Kubernetes
• تثبيت بايثون 3 وإعداد بيئتها البرمجية
• تعرّف على كوبرنيتس Kubernetes

تعد عملية نشر نسخ instances من تطبيق ويب يدويًا على خادم أو أكثر عملية رتيبة وتستغرق الكثير من الوقت، لكن ببذل جهد بسيط يمكنك جعل عملية نشر تطبيق الويب مؤتمتة دون الحاجة لتدخل يدوي. سنسلط الضوء في هذا المقال على طريقة بسيطة لأتمتة نشر تطبيقات الويب باستخدام كل من خطافات الويب webhooks وحزم البناء buildpacks وملفات Procfiles.

لطالما كانت عملية تشغيل تطبيقات الويب على الخادم ودفع push أية تحديثات لاحقة إليه عملية مضجرة وشاقة لمطوري الويب، مما يدفعهم للاستعانة بأحد مزودي المنصة كخدمة Platform as a service أو PaaS اختصارًا فهذه المنصات توفر لهم بيئة متكاملة لتطوير وتشغيل التطبيقات دون الحاجة إلى إدارة البنية التحتية، كما تُسهّل نشر التطبيقات دون أن يضطر المطوّر للاهتمام بإجراءات حجز الخادم وإعداده مقابل زيادة طفيفة في التكلفة ونقص بسيط في المرونة.

لكن قد يحتاج المطور أو مسؤول DevOps لنشر التطبيقات على خوادم مدارة دون الاستعانة بطرف ثالث. وفي هذه الحالة يفضل أن يبتكر أداة بسيطة لأتمتة عملية النشر، وهو أمر غير معقّد، ويغدو أسهل كلما كانت المتطلبات أبسط، لذا سنتعلم في مقال اليوم كيف نطور هذه الأداة وندعها تنفذ الأجزاء الروتينية والمملة من عمليات نشر تطبيقات الويب نيابة عنا ونوفر وقتنا وجهدنا.

ملاحظة: تختلف خطوات أتمتة نشر موقع مبني بلغة PHP عن خطوات نشر تطبيق Node.js. كما توجد حلول جاهزة أشمل تدعى حزم البناء buildpacks مثل دوكو Dokku تناسب مجموعة أوسع من التقنيات. سنشرح في هذا المقال أداة بسيطة لأتمتة عمليات نشر تطبيقات الويب الخاصة بنا، وذلك باستخدام خطافات الويب webhooks وحزم البناء buildpacks وملفات Procfiles في غيت هب GitHub. ويمكن الاطلاع على الشيفرة المصدرية source code للنموذج الأولي منها على موقع غيت هب GitHub. ملاحظة: تستخدم حزم البناء buildpacks لتحديد كيفية تكوين بيئة التطبيق قبل نشره، وتحدد ملفات Procfiles النصية أنواع العمليات في التطبيق، مما يسهل تشغيلها تلقائياً. وسنشرحها مفصلًا في الفقرات التالية.

بناء تطبيق الويب

ستكون أولى خطواتنا كتابة برنامج بسيط بلغة غو Go، لا تقلق إذا كنت لا تألف العمل بلغة غو GO فبنية الشيفرة البرمجية المستخدمة بسيطة نسبيًا وستجدها سهلة الفهم. ويمكن كتابة البرنامج باللغة التي تناسبنا. قبل البدء لنتأكد من تثبيت Go distribution على نظام التشغيل باتباع الخطوات المذكورة الموقع الرسمي، بعدها يفضل تنزيل الشيفرة المصدرية لأداتنا باستنساخ clone مستودع غيت هب GitHub repository، فهذا سيسهّل متابعة تتمة الخطوات، فمقاطع الشيفرة البرمجية في المستودع مسمّاة بنفس أسماء الملفات التي سنحددها في المقال. إن استخدام برنامج غو Go دونًا عن غيره لكتابة برنامجنا سيحدّ من حاجتنا للاستعانة باعتماديات dependencies خارجية، ففي حالتنا لن نحتاج لتشغيل برنامج غو على الخادم إلا لتثبيت غيت Git وباش Bash، كما أن البرنامج لا يستهلك الكثير من موارد الجهاز مثل الذاكرة رام RAM والمعالج CPU عندما نضبطه بطريقة صحيحة.

ما هي خطافات الويب Webhooks في غيت هب

تمكّننا خطافات الويب في غيت هب من ضبط المستودع GitHub repository ليصدّر الأحداث events كلما طرأ تغيير ضمن المستودع أو أجرى مستخدم إجراء معينًا في المستودع المستضاف، وهذا يتيح للمستخدمين التسجيل subscribe في هذه الأحداث وتلقي إشعارات بمختلف الأحداث التي تجري في مستودعنا وما يتعلق به من خلال استدعاءات الروابط URL invocations حيث سيستدعى عنوان URL معين تلقائيًا عندما يقع حدث معين في المستودع.

خطوات إنشاء Webhooks في غيت هب

يعد إنشاء خطاف ويب Webhooks عملية بسيطة سنلخصها في الخطوات التالية:

1. نفتح صفحة الإعدادات settings في مستودعنا
2. نضغط على خطافات الويب والخدمات Webhooks & Services في قائمة الخيارات
3. نضغط على زر إضافة خطاف ويب Add webhook.
4. ندخل رابط، ونضيف إن شئنا رمزًا سريًا secret يتيح للمستقبل التحقق من حمولة البيانات الواردة payload
5. نحدد الاختيارات الأخرى في الصفحة حسب متطلباتنا
6. أخيرًا، نضغط على الزر الأخضر Add webhook.

يقدم غيت هب توثيقًا مستفيضًا لخطافات الويب وجميع التفاصيل المرتبطة بها، لكن الجزء الذي سنحتاج إليه في مقالنا هذا هو حدث الدفع push event الذي يُصدَّر كلما أجرى مستخدم عملية دفع إلى أي فرع branch في المستودع repository.

حزم البناء Buildpacks

أصبحت حزم البناء جزءًا لا يتجزأ من عملية نشر التطبيقات في وقتنا هذا، ويستخدمها العديد من مزودي المنصات كخدمة PaaS. حيث تتيح لنا حزم البناء تحديد كيفية ضبط مكدس التقنيات stack التي سنحتاجها لتشغيل تطبيقنا قبل أن ننشره، وكتابتها بغاية السهولة، ففي معظم الأحيان لن نحتاج حتى لكتابتها بنفسنا حيث تستطيع بإجراء بحث سريع على الإنترنت إيجاد حزم بناء جاهزة يمكننا استخدامها في عملية نشر تطبيقنا دون الحاجة إلى تعديلها. فمثلًا تقدم منصة Heroku توثيقًا شاملًا عن بنية حزم البناء وقائمة تضم أكثر حزم البناء المستخدمة وأفضلها بنيةً. تستخدم أداة الأتمتة التي نبنيها سكربت تصريف compile script لتجهيز التطبيق قبل تشغيله. ولا بد أن ننوه أننا لن نستفيض في كتابة حزم البناء، وإنما سنفترض أن سكربتات حزم البناء buildpack scripts الجاهزة تتوافق مع بيئة سطر الأوامر باش Bash، وأنها ستُشغَّل على نظام تشغيل أبونتو Ubuntu مثُبّت حديثًا ولم يطرأ عليه أي تعديل، ويمكن لاحقًا التوسّع أكثر فيها حسب متطلبات عملنا.

ملفات Procfiles

هي ملفات نصية بسيطة تمكّننا من تحديد مختلف أنواع الإجرائيات processes المستخدمة في تطبيقنا، وتُستخدم عادةً في معظم التطبيقات البسيطة إجرائية ويب web واحدة فقط تعالج طلبات بروتوكول HTTP. لكتابة هذه الملفات ما علينا سوى تحديد نوع إجرائية واحد في كل سطر وذلك بكتابة اسمها متبوعًا بنقطة مزدوجة : متبوعة بالأمر الذي سيولّد spawn هذه الإجرائية كمل يلي:

<type>: <command>

على سبيل المثال، إذا كان تطبيقنا مكتوب بنود جي إس Node.js، علينا تنفيذ الأمر node index.js لتشغيل خادم الويب. يمكن إذًا أن ننشئ ملف Procfile في المجلد الأساسي للشيفرة البرمجية ونسميه Procfile ونكتب ما يلي ضمنه:

web: node index.js

نلزم تطبيقاتنا بتحديد أنواع الإجرائيات في ملفات Procfiles لنتمكن من تشغيلها تلقائيًا بعد سحب pulling الشيفرة البرمجية.

معالجة الأحداث

نحتاج في برنامجنا إلى إضافة خادم HTTP مهمته استقبال طلبات POST الواردة من غيت هب، لذا علينا أن نخصص مسار رابط URL path لمعالجة هذه الطلبات. ونقدم في النموذج التالي مثالًا عن بنية الدالة function التي ستعالج الحمولات payloads الواردة من هذا النوع:

// hook.go
type HookOptions struct {
    App    *App
    Secret string
}


func NewHookHandler(o *HookOptions) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        evName := r.Header.Get("X-Github-Event")
        if evName != "push" {
            log.Printf("Ignoring '%s' event", evName)
            return
        }


        body, err := ioutil.ReadAll(r.Body)
        if err != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            return
        }


        if o.Secret != "" {
            ok := false
            for _, sig := range strings.Fields(r.Header.Get("X-Hub-Signature")) {
                if !strings.HasPrefix(sig, "sha1=") {
                    continue
                }
                sig = strings.TrimPrefix(sig, "sha1=")
                mac := hmac.New(sha1.New, []byte(o.Secret))
                mac.Write(body)
                if sig == hex.EncodeToString(mac.Sum(nil)) {
                    ok = true
                    break
                }
            }
            if !ok {
                log.Printf("Ignoring '%s' event with incorrect signature", evName)
                return
            }
        }


        ev := github.PushEvent{}
        err = json.Unmarshal(body, &ev)
        if err != nil {
            log.Printf("Ignoring '%s' event with invalid payload", evName)
            http.Error(w, "Bad Request", http.StatusBadRequest)
            return
        }


        if ev.Repo.FullName == nil || *ev.Repo.FullName != o.App.Repo {
            log.Printf("Ignoring '%s' event with incorrect repository name", evName)
            http.Error(w, "Bad Request", http.StatusBadRequest)
            return
        }


        log.Printf("Handling '%s' event for %s", evName, o.App.Repo)


        err = o.App.Update()
        if err != nil {
            return
        }
    })
}

نبدأ بالتحقق من نوع الحدث event الذي ولّد هذه الحمولة payload، وبما أن حدث الدفع push هو الحدث الوحيد الذي يهمنا يمكننا تجاهل بقية الأحداث. لكن حتى لو ضبطنا خطاف الويب ليصدّر أحداث الدفع فقط، لا بد أن نتوقع استقبال نوع آخر على الأقل من الأحداث على نقطة اتصال خطافنا hook endpoint التي تمثل الرابط الذي تُرسَل إليه البيانات وهو الحدث Ping.

الغاية من هذا الحدث التأكد من ضبط خطاف الويب بطريقة صحيحة على غيت هب. الخطوة التالية هي قراءة محتوى الطلب الوارد بأكمله، ثم حساب قيمة التشفير باستخدام خوارزمية التشفير HMAC-SHA1 والرمز السري secret ذاته الذي حددناه عند ضبط خطاف الويب، ومقارنتها بالبصمة signature المتضمَّنة في ترويسة الطلب للتحقق من صلاحية الحمولة payload الواردة، وفي حالتنا اخترنا تجاهل خطوة التحقق هذه إذا لم يكن الرمز السري محدَّدًا. 

ملاحظة: ننصح بوضع حد أقصى لحجم البيانات الذي يمكن التعامل معه قبل قراءة محتوى الطلب كاملًا، لكننا لن نتطرق إلى هذا في مقالنا وسنركز على الجوانب الأساسية للأداة فقط. بعدها، نستخدم هيكل بيانات struct من مكتبة GitHub client library for Go لتفريغ أو تحويل unmarshal حمولة البيانات الواردة فيها، وبما أننا نعلم أنه حدث دفع push فيمكننا استخدام بنية حدث الدفع. ثم نستخدم مكتبة التشفير القياسية بصيغة Json لتفريغ الحمولة إلى نسخة من البنية، ستنفذ بعدها بعض عمليات التحقق من الصحة وفي حال خلوها من أية مشكلة ستُستدعى الدالة التي تبدأ بتحديث تطبيقنا.

تحديث التطبيق

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

تهيئة المستودع المحلي

تبدأ هذه العملية بإجراء تحقق بسيط لنحدد إذا كانت هذه المرة الأولى التي نحاول نشر التطبيق فيها، وذلك بالتحقق من وجود مجلد المستودع المحلي local repository، فإذا لم يكن موجودًا نبدأ أولى خطواتنا بتهيئة initialize المستودع المحلي لدينا:

// app.go


func (a *App) initRepo() error {
    log.Print("Initializing repository")


    err := os.MkdirAll(a.repoDir, 0755)
    // Check err


    cmd := exec.Command("git", "--git-dir="+a.repoDir, "init")
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    cmd = exec.Command("git", "--git-dir="+a.repoDir, "remote", "add", "origin", fmt.Sprintf("git@github.com:%s.git", a.Repo))
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    return nil
}

يمكننا تهيئة المستودع المحلي لتطبيقنا بالخطوات التالية:

1. ننشئ مجلدًا للمستودع المحلي local repository في حال عدم وجوده.
2. نستخدم بالأمر git init لإنشاء مستودع فارغ bare repository
3. نضيف رابطًا للمستودع البعيد remote repository إلى مستودعنا المحلي ونسميه origin. بعد تهيئة المستودع سيكون جلب التغييرات عملية بسيطة.

جلب التغييرات

لجلب التغييرات من المستودع البعيد لن نحتاج سوى لاستدعاء أمر واحد، وذلك وفق ما يلي:

// app.go


func (a *App) fetchChanges() error {
    log.Print("Fetching changes")


    cmd := exec.Command("git", "--git-dir="+a.repoDir, "fetch", "-f", "origin", "master:master")
    cmd.Stderr = os.Stderr
    return cmd.Run()
}

إن تنفيذ أمر جلب التغييرات git fetch إلى مستودعنا المحلي بهذه الطريقة يجنبنا مشاكل عجز Git عن التقدم السريع fast-forward في بعض الحالات. وصحيح أننا لا ننصح بالاعتماد على عمليات الجلب الإجبارية، لكن إن احتجنا إلى تنفيذ عملية دفع إجبارية إلى مستودعنا البعيد يمكن اتباع هذه الطريقة.

تصريف التطبيق

بما أننا نستخدم سكربتات من حزم البناء buildpacks لتصريف compile تطبيقاتنا التي ننشرها، تتمثل مهمتنا بتنفيذ الخطوات البسيطة التالية من أجل تحضير وتصريف التطبيق بشكل آلي:

// app.go


func (a *App) compileApp() error {
    log.Print("Compiling application")


    _, err := os.Stat(a.appDir)
    if !os.IsNotExist(err) {
        err = os.RemoveAll(a.appDir)
        // Check err
    }
    err = os.MkdirAll(a.appDir, 0755)
    // Check err
    cmd := exec.Command("git", "--git-dir="+a.repoDir, "--work-tree="+a.appDir, "checkout", "-f", "master")
    cmd.Dir = a.appDir
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    buildpackDir, err := filepath.Abs("buildpack")
    // Check err


    cmd = exec.Command("bash", filepath.Join(buildpackDir, "bin", "detect"), a.appDir)
    cmd.Dir = buildpackDir
    cmd.Stderr = os.Stderr
    err = cmd.Run()
    // Check err


    cacheDir, err := filepath.Abs("cache")
    // Check err
    err = os.MkdirAll(cacheDir, 0755)
    // Check err


    cmd = exec.Command("bash", filepath.Join(buildpackDir, "bin", "compile"), a.appDir, cacheDir)
    cmd.Dir = a.appDir
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
    return cmd.Run()
}

لنشرح الكود أعلاه خطوة بخطوة:

• نبدأ بحذف المجلد السابق الخاص بتطبيقنا في حال وجوده، ثم ننشئ مجلدًا جديدًا ونسحب checkout محتويات الفرع الرئيسي master branch إليه
• نستخدم بعد ذلك سكريبت detect الموجود ضمن حزمة البناء التي ضبطناها لنحدد إذا كان باستطاعتنا معالجة التطبيق
• ننشئ مجلد لذاكرة التخزين المؤقتة ونسميه cache من أجل عملية تصريف حزمة البناء إذا دعت الحاجة لذلك، علمًا أن المجلد قد يكون موجودًا مسبقًا في حال أجرينا عمليات تصريف سابقة
• يمكننا في هذه المرحلة استدعاء سكربت التصريف المسمى compile من حزمة البناء وجعله يجهّز كل ما يحتاجه التطبيق قبل تشغيله عندما تُشغَّل حزم البناء بطريقة صحيحة فستتكمن من التعامل مع التخزين المؤقت caching وإعادة استخدام الموارد مسبقة التخزين

إعادة تشغيل التطبيق

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

// app.go


func (a *App) stopProcs() error {
    log.Print(".. stopping processes")


    for _, n := range a.nodes {
        err := n.Stop()
        if err != nil {
            return err
        }
    }


    return nil
}


func (a *App) startProcs() error {
    log.Print("Starting processes")


    err := a.readProcfile()
    if err != nil {
        return err
    }


    for _, n := range a.nodes {
        err = n.Start()
        if err != nil {
            return err
        }
    }


    return nil
}

في هذا النموذج من برنامجنا نوقف مختلف الإجرائيات ونشغلها بالمرور على مصفوفة من العقد nodes، تكون فيها كل عقدة عبارة عن إجرائية تقابل إحدى نسخ التطبيق وفق الإعدادات المضبوطة قبل تشغيل أداة الأتمتة على الخادم. نراقب في أداتنا الحالة الأساسية لإجرائية كل عقدة، كما نحتفظ بملفات سجل log files عنها. قبل تشغيل جميع العقد يُسنَد إلى كل منها رقم منفذ فريد، بدءًا من رقم نحدده وفق ما يلي:

// node.go


func NewNode(app *App, name string, no int, port int) (*Node, error) {
    logFile, err := os.OpenFile(filepath.Join(app.logsDir, fmt.Sprintf("%s.%d.txt", name, no)), os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
    if err != nil {
        return nil, err
    }


    n := &Node{
        App:     app,
        Name:    name,
        No:      no,
        Port:    port,
        stateCh: make(chan NextState),
        logFile: logFile,
    }


    go func() {
        for {
            next := <-n.stateCh
            if n.State == next.State {
                if next.doneCh != nil {
                    close(next.doneCh)
                }
                continue
            }


            switch next.State {
            case StateUp:
                log.Printf("Starting process %s.%d", n.Name, n.No)


                cmd := exec.Command("bash", "-c", "for f in .profile.d/*; do source $f; done; "+n.Cmd)
                cmd.Env = append(cmd.Env, fmt.Sprintf("HOME=%s", n.App.appDir))
                cmd.Env = append(cmd.Env, fmt.Sprintf("PORT=%d", n.Port))
                cmd.Env = append(cmd.Env, n.App.Env...)
                cmd.Dir = n.App.appDir
                cmd.Stdout = n.logFile
                cmd.Stderr = n.logFile
                err := cmd.Start()
                if err != nil {
                    log.Printf("Process %s.%d exited", n.Name, n.No)
                    n.State = StateUp


                } else {
                    n.Process = cmd.Process
                    n.State = StateUp
                }


                if next.doneCh != nil {
                    close(next.doneCh)
                }


                go func() {
                    err := cmd.Wait()
                    if err != nil {
                        log.Printf("Process %s.%d exited", n.Name, n.No)
                        n.stateCh <- NextState{
                            State: StateDown,
                        }
                    }
                }()


            case StateDown:
                log.Printf("Stopping process %s.%d", n.Name, n.No)


                if n.Process != nil {
                    n.Process.Kill()
                    n.Process = nil
                }


                n.State = StateDown
                if next.doneCh != nil {
                    close(next.doneCh)
                }
            }
        }
    }()


    return n, nil
}


func (n *Node) Start() error {
    n.stateCh <- NextState{
        State: StateUp,
    }
    return nil
}


func (n *Node) Stop() error {
    doneCh := make(chan int)
    n.stateCh <- NextState{
        State:  StateDown,
        doneCh: doneCh,
    }
    <-doneCh
    return nil
}

قد تبدو كتابة هذه الشيفرة البرمجية للوهلة الأولى أكثر الخطوات تعقيدًا حتى الآن، لذا دعنا نبسطها بتقسيمها إلى 4 أجزاء: يمثل مضمون دالة NewNode أول جزئين، فعندما تُستدعَى هذه الدالة تهيئ populate نسخة من هيكل بيانات Node بإعدادات محددة وتولّد برنامجًا routine بلغة غو Go مهمته إيقاف الإجرائيات المقابلة لهذه العقدة وتشغيلها. 

يمثل التابعان Start وStop في بنية Node الجزئين التاليين، حيث توقَف الإجرائية أو تشغَّل بتمرير رسالة message خلال قناة معينة تفيد بأن برنامج غو هذا الذي ينفَّذ على كل عقدة على حدة يستمر في المراقبة. يمكن تمرير رسالة لتشغيل إجرائية ورسالة مختلفة لإيقافها.

بما أن الخطوات الفعلية لإيقاف أو تشغيل إجرائية تحدث ضمن برنامج Go routine، فلا مجال لحدوث حالات تسابق race conditions بسبب الطريقة التي تتم بها إدارة تشغيل الأكواد بشكل متوازي يبدأ برنامج غو Go routine حلقة لا نهائية infinite loop تبقى بانتظار رسالة message في قناة stateCh، فإذا مرت الرسالة في القناة يُرسَل طلب إلى العقدة node بتشغيل الإجرائية ضمن case StateUp، ونستخدم برنامج باش Bash لتنفيذ هذا الأمر. 

أثناء هذه العملية تُضبط العقدة الأمر بحيث يستخدم متغيرات البيئة environment variables التي حددها المستخدم، ويعيد توجيه الخرج القياسي standard output ومجاري الخطأ error streams إلى ملف سجل log file سبق تحديده. أما لإيقاف الإجرائية ضمن case StateDown فإن البرنامج يوقفها قسريًا باستخدام أمر kill. في حال رغبنا بإيقاف الإجرائية تدريجيًا يمكننا جعله يرسل إشارة SIGTERM والانتظار بضع ثوان قبل إيقافها. يسهّل تابعا Start و Stop تمرير الرسالة المناسبة إلى القناة، إذ يرسل التابع Start رسالة إلى القناة بتشغيل الإجرائية ويعود، في حين ينتظر تابع Stop أن تتوقف الإجرائية قبل أن يعود.

جمع الخطوات السابقة

لم يتبقَ لنا الآن سوى إضافة جميع الشيفرات السابقة إلى الدالة الرئيسية لبرنامجنا، حيث سيُنفَّذ تحميل ملف الإعدادت وتحليله parse، وتحديث حزم البناء، ومحاولة تحديث تطبيقنا لمرة واحدة، وتشغيل خادم الويب ليصغي إلى حمولات حدث الدفع push event التي ترد من غيت هب.

// main.go


func main() {
    cfg, err := toml.LoadFile("config.tml")
    catch(err)


    url, ok := cfg.Get("buildpack.url").(string)
    if !ok {
        log.Fatal("buildpack.url not defined")
    }
    err = UpdateBuildpack(url)
    catch(err)


    // Read configuration options into variables repo (string), env ([]string) and procs (map[string]int)
    // ...


    app, err := NewApp(repo, env, procs)
    catch(err)


    err = app.Update()
    catch(err)


    secret, _ := cfg.Get("hook.secret").(string)


    http.Handle("/hook", NewHookHandler(&HookOptions{
        App:    app,
        Secret: secret,
    }))


    addr, ok := cfg.Get("core.addr").(string)
    if !ok {
        log.Fatal("core.addr not defined")
    }


    err = http.ListenAndServe(addr, nil)
    catch(err)
}

بما أن أداتنا تتطلب أن تكون حزم البناء مستودعات غيت بسيطة، فلن تنفذ دالة UpdateBuildpack المتضمنة في شيفرة buildpack.go سوى عمليتي نسخ git clone وسحب git pull لرابط المستودع عند الضرورة وذلك لتحديث النسخة المحلية من حزمة البناء.

تجربة الأداة

في حال لم نستنسخ المستودع بعد فيمكن استنساخه الآن. وإذا كان بGo distribution مثبتًا فيمكن البدء بتصريف compile البرنامج.

mkdir hopper
cd hopper
export GOPATH=`pwd`
go get github.com/hjr265/toptal-hopper
go install github.com/hjr265/toptal-hopper

لنطلع على ما تنفذه هذه الأوامر على التوالي:

• إنشاء مجلد وتسميته hopper
• الانتقال إليه
• جعله المجلد الخاص بمساحة العمل GOPATH
• جلب الشيفرة من غيت هب إلى جانب مكتبات غو Go الضرورية، وتصريف البرنامج لشيفرة binary يمكن إيجادها في مجلد ‎$GOPATH/bin

قبل استخدام هذه الأداة على خادم علينا أن ننشئ تطبيق ويب بسيط لنختبر هذه الأداة عليه. في حال رغبنا بالحصول على تطبيق جاهز قد أنشأ صاحب المقال تطبيق ويب بسيط يعرض عبارة "Hello World" بلغة Node.js ورفعه إلى مستودع غيت هب آخر يمكننا اشتقاقه fork وإعادة استخدامه لاختبار الأداة. علينا في الخطوة التالية رفع الشيفرة الثنائية المصرَّفة compiled binary إلى خادم وإنشاء ملف إعدادات في المجلد ذاته:

# config.tml 


[core]
addr = ":26590"
[buildpack]
url = "https://github.com/heroku/heroku-buildpack-nodejs.git"


[app]
repo = "hjr265/hopper-hello.js"


    [app.env]
    GREETING = "Hello"


    [app.procs]
    web = 1


[hook]
secret = ""

لنبدأ بأول خيار في ملف الإعدادات لدينا وهو core.addr الذي يتيح لنا ضبط منفذ HTTP لخادم الويب الداخلي لبرنامجنا، وقد اخترناه في مثالنا هذا ليكون 26590: وهذا يعني أن برنامجنا سيصغي إلى حمولات حدث الدفع عن طريق الرابط http://{host}:26590/hook.

عندما نضبط خطاف الويب في غيت هب ما عليك سوى تبديل {host} أي المضيف باسم النطاق أو عنوان IP الذي يشير إلى خادمنا. وفي حال كنا نستخدم جدار حماية على خادمنا لا ننسى أن فتح هذا المنفذ عليه. ثم نحدد حزمة البناء بإضافة رابط غيت الذي يشير إليها، ونستخدم في مثالنا حزمة بناء بلغة Node.js الخاصة بهيروكو Heroku.

أما خيار app فقد حددنا ضمنه في خيار repo الاسم الكامل لمستودع غيت هب الذي يستضيف شيفرة التطبيق البرمجية، وبما أن رابط استضافة شيفرة التطبيق المستخدم في مثالنا https://github.com/hjr265/hopper-hello.js حددنا الاسم الكامل للمستودع hjr265/hopper-hello.js، ثم حددنا بعض متغيرات البيئة الخاصة بالتطبيق وعدد كل نوع من الإجرائيات التي نحتاجها، وأنهينا الملف باختيار رمز سري لنتحقق من حمولات حدث الدفع الواردة.

يمكننا الآن تشغيل برنامج الأتمتة الذي بنيناه على الخادم. في حال كانت جميع إعداداتنا صحيحة إضافة إلى ضبط مفاتيح SSH Keys حتى يُسمح للخادم بالوصول إلى المستودع، سينجح البرنامج في جلب الشيفرة البرمجية وتجهيز البيئة باستخدام حزمة البناء وتشغيل التطبيق.

ما علينا الآن سوى إعداد خطاف ويب في مستودع غيت هب لتصدير أحداث الدفع وتوجيهها إلى الرابط http://{host}:26590/hook. ولا ننسى بالطبع استبدال {host} باسم النطاق أو عنوان IP الذي يشير إلى الخادم. لنختبر عمل الأداة التي بنيناها، نحاول إجراء بعض التغييرات على التطبيق وندفعها إلى غيت هب، ستلاحظ حينها أن أداة الأتمتة ستبدأ العمل فورًا وتٌحدّث المستودع على الخادم وتصّرف التطبيق ثم تعيد تشغيله.

الخاتمة

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

ترجمة -وبتصرّف- للمقال Deploy Web Applications Automatically Using GitHub Webhooks لصاحبه Mahmud Ridwan.

اقرأ أيضًا

• كيف تنشر تطبيق ويب بلغة Go باستخدام خادم Nginx على أوبنتو 18.04
• نشر تطبيقات الويب الموجهة لبيئة الإنتاج
• نشر تطبيق Node.js على الويب: خدمة هيروكو (Heroku) مثالًا
• الفرق بين أداتي دوكر Docker وبودمان Podman

نشرح في هذا المقال نشر تطبيق روبي أون ريلز Ruby on Rails على خادم أوبنتو خطوة بخطوة بدايةً من اختيار خادم الاستضافة وتثبيت الاعتماديات dependencies عليه، ووصولًا إلى إعداد خادم NGINX لاستقبال طلبات التطبيق وبناء قاعدة بيانات التطبيق ونشرها على خادم الاستضافة بمساعدة Capistrano وهي أداة مفتوحة المصدر مخصصة لأتمتة عمليات النشر.

أولًا: إعداد خادم الإنتاج

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

اختيار مزود الاستضافة

هناك العديد من مزودي خدمات الاستضافة ولكل منهم سلبياته وإيجابياته، ويُقصد بمزود خدمة الاستضافة الجهة التي تمتلك خوادم موجودة في مركز بيانات datacenter وتؤجرها للراغبين باستخدامها بمقابل مادي يدفعونه شهريًا.

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

إذا كنت تحتاج تحكمًا كبيرًا ببيئة تطبيقك فاستبعد مزودي خدمات الاستضافة المُدارة managed hosting providers أي شركات الاستضافة التي تتكفل بإدارة البنية التحتية التي استأجرتها كاملة لأنها لا تمنحك تحكمًا كافيًا ببيئتك وتفتقر عادةً إلى تثبيت آخر التحديثات.

كيف أحدد مواصفات الخادم الذي أحتاجه لتطبيق ريلز؟

تحتاج تطبيقات إطار العمل Rails وتطبيقات روبي عمومًا إلى سعة ذاكرة وصول عشوائي RAM كبيرة، فسعة الذاكرة RAM معيار أساسي عليك التركيز عليه عند اختيار الخادم، وتذكر أنك ستحتاج لتثبيت مكونات أخرى على الخادم ستأخذ حصتها من RAM أيضًا، ومنها قاعدة بيانات التطبيق مثل: MongoDB أو PostgreSQL أو Redis التي تعمل في الخلفية.

فإذا كنت تنشر تطبيقك الأول فإن خادمًا بذاكرة RAM حجمها 2 جيجابايت مناسب ومقبول التكلفة، وبالرغم من إمكانية البدء بذاكرة 1 جيجابايت لكنها لن تلبي طلبك على الأغلب وسرعان ما ستنفذ عند تجميع الأصول compiling assets وتجهيز الملفات أثناء النشر إلى بيئة الإنتاج.

كما ستحتاج لزيادة سعة RAM على الخادم في الحالات التي تستخدم فيها اعتماديات كبيرة مع تطبيقك مثل خدمات البحث أو غيرها حسب ما تتطلبه هذه الاعتماديات إضافةً إلى احتياجات لتطبيقك، فخدمة بحث مثل ElasticSearch على سبيل المثال تحتاج لوحدها إلى 4 جيجابايت، لذا يلجأ البعض لتشغيلها على خادم منفصل عن خادم تطبيقات روبي وريلز لتسهيل توسعة الموارد المحجوزة للخدمتين (أي التطبيق والبحث) بمعزل عن بعضهما.

إنشاء الخادم

سنعرض هنا كمثال طريقة إنشاء الخادم على منصة الاستضافة DigitalOcean علمًا أن العملية متقاربة في معظم المنصات، افتح المنصة وانتقل إلى صفحة إنشاء قطرة Droplet ثم تابع الخطوات.

ملاحظة: Droplet مصطلح خاص بمنصة DigitalOcean يشير إلى وحدة افتراضية تشبه الخادم الافتراضي Virtual Server يمكن للمستخدمين إنشاؤها لتشغيل المواقع والتطبيقات وقواعد بيانات ويمكن تخصيص مواردها المختلفة كالمعالج والذاكرة ومساحة التخزين.

الخطوة 1: اختر نظام تشغيل الخادم

اخترنا هنا نظام أوبنتو 20.24، وهو نظام تشغيل يتمتع بدعم فني طويل الأمد LTS أي أنه سيتلقى تحديثات أمنية أكثر من المعتاد وعلى مدى سنوات طويلة، وهذا أمر مهم عند نشر التطبيقات في بيئة الإنتاج.

توضح الصورة التالية خيار الخادم أوبنتو 20.24 من القائمة المنسدلة.

الخطوة 2: حدد حجم الخادم ومواصفاته

بعد اختيار نظام التشغيل الخاص بخادم الاستضافة ستظهر أمامك نافذة لتحدد حجم الخادم ومواصفاته، كما توضح الصورة التالية.

في حال لم تكن متأكدًا من الحجم المناسب لتطبيقك، يمكنك اختيارحجم RAM لتكون 2 جيجابايت، وتغيير لاحقًا الحجم زيادة أو نقصانًا حسب احتياجات تطبيقك، وهنا تكمن ميزة الخوادم الافتراضية مقارنة بالخوادم الفيزيائية إذ يمكنك تغيير مواصفاتها بسهولة في أي لحظة بزيادة سعة الذاكرة RAM أو إنقاصها وكذلك الأمر بالنسبة لوحدات المعالجة المركزية CPU ووحدات التخزين وغيرها.

الخطوة 3: اختر المنطقة الجغرافية

الخطوة التالية هي تحديد منطقة الخادم server region أي المكان الجغرافي الذي يتواجد فيه مركز البيانات الذي سيعمل عليه خادمك الافتراضي، اختر المنطقة الأقرب لمكان تواجد مستخدمي تطبيقك أو مكان تواجدك كمدير للتطبيق والخادم.

الخطوة 4: ضبط الخيارات الإضافية

يوجد عدد من الخيارات الأخرى يمكنك ضبطها حسب احتياجات عملك إذا رغبت بذلك، ومنها:

• 1. الشبكات الخاصة Private Networking: يفيدك إعداد الشبكات الخاصة إذا كان خادمك يحتاج للتخاطب مع خوادم أخرى، كالحالة التي يكون فيها خادم قاعدة البيانات منفصلًا عن خادم التطبيق.

• 2. البروتوكول IPv6: بتفعيل هذا الخيار يمكنك إعطاء خادمك عنوان IPv6.

• 3. المراقبة Monitoring: يعطيك بعض المقاييس التقريبية التي تفيدك في قياس نسب استخدام الخادم.

• 4. النسخ الاحتياطي Backups: يعني تفعيل هذا الخيار أخذ صورة image أو نسخة كاملة عن خادمك يمكنك استعادته منها عند حدوث أي طارئ، لكن هذه النسخ الكاملة لا تُشَغَّل بفترات متقاربة لذا تُعدّ النسخ الاحتياطية الساعية لقاعدة بيانات التطبيق أو Hourly database backups أفضل منها في معظم الحالات.

الخطوة 5: أنشئ خادمك

بعد ضبط كافة الخيارات السابقة، اضغط على زر الإنشاء Create وستُنشئ DigitalOcean خادمك الجديد خلال دقيقة تقريبًا. بعدها توجه إلى بريدك الإلكتروني بمجرد إتمام عملية الإنشاء لتستلم كلمة مرور الخادم.

يمكنك الآن الاتصال بالخادم من حاسوبك المحلي Local Machine بواسطة عنوان IP الخاص به ومستخدم الجذر root الذي استلمته عبر البريد الإلكتروني، كما في المثال التالي طبعًا مع استبدال 1.2.3.4 بعنوان IP لخادمك:

ssh root@1.2.3.4

الخطوة 6: أنشئ مستخدم النشر

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

إذًا في أثناء دخولك الأول إلى الخادم باستخدام حساب الجذر root أنشئ مستخدمًا جديدًا وامنحه امتيازات sudo كما يلي:

root@1.2.3.4
adduser deploy
adduser deploy sudo
exit

أضف بعدها مفتاح SSH إلى الخادم لتسريع الدخول إليه، سنستخدم في ذلك الأداة ssh-copy-id، علمًا أنها لا تتوفر افتراضيًا على أجهزة ماك فإذا كان جهازك المحلي من نوع ماك ثبتها باستخدام homebrew وفق الأمر brew install ssh-copy-id ثم نفذ التالي:

ssh-copy-id root@1.2.3.4
ssh-copy-id deploy@1.2.3.4

يمكنك الآن تسجيل الدخول إلى الخادم بحساب المستخدم root أو المستخدم deploy ومن دون الحاجة لكتابة كلمة المرور لأن تفعيل مفتاح SSH يغنيك عنها.

لنفتح الآن جلسة اتصال SSH بواسطة مستخدم النشر deploy وهو المستخدم الذي سننفذ بواسطته كافة الخطوات التالية في المقال، علمًا أنك لن تُطالب بإدخال كلمة مروره كما ذكرنا:

ssh deploy@1.2.3.4

ثانيًا: تثبيت روبي على الخادم

يشبه تثبيت روبي في بيئة الإنتاج تثبيته في بيئة التطوير مع مزيد من التدقيق في تثبيت جميع اعتماديات لينكس الضرورية لضمان تصريف compile روبي بطريقة صحيحة، ويساعدك استخدام مدير إصدارات روبي Ruby version manager على نشر الإصدارات الجديدة بسهولة ومن دون أي تعديل في ملفات الإعداد config files.

الخطوة الأولى هي تثبيت الاعتمادات الضرورية لتصريف كل من روبي وإطار العمل ريلز، وأهمها ما يلزم لعمل المكتبة Webpacker مع ريلز لذا سنبدأ بإضافة مستودعات Yarn و Node.js إلى نظامنا لنتمكن من تثبيتها.

ثم سنثبت Redis لنستطيع استخدام ActionCable مع مقابس الويب WebSocket في بيئة الإنتاج، كما قد يرغب البعض باستخدام Redis بصفته مخزن تخبئة cashing لخادم الإنتاج.

لنطبق ذلك عمليًّا، تأكد أولًا من تسجيل دخولك بالمستخدم deploy ثم اكتب الأوامر التالية:

deploy@1.2.3.4
# إضافة مستودع Node.js
curl -sL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
# إضافة مستودع Yarn 
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo add-apt-repository ppa:chris-lea/redis-server
# تحديث الحزم من المستودعين المضافين أعلاه
sudo apt-get update
# تثبيت الاعتماديات المطلوبة لتصريف روبي من المستودعين المضافين
sudo apt-get install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev software-properties-common libffi-dev dirmngr gnupg apt-transport-https ca-certificates redis-server redis-tools nodejs yarn

يمكننا الآن تثبيت روبي على الخادم بعد إتمام تثبيت الاعتماديات وقد استخدمنا في هذا المقال الإصدار 3.3.1 من روبي لكن تستطيع اختيار الإصدار الذي تفضله.

كما سبق وذكرنا سنستخدم مدير الإصدارات rbenv لتثبيت روبي، فهو أسهل في التعامل والترقية وأيضًا يوفر لك عددًا من المكونات الإضافية المفيدة لضبط متغيرات بيئة الإنتاج.

نَفِّذْ الأوامر التالية:

deploy@1.2.3.4
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc
git clone https://github.com/rbenv/rbenv-vars.git ~/.rbenv/plugins/rbenv-vars
exec $SHELL
rbenv install 3.3.1
rbenv global 3.3.1
ruby -v
# ruby 3.3.1

نثبت الآن مُجَمِّع الوحدات Bundler (وهو أداة تستخدم في مشاريع الويب لتنظيم الوحدات والاعتماديات وتوليد الأصول):

deploy@1.2.3.4
# يثبت الأمر التالي الإصدار الأخير من Bundler، والإصدار الأحدث عند إعداد المقال هو 2‪.x 
gem install bundler
# أو نفذ الأمر التالي إذا رغبت بتثبيت إصدار أقدم مثل 1‪.x
gem install bundler -v 1.17.3
# يعطيك الأمر التالي رقم إصدار Bundler ويساعدك بالنتيجة على التأكد من صحة تثبيته
bundle -v
# Bundler version 2.0

إذا حصلت على رسالة خطأ مفادها عدم العثور على Bundler، نفذ الأمر rbenv rehash وكرر المحاولة.

ثالثًا: إعداد خادم الويب NGINX والوحدة Passenger

يتطلب العمل في بيئة الإنتاج وجود خادم ويب مثل NGINX أمام ريلز لاستقبال طلبات HTTP والتعامل مع شهادات SSL وملفات التطبيق الثابتة static files بطريقة أسرع من روبي، وعلى أرض الواقع من غير المنطقي طرح تطبيقك للمستخدمين من دون خادم ويب.

اعتمدنا في مثالنا على NGINX والوحدة Passenger، إذ سيستقبل NGINX طلبات HTTP الواردة إلى خادم التطبيق، ويحولها إلى Passenger الذي سيشغل تطبيقك.

اكتب الأوامر التالية لديك لإضافة مستودع Passenger وتثبيته على الخادم:

deploy@1.2.3.4
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7
sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger $(lsb_release -cs) main > /etc/apt/sources.list.d/passenger.list'
sudo apt-get update
sudo apt-get install -y nginx-extras libnginx-mod-http-passenger
if [ ! -f /etc/nginx/modules-enabled/50-mod-http-passenger.conf ]; then sudo ln -s /usr/share/nginx/modules-available/mod-http-passenger.load /etc/nginx/modules-enabled/50-mod-http-passenger.conf ; fi
sudo ls /etc/nginx/conf.d/mod-http-passenger.conf

ثم افتح ملف إعدادات Passenger باستخدام أي محرر نصوص تفضله مثل nano أو vim كما يلي:

deploy@1.2.3.4
# تحرير الملف باستخدام nano
sudo nano /etc/nginx/conf.d/mod-http-passenger.conf
# تحرير الملف باستخدام vim
sudo vim /etc/nginx/conf.d/mod-http-passenger.conf

عَدِّل السطر الذي يحتوي القيمة passenger_ruby ضمن الملف ليصبح وفق التالي، وذلك لتوجيه Passenger إلى الإصدار المطلوب من روبي:

passenger_ruby /home/deploy/.rbenv/shims/ruby;

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

ثم شغل NGINX كما يلي:

deploy@1.2.3.4
sudo service nginx start

يمكنك التأكد من صحة تشغيل NGINX بفتح عنوان IP العام للخادم في متصفح الإنترنت لديك، وستحصل على رسالة الترحيب التالية "Welcome to NGINX".

والآن احذف ملف الإعدادات الافتراضي لخادم NGINX، وأضف ملفًا خاصًا لتطبيقك:

deploy@1.2.3.4
sudo rm /etc/nginx/sites-enabled/default
# تحرير الملف باستخدام nano
sudo nano /etc/nginx/sites-enabled/myapp
# تحرير الملف باستخدام VIM
sudo vim /etc/nginx/sites-enabled/myapp

عدل على الملف ليصبح وفق الآتي، واستبدل myapp باسم تطبيقك، علمًا أننا سنستخدم الملف نفسه لاحقًا لتحديد المجلد deploy_to الخاص بالمكتبة Capistrano:

server {
  listen 80;
  listen [::]:80;

  server_name _;
  root /home/deploy/myapp/current/public;

  passenger_enabled on;
  passenger_app_env production;

  location /cable {
    passenger_app_group_name myapp_websocket;
    passenger_force_max_concurrent_requests_per_process 0;
  }

  # Allow uploads up to 100MB in size
  client_max_body_size 100m;

  location ~ ^/(assets|packs) {
    expires max;
    gzip_static on;
  }
}

احفظ التغييرات على الملف وأغلقه، ثم أعد تحميل NGINX كما يلي لتطبيق التغييرات:

deploy@1.2.3.4
sudo service nginx reload

رابعًا: إنشاء قاعدة البيانات

سنعرض طريقتين لإنشاء قاعدة بيانات التطبيق، الأولى باستخدام PostgreSQL وهي الخيار الأفضل في بيئة الإنتاج، والثانية باستخدام MySQL، اتبع الأسلوب الذي يناسبك.

إنشاء قاعدة بيانات PostgreSQL

ثبت في البداية خادم Postgres مع المكتبة libpq التي تسمح بتصريف gem pg وهي مكتبة روبي المخصصة للتعامل مع PostgreSQL. للمزيد يمكنك مشاهدة الفيديو التالي:

سينشأ مع التثبيت مستخدم لينكس يدعى postgres يملك الصلاحيات الكاملة على قاعدة البيانات، يمكنك استخدامه لإنشاء مستخدم قاعدة بيانات خاص بتطبيقك، اخترنا له الاسم deploy في مثالنا.

ثم أنشئ قاعدة بيانات التطبيق، تدعى في مثالنا myapp، وتأكد أن المستخدم deploy هو مالك قاعدة البيانات، وفق الأوامر التالية:

deploy@1.2.3.4
sudo apt-get install postgresql postgresql-contrib libpq-dev
sudo su - postgres
createuser --pwprompt deploy
createdb -O deploy myapp
exit

والآن يمكنك الاتصال بقاعدة البيانات الجديدة وفق التالي:

psql -U deploy -W -h 127.0.0.1 -d myapp

استخدم 127.0.0.1 بدلًا من localhost عند الاتصال بقاعدة البيانات.

إنشاء قاعدة بيانات MySQL

ستحتاج لتثبيت نسختي الخادم server والعميل client من MySQL لإنشاء قاعدة بيانات التطبيق وتصريف روبي gem عبر الواحهة mysql2 (يساعدك الاطلاع على المقال كيفية تثبيت MySQL على أوبونتو 18.04).

وبعد التثبيت اكتب الأوامر التالية:

deploy@1.2.3.4
sudo apt-get install mysql-server mysql-client libmysqlclient-dev
sudo mysql_secure_installation
# هذا الأمر مخصص لفتح واجهة سطر الأوامر لنظام MySQL لننشئ المستخدم وقاعدة البيانات
mysql -u root -p

بعد تنفيذ الأوامر السابقة ستفتح واجهة سطر الأوامر لنظام MySQL وبواسطتها يمكنك إنشاء قاعدة بيانات تطبيقك ومستخدم قاعدة بيانات مخصص لإدارتها ويملك الصلاحيات الكاملة عليها، ويستحسن أن تلتزم بإنشاء مستخدم قاعدة بيانات خاص للتطبيق فهذا الإجراء يُعدّ أكثر آمانًا.

عندما تقرأ الأوامر الموجودة أسفل الفقرة سيتبادر لذهنك أننا ننشئ مستخدمين اثنين على قاعدة البيانات لكن ذلك يرجع لاختلاف طريقة تعامل MySQL مع الاتصالات المحلية localhost والبعيدة التي تجري عبر الشبكة أي عبر عنوان IP، وبالأوامر التي كتبناها هنا قد سمحنا بنوعي الاتصال.

وانتبه قبل التنفيذ لضرورة استبدال الأسماء المذكورة بما يناسب تطبيقك كما يلي:

• استبدل myapp باسم قاعدة بياناتك، وهي تماثل اسم التطبيق عادةً.
• استبدل omeFancyPassword123 بكلمة مرورك.
• استبدل deploy باسم مستخدم قاعدة البيانات الذي تختاره.

deploy@1.2.3.4
CREATE DATABASE IF NOT EXISTS myapp;
CREATE USER IF NOT EXISTS 'deploy'@'localhost' IDENTIFIED BY '$omeFancyPassword123';
CREATE USER IF NOT EXISTS 'deploy'@'%' IDENTIFIED BY '$omeFancyPassword123';
GRANT ALL PRIVILEGES ON myapp.* TO 'deploy'@'localhost';
GRANT ALL PRIVILEGES ON myapp.* TO 'deploy'@'%';
FLUSH PRIVILEGES;
\q

خامسًا: النشر باستخدام Capistrano

بعد إتمام تهيئة الخادم وأدواته حان الوقت لتحميل الشيفرة البرمجية الخاصة بالتطبيق إلى مرحلة الإنتاج.

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

إعداد Capistrano

ثَبِّت Capistrano ضمن تطبيق ريلز على حاسوبك المحلي (أي حيث طورت التطبيق وحيث توجد شيفرته البرمجية).

ثم أضف جواهر روبي أو gems التالية إلى الملف Gemfile كما يلي:

gem 'capistrano', '~> 3.11'
gem 'capistrano-rails', '~> 1.4'
gem 'capistrano-passenger', '~> 0.2.0'
gem 'capistrano-rbenv', '~> 2.1', '>= 2.1.4'

ثم نَفِّذ الأوامر التالية من حاسوبك المحلي بهدف تثبيت gems السابقة وتثبيت ملفات الإعدادات الخاصة بالمكتبة Capistrano:

bundle
cap install STAGES=production

وستنشئ بعدها الملفات التالية:

• Capfile.
• config/deploy.rb.
• config/deploy/production.rb.

افتح في البداية الملف Capfile وأضِف إليه الأسطر التالية:

require 'capistrano/rails'
require 'capistrano/passenger'
require 'capistrano/rbenv'

set :rbenv_type, :user
set :rbenv_ruby, '3.3.1'

ثم افتح الملف config/deploy.rb لتُعرِّف تطبيقك ضمنه، وتحصل على التفاصيل الخاصة بمستودع التطبيق:

set :application, "myapp"
set :repo_url, "git@github.com:username/myapp.git"

# Deploy to the user's home directory
set :deploy_to, "/home/deploy/#{fetch :application}"

append :linked_dirs, 'log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', '.bundle', 'public/system', 'public/uploads'

# Only keep the last 5 releases to save disk space
set :keep_releases, 5

# Optionally, you can symlink your database.yml and/or secrets.yml file from the shared directory during deploy
# This is useful if you don't want to use ENV variables
# append :linked_files, 'config/database.yml', 'config/secrets.yml'

وأخيرًا عَدِّل على الملف config/deploy/production.rb لإضافة عنوان IP العام للخادم إلى عمليات النشر، وذلك وفق التالي، ولا تنسَ استبدال 1.2.3.4 بعنوان خادمك:

server '1.2.3.4', user: 'deploy', roles: %w{app db web}

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

ssh deploy@1.2.3.4

ونفذ التالي:

mkdir /home/deploy/myapp
nano /home/deploy/myapp/.rbenv-vars

ثم أضف متغيرات البيئة المناسبة لحالتك من بين التالي إلى هذا الملف:

# For Postgres
DATABASE_URL=postgresql://deploy:PASSWORD@127.0.0.1/myapp

# For MySQL
DATABASE_URL=mysql2://deploy:$omeFancyPassword123@localhost/myapp

RAILS_MASTER_KEY=ohai
SECRET_KEY_BASE=1234567890

STRIPE_PUBLIC_KEY=x
STRIPE_PRIVATE_KEY=y
# etc...

احفظ التغييرات على الملف، وستُحَمَّل متغيرات البيئة المذكورة هنا تلقائيًا إلى الخادم في كل مرة تُشَغِّل فيها أوامر روبي داخل مجلد التطبيق على الخادم.

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

يمكنك الآن نشر التطبيق على خادم الإنتاج، بتنفيذ الأمر التالي من حاسوبك المحلي:

cap production deploy

اكتب عنوان IP الخادم في متصفح الإنترنت وإذا كانت كافة إعداداتك صحيحة فستظهر أمامك واجهة تطبيق ريلز Rails الذي نشرته.

وإذا لم تحصل على واجهة ريلز، فيمكنك تتبع الخطأ بمراجعة ملفات تسجيل الأحداث logs من جلسة اتصال SSH مع الخادم كما يلي:

deploy@1.2.3.4
# لعرض ملفات تسجيل الأحداث الخاصة بريلز
less /home/deploy/myapp/current/log/production.log
# لعرض ملفات تسجيل الأحداث الخاصة بخادم NGINX و Passenger 
sudo less /var/log/nginx/error.log

تنجم أغلب الأخطاء عن وجود خلل في أحد متغيرات البيئة أو ملفات الإعدادات التي جهزناها لمرحلة الإنتاج، وبمجرد وصولك للخطأ وتصحيحه يمكنك إعادة تشغيل تطبيقك أو إعادة نشره ثم التحقق مجددًا من المتصفح لمعرفة النتيجة.

سادسًا: توصيات إضافية

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

• تركيب شهادة SSL على الخادم من خدمة مجانية مثل LetsEncrypt أو غيرها لحماية البيانات المتبادلة مع التطبيق، يساعدك في ذلك مقال تنصيب شهادة SSL مجانية عبر خدمة Let's encrypt على خادوم لينكس على أكاديمية حسوب.

• تفعيل النسخ الاحتياطي الساعي Hourly Backups أو النسخ الاحتياطي الدوري عمومًا الذي ينسخ بياناتك إلى وحدة تخزين خارجية مثل S3، فهو يخفف من مخاطر ضياع البيانات ويساعدك على استعادتها في حال تعرض خادمك أو تطبيقك لأي عطل أو حادث طارئ.

• اتباع خطة لتدوير ملفات تسجيل الأحداث logs حتى لا تملأ مساحة التخزين على الخادم دون أن تنتبه لها.

• اتخاذ التدابير الأمنية الضرورية لحماية الخادم من الهجمات السيبرانية، يفيدك في ذلك مقال 7 تدابير أمنية لحماية خواديمك والمقالات الأخرى الموجودة في قسم حماية على أكاديمية حسوب.

ترجمة -وبتصرف- لمقال Deploy Ruby On Rails:Ubuntu 24.04 Noble Numbat in 2024 من موقع Go Rails.

اقرأ أيضًا

• كيفية نشر تطبيق Express وتوسيعه باستخدام إضافة MemCachier من منصة تطبيقات DigitalOcean
• نشر تطبيقات Flask باستخدام PythonAnywhere
• نشر التطبيقات وتوزيعها وفق نهج التسليم المستمر
• فيديو: نشر تطبيق React.js ذو واجهات خلفية Node.js على منصة Heroku

يُعد إطار Express أحد الإطارات الشائعة لبناء تطبيقات الويب السريعة وواجهات برمجة التطبيقات API باستخدام بيئة التشغيل Node.js.

منصة تطبيقات DigitalOcean عبارة عن منتج منصة على أساس خدمة PaaS لضبط إعدادات التطبيقات ونشرها من مستودع شيفرات برمجية، فهي توفر طريقة سريعة وفعالة لنشر تطبيقات Express.

سنتعلم في دليلنا هذا، كيفية نشر تطبيق Express على منصة تطبيقات DigitalOcean ثم توسيع نطاقه عن طريق إضافة التخزين المؤقت باستخدام إضافة متجر DigitalOcean Marketplace المخصصة لـ MemCachier. إذ يتوافق MemCachier مع نظام memcached للتخزين المؤقت للكائنات ولديه عدة مزايا، مثل تحسين سيناريوهات الفشل باستخدام مجموعة حواسيب عالية التوفر.

سننشئ أولاً تطبيق Express يحسب عددًا أوليًا، ويحتوي على زر "أعجبني"، ويستخدم محرك قوالب Template engine. ستمكنك هذه الميزات من تنفيذ عدة استراتيجيات تخزين مؤقت لاحقًا.

ثم ستدفع شيفرة التطبيق على Git Hub لتنشره بعدها على منصة التطبيقات App Platform. وأخيرًا، ستطبق ثلاث تقنيات تخزين مؤقت للكائنات لتسريع التطبيق وجعله سهل التطوير والتوسع. بنهاية هذا المقال، ستكون قادرًا على نشر تطبيق Express على منصة App Platform، وتطبيق تقنيات التخزين المؤقت لتخزرين العمليات ذات الاستخدام الكثيف للموارد، وتخزين طرق العرض المصيّر rendered views، والجلسات sessions.

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

لمتابعة خطوات هذا المقال التعليمي، ستحتاج إلى ما يلي:

• تثبيت بيئة تشغيل Node.js على جهازك العامل بنظام أوبنتو 22.04، ننصحك باتباع خطوات المقال التالي. أما إن كنت تستخدم نظام تشغيل آخر، فعليك اتباع المقال التالي.
• خادم Express مُثبّت عليه Node.js، ووللقيام بذلك ننصحك بالإطلاع على الخطوتين الأولى والثانية في هذا المقال.
• حساب غيت هب GitHub و تثبيت غيت Git على جهازك، إذ سننشر التطبيق في حسابك على غيت هب GitHub ثم سننشره على منصة تطبيقات DigitalOcean، اتبع الخطوات الواردة في المقال التالي لتثبيت غيت على جهازك.
• حساب على DigitalOcean لنشر التطبيق على منصة App Platform، وننبهك إلى أن نشر التطبيقات على هذه المنصة مأجور، لذا اطّلع على أجور منصة App Platform قبل البدء.
• متصفح إنترنت مثل متصفح كروم Chrome أو فايرفوكس Fire Fox.

• فهم أساسيات عمل موّلد قوالب Express.

• فهم آلية عمل البرمجيات الوسيطة middle-ware .

الخطوة الأولى: ضبط قالب عرض مصيّر

سنثبّت في هذه الخطوة موّلد قوالب Express، وننشئ قالبًا للمسار الرئيسي للتطبيق GET/، ثم سنحدّث المسار كي يستخدم هذا القالب. تمَكّننا القوالب من استخدام التخزين المؤقت للعرض المصيّر rendered view، مما يزيد سرعة معالجة الطلب ويقلل استخدام الموارد.

لبدء العمل، انتقل إلى مجلد مشروع خادم Express باستخدام المحرر، سنثبّت محرك قوالب Express لاستخدام القوالب الثابتة في التطبيق، حيث يستبدل محرك القوالب المتغيرات الموجودة في ملف القالب بالقيم ثم يحول القالب إلى ملف HTML، ثم يُرسَل كرد أو استجابة response على طلب request. إذ يؤدي استخدام القوالب إلى تسهيل العمل باستخدام HTML.

والآن، ثبّت مكتبة قوالب جافا سكربت المضمنة ejs، كما يمكنك استخدام أحد محركات القوالب التي يدعمها Express مثل Mustache أو Pug أو Nunjucks.

npm install ejs

بعد تثبيت مكتبة ejs، عليك ضبط إعدادات تطبيق Express كي يستخدمها، وذلك عن طريق فتح الملف server.js في محرر النصوص البرمجية، وإضافة السطر الثالث كما يلي:

server.js
const express = require('express');

const app = express();

app.set('view engine', 'ejs');

app.get('/', (req, res) => {
  res.send('Successful response.');
});
...

يعدّل هذا السطر إعدادات التطبيق ويعين خاصيّة view engine على ejs. ثم احفظ الملف بعد ذلك.

ملاحظة: سنستخدم في هذا المقال الإعداد view engine، كما يمكنك استخدام الإعداد views الذي يدّل تطبيق Express على مكان وجود ملفات القوالب، وقيمته الافتراضية هي views/. والآن، أنشئ مجلد views ثم أنشئ فيه الملف views/index.ejs وافتحه في محرر النصوص البرمجية. وأضف توصيف القالب إلى الملف:

views/index.ejs
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Find the largest prime number</title>
  </head>
  <body>
    <h1>Find the largest prime number</h1>

    <p>
      For any number N, find the largest prime number less than or equal to N.
    </p>
  </body>
</html>

ثم احفظ الملف. بعد أن أنشأت القالب، عليك تعديل المسار كي تتمكن من استخدامه. افتح الملف server.js وأضف ما يلي إليه:

...

app.get('/', (req, res) => {
  res.render('index');
});

...

لاحظ أن دالة رد النداء render تأخذ اسم القالب كوسيط أول، وفي مثالنا يتوافق index مع اسم الملف views/index.ejs. والآن، أعد تشغيل التطبيق لكي تطبق التغيرات التي أجريتها. أوقف عمل الخادم في الطرفية باستخدام المفتاحين Ctrl+C ثم أعد تشغيل الخادم باستخدام الأمر التالي:

node server.js

الآن انتقل إلى localhost:3000 في المتصفح لمشاهدة محتوى القالب، ستحصل على نتيجة مماثلة لما يلي:

والآن، أصبح تطبيقك يتمتع بعرض مُصَيّر للقوالب، لكنه لا ينفذ شيئًا الآن. سنضيف في الخطوة التالية وظيفة للعثور على عدد أولي.

الخطوة الثانية، إضافة الوظائف إلى تطبيق Express

سنضيف في هذه الخطوة ميّزة العثور على عدد أولي، وميّزة إبداء الإعجاب باستخدام زر "أعجبني Like". سنستخدم هذه الميزات للتفاعل مع التطبيق بعد نشره على منصة App Platform في الخطوة الرابعة من هذا المقال.

العثور على العدد الأولي

سنضيف الآن دالة إلى تطبيقنا وظيفتها العثور على أكبر عدد أولي أقل من أو يساوي N، حيث يشير N إلى عدد ما. سنرسل العدد N عبر استمارة باستخدام التابع GET إلى المسار الرئيسي (/) مع إضافة N كوسيط للاستعلام query، كما يلي:

 localhost:3000/?n=10 

تمثل القيمة 10 هنا عينة الاستعلام، ويمكن أن يحتوي المسار الرئيسي على عناوين URL متعددة تنتج طرق عرض مصيّرة، كما يمكن تخزينها مؤقتًا بصورة فردية.

أضف نموذجًا كالتالي يحتوي على عنصر إدخال لإدخال N في الملف views/index.ejs:

...

<p>
  For any number N, find the largest prime number less than or equal to N.
</p>

<form action="/" method="get">
  <label>
    N
    <input type="number" name="n" placeholder="e.g. 10" required>
  </label>
  <button>Find Prime</button>
</form>

...

لاحظ أن إجراء النموذج form يُرسَل إلى المسار الرئيسي /، الذي سيُعالَج بواسطة المسار الرئيسي (...'/')get.app في ملف server.js. وبما أن التابع هو get، فستضاف بيانات n إلى عنوان URL كوسيط للاستعلام. بعد ذلك، عند إجراء طلب باستخدام وسيط استعلام n، ستُمَرَر تلك البيانات إلى القالب.

أضف الأسطر التالية بعد التابع get على الملف server.js، ثم احفظ الملف:

...

app.get('/', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.render('index');
    return;
  }

  const locals = { n };
  res.render('index', locals);
});

...

تتحقق الأسطر السابقة من وجود طلب له وسيط استعلام ذو القيمة n، فإذا تحقق ذلك يُصيَّر الملف index مع تمرير القيمة n إليه، وإلا فيُعرض الملف index بدون بيانات.

ملاحظة: لا يمكن الوثوق دائمًا بالبيانات التي يدخلها المستخدم، لذا لإنشاء تطبيق جاهزًا للنشر يُنصح بالتحقق من المدخَلات باستخدام مكتبة joi. لاحظ أن للتابع render وسيط ثاني اختياري locals يُعَرّف المتغيرات المحلية التي تمرر إلى القالب لتصيير العرض. يحدد اسم الواصف المختصر الخاصية n للكائن المحلي locals، فعندما يكون للمتغير نفس اسم واف الكائن المُسند إليه، يمكن حذف اسم المتغير. لذلك يمكن كتابة { n: n } بالشكل { n }.

والآن، أصبح بإمكاننا عرض القالب بعد أن أضفنا إليه البيانات. أضف الأسطر التالية على ملف views/index.ejs:

<% if (locals.n) { %>
  <p>N: <%= n %></p>
<% } %>

...

وهكذا يعرض التطبيق المتغيرات المحلية n إن وجدت. احفظ الملف، ثم أعد تشغيل الخادم لتحديث التطبيق. سيُعرَض النموذج مع زر لإيجاد العدد الأولي Find Prime، حيث يأخذ التطبيق المدخلات من المستخدم ويعرضها تحت النموذج:

أدخل عددًا ما ولاحظ أن العنوان URL سيتغير وسيضاف إليه العدد الذي أدخلته، على سبيل المثال، إن أدخلت العدد 40 سيصبح العنوان كالتالي: http://localhost:3000/?n=40 كما سيُعرض العدد الذي أدخلته أسفل النموذج على الشكل التالي N: 40.

والآن بعد أن أصبح بإمكاننا إدخال قيمة للعدد N وعرضها، علينا إضافة دالة للعثور على أكبر عدد أولي أصغر أو مساوي للعدد N، وعرض النتيجة على الشاشة.

أنشئ مجلد utils، ثم أنشئ الملف utils/findPrime.js. افتح الملف findPrime.js في المحرر ثم أضف الكود التالية لتعريف وظيفة أو دالة للعثور على العدد الأولي، ولا تنسَ حفظ الملف بعدها:

utils/findPrime.js
/**
 * Find the largest prime number less than or equal to `n`
 * @param {number} n A positive integer greater than the smallest prime number, 2
 * @returns {number}
 */
module.exports = function (n) {
  let prime = 2; // initialize with the smallest prime number
  for (let i = n; i > 1; i--) {
    let isPrime = true;
    for (let j = 2; j < i; j++) {
      if (i % j == 0) {
        isPrime = false;
        break;
      }
    }
    if (isPrime) {
      prime = i;
      break;
    }
  }
  return prime;
};

يوّثق تعليق JSDoc عمل الدالة، إذ تبدأ الخوارزمية بالعدد الأولي الأول 2، ثم ثم تكرر العمل بدءًا من العدد n وتنقص الرقم بمقدار 1 في كل حلقة. وتستمر الدالة في حلقة التكرار والبحث عن عدد أولي حتى يصبح الرقم 2، وهو أصغر رقم أولي.

تفترض كل حلقة أن العدد الحالي هو عدد أولي، ثم تتحقق من صحة هذا الافتراض، عن طريق التحقق من وجود عامل آخر للعدد الحالي آخر غير 1 ونفسه. إذا أمكن قسمة العدد الحالي على أي رقم أكبر من 1 وأقل من العدد نفسه دون باقي، فهو ليس عددًا أوليًا. ثم ستتحق الدالة بعد ذلك من العدد التالي. بعدها، أضف السطر الثاني إلى ملف server.js لاستيراد دالة العدد الأولي:

const express = require('express');
const findPrime = require('./utils/findPrime');

...

عدّل على المسار الرئيسي لإيجاد العدد الأولى وتمرير قيمته إلى القالب من خلال إضافة السطر التالي إلى ملف server.js، ثم احفظ الملف:

const prime = findPrime(n);

والآن، لعرض النتيجة في القالب وإظهار قيمة N أضف الشيفرة التالية في ملف views/index.ejs:

<% if (locals.n && locals.prime) { %>
  <p>
    The largest prime number less than or equal to <%= n %> is <strong><%= prime %></strong>.
  </p>
<% } %>
...

بدلًا عن:

<% if (locals.n) { %>
  <p>N: <%= n %></p>
<% } %>

ولا تنسَ حفظ الملف، ثم أعد تشغيل الخادم. اختبر عمل الدالة عن طريق إدخال عدد ما، كالعدد 10، ستظهر رسالة:

 The largest prime number less than or equal to 10 is 7 

ومفادها أن العدد الأولي الأعظمي الأصغر أو يساوي العدد 10 هو العدد 7.

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

إضافة زر أعجبني

ينتج تطبيقنا حاليًا طرق عرض ونتائج مختلفة بناءً على كل عدد N ندخله، ومن المرجح أن يظل المحتوى كما هو. سيوفر لنا زر أعجبني Like طريقة لتحديث محتوى العرض. يوضح لنا هذا الزر الحاجة إلى إبطال طريقة العرض المخزنة مؤقتًا عند تغير محتوياتها، إذ سيفيدنا ذلك عند التخزين المؤقت لطرق العرض المصيّرة لاحقًا في مقالنا. عند استخدام زر "أعجبني"، يجب تخزين بيانات الإعجاب في مكان ما. على الرغم من أن التخزين الثابت persistent storage مثالي، إلا أننا ستخزن الإعجابات في الذاكرة نظرًا لأن إنشاء قاعدة بيانات يقع خارج نطاق مقالنا. هكذا، ستكون البيانات سريعة الزوال، مما يعني أننا سنفقد كل البيانات عندما يتوقف الخادم. افتح ملف server.js وأضف المتغير التالي:

/**
 * Key is `n`
 * Value is the number of 'likes' for `n`
 */
const likesMap = {};

يُستخدم الغرض likesMap كخريطة لتخزين إعجابات الأعداد. المفتاح هو n وقيمه هي عدد إعجابات n. يجب تهيئة إعجابات العدد عند إرساله. أضف السطر الثاني والثالث على ملف server.js لتهيئة إعجابات N:

...

  const prime = findPrime(n);

  // Initialize likes for this number when necessary
  if (!likesMap[n]) likesMap[n] = 0;

  const locals = { n, prime };
  res.render('index', locals);

..

تتحقق عبارة if من وجود إعجابات للعدد الحالي. في حالة عدم وجود إعجابات، يُهيَّئ likesMaps على القيمة 0. ثم أضف الإعجابات كمتغير محلي للعرض، عن طريق تعديل سطر المتغيرات المحلية ليصبح كما يلي ولا تنسَ حفظ الملف:

const locals = { n, prime, likes: likesMap[n] };
  res.render('index', locals);

بعد أن أصبح لدينا بيانات الإعجابات، أصبح بإمكاننا عرض قيمتها وإضافة زر أعجبني. عدّل على ملف views/index.ejs لإضافة توصيف Markup لزر أعجبني كما يلي:

<% if (locals.n && locals.prime) { %>
  <p>
    The largest prime number less than or equal to <%= n %> is <strong><%= prime %></strong>.
  </p>

  <form action="/like" method="get">
    <input type="hidden" name="n" value="<%= n %>">
    <input type="submit" value="Like"> <%= likes %>
  </form>
<% } %>

يجب أن يبدو ملف views/index.ejs على النحو التالي:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Find the largest prime number</title>
  </head>
  <body>
    <h1>Find the largest prime number</h1>

    <p>
      For any number N, find the largest prime number less than or equal to N.
    </p>

    <form action="/" method="get">
      <label>
        N
        <input type="number" name="n" placeholder="e.g. 10" required>
      </label>
      <button>Find Prime</button>
    </form>

    <% if (locals.n && locals.prime) { %>
      <p>
        The largest prime number less than or equal to <%= n %> is <strong><%= prime %></strong>.
      </p>
      <form action="/like" method="get">
        <input type="hidden" name="n" value="<%= n %>">
        <input type="submit" value="Like"> <%= likes %>
      </form>
    <% } %>
  </body>
</html>

لا تنسَ حفظ الملف. ثم أعد تشغيل الخادم. سيظهر على الشاشة زر أعجبني له القيمة 0 بعد ظهور نتيجة العدد الأولي.

يؤدي النقر فوق زر "أعجبني" إلى إرسال طلب GET إلى المسار like/، بالقيمة الحالية لـ N كوسيط استعلام عبر إدخال غير مرئي. لكن ستحصل على رسالة خطأ 404 والعبارة Cannot GET /like، لأن التطبيق ليس لديه مسار مطابق بعد. سنضيف الآن المسار اللازم للتعامل مع الطلب، وذلك عبر إضافة الأسطر التالية:

app.get('/like', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.redirect('/');
    return;
  }

  likesMap[n]++;

  res.redirect(`/?n=${n}`);
});

...

يتحق المسار الجديد من وجود n وفي حال عدم وجودها نعود إلى المسار الرئيسي. أما في حال وجودها، فيزيد التطبيق عدد الإعجابات لهذا العدد. ثم يوجهنا إلى شاشة العرض التي ضغطنا فيها على زر "أعجبني". يجب أن يبدو الملف على النحو التالي:

const express = require('express');
const findPrime = require('./utils/findPrime');

const app = express();

app.set('view engine', 'ejs');

/**
 * Key is `n`
 * Value is the number of 'likes' for `n`
 */
const likesMap = {};

app.get('/', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.render('index');
    return;
  }

  const prime = findPrime(n);

  // Initialize likes for this number when necessary
  if (!likesMap[n]) likesMap[n] = 0;

  const locals = { n, prime, likes: likesMap[n] };
  res.render('index', locals);
});

app.get('/like', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.redirect('/');
    return;
  }

  likesMap[n]++;

  res.redirect(`/?n=${n}`);
});

const port = process.env.PORT || 3000;
app.listen(port, () =>
  console.log(`Example app is listening on port ${port}.`)
);

احفظ الملف، ثم أعد تشغيل التطبيق واختبر زر "أعجبني"، يجب أن يزداد عدد الإعجابات مع كل نقرة.

ملاحظة: يمكنك استخدام تابع POST بدلاً من GET لهذا المسار، والذي يوافق نمط RESTful أكثر لأننا حدثنا أحد الموارد. نستخدم في مقالنا تابع GET بدلاً من التعامل مع طلب POST حتى تتمكن من العمل مع وسطاء استعلام الطلب المألوفة.

أصبح التطبيق مكتملًا الآن ويعمل جيدًا، ويمكنك الاستعداد لنشره على منصة App Platform. في الخطوة التالية، سنُوْدِع الشيفرة في غيت Git، ثم ندفعها إلى مستودع غيت هب GitHub.

الخطوة الثالثة، إنشاء مستودع الشيفرات البرمجية

سننشئ في هذه الخطوة مستودع شيفرات برمجية Code Repository كي نخزّن فيه الملفات اللازمة للنشر. سنُوْدِع commit الشيفرة في غيت Git، ثم ندفعها push أو نضيفها إلى مستودع غيت هب GitHub، الذي سنستخدمه لنشر التطبيق على App platform.

إيداع الشيفرة في جيت

سنُودع الشيفرة في جيت كي تصبح جاهزةً لإضافتها أو دفعها إلى جيت هب.

ملاحظة: إن لم تسجل الدخول إلى حسابك وتضبط الإعدادات، فاحرص على إعداد غيت و مصادقته حسابك على غيت هب باستخدام بروتوكول SSH.

أولًا، عليك تهيئة مستودع غيت:

git init

ثم عليك استبعاد اعتماديات التطبيق dependencies، وذلك بإنشاء ملف اسمه gitignore. وإضافة الشيفرة التالية فيه:

.gitignore
node_modules

# macOS file
.DS_Store

ملاحظة: السطر DS_Store. خاص بالأجهزة التي تعمل باستخدام نظام ماك أو إس mac OS ولا حاجة لإضافة إن كان نظام التشغيل مختلفًا. والآن احفظ الملف.

ثم أضف كل الملفات إلى غيت:

git add .

وأَودِع التغييرات بواسطة الأمر التالي:

git commit -m "Initial commit"

يُستخدم الخيار m- لتحديد رسالة إيداع من اختيارك. والآن بعد إيداع الشيفرة، ستحصل على خرج مماثل لما يلي:

Output
[main (root-commit) deab84e] Initial commit
 6 files changed, 1259 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 package-lock.json
 create mode 100644 package.json
 create mode 100644 server.js
 create mode 100644 utils/findPrime.js
 create mode 100644 views/index.ejs

أي أنك أودعت الشيفرة في غيت، والآن عليك دفعها إلى غيت هب.

دفع الشيفرة إلى مستودع غيت هب

أصبح بإمكانك الآن دفع الشيفرة إلى غيت هب، ثم ربط الشيفرة بمنصة App Platform ونشره. أولاً، سجل الدخول إلى غيت هب من المتصفح وأنشئ مستودعًا جديدًا باسم Express-memcache. ثم أنشئ مستودعًا فارغًا بدون ملفات README أو gitignore. أو ملفات الشهادات. يمكنك جعل المستودع خاصًا أو عامًا. كما يمكنك مراجعة توثيق غيت هب حول كيفية إنشاء مستودع جديد. ثم عد إلى الطرفية، وأضف المستودع الذي أنشأته بمثابة remote origin، وحدّث اسم المستخدم الخاص بك:

git remote add origin https://github.com/your_username/express-memcache.git

يوجه الأمر السابق غيت إلى المكان الذي يجب عليه إضافة الشيفرة فيه. ثم سمّي الفرع الافتراضي فرعًا رئيسيًا main:

git branch -M main

ثم أضف الشيفرة إلى مستودعك:

git push -u origin main

ثم أدخل بياناتك إذا طُلب منك ذلك. وستحصل على خرج مشابه لما يلي:

Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (10/10), 9.50 KiB | 9.50 MiB/s, done.
Total 10 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/your_username/express-memcache.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

وبهذا أصبحت شيفرة التطبيق موجودةً على غيت هب، وأصبح التطبيق جاهزًا للنشر على منصة App Platform.

الخطوة الرابعة، نشر التطبيق على منصة App Platform

سننشر في هذه الخطوة، تطبيقنا على منصة تطبيقات App Platform. سننشئ حسابًا على المنصة ونسمح له بالوصول إلى مستودع غيت هب لنشر التطبيق. سنحدّث أولًا إعدادات البيئة كي يُتاح لها قراءة الضبط بواسطة عنوان البيئة PORT.

تحديث إعدادات بيئة التطبيق

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

...

const port = process.env.PORT || 3000;
app.listen(port, () =>
  console.log(`Example app is listening on port ${port}.`)
);

تنّص هذه الأسطر على استخدام متغير البيئة port في حال وجوده، أو استخدام المنفذ الافتراضي 3000. والآن، أصبح التطبيق قادرًا على القراءة من منفذ بيئة منصة التطبيقات التي سننشره عليها.

إنشاء ونشر التطبيق على منصة App Platform

سنُعدّ التطبيق للنشر على منصة App Platform، ولكن تذكر أن هذه الخطوة مأجورة، وعليك دفع رسوم تشغيل التطبيق على منصة App Platform بالثانية (بدءًا من دقيقة واحدة على الأقل). يمكنك الإطلاع على الأسعار في صفحة المعاينة Review، كما يمكنك الاطلاع على نظام تسعير منصة App Platform للحصول على تفاصيل أكثر.

أولاً، سجل الدخول إلى حسابك على DigitalOcean، ثم انقر على إنشاء create من لوحة تحكم التطبيقات Apps Dashboard. كما يمكنك الاطلاع على توثيق كيفية إنشاء التطبيقات في منصة App Platform.

ثم ادخل إلى صفحة Create Resource From Source Code screen، واختر غيت هب كمزود الخدمة Service Provider، وامنح الإذن
لـDigitalOcean للوصول إلى مستودعك. ننصحك بتحديد المستودع الذي تريد نشره فقط. سُتطالب بتثبيت تطبيق DigitalOcean GitHub. حدد مستودعك من القائمة وانقر فوق التالي Next. في شاشة الموارد Resources، انقر على تعديل الشريحة Edit Plan لتحديد حجم الاشتراك.

سنستخدم في مقالنا الاشتراك الأساسي ذو خدمات الويب الأصغر حجمًا (512 ميغابايت من ذاكرة الوصول العشوائي vCPU | RAM) مخصصة لمورد express-memcache. إذ يوفر الاشتراك الأساسي وأصغر خدمة ويب موارد كافيةً لتطبيقنا التدريبي. بعد اختيار الاشتراك، انقر على رجوع Back. ثم انقر على علامة تبويب المعلومات info في شريط التنقل الأيسر وانتبه على المنطقة التطبيق، إذ سنحتاج إلى ذلك في الخطوة التالية لإضافة MemCachier من متجر DigitalOcean. أخيرًا، انقر على نافذة المعانية Review، ثم زر إنشاء موارد Create Resources لإنشاء التطبيق ونشره. سيستغرق الأمر بعض الوقت لإنشاء التطبيق ونشره. ستصلك رسالة عند الانتهاء فيها رابط التطبيق بعد نشره.

بهذا نكون قد أنشأنا تطبيق Express يمكنه العثور على رقم أولي ويحتوي على زر أعجبني. ثم أَودَعنا شيفرة التطبيق إلى غيت ودفعناه إلى غيت هب، ثم نشرنا التطبيق على App Platform. والآن، لجعل تطبيق Express أسرع وأكثر قابلية للتوسع، سوف ننفذ ثلاث استراتيجيات للتخزين المؤقت للكائنات. ستحتاج إلى ذاكرة تخزين مؤقت Cache، والتي سننشئها في الخطوة التالية.

الخطوة الخامسة، إعداد ذاكرة تخزين مؤقت للكائنات باستخدام MemCachier

في هذه الخطوة، سننشئ ونضبط إعدادات ذاكرة تخزين مؤقت للكائنات. يمكنك استخدام أي ذاكرة تخزين مؤقت متوافقة مع memcached. سنستخدم في مقالنا إضافة MemCachier من متجر DigitalOcean. وذاكرة التخزين المؤقت MemCachier هي عبارة عن ذاكرة تخزين مؤقت تخزن البيانات على هيئة قيمة-مفتاح.

أولًا، علينا إضافة MemCachier من متجر Digital Ocean، وللقيام بذلك انتقل إلى صفحة إضافة MemCachier، ثم انقر على Add MemCachier، ثم اختر المنطقة المناسبة لتطبيقك، يجب أن تختار المنطقة نفسها للتطبيق والذاكرة كي تخفف من التأخير بقدر الإمكان. كما يمكنك مراجعة إعدادات التطبيق للتأكد من المنطقة واختيار اشتراك معين. ثم، انقر على Add MemCachier لإضافة الذاكرة المؤقتة.

ملاحظة: لمعرفة اختصارات اسماء المناطق، ننصحك بزيارة مركز بيانات DigitalOcean، فمثلًا منطقة سان فرانسيسكو اختصارها هو sfo3.

والآن، عليك ضبط إعدادات التطبيق لاستخدام الذاكرة. انتقل إلى لوحة تحكم الإضافات Add-Ons dashboard ثم انقر على إضافة MemCachier للانتقال إلى لوحة التحكم. بعدها، انقر على زر عرض Show متغيرات الإعدادات Configuration Variables لعرض القيم التالية MEMCACHIER_USERNAME، MEMCACHIER_PASSWORD، MEMCACHIER_SERVERS. انتبه على هذه القيم لأننا سنحتاجها لاحقًا.

سنحفظ الآن متغيرات إعدادات MemCachier كمتغيرات بيئة للتطبيق. انتقل إلى لوحة تحكم التطبيق ثم انقر على الإعدادات Settings. ثم من Components انقر على express-memc وانتقل لقسم متغيرات البيئة Environment Variables وانقر على تعديل Edit ثم أضف متغيرات إعدادات MemCachier ذات المفاتيح: (MEMCACHIER_USERNAME، MEMCACHIER_PASSWORD، MEMCACHIER_SERVERS) وأضف القيم كل منها وفقًا للقيم الموجودة في لوحة تحكم MemCachier> انقر على خيار التشفير Encrypt بجانب المفتاح MEMCACHIER_PASSWORD لتشفير كلمة المرور، ثم انقر على حفظ Save.

والآن، علينا ضبط عميل ذاكرة memcache client في التطبيق باستخدام المتغيرات التي أدخلنا كي يستطيع التطبيق التخاطب مع الذاكرة. ثبّت المكتبة memjs في الطرفية:

npm install memjs

ثم أنشأ مجلد خدمات services، وأنشأ فيه الملف services/memcache.js وافتحه في المحرر. ثم استورد مكتبة memjs في أعلى الملف واضبط إعدادات عميل الذاكرة cache client:

const { Client } = require('memjs');

module.exports = Client.create(process.env.MEMCACHIER_SERVERS, {
  failover: true,
  timeout: 1,
  keepAlive: true,
});

ولا تنسَ حفظ الملف.

تنشأ الشيفرة السابقة عميل لذاكرة التخزين المؤقتة MemCachier. أما بالنسبة للخيار failover، ضبطناه على القيمة true لاستخدام مجموعة حواسيب MemCachier عالية التوفر في حال حدوث الفشل. إذ إنه في حالة فشل الخادم، ستُرسل أوامر المفاتيح المخزنة على هذا الخادم تلقائيًا إلى الخادم التالي المتاح.

ينصح باستخدام مهلة timeout مدتها ثانية واحدة إذ إنها أفضل للتطبيقات المنشورة من المهلة الافتراضية البالغة 0.5 ثانية. أما السطر keepAlive: true فيبقي الاتصال مع ذاكرة التخزين المؤقت مفتوحًا حتى في وضع الخمول، وهو أمر محبّذ لأن عملية إجراء الاتصال بطيئة، ويجب أن تكون ذاكرة التخزين المؤقت سريعة لتكون فعالة. حصلنا في هذه الخطوة على ذاكرة تخزين مؤقت باستخدام إضافة MemCachier من متجر DigitalOcean. ثم أضفنا إعدادات ذاكرة التخزين المؤقت كمتغيرات بيئة في منصة التطبيقات، كي نستطيع إعداد عميل باستخدام مكتبة memjs ويتمكن التطبيق من الاتصال بذاكرة التخزين المؤقت.

والآن، أصبحنا جاهزين لتطبيق للتخزين المؤقت في Express، وهو ما سنتعلمه في خطوتنا التالية.

الخطوة السادسة، تطبيق تقنيات التخزين المؤقت في Express باستخدام إضافة MemCachier

أصبح بإمكانك الآن استخدام ذاكرة التخزين المؤقت للكائنات بعد نشر التطبيق وإضافة ميزة التخزين المؤقت MemCachier. إذ سننفذ في هذه الخطوة ثلاث تقنيات للتخزين المؤقت للكائنات. سنبدأ بالتخزين المؤقت للعمليات ذات الاستخدام الكثيف للموارد لتحسين سرعة الاستخدام وكفاءته. بعد ذلك، سنطبق تقنيات لتخزين طرق العرض المصيّرة بعد الإدخال لتحسين معالجة الطلب وتخزين الجلسات القصيرة مؤقتًا لإتاحة المجال لتوسيع نطاق تطبيقك فيما بعد.

التخزين المؤقت للعمليات ذات الاستخدام الكثيف للموارد

سنخزن العمليات الحوسبية ذات الاستخدام الكثيف للموارد تخزينًا مؤقتًا لتسريع التطبيق، مما يؤدي إلى استخدام وحدة المعالجة المركزية بكفاءة أكبر. إذ تُعد الدالة findPrime عملية حسابية تستخدم الموارد بكثافة عند إدخال عدد كبير. سنخزن نتائج الدالة مؤقتًا عند توفرها بدلاً من تكرار العملية الحسابية. أولاً، افتح ملف server.js لإضافة عميل الذاكرة memcache:

const express = require('express');
const findPrime = require('./utils/findPrime');
const memcache = require('./services/memcache');

...

ثم خزّن عددًا أوليًا محسوبًا من قبل في الذاكرة المؤقتة كما يلي:

...

  const prime = findPrime(n);

  const key = 'prime_' + n;

  memcache.set(key, prime.toString(), { expires: 0 }, (err) => {
    if (err) console.log(err);
  });

...

ولا تنسَ حفظ الملف. لاحظ أن التابع set يقبل مفتاحًا key كوسيط أول، وقيمة للسلسلة أي value كوسيطه الثاني. لذا حولنا العدد الأولي إلى سلسلة، أما الشرط الثالث فيحرص على عدم انتهاء مدة العنصر المُخزّن، والشرط الرابع والأخير هو تابع استدعاء اختياري عند حدوث خطأ ما.

ملاحظة1: يجب التعامل مع أخطاء ذاكرة التخزين المؤقت بحذر. إذ تعد هذه ذاكرة بمثابة تحسين ويجب ألا تؤدي إلى تعطل التطبيق. في من الممكن أن يعمل التطبيق على نحو جيد، وإن كان أبطأ، بدون ذاكرة التخزين المؤقت.

ملاحظة 2: بإمكان التطبيق الآن العمل محليًا ولكن بدون تخزين مؤقت، وسيظهر خطأ في الخرج عند استدعاء memcache.set لأن التطبيق لن يستمكن من إيجاد خادم تخزين مؤقت، وستحصل حينها على خرج مشابه للتالي:

Output
MemJS: Server <localhost:11211> failed after (2) retries with error - connect ECONNREFUSED 127.0.0.1:11211
Error: No servers available
...

لن تحتاج إلى التخزين المحلي لإكمال باقي خطوات المقال. إذا يمكنك تشغيل localhost:11211 في العنوان الذي يُعد العنوان الافتراضي لـ memjs.

والآن، عليك إيداع التغييرات:

git add . && git commit -m "Add memjs client and cache prime number"

ثم أضف هذه التغييرات إلى غيت هب، والتي ستُنشر إلى منصة التطبيقات تلقائيًا:

git push

ستظهر رسالة على لوحة تحكم منصة التطبيقات تشير إلى أن تطبيقك قيد الإنشاء، بعد أن كانت حالته Deployed أي منشور. وعند اكتمال إنشاء التطبيق، افتح التطبيق في متصفحك وأدخل عددًا للعثور على أكبر عدد أولي أصغر أو مساوٍ له.

ملاحظة: قد تظهر رسالة "Waiting for service" على لوحة التحكم، وتعني حالة انتظار الخدمة، وهذه الرسالة ستختفى من تلقاء نفسها، ولكن إن طال ظهورها عليك تحديث التطبيق للتأكد أن التطبيق قد نُشر بعد اكتمال إنشائه.

والآن، عليك الرجوع إلى صفحة إضافات لوحة التحكم ثم النقر على View MemCachier لعرض لوحة تحليلات ذاكرة التخزين المؤقت.

في هذه اللوحة، زدنا الخيار Set Cmds في لوحة All Time Stats وحالة العناصر Items في لوحة التخزين Storage بمقدار 1.
في كل مرة ترسل عددًا، سيزداد كل من Set Cmds وItems. ويجب عليك الضغط على زر التحديث لتحميل الإحصائيات الجديدة.

ملاحظة: يُعد التحقق من سجلات التطبيق على منصة App Platform أمرًا مفيدًا لتصحيح الأخطاء. يمكنك النقر من لوحة تحكم التطبيق على Runtime Logs لعرض الأخطاء.

يمكن الاستفادة من العناصر المخزنة في الذاكرة المؤقتة. ستتحقق الآن مما إذا كان العنصر قد خُزّن مسبقًا، وإذا كان الأمر كذلك، فسوف يُعرض من ذاكرة التخزين المؤقت، وإلا سيبحث التطبيق عن العدد الأولي كما في السابق. عّدل ملف server.js، إذ عليك تعديل بعض الأسطر وإضافة بعد الاسطر الجديدة كما يلي:

...

app.get('/', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.render('index');
    return;
  }

  let prime;

  const key = 'prime_' + n;

  memcache.get(key, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      // Use the value from the cache
      // Convert Buffer string before converting to number
      prime = parseInt(val.toString());
    } else {
      // No cached value available, find it
      prime = findPrime(n);

      memcache.set(key, prime.toString(), { expires: 0 }, (err) => {
        if (err) console.log(err);
      });
    }

    // Initialize likes for this number when necessary
    if (!likesMap[n]) likesMap[n] = 0;

    const locals = { n, prime, likes: likesMap[n] };
    res.render('index', locals);
  });
});

...

تهيئ الشبفرة السابقة العدد الأولي prime بدون قيمة، باستخدام الكلمة المفتاحية Let، حيث أُعيدَ تعيين قيمتها. ثم يحاول تابع memcache.get استرداد العدد الأولي المخزن. توجد معظم شيفرة المتحكم الآن في تابع الاستدعاء memcache.get لأن نتيجته لازمة لتحديد كيفية التعامل مع الطلب. فإن كان ثمة قيمة مخزنة متاحة، فعليه استخدامها، وإلا عليه إجراء الحسابات اللازمة للعثور على العدد الأولي وتخزين النتيجة في ذاكرة التخزين المؤقت. إن القيمة التي يستدعيها تابع الاستدعاء memcache.get هي قيمة تخزين مؤقتة Buffer، لذا عليك تحويلها إلى سلسلة قبل تحويل التابع prime إلى عدد. أودع التغييرات ثم ادفعها إلى غيت هب لتنشرها:

git add . && git commit -m "Check cache for prime number" && git push

عندما ترسل رقمًا لم يخزّن بعد في التطبيق، ستزداد إحصائيات Set Cmds وحالة العناصر Items وإحصائيات الأخطاء get misses في لوحة تحكم MemCachier بمقدار 1. تحدث حالة الخطأ miss عند محاولة الحصول على العنصر من ذاكرة التخزين المؤقت قبل تعيينه، فالعنصر غير موجود في ذاكرة التخزين المؤقت، مما يؤدي إلى حدوث خطأ، ثم يخزّن العنصر بعد ذلك. عند إدخال عدد مخزّن مسبقًا، سيزداد عدد مرات الحصول على النتائج get hits.

وهكذا نكون قد خزّنا العمليات ذات الاستخدام الكثيف للموارد تخزينًا مؤقتًا. بعد ذلك، سنخزّن طرق عرض التطبيق المصيّرة مؤقتًا.

تخزين طرق العرض المصيّرة

سنخزّن الآن طرق عرض التطبيق مؤقتًا باستخدام برنامج وسيط. أعددنا في خطوة سابقة ejs كمولد قوالب وأنشأنا قالبًا لعرض كل رقم مُدخل n. قد يستهلك إنشاء العرض كثيرًا من الموارد، لذا فإن تخزينه مؤقتًا يمكن أن يسرع معالجة الطلب ويستخدم موارد أقل.

أولًا، أنشئ مجلدًا للبرنامج الوسيط وسمّه middleware. ثم أنشئ الملف middleware/cacheView.js وافتحه في المحرر. ثم أضف هذه الأسطر في ملف CacheView.js لدالة البرنامج الوسيط:

const memcache = require('../services/memcache');

/**
 * Express middleware to cache views and serve cached views
 */
module.exports = function (req, res, next) {
  const key = `view_${req.url}`;

  memcache.get(key, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      // Convert Buffer string to send as the response body
      res.send(val.toString());
      return;
    }
  });
};

استوردنا في الشيفرة السابقة عميل الذاكرة memcache. ثم عرفنا عن مفتاح، مثل view_/?n=100. وبعدها، تحققنا من وجود عرض لهذا المفتاح في ذاكرة التخزين المؤقت باستخدام التابع memcache.get. إذا لم يكن هناك خطأ ووُجدت قيمة لهذا المفتاح، ينتهي الطلب عن طريق إرسال العرض مرةً أخرى إلى العميل.

بعد ذلك، إذا لم يكن العرض مخزنًا، فعليك تخزينه مؤقتًا، عن طريق تعديل override التابع res.send بإضافة الأسطر التالية على ملف middleware/cacheView.js:

const originalSend = res.send;
    res.send = function (body) {
      memcache.set(key, body, { expires: 0 }, (err) => {
        if (err) console.log(err);
      });

      originalSend.call(this, body);
    };

يجب أن يصبح محتوى الملف middleware/cacheView.js كالتالي:

const memcache = require('../services/memcache');

/**
 * Express middleware to cache views and serve cached views
 */
module.exports = function (req, res, next) {
  const key = `view_${req.url}`;

  memcache.get(key, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      // Convert Buffer string to send as the response body
      res.send(val.toString());
      return;
    }
  const originalSend = res.send;
    res.send = function (body) {
      memcache.set(key, body, { expires: 0 }, (err) => {
        if (err) console.log(err);
      });

      originalSend.call(this, body);
    };
  });
};

يمكنك تعديل التابع res.send باستعمال دالة تخزن العرض في ذاكرة التخزين المؤقت قبل استدعاء دالة الإرسال الأساسية send كالمعتاد. إذ يمكنك استدعاء دالة الإرسال الأساسية send باستخدام تابع الاستدعاء call الذي يستخدم this والذي يعبر عن context الحالي بعد تعليمة الذاكرة memcache.set. احرص على استخدام دالة مجهولة (وليس دالة سهمية)، كي تحدد قيمة this الصحيحة. بعد ذلك، مرر التحكم إلى البرنامج الوسيط عن طريق إضافة الأمر next:

...

/**
 * Express middleware to cache views and serve cached views
 */
module.exports = function (req, res, next) {
  const key = `view_${req.url}`;

  memcache.get(key, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      // Convert Buffer to UTF-8 string to send as the response body
      res.send(val.toString());
      return;
    }

    const originalSend = res.send;
    res.send = function (body) {
      memcache.set(key, body, { expires: 0 }, (err) => {
        if (err) console.log(err);
      });

      originalSend.call(this, body);
    };

    next();
  });
};

...

إن إضافة التابع next يؤدي استدعاء دالة البرنامج الوسيط التالي في التطبيق. لكن لا يوجد في مثالنا برامج وسيط آخر، لذلك يُستدعى المتحكم controller. يوّلد التابع res.render الخاص بـ Express صفحة عرض view، ثم يستدعي التابع res.send داخليًا باستخدام طريقة العرض. والآن، في وحدة تحكم المسار الرئيسي، يُستدعى تابع التعديل override عند استدعاء res.render، ليخزّن العرض في ذاكرة التخزين المؤقت قبل استدعاء دالة send الأصلية لإكمال الرد.

ملاحظة: يمكنك تمرير استدعاء للتابع render في المتحكم، ولكن عليك تكرار شيفرة التخزين المؤقت للعرض في وحدة التحكم لكل مسار يخزن مؤقتًا. والآن، استورد البرنامج الوسيط في الملف server.js:

const express = require('express');
const findPrime = require('./utils/findPrime');
const memcache = require('./services/memcache');
const cacheView = require('./middleware/cacheView');

...

ثم أضف الوسيط cacheView لاستخدامه في المسار الرئيسي مع التابع / Get:

...

app.get('/', cacheView, (req, res) => {
  ...
});

...

ثم أودع التغييرات وادفعها إلى غيت هب لنشرها:

git add . && git commit -m "Add view caching" && git push

عند إدخال عدد جديد، ستزداد إحصائيات لوحة تحكم MemCachier لكل من Set Cmds وItems وget misses بمقدار اثنين: مرة لحساب العدد الأولي ومرة للعرض. عند تحديث التطبيق بنفس الرقم، فسترى زيادةً بمقدار 1 في get hit لوحة التحكم. لأن صفحة العرض استُرِدت من ذاكرة التخزين المؤقت، لذلك لا توجد حاجة لجلب نتيجة العدد الأولي من التطبيق ملاحظة: إن خيار view cache مفعّل تلقائيًا في الإنتاج، لكن هذا الخيار لا يخزن محتوى خرج القالب، بل يخزن القالب فقط.ويعاد عرض الصفحة مع كل طلب، حتى عندما تكون ذاكرة التخزين المؤقت قيد التشغيل. إذًا فخيار view cache، مختلف ولكنه مكمل للتخزين المؤقت للعرض الذي طبقناه.

قد تلاحظ بعد أن خزّنا العرض أن زر الاعجاب لا يعمل. إذا سجلت عدد الإعجابات، فستلاحظ أنها تتغير وتزداد، لكن العرض المخزّن بحاجة إلى التحديث عندما يتغير عدد الإعجابات. إذًا يجب إيقاف العرض المخزن مؤقتًا عند تغيير العرض.

ثم سنوقف العرض المخزّن عندما يتغير عدد الإعجابات likes وذلك عن طريق حذفه من ذاكرة التخزين المؤقت. عدّل دالة إعادة التوجيه redirect في ملف server.js عن طريق إضافة الأسطر التالية:

likesMap[n]++;

  // The URL of the page being 'liked'
  const url = `/?n=${n}`;

  res.redirect(url);

لتصبح الدالة كما يلي:

...
app.get('/like', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.redirect('/');
    return;
  }

  likesMap[n]++;

  // The URL of the page being 'liked'
  const url = `/?n=${n}`;

  res.redirect(url);
});

...

بعد تغير عدد الاعجابات في صفحة العرض، ستصبح النسخة المخزنة غير صالحة، لذا أضف الأسطر التالية لحذف عدد الإعجابات من ذاكرة التخزين المؤقت عندما تتغير الإعجابات likes:

...
  const url = `/?n=${n}`;

  // The view for this URL has changed, so the cached version is no longer valid, delete it from the cache.
  const key = `view_${url}`;
  memcache.delete(key, (err) => {
    if (err) console.log(err);
  });

  res.redirect(url);
...

يجب أن يكون ملف server.js مماثلًا لما يلي:

const express = require('express');
const findPrime = require('./utils/findPrime');
const memcache = require('./services/memcache');
const cacheView = require('./middleware/cacheView');

const app = express();

app.set('view engine', 'ejs');

/**
 * Key is `n`
 * Value is the number of 'likes' for `n`
 */
const likesMap = {};

app.get('/', cacheView, (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.render('index');
    return;
  }

  let prime;

  const key = 'prime_' + n;

  memcache.get(key, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      // Use the value from the cache
      // Convert Buffer string before converting to number
      prime = parseInt(val.toString());
    } else {
      // No cached value available, find it
      prime = findPrime(n);

      memcache.set(key, prime.toString(), { expires: 0 }, (err) => {
        if (err) console.log(err);
      });
    }

    // Initialize likes for this number when necessary
    if (!likesMap[n]) likesMap[n] = 0;

    const locals = { n, prime, likes: likesMap[n] };
    res.render('index', locals);
  });
});

app.get('/like', (req, res) => {
  const n = req.query.n;

  if (!n) {
    res.redirect('/');
    return;
  }

  likesMap[n]++;

  // The URL of the page being 'liked'
  const url = `/?n=${n}`;

  // The view for this URL has changed, so the cached version is no longer valid, delete it from the cache.
  const key = `view_${url}`;
  memcache.delete(key, (err) => {
    if (err) console.log(err);
  });

  res.redirect(url);
});

const port = process.env.PORT || 3000;
app.listen(port, () =>
  console.log(`Example app is listening on port ${port}.`)
);

لا تنسَ حفظ الملف، ثم أودع التغييرات وادفعها للنشر:

git add . && git commit -m "Delete invalid cached view" && git push

والآن سيعمل زر الاعجاب في التطبيق وستتغير الإحصائيات التالية في لوحة تحكم MemCachier عند النقر على الزر:

• delete hits تزداد عند حذف العرض.
• get misses تزداد عند حذف العرض وعدم وجوده في ذاكرة التخزين المؤقت.
• get hits تزداد عند العثور على العدد الأولي في ذاكرة التخزين المؤقت.
• Set Cmds تزداد عند إضافة العرض إلى ذاكرة التخزين المؤقت.
• Items تبقى على حالها عند حذف أو إضافة العرض. وهكذا نكون قد طبقنا التخزين المؤقت للعرض وأبطلنا استخدام صفحات العرض المخزنة عند تغييرها. أما التقنية الأخيرة التي سننفذها هي التخزين المؤقت للجلسة.

التخزين المؤقت للجلسات

سنتعلم في هذه الفقرة كيفية إضافة جلسات Sessions وتخزينها مؤقتًا في تطبيق Express، مما يجعل ذاكرة التخزين المؤقت مخزنًا للجلسات. وحيث إن إحدى الاستخدامات الشائعة للجلسات هي تسجيل دخول المستخدم user login، لذا يمكننا اعتبار هذه الفقرة خطوةً أوليةً لتنفيذ نظام تسجيل دخول المستخدم في المستقبل (على الرغم من أن نظام تسجيل دخول المستخدم خارج عن نطاق مقالنا). يمكن أن يكون تخزين الجلسات قصيرة الأمد في ذاكرة التخزين المؤقت أسرع وأكثر قابليةً للتوسع من تخزينها في قواعد البيانات.

ملاحظة: تعتبر ذاكرة التخزين المؤقت مثالية لتخزين الجلسات القصيرة التي انتهت مدتها. ومع ذلك، فإن ذاكرة التخزين المؤقت ليست دائمة؛ لذا تعد حلول التخزين الدائمة كقواعد البيانات أكثر ملاءمةً لتخزين الجلسات طويلة الأمد.

والآن، ثبّت أداة الجلسات express-session كي تضيف جلسات إلى التطبيق وإلى مكتبة connect-memjs لاستخدام MemCachier كمخزن للجلسات:

npm install express-session connect-memjs

استورد ملف express-session و connect-memjs إلى ملف server.js:

const express = require('express');
const findPrime = require('./utils/findPrime');
const memcache = require('./services/memcache');
const cacheView = require('./middleware/cacheView');
const session = require('express-session');
const MemcacheStore = require('connect-memjs')(session);

...

تُمرَر جلسة البرنامج الوسيط يتم تمرير البرنامج الوسيط للجلسة إلى وحدة الاتصال connect في memcached، مما يسمح لها بالوراثة من Express.session.Store.

عدّل إعدادات البرنامج الوسيط للجلسة كي يستخدا ذاكرة التخزين المؤقت كمخزن له، وذلك بإضافة الأسطر التالية:

...

app.set('view engine', 'ejs');

app.use(
  session({
    secret: 'your-session-secret',
    resave: false,
    saveUninitialized: true,
    store: new MemcacheStore({
      servers: [process.env.MEMCACHIER_SERVERS],
      prefix: 'session_',
    }),
  })
);

...

يستخدم secret لتسجيل ملفات تعريف الارتباط للجلسة أو ما يُعرف باسم cookie. لا تنسَ استبدال your-session-secret بسلسلة مميزة. ملاحظة: يجب استخدام متغيرات البيئة لضبط secret لمراحل الإنتاج، وذلك بإضافة السطر

secret: process.env.SESSION_SECRET || 'your-session-secret'

لكن عندها يجب ضبط متغير البيئة في لوحة تحكم App Platform. يجبر الأمر Resave الجلسة على إعادة الحفظ إذا تُعدَل أثناء الطلب. ولأننا لا نريد تخزين العنصر في الذاكرة التخزين المؤقت مرة أخرى، لذا علينا ضبط قيمته على false. saveUninitialized: false is useful when you only want to save modified sessions, as is often the case with login sessions where a user property might be added to the session after authentication. In this case, you will store all sessions indiscriminately, so you set it to true. يُعد الأمر saveUninitialized: false مفيدًا لحفظ الجلسات المعدلة فقط، كما هو الحال غالبًا مع جلسات تسجيل الدخول، حيث يمكن إضافة خاصية مستخدم إلى الجلسة بعد المصادقة، حينها سنخزّن جميع الجلسات بصورة عشوائية، لذلك سنضبطها على القيمة true.

أخيرًا، اربط قيمة store مع ذاكرة التخزين المؤقتة، واضبط بادئة ذاكرة التخزين المؤقت للجلسة على ._session وهذا يعني أن مفتاح عنصر الجلسة في الذاكرة سيبدو كالتالي: session_<session ID>.

بعدها، أضف برامجًا وسيطًا لتصحيح الأخطاء على مستوى التطبيق، والتي ستساعد في تحديد الجلسات المخزنة قيد التنفيذ:

...

app.use(
  session({
    ...
  })
);

/**
 * Session sanity check middleware
 */
app.use(function (req, res, next) {
  console.log('Session ID:', req.session.id);

  // Get the item from the cache
  memcache.get(`session_${req.session.id}`, (err, val) => {
    if (err) console.log(err);

    if (val !== null) {
      console.log('Session from cache:', val.toString());
    }
  });

  next();
});

...

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

git add . && git commit -m "Add session caching" && git push

أدخل رقمًا في التطبيق ثم تحقق من سجلات وقت التشغيل **Runtime Logs ** في لوحة التحكم للوصول إلى رسائل تصحيح الأخطاء. ستجد معرف الجلسة والقيمة التي سجلتها، مما يوضح أن الجلسات تعمل وتخزّن بصورة صحيحة. في لوحة تحكم MemCachier، عند تخزين العرض والجلسة، سترى ثلاث نتائج لكل تحديث للصفحة: واحدة لصفحة العرض، وواحدة للجلسة، وواحدة لجلسة برنامج تصحيح الأخطاء الوسيط. والآن، يمكنك التوقف عند هذه الخطوة، أو يمكنك الاطلاع على الخطوة السابعةالإضافية.

الخطوة السابعة، حذف الموارد (اختيارية)

ثمة رسوم عليك دفعها عند نشر التطبيق على منصة App platform، لذا يمكنك حذف التطبيق وإضافة MemCachier عند الانتهاء. انقر على الإجراءات Actions من لوحة التحكم ثم انقر على حذف التطبيق Destroy App. لحذف إضافة MemCachier، انقر على الإضافات Add-Ons، ثم على MemCachier، وانقر بعدها على الإعدادات والحذف Settings and Destroy. تلغى ذاكرة MemCachier المجانية بعد 30 يومًا من عدم استخدامها، ولكن يُعد تنظيف الادوات أمرًا جيدًا.

ختامًا

تعلمنا في مقالنا كيفية إنشاء تطبيق Express للعثور على عدد أولي باستخدام وكيفية إضافة زر "أعجبني". ثم رفعنا هذا التطبيق على غيت هب ونشرناه على منصة تطبيقات DigitalOcean. ثم سرّعنا التطبيق وجعلناه قابلًا للتوسع من خلال تنفيذ ثلاث تقنيات للتخزين المؤقت للكائنات باستخدام إضافة MemCachier للتخزين المؤقت للعمليات ذات الاستخدام الكثيفة للموارد، ومن خلال العرض view، والجلسات sessions.

يمكنك الاطلاع على ملفات هذا المقال في مستودع مجتمع DigitalOcean، تحتوي المفاتيح في كل استراتيجيات التخزين المؤقت التي نفذناها على بادئة: _prime و  _view و _session prime_ و view_ وsession_. بالإضافة إلى ميزة فضاء الاسم، توفر البادئة فائدةً إضافيةً وهي السماح بتحديد أداء ذاكرة التخزين المؤقت.

استخدمنا في مقالنا شريحة المطورين developer plan في MemCachier، ولكن يمكنك تجربة شريحة مُدارة بالكامل تأتي مع مجموعة ميزات االفحص الدقيق Introspection، مما يتيح لك تتبع أداء البادئات الفردية. على سبيل المثال، يمكنك مراقبة معدل النقر hit rate أو نسبة النقر hit ratio على أي بادئة، مما يوفر رؤية تفصيلية لأداء ذاكرة التخزين المؤقت. إن أردت متابعة استخدام MemCachier، يمكنك مراجعة التوثيقات التالية.

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

ترجمة -وبتصرف- [للمقال ](How To Deploy an Express Application and Scale with MemCachier on DigitalOcean App Platform) من موقع DigitalOcean لكاتبيه Patrick O'Hanlon و Caitlin Postal.

اقرأ أيضًا

• مدخل إلى إطار عمل الويب Express وبيئة Node
• دليل استخدام Node.js وإطار العمل Express للمبتدئين
• نشر تطبيق Express في بيئة الإنتاج
• مقدمة إلى القوالب Template في Express: إنشاء القالب الأساسي لموقع مكتبة محلية مثالًا

تشير إدارة الضبط Configuration Management -أو CM اختصارًا- إلى عملية المعالجة المنتظمة للتغييرات على النظام بطريقة تحافظ على التكامل بمرور الوقت، ويُستخدَم هذا المصطلح على نطاق واسع للإشارة إلى إدارة ضبط الخادم بالرغم من أن هذه العملية لم تنشأ في مجال تقانة المعلومات.

تلعب عملية الأتمتة دورًا أساسيًا في إدارة ضبط الخادم، وهي الآلية المُستخدَمة لجعل الخادم يصل إلى الحالة المرغوبة، والتي حدَّدتها مسبقًا سكربتات الإعداد المسبق Provisioning Scripts باستخدام لغة وميزات معينة خاصة بالأداة. تُعَد الأتمتة جوهر إدارة ضبط الخوادم، لذا من الشائع الإشارة إلى أدوات إدارة الضبط بأنها أدوات الأتمتة Automation Tools أو أدوات أتمتة تقانة المعلومات IT Automation Tools. يوجد مصطلح شائع آخر يُستخدَم لوصف ميزات الأتمتة التي تقدّمها أدوات إدارة الضبط وهو تنسيق الخادم Server Orchestration أو تنسيق تقانة المعلومات IT Orchestration، لأن هذه الأدوات قادرة على إدارة خادم أو مئات الخوادم من جهاز تحكم مركزي، وقد فصلنا الفرق بينهما في مقال الفرق بين التنسيق والأتمتة فارجع إليه لمزيد من التفاصيل.

هناك عدد من أدوات إدارة الضبط المتاحة في السوق مثل:

• Puppet
• Ansible
• Chef
• Salt

حيث ستتميز كل أداة بخصائصها وستعمل بطرق مختلفة، إلا أن لها الغرض نفسه، وهو التأكد من أن حالة النظام تتطابق مع الحالة التي توضحها سكربتات الإعداد المسبق.

هذا المقال جزء من سلسلة حول إدارة ضبط الخوادم، وإليك روابط فصول السلسلة:

• مدخل إلى إدارة ضبط الخوادم Configuration Management
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة دليل تشغيل الأداة Ansible
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة ملفات البيان Manifests للأداة Puppet
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة الوصفات Recipes في الأداة Chef

الفوائد التي تجنيها الخوادم من إدارة الضبط

يتطلب استخدام إدارة الضبط تخطيطًا أوليًا وجهدًا أكثر من إدارة النظام اليدوية، ولكن ستتحسّن بنى الخادم التحتية بأكملها باستثناء البسيطة منها من خلال الفوائد التي توفرها إدارة الضبط، حيث سنوضح فيما يلي بعضًا من هذه الفوائد.

الإعداد المسبق السريع للخوادم الجديدة

يمكن لأداة إدارة الضبط أتمتة معظم -إن لم يكن كل- عملية الإعداد المسبق نيابة عنك عند نشر خادم جديد، إذ تجعل الأتمتة عملية الإعداد المسبق أسرع وأكثر كفاءة لأنها تتيح أداء المهام الشاقة بصورة أسرع وأدق من أيّ إنسان يطبّقها، حيث يمكن أن يستغرق نشر خادم الويب يدويًا مثلًا ساعات بالموازنة مع بضع الدقائق التي تحتاجها إدارة أو أتمتة الضبط حتى مع وجود التوثيق الصحيح والشامل.

التعافي السريع من الأحداث العصيبة

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

لا مزيد من الخوادم ذات الإدارة اليدوية Snowflake

تبدو للوهلة الأولى إدارة النظام اليدوية طريقة سهلة لنشر الخوادم وإصلاحها بسرعة ولكن لها سلبياتها، إذ يصبح بمرور الوقت من الصعب معرفة ما هو مُثبَّتٌ على الخادم وما هي التغييرات التي أجريت عندما لا تكون العملية مؤتمتة. يمكن للإصلاحات اليدوية السريعة Hotfixes وتعديلات الضبط وتحديثات البرمجيات أن تحوّل الخوادم إلى خوادم Snowflake فريدة تصعب إدارتها وتكرارها. تُوثَّق جميع الإجراءات اللازمة لإحضار خادم جديد أو تحديث خادم موجود مسبقًا في سكربتات الإعداد المسبق باستخدام أداة إدارة الضبط.

التحكم في الإصدارات لبيئة الخادم

سيكون لديك القدرة على تطبيق العديد من الأدوات وطرق سير العمل التي تستخدمها في شيفرة البرمجيات على بيئة الخادم بمجرد ترجمة ضبط خادمك إلى مجموعة من سكربتات الإعداد المسبق.

يمكن استخدام أدوات التحكم في الإصدارات مثل جيت Git لتتبّع التغييرات التي أُجريت على الإعداد المسبق ولإبقاء فروع الإصدارات القديمة من السكربتات منفصلةً، ويمكنك استخدام التحكم في الإصدارات لتنفيذ سياسة مراجعة الشيفرة البرمجية لسكربتات الإعداد المسبق، إذ يجب إرسال أي تغييرات بوصفها طلبَ سحب ويجب أن يوافق قائد المشروع عليها قبل قبولها. ستضيف هذه الممارسة تناسقًا إضافيًا إلى إعداد بنيتك التحتية.

البيئات المكررة

تسهّل إدارة الضبط تكرار البيئات مع البرمجيات والضبط نفسه، مما يمكّنك من بناء نظام بيئي متعدد المراحل بفعالية مع خوادم الإنتاج والتطوير والاختبار، ويمكنك استخدام الآلات الافتراضية المحلية للتطوير، والتي أُنشِئت باستخدام سكربتات الإعداد المسبق نفسها. ستعمل هذه الممارسة على تقليل المشاكل التي تسببها اختلافات البيئة التي تحدث بصورة متكررة عند نشر التطبيقات في بيئة الإنتاج أو عند مشاركتها بين زملاء العمل الذين يستخدمون إعدادات أجهزة مختلفة (مثل نظام تشغيل و/أو إصدارات برمجيات و/أو ضبط مختلف).

نظرة عامة على أدوات إدارة الضبط

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

سنوضّح فيما يلي الميزات الأكثر شيوعًا الموجودة في معظم أدوات إدارة ضبط الخوادم.

إطار عمل مؤتمت

توفر كل أداة إدارة ضبط CM صياغة محددة ومجموعة من الميزات التي يمكنك استخدامها لكتابة سكربتات الإعداد المسبق، إذ تحتوي معظم الأدوات على ميزات تجعل لغتها تشبه لغات البرمجة التقليدية ولكن بطريقة مبسطة، حيث تُعَد المتغيرات والحلقات والتعليمات الشرطية ميزات شائعة متوفرة لتسهيل إنشاء سكربتات إعداد مسبق أكثر تنوعًا.

السلوك الراسخ Idempotent Behavior

تتعقّب أدوات إدارة الضبط حالة الموارد لتجنب تكرار المهام التي جرى تنفيذها مسبقًا، فإذا ثُبِّتت الحزمة، فلن تحاول الأداة تثبيتها مرة أخرى. الهدف هو أن يصل النظام (أو يحتفظ) بالحالة المطلوبة بعد تشغيل كل إعداد مسبق حتى لو شغّلته عدة مرات. تتمتع هذه الأدوات بسلوك راسخ وهذا ما يميزها، ولكن لا يُفرَض هذا السلوك بالضرورة في جميع الحالات.

معلومات النظام

توفر أدوات إدارة الضبط معلومات مفصلة حول النظام المُعَد مسبقًا، وهذه البيانات متاحة من خلال المتغيرات العامة وتُعرَف باسم الحقائق Facts، والتي تشمل أشياءً مثل واجهات الشبكة وعناوين IP ونظام التشغيل والتوزيع. ستوفر كل أداة مجموعة مختلفة من الحقائق، ويمكن استخدامها لجعل سكربتات الإعداد المسبق والقوالب أكثر تكيفًا مع أنظمة متعددة.

نظام القوالب

توفر معظم أدوات إدارة الضبط CM نظام قوالب مبني مسبقًا يمكن استخدامه لتسهيل إعداد ملفات الضبط والخدمات، حيث تدعم القوالب عادةً المتغيرات والحلقات والتعليمات الشرطية التي يمكن استخدامها لتحقيق أقصى قدر من التنوع، فمثلًا يمكنك استخدام قالب لإعداد مضيف وهمي جديد بسهولة ضمن خادم أباتشي Apache مع إعادة استخدام القالب نفسه لعمليات تثبيت خوادم متعددة. يجب أن يحتوي القالب على عناصر بديلة للقيم التي يمكن أن تتغير من مضيف إلى آخر مثل NameServer و DocumentRoot بدلًا من وجود قيم ثابتة وساكنة فقط.

التوسع Extensibility

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

يمكن بسهولة العثور على الوحدات والإضافات التابعة لجهات خارجية على الإنترنت، وخاصة لإعدادات الخادم الشائعة مثل تثبيت خادم ويب PHP، إذ تميل أدوات إدارة الضبط CM إلى إنشاء مجتمع قوي حولها وتشجع المستخدمين على مشاركة توسّعاتها المخصصة. يمكن أن يوفر لك استخدام التوسّعات التي يوفرها المستخدمون الآخرون الكثير من الوقت، ويمثل طريقة ممتازة لتعلم كيفية حل المستخدمين الآخرين للمشاكل الشائعة باستخدام الأداة التي تختارها.

اختيار أداة إدارة الضبط

هناك العديد من أدوات إدارة الضبط CM المتاحة في السوق، ولكلٍ منها مجموعة مختلفة من الميزات ومستويات تعقيد مختلفة، ومن هذه الأدوات Chef و Ansible و Puppet. التحدي الأول هو اختيار أداة مناسبة لاحتياجاتك، فهناك بعض الأشياء التي يجب أن تأخذها في الحسبان قبل الاختيار وسنوضّحها فيما يلي.

تعقيد البنية التحتية

تتطلب معظم أدوات إدارة الضبط حدًا أدنى من التسلسل الهرمي يتكون من جهاز متحكِّم وعقدة سيديرها المتحكِّم، فمثلًا تتطلب أداة Puppet تثبيت تطبيق وكيل Agent على كل عقدة وتثبيت تطبيق رئيسي Master على جهاز المتحكِّم. بينما تتمتع أداة Ansible ببنية لامركزية لا تتطلب تثبيت برامج إضافية على العقد، ولكنها تعتمد على بروتوكول SSH لتنفيذ مهام الإعداد المسبق. يمكن أن تبدو البنية التحتية المبسطة مناسبة بصورة أفضل للمشاريع الأصغر، ولكن يجب مراعاة جوانب أخرى مثل قابلية التوسع والأمان، والتي يمكن ألّا تفرضها الأداة.

يمكن أن تحتوي بعض الأدوات على مزيدٍ من المكونات والأجزاء المتحركة، مما يزيد من تعقيد بنيتك التحتية، ويؤثر على مسار التعلم ويمكن أن يزيد من تكلفة التنفيذ الإجمالية.

مسار التعلم

توفر أدوات إدارة الضبط CM صياغة مخصصة، حيث تستخدم في بعض الأحيان لغة مجال محدَّد Domain Specific Language -أو DSL اختصارًا، ومجموعة من الميزات التي تشكل إطار عملها للأتمتة. تتطلب بعض الأدوات إتقان مسار تعليمي أعلى كما هو الحال مع لغات البرمجة التقليدية، ويمكن أن تؤثر متطلبات البنية التحتية على مدى تعقيد الأداة ومدى سرعة قدرتك على رؤية عائد استثمارك.

التكلفة

تقدم معظم أدوات إدارة الضبط CM إصدارات مجانية أو مفتوحة المصدر مع اشتراكات مدفوعة للحصول على ميزات وخدمات متقدمة، حيث تحتوي بعض الأدوات على قيود أكثر من غيرها، لذلك يمكن أن تدفع مقابل هذه الخدمات اعتمادًا على احتياجاتك الخاصة وكيفية نمو بنيتك التحتية.

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

الأدوات المتقدمة

تقدم معظم الأدوات خدمات مدفوعة يمكن أن تشمل الدعم والتوسّعات والأدوات المتقدمة كما ذكرنا سابقًا، لذا يجب أن تحلل احتياجاتك المحددة وحجم بنيتك التحتية وما إذا كانت هناك حاجة لاستخدام هذه الخدمات أم لا. تُعَد لوحات الإدارة مثلًا خدمة شائعة تقدمها هذه الأدوات، ويمكن أن تسهّل بصورة كبيرة عملية إدارة ومراقبة جميع خوادمك من نقطة مركزية، إذ يجب أن تفكر في خيارات الضرورة المستقبلية المحتمَلة حتى إن لم تكن بحاجة إلى مثل هذه الخدمات حاليًا.

المجتمع والدعم

يمكن أن يكون المجتمع القوي والمرحِّب موردًا مهمًا للدعم والتوثيق، حيث يكون المستخدمون سعيدين عادةً بمشاركة معرفتهم والتوسعات التي يجرونها (الوحدات والإضافات وسكربتات الإعداد المسبق) مع مستخدمين آخرين، مما يكون مفيدًا في تسريع مسار تعلمك وتجنب التكاليف الإضافية للدعم أو التدريب المدفوع.

نظرة عامة إلى أدوات إدارة الضبط الشائعة

يمنحك الجدول التالي نظرة عامة سريعة على الاختلافات الرئيسية بين ثلاث من أكثر أدوات إدارة الضبط شيوعًا المتوفرة في السوق اليوم وهي: Ansible و Puppet و Chef.

الخطوات التالية

رأينا حتى الآن كيفية عمل إدارة ضبط الخوادم، وما يجب مراعاته عند اختيار أداة لبناء بنية إدارة الضبط التحتية، وسنتعرّف في المقالات اللاحقة عمليًا على ثلاث أدوات شائعة لإدارة الضبط هي: Ansible و Puppet و Chef، حيث سنستخدم مثالًا بسيطًا لإعداد الخادم الذي يجب أن يكون مؤتمتًا بالكامل بواسطة كل أداة من هذه الأدوات لمنحك فرصة للموازنة بين هذه الأدوات بنفسك، إذ يتكون هذا الإعداد من خادم أوبنتو 18.04 يشغّل أباتشي Apache لاستضافة صفحة ويب بسيطة.

الخلاصة

يمكن لإدارة الضبط تحسين تكامل الخوادم بصورة كبيرة بمرور الوقت من خلال توفير إطار عمل لأتمتة العمليات وتتبع التغييرات التي أُجريت على بيئة النظام. سنرى في المقال التالي كيفية تطبيق استراتيجية إدارة الضبط عمليًا باستخدام أداة Ansible.

ترجمة -وبتصرُّف- للمقال An Introduction to Configuration Management لصاحبته Erika Heidi.

اقرأ أيضًا

• دليل إعداد خادم ويب محلي خطوة بخطوة
• مراقبة وإدارة عدة خوادم لينكس عبر واجهة متصفح مرئية باستخدام Cockpit

يُعَد نهج التكامل والتسليم والنشر المستمر -المعروف باسم CI/CD- جزءًا لا يتجزأ من التطوير الحديث الذي يهدف إلى تقليل الأخطاء أثناء التكامل والنشر مع زيادة سرعة إنجاز المشروع الرقمي، حيث يمثل هذا النهج فلسفة ومجموعة من الممارسات التي يعزّزها استخدام أدوات قوية تؤكد على الاختبار المؤتمت في كل مرحلة من مراحل خط إنتاج Pipeline البرمجيات، وبالتالي يمكنك من خلال دمج هذه الأفكار ضمن ممارساتك تقليلُ الوقت المطلوب لتكامل التغييرات لإصدارٍ ما واختبار كل تغيير بدقة قبل نقله إلى مرحلة الإنتاج.

اقتباس

يشير مصطلح CI إلى continuous integration أي التكامل المستمر، و CD إلى continuous delivery التسليم المستمر أو continuous deployment أي النشر المستمر.

يتمتع نهج CI/CD بالعديد من الفوائد، ولكن يتطلب التقديم الناجح لهذا النهج في أغلب الأحيان قدرًا كبيرًا من الأمور التي يجب أن تضعها في الحسبان، إذ يمكن أن يكون تحديد كيفية استخدام الأدوات والتغييرات التي قد تحتاجها في عملياتك أمرًا صعبًا بدون اتباع طريقة التجربة والخطأ، ولكن ستكون جميع عمليات التقديم مختلفة، لذا يمكن أن يساعدك الالتزام بأفضل الممارسات على تجنب المشاكل الشائعة والتحسن بصورة أسرع.

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

حافظ على سرعة خطوط الإنتاج

تساعد خطوط إنتاج CI/CD في الاهتمام بالتغييرات ابتداءً من دورات الاختبار المؤتمت ثم بيئات التحضير Staging Environments وأخيرًا مرحلة الإنتاج، فكلما كانت خطوط الإنتاج تشمل مرحلة الاختبار، زادت ثقتك في أن التغييرات لن تحدث آثارًا جانبية غير متوقعة في مرحلة النشر والتسليم، ولكن يجب أن يمر كل تغيير بهذه العملية، لذا يُعَد الحفاظ على خطوط إنتاجك سريعة وموثوقة أمرًا مهمًا للغاية.

يمكن أن يكون من الصعب الموازنة بين هذين المطلبين، فهناك بعض الخطوات المباشرة التي يمكنك اتخاذها لتحسين السرعة مثل توسيع بنية CI/CD التحتية وتحسين مرحلة الاختبارات، ولكن قد تضطر مع مرور الوقت إلى اتخاذ قرارات حاسمة بشأن القيمة النسبية للاختبارات المختلفة ومرحلة أو ترتيب إجرائها. لذا يُعَد تقليص مجموعة اختباراتك -من خلال إزالة الاختبارات ذات القيمة المنخفضة أو التي لا تدل على أمور جوهرية- أذكى طريقة في بعض الأحيان للحفاظ على السرعة التي تتطلبها خطوط الإنتاج المُستخدَمة بكثرة.

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

دورة إدارة تطوير المنتجات

احترف إدارة تطوير المنتجات الرقمية بدءًا من التخطيط وتحليل السوق وحتى إطلاق منتج مميز وناجح

اشترك الآن

عزل وتأمين بيئة منظومة CI/CD

تمثل منظومة CI/CD إحدى أكثر البنى التحتية أهمية التي يجب حمايتها من وجهة نظر الأمان التشغيلي، إذ يجب تأمينها بما أن لديها وصولًا كاملًا إلى شيفرتك البرمجية الأساسية وثبوتياتك لنشرها في بيئات مختلفة، ويجب عزلها وقفلها قدر الإمكان نظرًا لقيمتها العالية بوصفها هدفًا للمهاجمين.

يجب نشر أنظمة CI/CD على الشبكات الداخلية المحمية دون أن تكون مكشوفة لأطراف خارجية، لذلك يوصَى بإعداد شبكات VPN أو أي تقنية أخرى للتحكم في الوصول إلى الشبكة للتأكد من أن المشغّلين الموثقين فقط هم من يمكنهم الوصول إلى نظامك.

يمكن أن تحتاج منظومة CI/CD خاصتك إلى الوصول إلى عدة شبكات مختلفة لنشر الشيفرة البرمجية في بيئات مختلفة اعتمادًا على مدى تعقيد مخطط شبكتك، فإن لم تُؤمَّن أو تُعزَل بصورة صحيحة، فقد يتمكّن المهاجمون الذين يمكنهم الوصول إلى بيئة واحدة من استخدام تقنية قفز الجزيرة Island Hop -وهي تقنية تُستخدَم لتوسيع الوصول من خلال الاستفادة من قواعد الشبكات الداخلية الأكثر تساهلًا- للوصول إلى بيئات أخرى عبر نقاط ضعف خوادم CI/CD.

تعتمد استراتيجيات العزل والأمان المطلوبة بصورة كبيرة على مخطط الشبكة وبنيتها التحتية ومتطلبات الإدارة والتطوير. يجب أن تضع في بالك أن أنظمة CI/CD هي أهداف ذات قيمة عالية وتتمتع في كثير من الحالات بدرجة كبيرة من الوصول إلى أنظمتك الأساسية الأخرى، وبالتالي ستساعد حماية الوصول الخارجي إلى الخوادم والتحكم في أنواع الوصول الداخلي المسموح به في تقليل مخاطر تعرض منظومة CI/CD للخطر.

جعل خط إنتاج CI/CD الطريقة الوحيدة للنشر في بيئة الإنتاج

تساعد الأدوات في أغلب الأحيان في فرض أفضل الممارسات للاختبار والنشر، مما يمكّن منظومة CI/CD من تحسين ممارسات التطوير وجودة الشيفرة البرمجية، إذ تتطلب ترقية الشيفرة البرمجية عبر خطوط إنتاج CI/CD أن يثبت كل تغيير التزامه بالمعايير والإجراءات المُوثّقة الخاصة بمؤسستك. تظهر حالات الفشل في خط إنتاج CI/CD مباشرةً ويتوقف تقدم الإصدار المتأثر إلى مراحل لاحقة من الدورة، إذ تحمي هذه الآلية البيئات الأكثر أهمية من الشيفرة البرمجية غير الموثوق بها.

يمكن تحقيق هذه المزايا من خلال التأكد من أن كل تغيير في بيئة إنتاجك يمر عبر خط إنتاجك، إذ يجب أن يكون خط إنتاج CI/CD هو الآلية الوحيدة التي تدخل من خلالها الشيفرة البرمجية إلى بيئة الإنتاج. يمكن أن يحدث ذلك تلقائيًا في نهاية الاختبار الناجح مع ممارسات النشر المستمر، أو من خلال الترقية اليدوية للتغييرات المُختبَرة التي تعتمدها وتتيحها منظومة CI/CD.

تبدأ الفِرق باستمرار في استخدام خطوط إنتاجهم للنشر، ولكنها تجري استثناءات عند حدوث مشاكل مع وجود ضغط لحلها بسرعة. يجب التخفيف من وقت التوقف والمشاكل الأخرى في أسرع وقت ممكن، ولكن يجب أن نفهم أن منظومة CI/CD هي أداة جيدة لضمان ألّا تدخل تغييراتك أخطاءً أخرى أو تسبّب تعطل النظام.

سيؤدي وضع إصلاحٍ ما لشيفرتك عبر خط الإنتاج (أو استخدام منظومة CI/CD للتراجع) إلى منع نشر الإصدار التالي للتطبيق من إزالة الإصلاحات العاجلة التي طبقتها يدويًا على البيئة الإنتاجية، إذ يحمي خط الإنتاج صلاحية عمليات النشر بغض النظر عمّا إذا كان ذلك إصدارًا منتظمًا أو مخططًا له أو إصلاحًا سريعًا لحل مشكلة جارية. يُعَد هذا الاستخدام لمنظومة CI/CD سببًا آخر للعمل على إبقاء خط إنتاجك سريعًا. 

الحفاظ على التطابق مع البيئة الإنتاجية ما أمكن

ترفع خطوط إنتاج CI/CD التغييرات من خلال سلسلة من مجموعات الاختبار وبيئات النشر، إذ تُنشَر التغييرات التي تجتاز متطلبات مرحلةٍ تلقائيًا أو توضَع في طابور للنشر اليدوي في بيئات أكثر تقييدًا، حيث تهدف المراحل المبكرة إلى إثبات أنه من المفيد مواصلة الاختبار ودفع التغييرات لتصبح مناسبة للبيئة الإنتاجية.

يساعد أن تكون بيئة الاختبار مطابقة قدر الإمكان للبيئة الإنتاجية أن نضمن في المراحل اللاحقة أن تظهِر الاختبارات بدقة كيفية تصرّف التغيير في البيئة الإنتاجية. يمكن أن تسمح الاختلافات الكبيرة بين بيئة التحضير staging وبيئة الإنتاج production أن تظهر مشاكل لم يعثر عليها في مرحلة الاختبار، وكلما زادت الاختلافات بين بيئتك الإنتاجية وبيئة الاختبار، قلَّ قياس اختباراتك لكيفية أداء الشيفرة البرمجية عند إصدارها.

يُتوقَّع وجود بعض الاختلافات بين بيئتي التحضير والإنتاج، ولكن يجب إبقاؤها قابلة للإدارة والتأكد من فهمها جيدًا، إذ تستخدم بعض المؤسسات عمليات النشر الأزرق والأخضر Blue-green Deployments لمبادلة حركة مرور الإنتاج بين بيئتين متطابقتين تقريبًا تتناوبان بين كونهما بيئتي تحضير وإنتاج، وتضمنت الاستراتيجيات الأقل حِدةً نشر الضبط والبنية التحتية نفسها من الإنتاج إلى بيئة التحضير، ولكن على نطاق أقل. قد تختلف عناصرٌ مثل نقاط نهاية الشبكة بين بيئاتك، ولكن يمكن أن يساعد تحديد المعاملات لهذا النوع من البيانات المتغيرة في التأكد من أن الشيفرة البرمجية متناسقة وأن الاختلافات البيئية مُحدَّدة جيدًا.

البناء مرة واحدة فقط وترقية النتائج عبر خط الإنتاج

الهدف الأساسي لخط إنتاج التكامل المستمر والتسليم المستمر CI/CD هو بناء الثقة في تغييراتك وتقليل فرصة حدوث تأثير غير متوقع، حيث ناقشنا أهمية الحفاظ على التطابق بين البيئات، ولكن يجب ضمان مزيد من الاهتمام في جميع المكونات، فإن تطلّب برنامجك خطوة بناء أو حزمٍ أو تجميع، فيجب تنفيذ هذه الخطوة مرة واحدة فقط وإعادة استخدام الخرج الناتج على طول خط الإنتاج بأكمله.

يساعد هذا المقال في منع المشاكل التي تنشأ عند تصريف البرمجيات أو حزمها عدة مرات، مما يسمح بمنع تعارضات ضئيلة في المنتجات الثانوية الناتجة، إذ يمكن أن يعني بناء البرمجيات بصورة منفصلة في كل مرحلة جديدة أن الاختبارات في البيئات السابقة لم تستهدف البرمجيات نفسها الذي ستُنشَر لاحقًا، مما يؤدي إلى إبطال النتائج. يمكن تجنب هذه المشكلة من خلال أن تتضمن أنظمة CI عملية بناء بوصفها خطوة أولى في خط الإنتاج الذي ينشئ البرمجية ويحزمها في بيئة نظيفة، ويجب إصدار المنتج الثانوي الناتج وتحميله إلى نظام تخزين المنتجات الثانوية لتسحبها المراحل اللاحقة من خط الإنتاج، مما يضمن عدم تغيير البناء أثناء تقدمه عبر النظام.

إجراء أسرع الاختبارات في وقت مبكر

يُعَد إبقاء خط الإنتاج سريعًا بالكامل هدفًا عامًا ورائعًا، ولكن ستكون أجزاءٌ من مجموعة اختبارك حتمًا أسرع من غيرها. تعمل منظومة CI/CD بوصفها ممرًا لجميع التغييرات التي تدخل نظامك، لذا يُعَد اكتشاف حالات الفشل في أقرب وقت ممكن أمرًا مهمًا لتقليل الموارد المُخصَّصة لعمليات البناء التي تسبب مشاكلًا، ويمكن تحقيق ذلك من خلال تحديد أولويات الاختبارات الأسرع وإجرائها أولًا. احفظ الاختبارات المعقدة التي تستغرق وقتًا طويلًا حتى بعد التحقق من صحة البناء باستخدام اختبارات صغيرة سريعة التشغيل.

تحتوي هذه الإستراتيجية على عدد من الفوائد التي يمكن أن تساعد في الحفاظ على صحة عملية CI/CD، وتشجعك على فهم تأثير أداء الاختبارات الفردية، وتسمح لك بإكمال معظم اختباراتك مبكرًا، وتزيد من احتمالية الفشل السريع، مما يعني أنه يمكن التراجع عن التغييرات التي تسبب مشاكلًا أو إصلاحها قبل وقف عمل أعضاء الفريق الآخرين.

يعني تحديدُ أولويات الاختبار تشغيلَ اختبارات الوحدة لمشروعك أولًا، لأن هذه الاختبارات تميل إلى أن تكون سريعة ومعزولة وتركز على المكونات، وتمثّل اختبارات التكامل بعد ذلك المستوى التالي من التعقيد والسرعة، وتليها اختبارات على مستوى النظام، وأخيرًا اختبارات القبول التي تتطلب غالبًا مستوًى معينًا من التفاعل البشري.

تقليل التفريع في نظام التحكم في الإصدارات

يتمثل أحد المبادئ الرئيسية لمنظومة CI/CD في دمج التغييرات في المستودع المشترك الأساسي مبكرًا وفي مرات متعددة، مما يساعد في تجنب مشاكل التكامل المتعبة باستمرار عندما يحاول العديد من المطورين دمج تغييرات كبيرة ومتباينة ومتضاربة في الفرع الرئيسي للمستودع استعدادًا للنشر، إذ تُضبَط أنظمة CI/CD لمراقبة واختبار التغييرات الملتزمة بفرع واحد فقط أو عدة فروع.

يمكن الاستفادة من المزايا التي يوفرها التكامل المستمر CI من خلال تحديد عدد الفروع ونطاقها في مستودعك، حيث تشير معظم التطبيقات إلى أن المطورين يلتزمون مباشرة بالفرع الرئيسي main أو master أو يدمجون التغييرات من الفروع المحلية مرةً واحدةً على الأقل يوميًا.

تحتوي الفروع التي لا تتعقّبها منظومة CI/CD على شيفرة برمجية غير مُختبَرة بغض النظر عن أهميتها أو وظيفتها، حيث يساعد التقليل من التفريع لتشجيع التكامل المبكر بين شيفرات المطورين المختلفة على الاستفادة من نقاط القوة في النظام، ويمنع المطورين من إبطال المزايا التي يوفرها.

إجراء الاختبارات محليًا قبل الالتزام بخط إنتاج CI/CD

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

يمكن التأكد من أن المطورين يمكنهم الاختبار بفعالية من تلقاء أنفسهم من خلال أن تكون مجموعة اختباراتك قابلة للتشغيل باستخدام أمر واحد يمكن تشغيله من أيّ بيئة، إذ يجب أن تستخدم منظومة CI/CD الأمر نفسه الذي يستخدمه المطورون على أجهزتهم المحلية لبدء الاختبارات على الشيفرة البرمجية المضافة في المستودع، ويمكن تنسيق ذلك في أغلب الأحيان من خلال توفير سكربت bash أو أداة makefile لأتمتة تشغيل أدوات الاختبار بطريقة تكرارية ويمكن التنبؤ بها.

إجراء الاختبارات في بيئات مؤقتة عندما يكون ذلك ممكنًا

يكون من الجيد في أغلب الأحيان استخدام بيئات اختبار نظيفة ومؤقتة عندما يكون ذلك ممكنًا للمساعدة في ضمان إجراء الاختبارات بالطريقة نفسها في مراحل مختلفة، وهذا يعني تشغيل الاختبارات ضمن حاويات Containers لتجريد الاختلافات بين الأنظمة المضيفة ولتوفير واجهة برمجة تطبيقات معيارية لربط المكونات مع بعضها البعض بمقاييس مختلفة. تعمل الحاويات بأدنى قد من المعلومات المُحتفظة minimal state لذا لا تطّلع عمليات التشغيل اللاحقة لمجموعة الاختبارات على الآثارَ الجانبية أو حالات الاختبارات المحفوظة التي يمكن أن تؤدي إلى إفساد النتائج.

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

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

الخلاصة

سيكون كل تقديم لمنظومة CI/CD مختلفًا عن الآخر، ولكن سيساعدك اتباع بعض المبادئ الأساسية التي وضّحناها في هذا المقال على تجنب بعض العقبات الشائعة وتعزيز ممارسات الاختبار والتطوير، وسيساعد مزيج من العملية والأدوات والعادات في جعل تغييرات التطوير أكثر نجاحًا وتأثيرًا كما هو الحال مع معظم جوانب منهج التكامل المستمر والتسليم المستمر.

ترجمة -وبتصرُّف- للمقال An Introduction to CI/CD Best Practices لصاحبه Justin Ellingwood.

اقرأ أيضًا

• استخدام GitHub Actions لتحقيق التكامل المستمر والنشر المستمر
• التوسع أكثر في نهج التكامل والتسليم المستمر
• إعداد التكامل المستمر والنشر المستمر باستخدام الخدمتين CircleCI وCoveralls

تعلّمنا في المقال السابق دعم إطار عمل Svelte للغة TypeScript وكيفية استخدام ذلك لجعل تطبيقك أقوى، كما سنتعرّف في هذا المقال على كيفية نشر تطبيقك عبر الإنترنت ومشاركة بعض موارد التعلم التي يجب الانتقال إليها لمواصلة رحلة التعلّم في إطار عمل Svelte.

• المتطلبات الأساسية: يوصَى على الأقل بأن تكون على دراية بأساسيات لغات HTML وCSS وجافاسكربت JavaScript، ومعرفة باستخدام سطر الأوامر أو الطرفية، وستحتاج طرفية مثبَّت عليها node وnpm لتصريف وبناء تطبيقك.
• الهدف: التعرّف على كيفية تحضير تطبيق Svelte لعملية الإنتاج والموارد التعليمية التي يجب الاطلاع عليها بعد ذلك.

يمكن متابعة كتابة شيفرتك معنا، لذلك انسخ أولًا مستودع github -إذا لم تفعل ذلك مسبقًا- باستخدام الأمر التالي:

git clone https://github.com/opensas/mdn-svelte-tutorial.git

ثم يمكنك الوصول إلى حالة التطبيق الحالية من خلال تشغيل الأمر التالي:

cd mdn-svelte-tutorial/08-next-steps

أو يمكنك تنزيل محتوى المجلد مباشرةً كما يلي:

npx degit opensas/mdn-svelte-tutorial/08-next-steps

تذكَّر تشغيل الأمر npm install && npm run dev لبدء تشغيل تطبيقك في وضع التطوير.

تصريف التطبيق

شغّلنا حتى الآن تطبيقنا في وضع التطوير باستخدام الأمر npm run dev الذي يخبر إطار عمل Svelte بتجميع المكونات وملفات جافاسكربت في الملف public/build/bundle.js وجميع أقسام CSS الخاصة بالمكونات في الملف public/build/bundle.css، كما يشغّل خادم التطوير ويراقب التغييرات ويعيد تصريف التطبيق وتحديث الصفحة عند حدوث تغيير.

سيكون الملفان bundle.js و bundle.css كما يلي (لاحظ وجود حجم الملف على اليسار):

 504 Jul 13 02:43 bundle.css
95981 Jul 13 02:43 bundle.js

يمكن تصريف التطبيق للإنتاج من خلال تشغيل الأمر npm run build، إذ لن يشغّل إطار عمل Svelte خادم ويب أو يستمر في مراقبة التغييرات في هذه الحالة، ولكن سيصغّر ويضغط ملفات جافاسكربت باستخدام الأداة terser.

سيكون الملفان bundle.js و bundle.css كما يلي بعد تشغيل الأمر npm run build:

 504 Jul 13 02:43 bundle.css
21782 Jul 13 02:43 bundle.js

جرّب تشغيل الأمر npm run build في المجلد الجذر لتطبيقك الآن، كما يمكن أن تتلقى تحذيرًا، لكن يمكنك تجاهله حاليًا.

يبلغ حجم تطبيقنا بالكامل الآن 21 كيلوبايت و8.3 كيلوبايت عند ضغطه بتنسيق gzip، كما لا توجد أوقات تشغيل أو اعتماديات إضافية لتنزيلها وتحليلها وتنفيذها والاستمرار في عملها في الذاكرة، إذ حلّل إطار عمل Svelte المكونات وصرّف الشيفرة البرمجية إلى لغة جافاسكربت الصرفة Vanilla JavaScript.

عملية التصريف في إطار Svelte

سيستخدِم إطار عمل Svelte الأداة rollup بوصفها أداة تحزيم للوحدات افتراضيًا عندما تنشئ تطبيقًا جديدًا باستخدام الأمر الآتي:

 npx degit sveltejs/template my-svelte-project

ملاحظة: يوجد قالب رسمي لاستخدام Webpack والعديد من الإضافات التي يديرها المجتمع لأدوات التحزيم الأخرى.

يمكنك أن ترى في الملف package.json أنّ السكربتات dev وstart تستدعي أداة التحزيم Rollup:

"scripts": {
  "build": "rollup -c",
  "dev": "rollup -c -w",
  "start": "sirv public"
},

نمرّر في السكربت dev الوسيط ‎-w الذي يخبر أداة Rollup بمراقبة الملفات وإعادة البناء عند إجراء التغييرات، فإذا ألقينا نظرةً على الملف rollup.config.js، فيمكننا رؤية أنّ مصرِّف Svelte هو مجرد إضافة من Rollup:

import svelte from 'rollup-plugin-svelte';
// …
import { terser } from 'rollup-plugin-terser';

const production = !process.env.ROLLUP_WATCH;

export default {
  input: 'src/main.js',
  output: {
    sourcemap: true,
    format: 'iife',
    name: 'app',
    file: 'public/build/bundle.js'
  },
  plugins: [
    svelte({
      // تفعيل عمليات فحص وقت التشغيل عندما لا تكون في وضع الإنتاج
      dev: !production,
      // ‫سنستخرج أيّ مكون CSS في ملف منفصل، وهذا أفضل للأداء
      css: css => {
        css.write('public/build/bundle.css');
      }
    }),

سترى لاحقًا في الملف نفسه كيف تقلل أداة Rollup من حجم السكربتات في وضع الإنتاج وتطلق خادمًا محليًا في وضع التطوير:

   // ‫استدعِ الأمر "npm run start" في وضع التطوير بمجرد إنشاء الحزمة
    !production && serve(),

    // راقب المجلد‫ public وحدّث المتصفح عند حدوث تغييرات عندما لا تكون في وضع الإنتاج
    !production && livereload('public'),

    // ‫إذا أردت البناء للإنتاج (أي استخدمت npm run build بدلًا من npm run dev)، فطبّق عملية التصغير
    production && terser()
  ],

هناك العديد من إضافات Rollup التي تتيح لك تخصيص سلوكها، ومنها الإضافة svelte-preprocess التي يهتم بها فريق Svelte، حيث تعالج هذه الإضافة مسبقًا العديد من اللغات المختلفة في ملفات Svelte مثل PostCSS و SCSS و Less و CoffeeScript و SASS و TypeScript.

نشر تطبيق Svelte

لا يُعَدّ تطبيق Svelte من وجهة نظر خادم الويب أكثر من مجموعة من ملفات HTML و CSS و JavaScript، فكل ما تحتاجه هو خادم ويب قادر على تقديم ملفات ثابتة أو ساكنة، مما يعني أنه لديك الكثير من الخيارات للاختيار من بينها، إذًا لنلقِ نظرةً على بعض منها.

ملاحظة: يمكن تطبيق القسم التالي على أيّ موقع ويب ساكن من جانب العميل يتطلب خطوة بناء، وليس فقط على تطبيقات Svelte.

النشر باستخدام Vercel

يُعَدّ استخدام Vercel من أسهل الطرق لنشر تطبيق Svelte، ويُعَدّ Vercel منصةً سحابيةً مصمَّمةً خصيصًا للمواقع الساكنة، وتتمتع بدعم معظم أدوات الواجهة الأمامية الشائعة مثل إطار عمل Svelte.

اتبع الخطوات التالية لنشر تطبيقك:

1. سجّل للحصول على حساب Vercel.
2. انتقل إلى جذر تطبيقك وشغّل الأمر npx vercel، إذسيُطلَب منك في المرة الأولى إدخال عنوان بريدك الإلكتروني واتباع الخطوات الواردة في البريد الإلكتروني المرسل إلى هذا العنوان لأغراض أمنية.
3. شغّل الأمر npx vercel مرةً أخرى، وسيُطلَب منك الإجابة على بعض الأسئلة كما يلي:

> npx vercel
Vercel CLI 19.1.2
? Set up and deploy "./mdn-svelte-tutorial"? [Y/n] y
? Which scope do you want to deploy to? opensas
? Link to existing project? [y/N] n
? What's your project's name? mdn-svelte-tutorial
? In which directory is your code located? ./
Auto-detected Project Settings (Svelte):
- Build Command: `npm run build` or `rollup -c`
- Output Directory: public
- Development Command: sirv public --single --dev --port $PORT
? Want to override the settings? [y/N] n
   Linked to opensas/mdn-svelte-tutorial (created .vercel)
   Inspect: https://vercel.com/opensas/mdn-svelte-tutorial/[...] [1s]
✅  Production: https://mdn-svelte-tutorial.vercel.app [copied to clipboard] [19s]
   Deployed to production. Run `vercel --prod` to overwrite later (https://vercel.link/2F).
   To change the domain or build command, go to https://zeit.co/opensas/mdn-svelte-tutorial/settings

4. اقبل جميع الإعدادات الافتراضية وسيكون كل شيء على ما يرام.
5. انتقل إلى عنوان "Production" في متصفحك بمجرد الانتهاء من النشر، وسترى تطبيقك منشورًا.

كما يمكنك استيراد مشروع Svelte git إلى Vercel من GitHub أو GitLab أو BitBucket.

ملاحظة: يمكنك تثبيت Vercel بطريقة عامة باستخدام الأمر npm i -g vercel حتى لا تضطر إلى استخدام npx لتشغيله.

النشر التلقائي على صفحات GitLab Pages

يمكن استضافة الملفات الساكنة من خلال استخدام خدمات عبر الإنترنت تسمح لك بنشر موقعك تلقائيًا عندما ترفع التغييرات إلى مستودع git، وتتضمن معظم هذه الخدمات إنشاء خط أنابيب نشر يُشغَّل في كل عملية git push، كما تهتم ببناء موقع الويب ونشره.

سننشر فيما يلي تطبيق قائمة المهام على GitLab Pages:

يجب أولًا التسجيل في GitLab ثم إنشاء مشروع جديد، وسَمّ مشروعك الجديد باسم قصير وسهل مثل mdn-svelte-todo، إذ سيكون لديك عنوان url يشير إلى مستودع GitLab git الجديد مثل

 git@gitlab.com:[your-user]/[your-project].git

ثانيًا، يُفضَّل إضافة ملف ‎.gitignore لإخبار جيت git بالملفات التي يجب استبعادها من عملية التحكم بالمصدر قبل البدءأ برفع المحتوى إلى مستودع git، إذ سنخبر git في حالتنا باستبعاد الملفات الموجودة في المجلد node_modules من خلال إنشاء ملف ‎.gitignore في المجلد الجذر لمشروعك المحلي الذي يحتوي على ما يلي:

node_modules/

ثالثًا، لنعد الآن إلى GitLab، إذ سيرحب GitLab بك برسالة تشرح الخيارات المختلفة لرفع ملفاتك الموجودة مسبقًا بعد إنشاء مستودع جديد، لذا اتبع الخطوات المدرجة ضمن عنوان رفع مجلد موجود مسبقًا Push an existing folder:

cd your_root_directory # انتقل إلى المجلد الجذر لمشروعك
git init
git remote add origin https://gitlab.com/[your-user]/mdn-svelte-todo.git
git add .
git commit -m "Initial commit"
git push -u origin main

ملاحظة: يمكنك استخدام بروتوكول git بدلًا من بروتوكول https الذي يُعَدّ أسرع ولا يجعلك تكتب اسم المستخدِم وكلمة المرور في كل مرة تدخل فيها إلى مستودعك الأصلي، لكن يجب إنشاء زوج مفاتيح SSH لاستخدامه، وسيكون عنوان URL الأصلي كما يلي:

git@gitlab.com:[your-user]/mdn-svelte-todo.git

هيّأنا مستودع git محلي عبر التعليمات السابقة، ثم ضبطنا الأصل البعيد حيث سنرفع شيفرتنا ليكون مستودعنا على GitLab، ثم يجب وضع جميع الملفات في مستودع git المحلي وبعد ذلك نرفعها إلى الأصل البعيد على GitLab.

يستخدِم GitLab أداةً مبنيةً مسبقًا تسمى GitLab CI/CD لبناء موقعك ونشره على خادم GitLab Pages، إذ يُنشَأ تسلسل السكربتات الذي تشغّله الأداة GitLab CI/CD لإنجاز هذه المهمة من ملف يُدعى ‎.gitlab-ci.yml الذي يمكنك إنشاؤه وتعديله حسب الرغبة، كما ستجعل وظيفة معينة تسمى pages في ملف الإعداد GitLab على دراية بأنك تنشر موقع GitLab Pages.

لنجرب ذلك:

أولًا، أنشئ الملف ‎.gitlab-ci.yml ضمن جذر مشروعك وضَع فيه المحتوى التالي:

image: node:latest
pages:
  stage: deploy
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - public
  only:
    - main

طلبنا من GitLab استخدام صورة مع أحدث إصدار من Node لبناء تطبيقنا، ثم صرّحنا عن الوظيفة pages، لتفعيل GitLab Pages، وكلما كان هناك عملية رفع إلى المستودع، فسيشغّل GitLab الأمرين npm install و npm run build لبناء تطبيقنا، كما نطلب من GitLab نشر محتويات المجلد public، ونُعِد GitLab في السطر الأخير لإعادة نشر تطبيقنا فقط عندما يكون هناك عملية رفع إلى الفرع الرئيسي.

ثانيًا، يجب إنشاء مراجع لملفات جافاسكربت وCSS في الملف ذي المسار النسبي public/index.html، بما أنّ تطبيقنا سيُنشَر في مجلد فرعي مثل الآتي:

 https://your-user.gitlab.io/mdn-svelte-todo

ويمكن ذلك من خلال إزالة الشرطات المائلة / من العناوين:

• ‎/global.css
• ‎/build/bundle.css
• ‎/build/bundle.js

كما يلي:

<title>Svelte To-Do list</title>

<link rel='icon' type='image/png' href='favicon.png'>
<link rel='stylesheet' href='global.css'>
<link rel='stylesheet' href='build/bundle.css'>

<script defer src='build/bundle.js'></script>

ثالثًا، يجب الآن فقط رفع التغييرات إلى GitLab من خلال تشغيل الأوامر التالية:

> git add public/index.html
> git add .gitlab-ci.yml
> git commit -m "Added .gitlab-ci.yml file and fixed index.html absolute paths"
> git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 541 bytes | 541.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0)
To gitlab.com:opensas/mdn-svelte-todo.git
   7dac9f3..5725f46  main -> main

سيعرض GitLab رمزًا يوضح تقدّم هذه الوظيفة كلما كانت هناك وظيفة تعمل، كما سيسمح لك النقر عليه بفحص الخرج.

كما يمكنك التحقق من تقدم الوظائف الحالية والسابقة من قائمة "CI / CD" ثم الخيار "Jobs" الخاص بمشروع GitLab.

سيكون تطبيقك متاحًا على https://your-user.gitlab.io/mdn-svelte-todo/‎ بمجرد انتهاء GitLab من بناء ونشر تطبيقك، ويكون في حالتنا https://opensas.gitlab.io/mdn-svelte-todo/‎، كما يمكنك التحقق من عنوان URL لصفحتك في واجهة مستخدِم GitLab من قائمة Settings ثم الخيار "Pages".

سيُعاد بناء التطبيق تلقائيًا ونشره في GitLab Pages كلما رفعت تغييرات إلى مستودع GitLab باستخدام هذا الإعداد.

موارد إضافية لتعلم إطار عمل Svelte

سنمنحك الآن بعض الموارد والمشاريع للتحقق منها ومواصلة مشوار تعلّمك إطار عمل Svelte.

توثيق Svelte

يجب عليك بالتأكيد زيارة الصفحة الرئيسية لإطار Svelte حيث ستجد العديد من المقالات التي تشرحه، فإذا لم تفعل ذلك سابقًا، فاطّلع على برنامج Svelte التعليمي التفاعلي، وقد غطينا فعليًا معظم محتوياته في هذه السلسلة من المقالات، لذا لن يستغرق الأمر وقتًا طويلًا لإكماله، ويمكنك الرجوع إلى توثيق Svelte API والأمثلة المتاحة.

مشاريع ذات صلة

هناك مشاريع أخرى متعلقة بإطار عمل Svelte تستحق المراجعة ومنها:

• Sapper: إطار تطبيق مدعوم من Svelte يوفِّر التصيير من جانب الخادم SSR وتقسيم الشيفرة البرمجية والتوجيه المستند إلى الملفات والدعم دون اتصال والمزيد، كما يُعَدّ بمثابة Next.js لإطار عمل Svelte، فإذا أردت تطوير تطبيق ويب معقد إلى حد ما، فيجب عليك بالتأكيد إلقاء نظرة على هذا المشروع.
• Svelte Native: إطار عمل تطبيقات الهاتف المحمول مدعوم من Svelte، ويُعَدّ بمثابة React Native لإطار عمل Svelte.
• Svelte for VS Code: إضافة VS Code المدعوم رسميًا للعمل مع ملفات ‎.svelte.

الخلاصة

تهانينا، فقد أكملت سلسلة مقالات تعلم إطار عمل Svelte، حيث انتقلنا من مرحلة عدم المعرفة بإطار Svelte إلى إنشاء تطبيق كامل ونشره.

• تعلمنا مفهوم Svelte وما يميزه عن أطر عمل الواجهة الأمامية الأخرى.
• رأينا كيفية إضافة سلوك ديناميكي إلى موقع الويب، وكيفية تنظيم تطبيقنا في مكونات وطرق مختلفة لمشاركة المعلومات فيما بينها.
• استفدنا من نظام Svelte التفاعلي وتعلمنا كيفية تجنب الأخطاء الشائعة.
• رأينا بعض المفاهيم والتقنيات المتقدمة للتفاعل مع عناصر DOM ولتوسيع إمكانيات عناصر HTML برمجيًا باستخدام الموجّه use.
• رأينا بعد ذلك كيفية استخدام المخازن للعمل مع مستودع بيانات مركزي، وأنشأنا مخزننا المُخصَّص لاستمرار بيانات تطبيقنا في تخزين الويب.
• كما ألقينا نظرةً على دعم Svelte للغة TypeScript.

تعلمنا في هذا المقال خيارين من الخيارات لنشر تطبيقنا في عملية الإنتاج ورأينا كيفية إعداد خط أنابيب أساسي لنشر تطبيقنا على GitLab عند كل تغيير ثم قدمنا قائمةً بموارد Svelte للمضي قدمًا في تعلم Svelte.

يجب أن تكون لديك قاعدة قوية يمكنك من خلالها البدء في تطوير تطبيقات ويب احترافية باستخدام إطار عمل Svelte بعد الانتهاء من هذه السلسلة من المقالات.

ترجمة -وبتصرُّف- للمقال Deployment and next steps.

اقرأ أيضًا

• تقسيم تطبيق Svelte إلى مكونات
• إنشاء تطبيق قائمة مهام باستعمال إطار عمل Svelte
• بدء استخدام إطار العمل Svelte لبناء تطبيقات ويب
• التفاعلية ودورة الحياة وسهولة وصول المستخدمين في إطار عمل Svelte

تطبيق الويب Jitsi Meet هو تطبيق اجتماعات مرئية مفتوح المصدر يمكن استضافته محليًا، ويعتبر بديلًا جيدًا عن الخدمات الأخرى مثل Google Meet أو Zoom، حيث يمكن ربط Jitsi Meet مع أدوات أخرى مفتوحة المصدر مثل Nextcloud أو Rocket.Chat أو ‎Synapse (Matrix implementation)‎ التي تتكامل مع بعضها لتوفير حل شامل، يمكن أيضًا استخدام Jitsi Meet مجانًا على خوادمهم لكن بمزايا محدودة، وللمزايا الإضافية يمكن الانضمام إلى Jitsi كخدمة المقدم من مطوري Jitsi، يمكن بدلًا من ذلك استضافة البرنامج على خادم خاص محلي، حيث من السهل نشر برنامج Jitsi، سنعرض تلك الخطوات ونشرحها ونشرح طريقة استضافته خلف وكيل عكسي وبدون ذلك.

المستلزمات

يجب القيام ببعض التحضيرات قبل البدء، حيث يفضل امتلاك معرفة مبدئية عن دوكر والحاويات، وامتلاك اسم نطاق خاص، حيث أن عملية الوصول لخادم التطبيق في هذا المقال لن تكون اعتمادًا على عنوان IP، بل سنشرح خطوات النشر باستخدام اسم نطاق حقيقي أو اسم نطاق فرعي مع تفعيل بروتوكول الاتصال الآمن HTTPS، ويمكن خلال مرحلة الاختبار الوصول للتطبيق عبر مسار بالبنية:

HTTP://[some IP]:[some port]‎

أيضًا امتلاك خادم لينكس حقيقي أو مُستضاف ضمن السحابة، حيث يمكن استخدام خادم لينكس على عدة استضافات مثل Linode أو DigitalOcean أو Vultr أو UpCloud، بينما استخدام AWS يمكن أن يعتمد بشكل كبير على النظام الأساسي لذا لن نتحدث عنه، حيث تنصح التوصيات الرسمية للبرنامج بتوفر ذاكرة للخادم بحجم 4 جيجابايت ومعالج ثنائي النوى لخدمة بين 10 و 20 مستخدم.

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

تعديل سجلات DNS

لا يكفي شراء وامتلاء اسم نطاق، يجب التأكد من إدراج سجلات DNS له أيضًا، سنستعمل ضمن هذا المقال اسم النطاق التالي "openexperiment.in"، وتأكد عند اتباعك للخطوات ضمن هذا المقال من تبديل اسم النطاق إلى اسم النطاق الخاص بك، حيث بعد امتلاك اسم النطاق ونشر الخادم (خادم فقط من دون برنامج Jitsi)، يجب جلب عناوين IP للخادم (كل من عنواني IPv4 و IPv6) ونضيف سجلات من النوع A و AAAA لكل منها على الترتيب، وبعد الانتهاء من ذلك يجب إضافة سجل من النوع CNAME، يمكن إضافة نطاق فرعي محدد، أو تعيين ذلك بمحرف بدل في حال كنا سنستضيف البرنامج على النطاق الأساسي.

الصورة التالية توضح ما ذكرناه، قمنا بتغطية عناوين IP بما أنها خاصة بالخادم الذي جهزناه لهذا المثال ويجب تعيين عناوين IP الخاصة بالخادم الخاص بك.

قد تحتاج للانتظار قليلًا ليتم تطبيق التغييرات ضمن DNS، يمكن استخدام الأمر ping للتأكد من تطبيق التغييرات، عبر تنفيذ الأمر ping على اسم النطاق إلى أن نحصل ضمن الخرج على عنوان IP الخاص بالخادم كالتالي (أيضًا أخفينا العنوان الحقيقي واستبدلناه بمحارف x):

❯ ping openexperiment.in -4
PING openexperiment.in (xxx.xxx.xxx.xxx) 56(84) bytes of data.
^C64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=55 time=36.6 ms

--- openexperiment.in ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 36.610/36.610/36.610/0.000 ms

يمكن أيضًا استخدام الأمر dig للتحقق من سجلات DNS كالتالي:

dig openexperiment.in +nocmd +nocomments

ليظهر لنا خرج مشابه للتالي:

❯ dig openexperiment.in +nocmd +nocomments
;openexperiment.in.   IN  A
openexperiment.in.  2970  IN  A xxx.xxx.xxx.xxx
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Mar 07 11:38:20 IST 2021
;; MSG SIZE  rcvd: 62

فهم مكونات Jitsi Meet

من المفيد فهم مكونات البرنامج ودورها وأهميتها إلى جانب المكونات التي سنستخدمها لنشر التطبيق، يمكنك تجاوز هذه الفقرة إلى فقرة النشر إذا أردت:

• jitsi/web:latest : وهي واجهة الويب لبرنامج Jitsi Meet التي تستخدمها عبر المتصفح، وهي مرفقة داخل الصورة، مع خادم ويب Nginx.
• jitsi/prosody:latest : وهو خادم XMPP المسؤول عن الاتصالات المرئية أو الصوتية أو المحادثات النصية، وهو يعتبر أساس Jitsi.
• jitsi/jicofo:latest : وهو مكون من خادم XMPP مسؤول عن إدارة جلسات الفيديو بين المشاركين وجسر الفيديو، بمعنى آخر هو من يدير الاجتماع، وهو عنصر آخر ضروري من Jitsi.
• jitsi/jvb:latest : مكون جسر فيديو Jitsi مسؤول عن نقل قنوات الفيديو القادمة إلى كل المشاركين.

هذه هي المكونات الضرورية لعمل نسخة Jitsi المنشورة وهي فقط ما سنستخدمه ضمن هذا المقال، يوجد مكونات أخرى مثل Jibri و Jigasi ولكنها اختيارية ولن نتطرق إليها، إذا كنت تنوي نشر البرنامج خلف وكيل عكسي تأكد من إعداده أولًا قبل تنفيذ الخطوات التالية.

استنساخ مستودع docker-jitsi-meet

يحوي المستودع على كل الملفات التي سنحتاجها للنشر مع بعض التعديلات عليها، نستنسخ المستودع ونغير المسار الحالي إلى مسار مجلد المستودع كالتالي:

git clone https://github.com/jitsi/docker-jitsi-meet jitsi
cd jitsi

تعديل متغيرات البيئة

بما أننا نستخدم دوكر يجب تغيير بعض متغيرات البيئة، نستخدم نسخة ملف المثال لمتغيرات البيئة env.example المرفق داخل المستودع كقالب عبر تنفيذ الأمر:

cp env.example .env

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

./gen-passwords.sh

بعد إنهاء تنفيذه نلاحظ أنه تم ملئ النصوص السرية ضمن ملف ‎.env، ولن نحتاج كل تلك النصوص السرية لعملية النشر التي نقوم بها ويمكننا تركها دون حذف أو تعليق.

سنشرح الآن ثلاثة أقسام فرعية لإتمام عملية النشر، الأول لتعيين المتغيرات المشتركة لكلا طريقتي النشر مع وكيل عكسي وبدونه، والثاني للوكيل العكسي، والأخير للطريقة من دون استخدام الوكيل العكسي، كل تلك المتغيرات سيتم تعديلها ضمن الملف ‎.env .

المتغيرات المشتركة لكل من طريقة الوكيل العكسي وبدونه

المتغيرات التالية هي المشتركة بين طريقتي النشر، ونضيفها ضمن ملف ‎.env:

• CONFIG: يمكننا تغيير قيمة هذا المتغير لكنها غير ضرورية، قيمته تعبر عن مجلد ضمن المضيف سيتم ربطه وتركيبه ضمن الحاويات لتخزين البيانات داخله، يمكنك تغيير القيمة حسب ما تريد.
• PUBLIC_URL: اسم النطاق الذي سيتم استضافة Jitsi ضمنه مع البروتوكول، في مثالنا تكون قيمة هذا المتغير هي https://meet.openexperiment.in
• ENABLE_AUTH: في حال أردنا تفعيل الاستيثاق، فيجب على المستخدم إدخال اسم المستخدم وكلمة السر الخاصة بحسابه المسجل قبل أن يتمكن من الانضمام أو إنشاء اجتماع، إذا أردت تفعيل تلك الميزة يمكنك إلغاء تعليق هذا السطر وتعيين قيمته إلى 1.
• AUTH_TYPE: إذا عينت قيمة المتغير ENABLE_AUTH إلى 1، فيجب تعيين قيمة هذا المتغير إلى internal، يمكن أيضًا الاستيثاق عبر LDAP أو JWT ولكن لن نتطرق إليهما في هذا المقال.
• RESTART_POLICY: سياسة إعادة تشغيل الحاويات، حيث أن القيمة الافتراضية لها هي unless-stopped، ويفضل تغييرها إلى always أو on-failure.
• TZ: المنطقة الزمنية للنظام، إذا كان الخادم يعمل على المنطقة الزمنية UTC فلا داعي لتغيير هذه القيمة.

متغيرات طريقة النشر بدون الوكيل العكسي

إذا لم تكن تستخدم وكيل عكسي يجب إضافة المتغيرات التالية إلى ملف env.:

• HTTP_PORT, HTTPS_PORT: عين تلك القيم إلى 80 و 443 بالترتيب، وهي المنافذ التي ستُربط مع الحاوية.
• ENABLE_LETSENCRYPT: عين قيمتها إلى 1 في حال أردت تفعيل HTTPS.
• LETSENCRYPT_DOMAIN و LETSENCRYPT_EMAIL: اسم النطاق الذي ستستضاف عليه النسخة وعنوان البريد لإرسال إشعارات متعلقة بشهادة الحماية.
• ENABLE_HTTP_REDIRECT: عند تعيين قيمتها إلى 1 سيتم إعادة توجيه طلبات HTTP إلى HTTPS.
• ENABLE_HSTS: عند تعيين قيمتها إلى 1 سيتم إجبار المتصفح على استخدام اتصالات موثوقة فقط.

متغيرات مطلوبة للوكيل العكسي

إذا كنت ستستخدم وكيل عكسي يجب إضافة المتغيرات التالية إلى ملف env.:

• DISABLE_HTTPS: بما أن اتصال HTTPS سيتم معالجته من قبل خادم ويب الوكيل العكسي، فلا حاجة لفعيل HTTPS ضمن Jitsi، نعين قيمة هذا المتغير إلى 1.
• ENABLE_HTTP_REDIRECT: عينها إلى 0 لأنها غير ضرورية، حيث أن اتصالات HTTP و HTTPS ستعالج من قبل الوكيل العكسي.
• VIRTUAL_HOST و LETSENCRYPT_HOST: هذه المتغيرات غير موجودة ضمن الملف بشكل افتراضي، فيجب إضافتها وتعيين قيمها باسم النطاق الذي ستستضاف عليه النسخة.

تعديل ملف compose (فقط للوكيل العكسي)

نفتح ملف docker-compose.yml ضمن أي محرر نصوص، ونعدل خدمة خادم الويب فقط، عبر اتباع الخطوات التالية:

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

networks:
  net:
    external: true

وذلك بفرض اسم الشبكة هو net، يمكنك تغييره بحسب اسم الشبكة الذي لديك.

• إضافة متغيري البيئة VIRTUAL_HOST و LETSENCRYPT_HOST كالتالي:

- VIRTUAL_HOST
- LETSENCRYPT_HOST

نشر الحاوية

بعد الانتهاء من كل التعديلات يمكننا نشر Jitsi عبر تنفيذ الأمر docker-compose up -d، وتأكد بعدها أن حاويات الوكيل العكسي تعمل إذا كنت تستخدم طريقتها، بقي الآن عملية إنشاء مستخدمين جدد لخادم Jitsi.

إنشاء المستخدمين

إذا فعلت ميزة الاستيثاق ضمن الإعدادات السابقة، فيجب تسجيل المستخدمين قبل أن يتمكنوا من استخدام Jitsi، يمكن تنفيذ ذلك بسهولة، عبر التوجه إلى مجلد المستودع الذي قمنا باستنساخه وتنفيذ أمر مشابه للتالي مع تبديل اسم المستخدم USERNAME وكلمة السر PASSWORD:

docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua register [USERNAME] meet.jitsi [PASSWORD]

يمكن حذف مستخدم باستخدام الأمر unregister كالتالي مع تبديل اسم المستخدم بالاسم الصحيح:

docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua unregister [USERNAME] meet.jitsi

الآن يمكنك الذهاب إلى واجهة Jitsi Meet عبر المتصفح من خلال عنوان اسم النطاق الذي سجلناه للتطبيق:

ترجمة -وبتصرف- للمقال How to Self Host Jitsi Meet With Docker لصاحبه Debdut Chakraborty.

اقرأ أيضًا

• مدخل إلى خادم الويب
• مدخل إلى دوكر Docker
• ما عليك معرفته عن الفرق بين دوكر والأجهزة الافتراضية

يُعد جانغو Django إطار عمل ويب قوي يساعدك على إطلاق مشروعك سواءٌ كان تطبيق بايثون Python أو موقع ويب، ويتضمن خادم تطوير بسيط يُستخدم لاختبار الشيفرة محليًا ولكن من المعلوم أنه عندما يتعلق الأمر بالإطلاق الاحترافي للتطبيق للشركات أو الأعمال فإننا سنحتاج دومًا إلى خادم ويب قوي وأكثر أمانًا.

الطريقة التقليدية لنشر تطبيق جانغو هي استخدام واجهة بوابة خادم الويب Web Server Gateway Interface -أو اختصارًا WSGI- لكن مع ظهور بايثون 3 وتوفُّر ميزة دعم التنفيذ غير المتزامن أصبح بإمكانك تنفيذ تطبيقات بايثون من خلال المستَدعيات غير المتزامنة asynchronous callables مستخدمًا واجهة بوابة خادم غير متزامنة Asynchronous Server Gateway Interface -أو اختصارًا ASGI - ومع كون تقنية ASGI خلفًا لتقنية WSGI فمواصفات ASGI في بايثون قد ورثتها من WSGI وبالتالي يمكن أن تكون بديلًا عنها.

يوفّر جانغو النمط "غير متزامن في الخارج async outside، متزامن في الداخل sync inside" الذي يسمح بأن تكون الشيفرة متزامنة داخليًًا بينما يعالج خادم ASGI الطلبات بصورةٍ غير متزامنة، وبالتالي يمكن لخادم الويب معالجة العديد من الأحداث الواردة من والصادرة إلى كل التطبيقات بمجرد السماح له أن يمتلك مستدعًى callable غير متزامن. يبقى تطبيق جانغو متزامنًا بهدف الحفاظ على التوافقية العكسية backward compatibility وتجنُّب تعقيد الحوسبة التفرعية؛ وهذا يعني أيضًا أن تطبيق جانغو الذي تعمل عليه لا يلزمه أي تغييرات لينتقل من WSGI إلى ASGI.

ستعمل في هذا الدليل على تثبيت وضبط بعض المكونات على نظام أوبنتو 20.04 لدعم وخدمة تطبيقات جانغو؛ إذ ستثبّت قاعدة بيانات PostgreSQL بدلًا من SQLite المثبتة افتراضيًا، وستهيء أيضًا خادم تطبيقات غوني كورن Gunicorn المقترن بالخادم يوفي كورن Uvicorn، الذي يُعد أحد تنفيذات ASGI، وذلك بهدف ربطه مع تطبيقاتك بصورةٍ غير متزامنة. بعد ذلك، ستعدّ الخادم إنجن إكس Nginx ليعكس الخادم الوكيل proxy لخادم التطبيقات غوني كورن، الأمر الذي يعطيك وصولًا إلى مزاياه الأمنية ومزايا الأداء لخدمة تطبيقاتك.

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

ستحتاج لإكمال هذه المقالة إلى ما يلي:

• خادم أوبنتو 20.04 server واحد معدٌّ باتباع التعليمات الواردة في دليل إعداد خادم مبدئي لنظام أوبنتو، ويتضمن مستخدمًا غيرَ جذري non-root، لكنه يتمتع بصلاحيات sudo.

الخطوة الأولى - تثبيت الحزم البرمجية من مستودعات أدوات أوبنتو

ستعمل بدايةً على تنزيل وتثبيت جميع العناصر التي تحتاجها من مستودعات أدوات أوبنتو، وستستخدم مدير حزم بايثون pip لتثبيت المكونات الإضافية في وقتٍ لاحق.

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

نفّذ الأمر التالي لتثبيت حزم النظام المطلوبة لمشروعك:

$ sudo apt update
$ sudo apt install python3-venv libpq-dev postgresql postgresql-contrib nginx curl

سيثبّت هذا الأمر مكتبات بايثون اللازمة لإعداد بيئة افتراضية، ونظام قاعدة بيانات Postgres، والمكتبات اللازمة للتفاعل معها، وخادم الويب إنجن إكس Nginx.

ستنشئ في الخطوة التالية قاعدة بيانات PostgreSQL ومستخدمًا لها من أجل استخدامها في تطبيق جانغو الذي ستعمل عليه.

الخطوة الثانية - إنشاء قاعدة بيانات PostgreSQL ومستخدم لها

ستنشئ الآن قاعدة بيانات ومستخدمًا لها من أجل استخدامهما في تطبيق جانغو الذي ستعمل عليه.

يستخدم نظام قاعدة بيانات Postgres في الحالة الطبيعية مخطط استيثاق يُدعى استيثاق النظير peer authentication من أجل الاتصالات المحلية، ويقضي هذا النوع من الاستيثاق بأنه إذا طابق اسم مستخدم username نظام التشغيل اسم مستخدم صالح ضمن قاعدة بيانات Postgres، فسيُعطَى عندئذ صلاحية الدخول إلى قاعدة البيانات دون الحاجة إلى استيثاق إضافي.

لذلك، أثناء تثبيت Postgres، يُنشأ مستخدم نظام التشغيل باسم postgres ليطابق اسم المستخدم الإداري لنظام إدارة قواعد البيانات PostgreSQL، وهو أيضًا باسم postgres، إذ ستحتاج هذا المستخدم لإنجاز المهام الإدارية، علمًا بأنه يمكنك استخدام sudo وتمرير الخيار u- مع اسم المستخدم.

الآن سجّل الدخول إلى جلسة Postgres تفاعلية من خلال الأمر التالي:

$ sudo -u postgres psql

سيظهر لك محث PostgreSQL وهذا يعني أن صار بإمكانك تجهيز متطلباتك.

أولًا، أنشئ قاعدة بيانات للمشروع الذي تعمل عليه:

postgres=# CREATE DATABASE myproject;

ملاحظة: تنتهي كل تعليمة من تعليمات Postgres بفاصلة منقوطة، ولذا إذا واجهتك أي مشاكل فتحقق من أنك ختمت كل التعليمات بفواصل منقوطة.

بعد ذلك، أنشئ مستخدم قاعدة بيانات لمشروعك، واختر كلمة مرور قوية:

postgres=# CREATE USER myprojectuser WITH PASSWORD 'password';

ستعدّل بعد ذلك بعض معاملات الاتصال للمستخدم الذي أنشأته للتو، والهدف من هذه التعديلات هو تسريع عمليات قاعدة البيانات بحيث لا تضطر للاستعلام عن القيم الصحيحة ثم إعدادها في كل مرة يُؤسَّس فيها اتصال.

ستضع التشفير الافتراضي بالقيمة "UTF-8"، وهي التي يتوقعها جانغو، وستحدّد مخطط عزل الإجراءات الافتراضي بالقيمة "read committed" التي تؤدي إلى حجب عمليات القراءة من الإجراءات التي لم تودع بعد uncommitted transactions. أخيرًا، ستحدد المنطقة الزمنية، والقيمة الافتراضية لها في جانغو هي "UTC". جميع هذه التوصيات هي من القائمين على مشروع جانغو.

postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC';

يمكنك الآن منح المستخدم الجديد الوصولَ إلى قاعدة البيانات الجديدة ليتمكن من إدارتها:

postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

وعقب انتهائك، اخرج من محث PostgreSQL بالتعليمة التالية:

postgres=# \q

وبهذا نكون أعددنا نظام Postgres بحيث يتمكن جانغو من الاتصال به وإدارة معلومات قاعدة البيانات فيه.

الخطوة الثالثة- إنشاء بيئة بايثون افتراضية للمشروع

الآن بعد أن أصبح لديك قاعدة بيانات أصبح بإمكانك تجهيز ما تبقى من متطلبات المشروع. ستثبت فيما يلي متطلبات بايثون ضمن بيئة افتراضية بهدف تسهيل الإدارة.

أنشئ أولًا مجلدًا تحفظ فيه ملفات المشروع وانتقل إلى داخله:

$ mkdir ~/myprojectdir
$ cd ~/myprojectdir

ثم استخدم أداة البيئة الافتراضية المبنية مسبقًا من بايثون لإنشاء بيئة افتراضية جديدة.

$ python3 -m venv myprojectenv

سينشئ هذا مجلدًا اسمه "myprojectenv" ضمن المجلد "myprojectdir"، إذ سيثبت داخله إصدارًا محليًا من بايثون وإصدارًا محليًا من pip. يمكنك استخدامه لتثبيت وضبط بيئة بايثون معزولة عن المشاريع الأخرى.

ستحتاج قبل تثبيت متطلبات بايثون للمشروع إلى تفعيل البيئة الافتراضية باستخدام الأمر التالي:

$ source myprojectenv/bin/activate

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

(myprojectenv)user@host:~/myprojectdir$

لا بُد من تثبيت جانغو داخل البيئة الافتراضية، إذ يسمح تثبيته داخل بيئة مخصصة لمشروعك للمشاريع الأخرى وبيئاتها أن تُعالج بمعزلٍ عن بعضها بعضًا. الآن وبعد تفعيل البيئة الافتراضية، استخدم النسخة المحلية من الأمر pip لتثبيت كلٍّ من جانغو وغوني كورن ويوفي كورن وموائم PostgreSQL الذي اسمه "psycopg2".

ملاحظة: استخدم pip بدلًا من pip3 عند تفعيل البيئة الافتراضية، أي عندما يكون المُحث مسبوقًا بالاسم "(myprojectenv)"، حتى لو كنت تستخدم بايثون 3، إذ يُطلق دائمًا يطلق على نسخة الأداة للبيئة الافتراضية اسم pip بغض النظر عن إصدار بايثون.

(myprojectenv) $ pip install django gunicorn uvicorn psycopg2-binary

وبهذا يكون أصبح لديك كل البرمجيات اللازمة لبدء مشروع جانغو.

الخطوة الرابعة - إنشاء وضبط مشروع جانغو جديد

يمكنك الآن بعد الانتهاء من تثبيت مكونات بايثون أن تنشئ ملفات مشروع جانغو الفعلية.

إنشاء مشروع جانغو

نظرًا لأن مجلد المشروع موجود فعلًا، يمكنك أن تطلب من جانغو أن يثبت الملفات فيه، إذ سينشئ مجلدًا في المستوى الثاني مع الشيفرة الفعلية، وهو أمر طبيعي، ويضع سكريبت script الإدارة في هذا المجلد. الفكرة الرئيسية وراك ذلك هو أن تعرّف المجلد صراحةً بدلًا من ترك المجال لجانغو باتخاذ قرارات لها علاقةٌ بمجلدك الحالي نيابةً عنك:

(myprojectenv) $ django-admin startproject myproject ~/myprojectdir

الآن، لا بُدّ أن يحتوي مجلد المشروع ("myprojectdir/~" في مقالتنا) على المكونات التالية:

• "myprojectdir/manage.py/~": سكربت إدارة مشروع جانغو.
• "/myprojectdir/myproject/~": حزمة مشروع جانغو التي يجب أن تحتوي على الملفات: "init__.py__" و "asgi.py" و "settings.py" و "urls.py" و "wsgi.py".
• "/myprojectdir/myprojectenv/~": مجلد البيئة الافتراضية الذي أنشأته من قبل.

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

ستحتاج بعد إنشاء ملفات المشروع إلى ضبط بعض الإعدادات. افتح ملف الإعدادات بأي محرر نصوص تشاء، واستخدمنا هنا محرر النصوص نانو nano:

(myprojectenv) $ nano ~/myprojectdir/myproject/settings.py

ابحث في الملف عن الموجه ALLOWED_HOSTS الذي يعرّف قائمةً بعناوين وأسماء النطاقات للخادم التي يمكن أن تُستخدم للاتصال بنسخة جانغو. لذا ستؤدي أي طلبات واردة بترويسة مضيف وغير موجودة ضمن تلك القائمة إلى ظهور استثناء exception، ويطلب جانغو منك هذا منعًا لصنف معين من الثغرات الأمنية.

أدرج داخل الأقواس المربعة قائمة عناوين IP أو أسماء النطاقات المرافقة لخادم جانغو، وضع كل عنصر بين علامتي اقتباس مع الفصل بين كل عنصرين بفاصلة. للسماح بنطاق كامل وأي نطاقات فرعية، ضع نقطةً في بداية العنصر. لفهم هذا الكلام وضعنا في الشيفرة التالية بعض الأمثلة وسبقناها بعلامة التعليق لتُعامل مثل تعليقات.

ملاحظة: تأكد من إضافة localhost ضمن القائمة لأنك ستحتاج إلى خادم وكيل من أجل الاتصالات من خلال نسخة إنجن إكس محلية.

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']

ثم اعثر على القسم الذي يضبط الوصول إلى قاعدة البيانات، إذ سيبدأ بـكلمة "DATABASES". الضبط الموجود في الملف يخص قاعدة بيانات SQLite التي عدَلنا عن استخدامها إلى البديل PostgreSQL لذا لا بد من ضبط الإعدادات.

غيّر الإعدادات بمعلومات قاعدة بيانات PostgreSQL، وأخبر جانغو بأن يستخدم موائم psycopg2 الذي ثبتَّه بواسطة pip. سيُطلب منك التزويد باسم قاعدة البيانات واسم مستخدم قاعدة البيانات وكلمة المرور لمستخدم قاعدة البيانات، ثم تحديد أن قاعدة البيانات موجودة على الجهاز المحلي؛ أما إعدادات المنفذ PORT، فيمكنك تركها سلسلةً نصيةً فارغة.

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

. . .

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

. . .

STATIC_URL = '/static/'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

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

إتمام الإعداد الأولي للمشروع

يمكنك الآن تهجير migrate مخطط قاعدة البيانات الأولي إلى قاعدة بيانات PostgreSQL باستخدام سكريبت الإدارة:

(myprojectenv) $ ~/myprojectdir/manage.py makemigrations
(myprojectenv) $ ~/myprojectdir/manage.py migrate

أنشئ مستخدمًا إدرايًّا للمشروع على النحو التالي:

(myprojectenv) $ ~/myprojectdir/manage.py createsuperuser

ستحتاج إلى التزويد باسم مستخدم وبريد إلكتروني وتختار كلمة مرور ثم تؤكدها.

يمكنك أن تجمع كل المحتوى الساكن في موقع المجلد الذي هيّأته وذلك على النحو التالي:

(myprojectenv) $ ~/myprojectdir/manage.py collectstatic

ستحتاج إلى تأكيد العملية. بعد ذلك ستُوضع الملفات الساكنة في مجلد اسمه "static" ضمن مجلد المشروع.

يُفترض إذا كنت قد اتبعت دليل إعداد الخادم الأولي أن يكون لديك جدار ناري UFW يحمي خادمك، وستحتاج للسماح بالوصول إلى المنفذ الذي تستخدمه إذا أردت اختبار خادم التطوير.

أنشئ استثناءً للمنفذ 8000 على النحو التالي:

(myprojectenv) $ sudo ufw allow 8000

يمكنك الآن وأخيرًا اختبار مشروعك بتشغيل خادم تطوير جانغو على النحو التالي:

(myprojectenv) $ ~/myprojectdir/manage.py runserver 0.0.0.0:8000

اذهب إلى اسم نطاق الخادم الذي تستخدمه أو عنوان IP متبوعًا برقم المنفذ 8000 في متصفحك:

http://server_domain_or_IP:8000

يفترض الآن أن تظهر لك صفحة فهرس جانغو الافتراضية:

سيُطلب منك إدخال اسم المستخدم وكلمة المرور اللذين أنشأتهما بالأمر createsuperuser،إذا ألحقت "admin/" بنهاية عنوان URL في شريط العنوان :

يمكنك بعد انتهاء التحقق الوصولُ إلى الواجهة الافتراضية لإدارة جانغو:

اضغط على المفتاحين "CTRL+C" بعد انتهاء عملية الاستكشاف في النافذة الطرفية لإيقاف تشغيل خادم التطوير.

اختبار قدرة خادم غوني كورن على تخديم المشروع

سنستخدم في مقالتنا هذه خادم "غوني كورن Gunicorn" جنبًا إلى جنب مع خادم "يوفي كورن Uvicorn" لتشغيل التطبيق. ومع أن غوني كورن يُستخدم عادةً لنشر تطبيقات WSGI لكنه يُزوَّد بواجهة قابلة للتوصيل pluggable لتأمين نشر ASGI، وهو يفعل هذا من خلال السماح لك باستهلاك صنف عامل يظهر بواسطة خادم ASGI (وهو يوفي كورن). ونظرًا لأن الخادم "غوني كورن" هو منتج أعلى نضجًا من الخادم "يوفي كورن" ويزود بضبطٍ أكثر منه، ينصح أنصار الخادم "يوفي كورن" باستخدام الخادم "غوني كورن" مع الصنف العامل للخادم "يوفي كورن" لأنه خادم ومدير عمليات ذي مزايا مكتملة.

ستفحص خادم غوني كورن قبل مغادرة البيئة الافتراضية لتتأكد من أن بإمكانه تخديم التطبيق.

الآن لكي تستخدم الأصناف العاملة لخادم يوفي كورن مع خادم غوني كورن، ادخل إلى مجلد المشروع واستخدم الأمر gunicorn التالي لتحميل وحدة ASGI للمشروع.

(myprojectenv) $ cd ~/myprojectdir
(myprojectenv) $ gunicorn --bind 0.0.0.0:8000 myproject.asgi -w 4 -k uvicorn.workers.UvicornWorker

سيشغّل هذا الأمر خادم غوني كورن على نفس الواجهة التي كان يعمل عليها خادم تطوير جانغو. يمكنك الآن العودة واختبار التطبيق من جديد.

ملاحظة: ليس مطلوبًا استخدام خادم غوني كورن لتشغيل تطبيق ASGI، ولكي تستخدم فقط خادم يوفي كورن، استعن بالأمر التالي:

uvicorn myproject.asgi:application --host 0.0.0.0 --port 8080

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

إذا كانت صفحة ترحيب جانغو لا تزال ظاهرة حتى بعد تنفيذ هذه الأوامر، فإن هذا يعدّ تأكيدًا على أن الخادم غوني كورن قد خدّم الصفحة فعلًا وأنه يعمل على النحو المطلوب، وما قد حصل هو أنك عندما استخدمت الأمر gunicorn، فقد مرّرت وحدة module إلى خادم غوني كورن بتحديد مسار المجلد ذي الصلة إلى الملف asgi.py الخاص بـجانغو والذي يعدّ نقطة الدخول إلى تطبيقك، باستخدام صيغة وحدة بايثون. عُرّف داخل هذا الملف دالةٌ اسمها "application"، ستُستخدم للتواصل مع التطبيق.

إذا أردت معرفة المزيد عن مواصفات ASGI، زر الموقع الرسمي للخادم ASGI.

اضغط بعد انتهائك من الاختبار على المفتاحين "CTRL+C" في نافذة الطرفية لإيقاف تشغيل خادم غوني كورن.

وبهذا تكون انتهيت من ضبط تطبيق جانغو، ويمكنك الآن الخروج من البيئة الافتراضية بكتابة ما يلي:

(myprojectenv) $ deactivate

عندئذٍ سيُحذف مؤشر البيئة الافتراضية في محث النافذة التي تعمل فيها.

الخطوة الخامسة - إنشاء مقبس systemd وملفات خدمة لـخادم غوني كورن

تأكدتَ في القسم السابق من قدرة خادم غوني كورن على التفاعل مع تطبيق جانغو، وستنفّذ في الخطوة الحالية طريقةً أقوى لتشغيل وإطفاء خادم التطبيقات عبر إنشاء خدمة systemd وملفات المقبس socket files.

سيُنشأ مقبس خادم غوني كورن عند الإقلاع وسيستمع إلى الاتصالات، وعندما يحدث اتصال ستشغِّل خدمة systemd تلقائيًّا عمليةَ الخادم غوني كورن لتولي مهمة التعامل مع الاتصال.

الآن ابدأ بإنشاء ملف مقبس systemd لخادم غوني كورن وافتحه بمحرر النصوص الذي تريد وبصلاحيات sudo كما يلي:

$ sudo nano /etc/systemd/system/gunicorn.socket

ستنشئ في داخل الملف القسم [Unit] لوصف المقبس والقسم [Socket] لتعريف موضع المقبس والقسم [Install] للتأكد أن المقبس يُنشأ في الوقت المناسب:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

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

$ sudo nano /etc/systemd/system/gunicorn.service

ابدأ بالقسم [Unit] الذي يستخدم لتحديد البيانات الوصفية metadata والاعتماديات. ستحدد هنا وصفًا لخدمتك وتخبر نظام التهيئة init system أن يشغل هذا فقط عند الوصول إلى مستوى التشبيك المستهدف، ونظرًا لأن الخدمة تعتمد على المقبس والموجود وصفه في ملف المقبس، فستحتاج إلى تضمين الموجّه Requires للإشارة إلى تلك العلاقة:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

افتح بعد ذلك القسم [Service]، إذ ستحدّد في هذا القسم المستخدم والمجموعة اللتين تريد أن تُشغّل العملية من أجلهما. ستمنح حساب المستخدم النظامي ملكيةَ العملية لامتلاكه كافة الملفات اللازمة، وستعطي ملكية المجموعة للمجموعة "www-data" ليتمكنَ الخادم إنجن إكس من التواصل بسهولة مع خادم غوني كورن.

بعد ذلك، ستعدّ المجلد العامل وتحدد الأمر الذي ستستخدمه لتشغيل الخدمة، إذ ستحتاج في حالتنا هذه لتحديد المسار الكامل للملف التنفيذي لخادم غوني كورن المثبت ضمن البيئة الافتراضية. ستربِط العملية مع مقبس يونيكس Unix الذي أنشأته ضمن المجلد "run/" لتتمكن العملية من التواصل مع الخادم إنجن إكس، وستُرسل كل سجلات البيانات إلى جهاز الخرج القياسي لتتمكن العملية journald من جمع سجلات الخادم غوني كورن. يمكنك أيضًا أن تحدد أي إعدادات من اختيارك للخادم غوني كورن. وفيما يلي مثالٌ عن تحديد ثلاث عمليات عاملة:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          -k uvicorn.workers.UvicornWorker \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.asgi:application

القسم الأخير هو [Install]، الذي سيخبر systemd عما سيربطه مع هذه الخدمة إذا اخترنا تشغيلها عند الإقلاع. سترغب غالبًا بتشغيل هذه الخدمة عندما يكون نظام المتعدد المستخدمين في حالة عمل:

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          -k uvicorn.workers.UvicornWorker \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.asgi:application

[Install]
WantedBy=multi-user.target

وبهذا يكون ملف خدمة systemd قد اكتمل. بإمكانك الآن أن تحفظه وتغلقه.

يمكنك الآن تشغيل وتفعيل مقبس الخادم غوني كورن، إذ سينشئ هذا ملف المقبس في المسار "run/gunicorn.sock/" الآن وعند الإقلاع. عندما يُنشأ اتصال مع ذلك المقبس، ستشغّل systemd الخدمة "gunicorn.service" تلقائيًا لمعالجتها.

$ sudo systemctl start gunicorn.socket
$ sudo systemctl enable gunicorn.socket

الآن وبعد أن أنشأت ملفات المقبس وخدمة systemd، بإمكانك التأكد من نجاح ما أنجزته من خلال التأكد من وجود ملف المقبس.

الخطوة السادسة - التأكد من وجود ملف مقبس الخادم غوني كورن

ستتحقق في هذه الخطوة من ملف مقبس خادم غوني كورن. ابدأ أولًا بفحص حالة العملية لمعرفة ما إذا كانت قادرة على البدء:

$ sudo systemctl status gunicorn.socket

سيبدو خرج العملية السابقة قريبًا من التالي:

● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
     Active: active (listening) since Fri 2020-06-26 17:53:10 UTC; 14s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
      Tasks: 0 (limit: 1137)
     Memory: 0B
     CGroup: /system.slice/gunicorn.socket

ثم تحقق من وجود ملف "gunicorn.sock" ضمن المجلد "run/":

$ file /run/gunicorn.sock

وسيكون الخرج على النحو التالي:

/run/gunicorn.sock: socket

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

$ sudo journalctl -u gunicorn.socket 

ألق نظرةً أخرى على الملف في الرابط التالي لإصلاح أيّ مشاكل قبل المتابعة:

"etc/systemd/system/gunicorn.socket/"

الخطوة السابعة - فحص تنشيط المقبس

ستفحص في هذه الخطوة تنشيط المقبس، فإذا كنت في الوقت الحالي قد شغّلت فقط الوحدة gunicorn.socket، فلن تكون الخدمة gunicorn.service نشطةً لأن المقبس لم يكن قد استلم أي اتصالات بعد، ويمكنك فحص هذه الحالة بالأمر التالي:

$ sudo systemctl status gunicorn

ويكون الخرج على النحو التالي:

● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

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

$ curl --unix-socket /run/gunicorn.sock localhost

يفترض أن تتلقى الخرج على صيغة HTML من تطبيقك في الطرفية، والذي يشير إلى أن خادم غوني كورن قد شُغّل وأنه كان قادرًا على تخديم تطبيق جانغو الذي تعمل عليه. يمكن فحص ما إذا كانت خدمة غوني كورن في وضع التشغيل بكتابة الأمر التالي:

$ sudo systemctl status gunicorn

وسيكون الخرج على النحو التالي:

● gunicorn.service - gunicorn daemon
     Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-06-10 21:03:29 UTC; 13s ago
TriggeredBy: ● gunicorn.socket
   Main PID: 11682 (gunicorn)
      Tasks: 4 (limit: 4682)
     Memory: 98.5M
     CGroup: /system.slice/gunicorn.service
             ├─11682 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 -k uvicorn.workers.UvicornWorker --bind unix:/run/gunicorn.sock myproject.asgi:application
             ├─11705 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 -k uvicorn.workers.UvicornWorker --bind unix:/run/gunicorn.sock myproject.asgi:application
             ├─11707 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 -k uvicorn.workers.UvicornWorker --bind unix:/run/gunicorn.sock myproject.asgi:application
             └─11708 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 -k uvicorn.workers.UvicornWorker --bind unix:/run/gunicorn.sock myproject.asgi:application

Jun 10 21:03:29 django gunicorn[11705]: [2021-06-10 21:03:29 +0000] [11705] [INFO] ASGI 'lifespan' protocol appears unsupported.
Jun 10 21:03:29 django gunicorn[11705]: [2021-06-10 21:03:29 +0000] [11705] [INFO] Application startup complete.
Jun 10 21:03:30 django gunicorn[11707]: [2021-06-10 21:03:30 +0000] [11707] [INFO] Started server process [11707]
Jun 10 21:03:30 django gunicorn[11707]: [2021-06-10 21:03:30 +0000] [11707] [INFO] Waiting for application startup.
Jun 10 21:03:30 django gunicorn[11707]: [2021-06-10 21:03:30 +0000] [11707] [INFO] ASGI 'lifespan' protocol appears unsupported.
Jun 10 21:03:30 django gunicorn[11707]: [2021-06-10 21:03:30 +0000] [11707] [INFO] Application startup complete.
Jun 10 21:03:30 django gunicorn[11708]: [2021-06-10 21:03:30 +0000] [11708] [INFO] Started server process [11708]
Jun 10 21:03:30 django gunicorn[11708]: [2021-06-10 21:03:30 +0000] [11708] [INFO] Waiting for application startup.
Jun 10 21:03:30 django gunicorn[11708]: [2021-06-10 21:03:30 +0000] [11708] [INFO] ASGI 'lifespan' protocol appears unsupported.
Jun 10 21:03:30 django gunicorn[11708]: [2021-06-10 21:03:30 +0000] [11708] [INFO] Application startup complete.