أَحدَثَت مشاريع الحوسبة السحابية الأصيلة Cloud-native Computing تغييرًا كبيرًا في طريقة بناء التطبيقات ونشرها، ووفرت وسائل متنوعة تُسَهِّل العمل، بدايةً من أدوات التكامل Integrating وتحزيم Packaging شيفرة التطبيق تمهيدًا لنشره، ووصولًا إلى أدوات التوسعة Scaling وغير ذلك.

تندرج هذه الأعمال جميعها تحت مظلة DevOps وتُعدّ الحاويات في عصرنا الحالي أشهر مفاهيم DevOps الحديث وأكثرها تأثيرًا، وسنعرض في مقالنا هذا مثالًا عمليًّا عن نشر تطبيق ريآكت React بمساعدة الحاويات؛ إذ سننشئ صورة دوكر Docker للتطبيق ثم نرفعها إلى سجل الحاويات Container Registry وننشرها باستخدام خادم Droplet من منصة DigitalOcean.

متطلبات العمل

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

• إنشاء حساب على منصة DigitalOcean.
• تثبيت كل من دوكر Docker ومدير الحزم npm على جهازننا
• تشغيل خادم Droplet على DigitalOcean
• إعداد سجل الحاويات على DigitalOcean

تثبيت Docker

تساعدنا توثيقات دوكر وهذا الدليل على تثبيت دوكر على الجهاز. وعند إتمام التثبيت، سنستخدم الأمر docker --version للاستعلام عن إصدار دوكر والتحقق من نجاح تثبيته، وذلك وفق التالي:

docker --version
Docker version 26.0.0, build 2ae903e

إنشاء تطبيق ريآكت

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

npm create vite@latest react-app -- --template react

سيُنشئ هذا الأمر تطبيقًا تجريبيًّا ضمن المجلد react-app، وبعدها يمكن الانتقال للمجلد وتشغيل التطبيق بواسطة الأوامر التالية:

cd react-app
npm install
npm run dev

وعند الانتهاء من التشغيل سنحصل على رسالة شبيهة بالتالي:

OutputVITE v5.2.11  ready in 712 ms
➜  Local:   http://localhost:5173/
➜  Network: use --host to expose
➜  press h + enter to show help

يمكن الآن فتح التطبيق من المتصفح بكتابة العنوان localhost:5173 كما يلي:

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

إنشاء الملف Dockerfile

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

تُنشَئ صور دوكر باستخدام ملف خاص يدعى Dockerfile يتضمن التعليمات البرمجية اللازمة لبناء الصورة؛ إذ تتكون الصورة image من عدة طبقات layers للقراءة فقط. وعند إضافة أي تعليمة إلى الملف Dockerfile، تُضَاف طبقة جديدة إلى الصورة.

تُخَزَّن هذه الطبقات بهيئة قيم مُعَمَّاة hash من نوع SHA-256، ويمكن معرفة المزيد عن بنية صور الحاويات بمطالعة مقال ما هي صورة الحاوية container image؟

إذًا تُبنى صور دوكر بإنشاء الملف Dockerfile ويشمل ذلك خطوتين أساسيتين:

• بناء التطبيق
• إعداد خادم nginx وتشغيله لخدمة التطبيق

تنويه: ستُكتَب جميع التعليمات التي ننفذها في هاتين الخطوتين ضمن الملف Dockerfile.

1. بناء التطبيق

سنوجه Docker في البداية ليستخدم أحدث نسخة من Node.js لتكون الركيزة التي سيبني عليها تطبيق React وفق التالي:

FROM node:latest AS builder

بعد ذلك سنحَدِّد مجلد العمل WORKDIR الذي ستُنَفَّذ فيه جميع التعليمات اللاحقة، والذي سيكتمل فيه تطبيقنا:

WORKDIR /app

سننسخ بعدها الملف package.json إلى الحاوية builder ونشَغِّل npm install لتثبيت جميع الاعتماديات المطلوبة في الملف package.json وبذلك نضمن أن تطبيق React يمتلك كل ما يحتاجه ليعمل بصورة سليمة:

COPY package.json .
RUN npm install

والآن. يمكن نسخ بقية ملفات المشروع إلى الحاوية وتشغيل npm run build لتصريف compile التطبيق وفق الأمر التالي الذي سيُحَوِّل الشيفرة المصدرية لتطبيقنا إلى حزمة bundle جاهزة لبيئة الإنتاج ومُخَزَّنة في المجلد /dist ومُضبوطة لتعمل بكفاءة وأداء جيد:

COPY . ./
RUN npm run build

2. إعداد خادم nginx للتطبيق وتشغيله

يشتهر NGINX بالكفاءة والسرعة، لذا يُعدّ خيارًا مناسبًا للاستخدام كخادم ويب لتطبيقنا حتى يصله بالمستخدمين، وسنعتمد لبنائه أحدث صورة nginx متوفرة؛ ثم نستبدل ملف الإعدادات الافتراضي الذي يأتي مع الصورة default.conf بملف إعدادات مشروعنا ليتمكن خادم nginx من تلبية طلبات المستخدمين الواردة إلى التطبيق.

وذلك وفق الأوامر التالية:

FROM nginx:latest
RUN rm -rf /etc/nginx/conf.d/default.conf
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf

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

COPY --from=builder /app/dist /usr/share/nginx/html

سنضبط بعد ذلك قيمة مجلد العمل WORKDIR داخل حاوية nginx ليشير إلى مجلد التطبيق:

WORKDIR /usr/share/nginx/html

ثم نشَغِّل خادم nginx بواسطة الأمر التالي، الذي يوجه Docker لبدء تشغيله والحفاظ عليه في حالة عمل:

CMD ["/bin/bash", "-c", "nginx -g "daemon off;""]

إذا جمعنا كل التعليمات السابقة معًا، فستشكل الملف Dockerfile:

# ------------------------
# Step 1: Build react app
# ------------------------

# Use node:latest as the builder image
FROM node:latest AS builder

# Set the working directory
WORKDIR /app

# Copy package.json and install app dependencies
COPY package.json .
RUN npm install

# Copy other project files and build
COPY . ./
RUN npm run build

# --------------------------------------
# Step 2: Set up nginx to serve the app
# --------------------------------------
# Use nginx:latest as the base image
FROM nginx:latest

# Overwriting nginx config with our own config file
RUN rm -rf /etc/nginx/conf.d/default.conf
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf

# Copy over the build created in the Step 1
COPY --from=builder /app/dist /usr/share/nginx/html

# Set the working directory
WORKDIR /usr/share/nginx/html

# Start nginx server
CMD ["/bin/bash", "-c", "nginx -g \"daemon off;\""]

لذا سننشئ ملفًا نصيًّا باسم Dockerfile ضمن المجلد الجذر لتطبيقنا كما يلي:

touch Dockerfile

مع نسخ التعليمات السابقة ضمنه.

إنشاء ملف إعدادات NGINX

ذكرنا في الخطوة السابقة الخاصة بإعداد خادم NGINX أننا سنستبدل ملف الإعدادات الافتراضي للخادم بملف إعدادات مشروعنا، فكيف ننشئ ملف إعدادات المشروع؟

سنتوجه في البداية إلى مجلد الجذر لتطبيقنا ثم ننشئ بداخله مجلدًا جديدًا باسم nginx، وننشئ بداخله ملفًا نصيًّا يدعى default.conf كما يلي:

mkdir nginx
cd nginx && touch default.conf

ثم ننسخ الإعدادات التالية والصقها ضمنه:

server {
  listen 80;
  add_header Cache-Control no-cache;
  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
    expires -1;
  }
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
    root   /usr/share/nginx/html;
  }
}

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

بناء صورة التطبيق image

سنستخدم هننا تعليمة cd للعودة إلى مجلد الجذر لتطبيقنا حيث يوجد الملف Dockerfile، ثم ننفِّذ الأمر التالي:

docker image build -t react-app:v1.0 . --platform linux/amd64

تتميز كل صورة دوكر عن غيرها باسم name ووسم tag خاصين بها يُكتَبان بعد الراية t-؛ فالصورة في مثالنا تدعى react-app، ولها الوسم v1.0؛ أما الراية platform-- فتساعدنا على تحديد المنصة التي تُبنى الصور من أجلها، وتُعَدُّ خيارًا مهمًا في الحالات التي نحتاج فيها لبناء صورة متعددة المنصات cross-platform حتى تُحَِّدد الأنظمة التي ستتوافق معها.

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

[+] Building 113.9s (17/17) FINISHED
=> [internal] load build definition from Dockerfile
=> => transferring dockerfile: 982B
...
...
=> => writing image sha256:d125b102b094224c82ddb69f9ece98c7161c8660fe72fd5aec57e41a6d72cf2f
=> => naming to docker.io/library/react-app:v1.0

يمكن استخدام الأمر التالي الذي يعرض صور دوكر الموجودة لتتحقق من صحة بناء الصورة:

docker image list

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

OutputREPOSITORY   TAG   IMAGE ID       CREATED         SIZE
react-app    v1.0  d125b102b094   6 minutes ago   188MB

وكما نلاحظ، فصورة التطبيق التي بنيناها ضمن قائمة الصور الموجودة.

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

لننتقل الآن إلى الخطوة التالية وهي تخزين الصورة في مكان مركزي يُسَهِّل توزيعها ونشرها، وهنا يأتي دور سجل الحاويات Container Registry.

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

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

لنبدأ الآن خطوات رفع push الصورة react-app إلى السجل.

لرفع صورنا إلى السجل ينبغي امتلاك سجل خاص أو أن نستخدم سجلًا عامًا مثل Docker Hub أو خدمة أخرى نحو سجل الحاويات لمنصة ديجيتال أوشن كما فعلنا في هذا المثال، والذي يمكننا استخدامه بالمجان للمشاريع الصغيرة؛ إذ يمكننا حجز مستودع واحد بمساحة تخزينية لا تتجاو 500 ميجا بايت، وهذا يناسب في الواقع يناسب الصورة الوحيدة التي سنرفعها إلى السجل.

يمكننا البدء إذًا بإعداد سجل الحاويات المجاني free-tier registry، واختيار أحد مواقع مراكز البيانات في المنطقة، مع تسمية السجل باسم مناسب مثل my-container-registry، كما هو الحال في الصورة التالية:

تنويه: لا بد من توفر حساب خاص على منصة ديجيتال أوشن لاستخدام سجل الحاويات، ويمكن الاسترشاد بدليل فتح الحساب لمزيدٍ من المعلومات عن هذه الخدمة.

سنحتاج الآن لمفتاح الواجهة البرمجية API للاتصال بالسجل، لذا سنتوجه إلى تبويب tokens من الصفحة الرئيسية لحسابنا على المنصة وننشئ مفتاحًا جديدًا خاصًا بنا كما هو الحال في الصورة التالية:

سنملأ الآن النموذج الظاهر أمامنا بعد الضغط على زر إنشاء رمز جديد Generate New Token ونفَعِّل خيار التحكم الكامل Full Access طالما أنه لن يكون هناك أكثر من مستخدم وحيد للرمز، إذ لا توجد أي مخاطر أمنية.

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

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

docker login registry.digitalocean.com

سيُطلب منا عندها إدخال اسم المستخدم وكلمة المرور:

OutputUsername: ravish.foo@bar.com
Password:
Login Succeeded

وبإدخالهما تكتمل عملية تسجيل الدخول ويمكن رفع صورة تطبيقنا إلى السجل؛ ويجري ذلك بخطوتين، أولاهما عبر وسم tag الصورة بوسم خاص للرفع كما يلي:

docker tag react-app:v1.0 registry.digitalocean.com/my-container-registry/react-app

وثانيهما رفع الصورة إلى السجل كما يلي:

docker push registry.digitalocean.com/my-container-registry/react-app

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

OutputUsing default tag: latest
The push refers to repository [registry.digitalocean.com/my-container-registry/react-app]
5f70bf18a086: Pushed
fafde3127bc5: Pushed
155c640ab606: Pushed
993afd9f06ad: Pushed
9fd54926bcae: Pushed
175aa66db4cc: Pushed
e6380a7057a5: Pushed
1db2242fc1fa: Pushed
b09347a1aec6: Pushed
bbde741e108b: Pushed
52ec5a4316fa: Pushed
latest: digest: sha256:227a8c3ede3fc5c81b281228600bec84939f8a4a0cc770fc6e5527b3261e77f4 size: 2608

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

يمكننا ملاحظة أن الصورة react-app التي رفعناها إلى السجل تحمل الوسم الافتراضي latest لأننا لم نعطها وسمًا خاصًا عند الرفع، فأي صورة تُرفع للسجل دون وسم تُمنح افتراضيًا الوسم latest، ويمكن بالتأكيد تغيير هذا الوسم إلى أي وسم آخر تريده بواسطة خاصية الإصدار Versioning.

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

بهذا نكون انتهينا من بناء صورة التطبيق وأصبحت جاهزة على سجل الحاويات، كل ما علينا الآن تشغيل خادم Droplet لنشر deploy الحاوية باستخدام هذه الصورة.

تشغيل خادم Droplet

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

عمليًّا، ستكفينا الخطة ذات 6$ لبناء خادم Droplet مناسب لنشر الحاوية، وسيساعدنا هذا الدليل على إتمام العملية؛ إذ سنختار في البداية نظام التشغيل وليكن أوبنتو، وعند اكتمال تشغيل الخادم سيظهر أمامنا في لوحة تحكم حسابنا كما في الصورة التالية:

ننقر على الخادم لرؤية تفاصيله، وننسخ عنوان IP الخاص به، والذي نجده تحت الاسم الخادم كما في الصورة التالية:

يمكن الآن فتح جلسة اتصال ssh مع الخادم كما يلي، وذلك باستخدام عنوان IP المخصص له وكلمة المرور لحساب الجذر root التي تُطلب منا أثناء إعداد الخادم:

ssh root@143.244.130.234
root@143.244.130.234's password:

يمكن أيضًا اختيار عدم المطالبة بكلمة مرور عند الاتصال مع الخادم ببروتوكول ssh إذا أردنا ذلك.

ستظهر أمامنا رسالة الترحيب التالية بمجرد نجاح الاتصال:

Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-9-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon Apr 29 08:07:53 UTC 2024

  System load:  0.32              Processes:             106
  Usage of /:   9.3% of 23.17GB   Users logged in:       0
  Memory usage: 40%               IPv4 address for eth0: 143.244.130.234
  Swap usage:   0%                IPv4 address for eth0: 10.47.0.5

47 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

*** System restart required ***
Last login: Mon Apr 29 08:07:55 2024 from 198.211.111.194
root@ubuntu-s-1vcpu-1gb-blr1-01:~#

وبهذا صرنا متصلين بالخادم ويمكننا تنفيذ التعليمات عليه.

سحب صورة التطبيق من سجل الحاويات

من المهم في البداية التأكد من وجود Docker ضمن الخادم، وذلك بكتابة الأمر التالي:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker --version
Docker version 24.0.5, build ced0996

وإذا لم يكن موجودًا يمكننا تثبيته باستخدام الأمر التالي:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# snap install docker

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

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker login registry.digitalocean.com
Username: ravish.foo@bar.com
Password:
Login Succeeded

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

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker pull registry.digitalocean.com/my-container-registry/react-app

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

OutputUsing default tag: latest
latest: Pulling from my-container-registry/react-app
b0a0cf830b12: Already exists
8ddb1e6cdf34: Already exists
5252b206aac2: Already exists
988b92d96970: Already exists
7102627a7a6e: Already exists
93295add984d: Already exists
ebde0aa1d1aa: Already exists
6156e0586e61: Already exists
88bdf71f3911: Pull complete
f5524cce8c8a: Pull complete
4f4fb700ef54: Pull complete
Digest: sha256:227a8c3ede3fc5c81b281228600bec84939f8a4a0cc770fc6e5527b3261e77f4
Status: Downloaded newer image for registry.digitalocean.com/my-container-registry/react-app:latest
registry.digitalocean.com/my-container-registry/react-app:latest

وكما نلاحظ، فالأمر السابق قد سَحَبَ الصورة ذات الوسم latest أي الصورة الأحدث، لأننا لم نُحَدِّد أي وسم آخر في أمر السحب، وفي مثل هذه الحالة يسحب docker الصورة latest تلقائيًا.

تشغيل الحاوية

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

docker run -dp 80:80 registry.digitalocean.com/my-container-registry/react-app

وكتوضيح للشيفرة أعلاه، تجعل الراية d- الحاوية تعمل في الخلفية، وتصل الراية p 80:80 البوابة 80 في الخادم المضيف بالبوابة 80 في الحاوية لتتجه حركة مرور البيانات الواردة للخادم إلى بوابة الحاوية.

البوابة 80 هي البوابة المعيارية لحركة البيانات وفق البروتوكول HTTP وقد ضبطنا الخادم nginx ليستقبل الطلبات عبرها.

سننفِّذ الآن الأمر التالي للتأكد من أن الحاوية قيد التشغيل:

root@ubuntu-s-1vcpu-1gb-blr1-01:~# docker ps -a

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

يمكننا تجربة ذلك عبر كتابة عنوان IP لخادم Droplet في متصفحنا وستفتح أمامنا واجهة تطبيق React:

يمكننا إيقاف تشغيل الحاوية بواسطة الأمر:

docker stop <container_id>

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

docker rm <container_id>

الخلاصة

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

ترجمة -وبتصرف- لمقال How to deploy your React app using Container Registry لصاحبيه Ravish Ahmad Khan و Anish Singh Walia.

اقرأ أيضًا

• مدخل إلى الحاويات
• مدخل إلى دوكر Docker
• التعامل مع حاويات Docker
• أساسيات تنسيق الحاويات

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

لنشرح الطرق الثلاثة بالتفصيل في الفقرات التالية:

الطريقة الأولى: استخدام خيار --restart always

هذه الطريقة هي الإعداد الافتراضي لتشغيل الحاوية، فعندما نشغل حاوية دوكر باستخدام الأمر docker run يمكننا تحديد الخيار restart always-- لنقرر تشغيل الحاوية تلقائيًا عند إعادة تشغيل الخادم، أو عند توقف الحاوية لأي سبب كان.

يوضح المثال التالي تشغيل حاوية أباتشي مع تفعيل إعادة التشغيل التلقائي:

docker run -p 8080:80 --name apache -v "${PWD}":/usr/local/apache2/htdocs -d --restart always httpd

هنالك عدة احتمالات ممكنة للخيار restart-- نتحكم من خلالها في كيفية إعادة تشغيل الحاوية تلقائيًا تشمل التالي:

• restart no-- وهو الإعداد الافتراضي، ويعني عدم تشغيل الحاوية تلقائيًا عند توقف الحاوية لأي سبب كان
• restart always-- إعادة تشغيل الحاوية تلقائيًا بمجرد توقفها، وسيعاد تشغيل جميع الحاويات التي بدأ تشغيلها سابقًا باستخدام هذا الخيار
  تحذير: إذا كانت الحاوية تحتوي على خطأ برمجي تسبب في توقفها، فيتسبب هذا الخيار في محاولة إعادة تشغيلها بصورة مستمرة ومتكررة، إلا لو أوقفناها يدويًا باستخدام الأمر docker stop فعندها سيتوقف تشغيلها في نفس الجلسة، لكن ستعاد محاولة تشغيلها من جديد عند إعادة تشغيل الخادم
• restart unless-stopped-- يعمل هذا الخيار بشكل مشابه لخيار restart always-- الفرق هنا هو عدم إعادة تشغيل الحاوية التي أوقفناها يدويًا باستخدام docker stop
• restart on-failure-- إعادة تشغيل الحاوية تلقائيًا فقط في حالة توقفها بسبب خطأ ما

يمكننا معرفة سلوك إعادة التشغيل حاوية باستخدام الأمر docker inspect:

docker inspect <containername>
  ...
  "RestartPolicy": {
      "Name": "always",
      "MaximumRetryCount": 0
  },
  ...

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

docker update --restart on-failure <containername>

الطريقة الثانية: استخدام Docker Compose

يمكننا أيضًا تحديد طريقة إعادة التشغيل التلقائي للحاوية من خلال ملف docker-compose.yml باستخدام الكلمة المفتاحية restart كما يلي:

services:
   db:
     image: mariadb:latest
     restart: always

هناك أربعة إعدادات مسموح بها هنا وهي:

• no وهو الخيار الافتراضي ويعني إعادة تشغيل الحاوية يدويًا فقط
• always لإعادة تشغيل الحاوية دائمًا
• unless-stopped لإعادة تشغيل الحاوية في كافة الأحوال، إلا في حال أوقفناها يدويًا
• on-failure لإعادة تشغيل الحاوية فقط في حال توقفت نتيجة لحدوث خطأ

تتشابه دلالة الخيارات السابقة مع الخيارات المشروحة في الطريقة الأولى التي تستخدم الخيار restart-- مع الأمر docker run، لكن هنا سيكون المعامل restart: always ساري المفعول حتى نوقف الحاويات الموجودة في الملف docker-compose.yml ونحذفها يدويًا باستخدام الأمر docker-compose down.

ملاحظة: ينبغي التأكد من تحديد الكلمة المفتاحية restart في المستوى الصحيح داخل إعدادات الحاوية المعنية وهي db في المثال.

services:
  db:
    image: mariadb:latest
    volumes:
      - vol-db:/var/lib/mysql
    environment:
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: password
    restart: always

الطريقة الثالثة: إعادة تشغيل الحاوية باستخدام systemd

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

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

يمكن تحقيق ذلك باستخدام مدير الخدمات systemd، كما يمكننا استخدام supervisord أيضًا أو أي نظام مشابه آخر لإدارة الخدمات، ولكننا اخترنا systemd في مقالنا الحالي لكونه الأكثر استخدمًا وهو معتمد في معظم توزيعات لينكس.

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

• إمكانية بدء الخدمة بشكل صحيح عند تشغيل الجهاز
• إمكانية إعادة تشغيل الحاوية تلقائيًا في حال توقفت لأي سبب كان باستخدام إعداد Restart=always في ملف خدمة systemd
• سهولة مراجعة وإدارة سجلات الحاوية stdout بواسطة نظام تسجيل السجلات Journald
• استخدام كامل نظام systemd لإدارة المتطلبات كالتبعيات والأوامر التي يجب أن تنفذ قبل وبعد تشغيل الحاوية وتعريف متغيرات البيئة التي تحتاجها الحاوية بكفاءة

يعرض الكود التالي الحد الأدنى لمحتوى ملف خدمة systemd لتشغيل حاوية دوكر تحتوي على خادم nginx والموجود في المسار /etc/systemd/system/nginx.service:

[Unit]
Description=Docker container

[Service]
ExecStart=/usr/bin/docker run --name nginx \
    --net host \
    -v /srv/nginx/conf.d:/etc/nginx/conf.d \
    -v /srv/nginx/index.html:/usr/share/nginx/html/index.html \
    nginx

ExecStop=/usr/bin/docker stop nginx
ExecStopPost=/usr/bin/docker rm -f nginx

[Install]
WantedBy=multi-user.target

يحدد هذا الملف الأمور التالية:

• تشغيل الحاوية التي تحتوي على خادم nginx تلقائيًا عند تشغيل النظام
• إيقاف الحاوية بشكل صحيح عند إيقاف الخدمة
• حذف الحاوية بعد إيقافها
• تشغيل الخدمة تلقائيًا عند تشغيل النظام ووصوله لمرحلة multi-user target

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

سيعمل جزء WantedBy فقط عند تنفيذ الأمر systemctl enable nginx، وفي هذه الحالة ستفعَّل الخدمة عند بدء التشغيل لأنها ستكون مرتبطة بالوصول لمرحلة multi-user target في systemd، هذا يعني أنه عند تشغيل النظام، ستفعّل الخدمة تلقائيًا.

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

أيضًا، في حالتنا nginx التي هي خدمة عديمة الحالة stateless أي أنها لا تحفظ حالتها بين عمليات التشغيل المختلفة، لذا سيكون من الأفضل تحديث صورة دوكر الخاصة بالخدمة لأحدث إصدار متاح كلما شغلنا هذه الخدمة لنضمن بأنها تعمل بأحدث نسخة من الحاوية، ولتحقيق سنضيف أمر ExecStartPre المسؤول عن تنفيذ docker pull كي يعمل قبل الأمر ExecStart.

كما يمكننا فرض إعادة تشغيل الخدمة دائمًا في حال تعرضت لخطأ، وذلك كل 10 ثوانٍ مثلًا، من خلال الأسطر Restart و RestartSec والتي تشابه في تأثيرها الخيار restart=on-failure في أمر docker run الذي شرحناه في الطريقة الأولى.

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

لحل هذه المشكلة يمكن استخدام حل بسيط وهو استخدام الأمر ExecReload لإعادة تحميل عملية nginx داخل الحاوية فهذا يساعدنا عند الحاجة لتحديث إعدادات nginx أو إعادة تحميلها دون توقف الخدمة بالكامل، كما يمكننا استخدام حل بديل وهو إرسال إشارة باستخدام الأمر kill -s HUP، لنخبر nginx بأن يعيد تحميل إعداداته دون إيقافه بالكامل.

أخيرًا، يمكننا تغيير الأسماء المستخدمة في ملف الخدمة باستخدام متغيرات البيئة في السطر Environment. وفي حال وجدنا أن المتغيرات أصبحت كثيرة أو كانت مشتركة بين عدة ملفات خدمة على نفس الخادم، فيمكن استخدام ملف منفصل للمتغيرات باستخدام الخيار EnvironmentFile.

فيما يلي ملف الخدمة بعد إجراء التحسينات السابقة:

[Unit]
Description=Docker container
BindsTo=docker.service
After=docker.service

[Service]
Environment=NAME=%N
Environment=IMG=nginx
Restart=on-failure
RestartSec=10
ExecStartPre=-/usr/bin/docker kill ${NAME}
ExecStartPre=-/usr/bin/docker rm ${NAME}
ExecStart=/usr/bin/docker run --name ${NAME} \
    -p 80:80 \
    -p 443:443 \
    -v /srv/nginx/conf.d:/etc/nginx/conf.d \
    -v /srv/nginx/html:/usr/share/nginx/html/ \
    ${IMG}
ExecStop=/usr/bin/docker stop ${NAME}
ExecReload=/usr/bin/docker exec ${NAME} nginx -s reload

[Install]
WantedBy=multi-user.target

ملاحظة: يجري استبدال N% تلقائيًا باسم ملف الخدمة، وعلينا أن لا ننسى تشغيل الأمر systemctl daemon-reload في كل مرة نغير فيها إعدادات ملف الخدمة.

مراقبة سجلات الخدمة

عند تشغيل الخدمات باستخدام systemd مثل خدمة nginx في المثال السابق، ستوجه السجلات التي تنتج عن الخدمة إلى سجلات النظام journald، وهذا يسهل علينا الوصول لها وتحليلها.

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

journalctl -fu nginx

لا يمنعنا هذا الأسلوب من الحصول على ملفات سجلات منفصلة، فقد نحتاج لذلك كما في حالة استخدام virtualhosts لإدارة عدة مواقع ويب على نفس الخادم باستخدام nginx، في هذه الحالة سيكون من الأنسب لنا مشاركة مجلد السجلات الخاص بالحاوية وهو بشكل افتراضي /var/log/nginx مع جهاز المضيف حتى لا نفقدها عند إعادة التشغيل.

الخاتمة

تعرفنا في هذا المقال على ثلاث طرق مختلفة لإعادة تشغيل حاويات دوكر تلقائيًا بعد إعادة تشغيل الخادم، يعتمد اختيار الطريقة المناسبة على البئية ومتطلبات العمل، ففي الحالات البسيطة وإعدادات الحاوية الواحدة قد تكون طريقة restart-- في أمر docker run أو طريقة Docker Compose كافية. لكن في البيئات المعقدة التي تتضمن عدة خدمات ستوفر لنا طريقة systemd تحكمًا أكبر بالحاوية.

ترجمة -وبتصرف- للمقال Restart Docker Container Automatically After Reboot لكاتبه Umair Khurshid

اقرأ أيضًا

• ثلاث نصائح لتسمية حاويات Docker
• استخدام الأمر docker exec في حاويات Docker
• أساسيات تنسيق الحاويات
• مدخل إلى الحاويات

يُعرّف سجل دوكر Docker Registry بأنه تطبيق يُدّير عمليات تخزين صور حاويات Docker وتسليمها للمطورين، حيث تكون صور الحاويات متاحة أمامهم في سجلٍ مركزي واحد ومُضمّن فيها جميع المكونات الضرورية لعملها، وفي هذا استثمارٌ كبير لوقت المطوّر، إذ تكفل صور دوكر بيئة تشغيل مماثلة لمتطلباته عبر المحاكاة الافتراضية، وبهذا يمكن للمطور سحب الصورة التي يحتاجها من السجل مع كل ما يلزم وتنزيلها بهيئة مضغوطة، بدلًا من تنزيل الاعتماديات والحزم واحدة واحدة وتثبيتها داخل الحاوية في كل مرة، وبالمثل أيضًا يستطيع المطوّر أتمتة عمليات نشر الصور على السجل باستخدام أدوات التكامل المستمر (CI) مثل TravisCI أو غيرها لتحديث صوره باستمرار في مراحل التطوير والإنتاج.

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

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

متطلبات العمل

ستحتاج لتوفير المتطلبات التالية لتتابع معنا سير العمل خطوة بخطوة:

• خادمين مثبت عليهما نظام تشغيل أوبنتو (الإصدار 22.04 )، ويمكنك اتباع هذا الدليل لتجهيزهما، حيث يتضمن هذا الدليل طريقة إنشاء مستخدم جديد غير مستخدم الجذر لكنه يتمتع بصلاحيات sudo بالإضافة إلى آلية إعداد جدار الحماية للخادم، احرص على تنفيذ هذه الخطوات إذ سيستضيف أحد الخادمين سجل Docker الخاص بك وسنسميه الخادم المضيف host، وسيكون الخادم الآخر عميلًا client يستخدم السجل.

• تثبيت Docker على الخادمين، تساعدك الخطوتان 1 و 2 من مقال كيفية تثبيت دوكر واستخدامه على دبيان  في تنفيذ المطلوب فتثبيت Docker على دبيان يشبه تثبيته على أوبنتو.

اضبط بعد ذلك الإعدادات التالية على الخادم المضيف:

• ثبّت عليه دوكر كومبوزر Docker Compose مستعينًا بالخطوات الواردة في مقال تثبيت الأداة دوكر كومبوز Docker Compose واستخدامها ضمن نظام لينكس أوبونتو.

• ثبّت عليه إنجن إكس Nginx بإتباع الإرشادات الواردة في مقال كيفية تثبيت Nginx على أوبونتو 18.04.

• أمّن حماية الخادم Nginx الموجود على المضيف بشهادات مصدقة من Let’s Encrypt مثلًا لحماية سجل Docker الخاص الذي تنشؤه، اطلّع على مقال كيف تؤمّن خادم ويب NGINX على أوبنتو 16.04 على أكاديمية حسوب أو مقال تأمين خادم NGINX باستخدام Let’s Encrypt على DigitalOcean لإنجاز هذه الخطوة. وتأكد من توجيه حركة مرور البيانات الواردة إلى تطبيقك من HTTP إلى HTTPS.

• احجز اسم نطاق لخادمك المضيف لسجل Docker، واسم النطاق المعتمد في المقال هو your_domain، وتوفير اسم النطاق ضروري قبل البدء بإعدادات خدمة Let’s Encrypt.

الخطوة 1: تثبيت سجل Docker وإعداده

يفيدك تشغيل Docker من سطر الأوامر في بداية التشغيل وعند اختبار الحاويات، لكن استمرارك باستخدامه من سطر الأوامر لن يكون عمليًّا مع تقدم سير العمل، وبالأخص في عمليات النشر واسعة النطاق أو تلك التي تتطلب التحكم بعدة حاويات تعمل معًا على التوازي.

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

تُستخدم أداة Docker Compose أيضًا لإدارة سجل دوكر ومكوناته فهو تطبيق في نهاية الأمر ويتكون من عدة أجزاء.

لتشغيل مثيل instance لسجل Docker على Docker Compose عليك إعداد الملف docker-compose.yml لتعريف السجل، وتوفير مساحة تخزينية له على القرص الصلب ليُخزّن البيانات.

أنشئ في البداية مجلدًا اسمه docker-registry على الخادم المضيف وفق التالي، إذ سنُخزّن فيه إعدادات السجل:

$ mkdir ~/docker-registry

انتقل إلى المجلد الجديد بكتابة التالي:

$ cd ~/docker-registry

وأنشئ بداخله مجلدًا فرعيًّا باسم data، وفق الأمر التالي حيث سيُخزّن السجل صور الحاويات بداخله:

$ mkdir data

أنشئ أيضًا ملفًا نصيًّا باسم docker-compose.yml باستعمال محرر نصوص مثل نانو كما يلي:

$ nano docker-compose.yml

واكتب ضمنه المعلومات التالية، التي تُعرّف المثيل الأساسي لسجل Docker:

version: '3'

services:
  registry:
    image: registry:latest
    ports:
    - "5000:5000"
    environment:
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
    volumes:
      - ./data:/data

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

أما في قسم بيئة العمل environment فقد أسندنا القيمة data/ للمتغير REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY وهو المسؤول عن تحديد المجلد المخصص لتخزين بيانات السجل. وفي القسم volumes وصلنا المجلد data/ على نظام ملفات الخادم المضيف بالمجلد data/ داخل الحاوية، الذي يُعدّ بمثابة معبر فقط إذ ستُخزّن البيانات فعليًّا على الخادم المضيف.

احفظ التغييرات على الملف، وأغلقه وشغّل الآن الإعدادات بتنفيذ الأمر التالي:

$ docker compose up

سيبدأ تحميل حاوية السجل مع اعتمادياتها، وستصبح في وضع التشغيل، ثم ستحصل على خرج يشبه التالي:

[+] Running 2/2
 ⠿ Network docker-registry_default       Created  0.1s
 ⠿ Container docker-registry-registry-1  Created  0.1s
Attaching to docker-registry-registry-1
docker-registry-registry-1  | time="2024-01-19T14:31:20.40444638Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown"
docker-registry-registry-1  | time="2024-01-19T14:31:20.404960549Z" level=info msg="redis not configured" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown"
docker-registry-registry-1  | time="2024-01-19T14:31:20.412312462Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown"
docker-registry-registry-1  | time="2024-01-19T14:31:20.412803878Z" level=info msg="Starting upload purge in 52m0s" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown"
docker-registry-registry-1  | time="2024-01-19T14:31:20.41296431Z" level=info msg="listening on [::]:5000" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown"
...

يتضمن الخرج السابق رسالة تحذير مفادها عدم توفر اتصال HTTP آمن No HTTP secret provided، لا تقلق سنعالجها في الفقرات القادمة.

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

يمكنك الآن الضغط على CTRL+C لإيقاف التنفيذ.

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

الخطوة 2: ضبط إعدادات التوجيه لمنفذ Nginx

ذكرنا في بداية المقال أن تفعيل بروتوكول HTTPS على اسم نطاقك هو أحد متطلبات العمل الأولية، وسنعمل الآن على توجيه حركة مرور البيانات من اسم النطاق إلى حاوية السجل لنضمن أن الوصول لسجل Docker سيجري عبر اتصالٍ آمن.

لابد أنك جهزت الملف etc/nginx/sites-available/your_domain/ أثناء إعدادك لخادم Nginx، إذ يحتوى هذا الملف على قسمٍ خاص بإعدادات الخادم، افتحه بواسطة أي محرر نصوص وفق التالي، لنجري عليه بعض التعديلات:

$ sudo nano /etc/nginx/sites-available/your_domain

ابحث ضمنه عن القسم المسمى location:

...
        location / {
  ...
        }
...

المطلوب في حالتنا أمران: توجيه حركة مرور البيانات إلى المنفذ 5000 الذي يتلقى السجل عبره الطلبات، وإضافة ترويسات headers للطلبات الموجهة إلى السجل تحتوي معلوماتٍ إضافية عنها يضيفها الخادم. استبدل محتوى القسم location بالتالي لتنفيذهما:

...
location / {
    # Do not allow connections from docker 1.5 and earlier
    # docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents
    if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
      return 404;
    }

    proxy_pass                          http://localhost:5000;
    proxy_set_header  Host              $http_host;   # required for docker client's sake
    proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_read_timeout                  900;
}
...

تتأكد الجملة if من توفر عدة شروط قبل أن تسمح للطلب بالمرور إلى السجل، فتتحقق من وكيل المستخدم صاحب الطلب User Agent، ومن كون إصدار Docker الذي يستعمله أعلى من 1.5، ومن أنه ليس تطبيق مبرمج بلغة Go ويسعى للوصول إلى السجل. يمكنك معرفة المزيد عن ترويسة nginx بمراجعة دليل إعداد Ngin لسجل Docker من توثيقات Docker الرسمية.

احفظ التغييرات على الملف، وأعِد تشغيل Nginx بكتابة التعليمة التالية، حتى تأخذ التغييرات مفعولها:

$ sudo systemctl restart nginx

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

سنشغل السجل الآن لنتأكد من توجيه Nginx الطلبات الواردة إلى حاوية السجل، اكتب الأمر التالي:

$ docker compose up

استعرض العنوان التالي في متصفحك، والذي يتضمن اسم النطاق يليه v2 نقطة الوصول endpoint:

https://your_domain/v2

سيعرض لك المتصفح كائن JSON فارغ على الشكل:

وستحصل في الطرفية على الخرج التالي:

docker-registry-registry-1  | time="2024-01-19T14:32:50.082396361Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=779fe265-1a7c-4a15-8ae4-eeb5fc35de98 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="text/html; charset=utf-8" http.response.duration="162.546µs" http.response.status=301 http.response.written=39
docker-registry-registry-1  | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2 HTTP/1.0" 301 39 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"
docker-registry-registry-1  | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2/ HTTP/1.0" 200 2 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"
docker-registry-registry-1  | time="2024-01-19T14:32:50.132472674Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=0ffb17f0-c2a0-49d6-94f3-af046cfb96e5 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.429608ms http.response.status=200 http.response.written=2

يخبرك السطر الأخير أن الطلب GET قد وصل إلى نقطة الوصول /v2/ المذكورة في العنوان الذي طلبته من المتصفح، واستقبلته حاوية السجل (بفضل إعدادات التوجيه التي عملنا عليها) وأرسلت استجابة بكائن JSON {} مع رمز الاستجابة 200 الذي يشير لنجاح العملية.

اضغط الآن CTRL+C لإيقاف التنفيذ.

أنهينا بذلك إعدادات التوجيه وننتقل لإعدادات تأمين السجل.

الخطوة 3: ضبط إعدادات المصادقة Authentication

يتيح Nginx لمستخدمه إعداد آلية مصادقة Authentication باسم مستخدم وكلمة مرور لتقييد الوصول إلى مواقعهم المستضافة عليه وذلك بإنشاء ملف مصادقة htpasswd وكتابة أسماء المستخدمين المسموح له بالوصول إليه مع كلمات مرورهم. سنستخدم هذه الآلية هنا لحماية سجل Docker.

يمكنك الحصول على الأداة htpasswd بتثبيت الحزمة apache2-utils وفق الأمر التالي:

$ sudo apt install apache2-utils -y

سننشئ الآن المجلد docker-registry/auth/~ لتخزين ملف المصادقة الذي يتضمن بيانات الاعتماد، وفق ما يلي:

$ mkdir ~/docker-registry/auth

انتقل للمجلد الجديد بكتابة التالي:

$ cd ~/docker-registry/auth

نفذّ الأمر المبين أدناه لإنشاء المستخدم الأول، واستبدل العبارة username باسم المستخدم الفعلي، واحرص على كتابة الراية B- فهي مسؤولة عن تفعيل خاصية التشفير bcrypt التي تشترطها Docker:

$ htpasswd -Bc registry.password username

سيُطلب منك إدخال كلمة المرور الخاصة بهذا المستخدم، أدخلها بدقة. وستخزن بيانات الاعتماد هذه التي أدخلتها في registry.password.

ملاحظة: أعِدّ تنفيذ الأمر السابق بدون الراية c- لإضافة مستخدمين آخرين إلى الملف وفق التالي:

$ htpasswd -B registry.password username

إذ تشير الراية c- إلى إنشاء ملف جديد، وتعني إزالتها التعديل على الملف الحالي (أي إضافة مستخدمين جدد).

عدّل الآن الملف docker-compose.yml ليستخدم Docker ملف بيانات الاعتماد -الذي أنشأناه- لإجراء المصادقة مع المستخدمين للتحقق من هوياتهم. افتح أولًا الملف بكتابة التالي:

$ nano ~/docker-registry/docker-compose.yml

أضف الأجزاء المتعلقة بالمصادقة إلى محتواه، ليصبح كما يلي:

version: '3'

services:
  registry:
    image: registry:latest
    ports:
    - "5000:5000"
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/registry.password
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
    volumes:
      - ./auth:/auth
      - ./data:/data

أضفت بهذه التعديلات بعض المتغيرات إلى متغيرات البيئة لفرض استخدام المصادقة مع بروتوكول HTTP، ولتوفير مسار الملف htpasswd. فقد حدد المتغير REGISTRY_AUTH الذي يحمل القيمة htpasswd مخطط المصادقة المستخدم أو authentication scheme، وأُسندت القيمة التي تدل على مسار ملف المصادقة إلى المتغير REGISTRY_AUTH_HTPASSWD_PATH، أما المتغير REGISTRY_AUTH_HTPASSWD_REALM فيوضح نطاق تنفيذ المصادقة htpasswd.

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

ودعنا نتأكد من استخدام السجل لإجراء المصادقة. توجه في البداية إلى مجلد السجل الأساسي بكتابة الأمر:

$ cd ~/docker-registry

شغّل السجل بتنفيذ ما يلي:

$ docker compose up

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

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

نجحت إذا عملية المصادقة وسُمح لك بالوصول للسجل بعد إدخال بيانات الاعتماد الصحيحة. يمكنك الخروج بالضغط على CTRL+C في نافذة الطرفية.

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

الخطوة 4: بدء تشغيل سجل Docker بصفته خدمة

يعني تحويل سجل Docker إلى خدمة ضبط بعض الإعدادات في Docker Compose لإبقاء حاوية السجل في وضع التشغيل دائمًا، فتُقلع تلقائيًا مع إقلاع نظام التشغيل، ويُعاد تشغيلها بعد أي عطل.

اكتب الأمر التالي، وافتح الملف docker-compose.yml لنجري عليه بعض التعديلات:

$ nano docker-compose.yml

ابحث ضمن الملف عن قسم السجل المسمى registry، واكتب تحته السطر التالي:

...
  registry:
    restart: always
...

يعني ضبط المحدد restart على القيمة always أن حاوية السجل سيُعاد تشغيلها دائمًا بعد أي طارئ يسبب إيقافها. احفظ الآن التغييرات على الملف، وأغلقه لننتقل إلى الإجراء التالي.

اكتب الأمر المبين أدناه لبدء تشغيل حاوية السجل بصفتها عملية تعمل في الخلفية background process، وذلك بتمرير الراية d-:

$ docker compose up -d

يمكنك إغلاق جلسة SSH والاطمئنان بأن حاوية السجل لن تتوقف فهي الآن تعمل في الخلفية.

ستتناول الخطوة التالية زيادة حجم الملفات التي يُسمح برفعها على خادم Nginx ليناسب حجوم صور الحاويات التي ستحفظ على السجل.

الخطوة 5: زيادة حجم الملفات المسموح رفعها على Nginx

الحجم الأعظمي المسموح رفعه على خادم Nginx افتراضيًا هو 1m أي 1 ميجا بايت للملف الواحد، ويُعدّ صغيرًا نسبيًا موازنةً بحجوم صور الحاويات، لذا يتحتم علينا تغيره قبل البدء برفع الصور إلى السجل. يمكنك تغييره بتعديل قيمته في ملف إعدادات Nginx الموجود في المسار etc/nginx/nginx.conf/.

افتح ملف إعدادات Nginx بكتابة الأمر التالي:

$ sudo nano /etc/nginx/nginx.conf

أضف السطر التالي إلى القسم http ضمنه:

...
http {
        client_max_body_size 16384m;
        ...
}
...

زدنا بهذا التعديل الحجم الأعظمي للملف المسموح برفعه إلى 16 جيجا بايت، وذلك بضبط قيمة المحدد client_max_body_size على 16384m.

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

أعِدّ تشغيل الخادم Nginx لتأخذ التغييرات مفعولها، وفق التالي:

$ sudo systemctl restart nginx

يمكنك الآن رفع الصور إلى السجلات بدون أي أخطاء تتعلق بالحجم من Nginx.

الخطوة 6: نشر صور الحاويات على سجل Docker الخاص

أصبح خادم السجل قادرًا على استيعاب الملفات كبيرة الحجم، لذا سنجرب نشر صورة تجريبية عليه، فإذا لم يتوفر لديك أي صورة لرفعها، يمكنك تحميل صورة أوبنتو من Docker Hub (سجل Docker العام) لتجرب نشرها على هذا السجل.

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

$ docker run -t -i ubuntu /bin/bash

تمنحك الرايتان t- و i- واجهة صدفة shell تفاعلية لتُنفذ بواسطتها الأوامر داخل حاوية أوبنتو.

أنشئ الآن ملفًا يدعى SUCCESS داخل حاوية أوبنتو وفق التالي:

root@f7e13d5464d1:/# touch /SUCCESS

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

اخرج من صدفة الحاوية بكتابة التالي:

root@f7e13d5464d1:/# exit

أنشئ الآن صورة عن هذه الحاوية بعد تخصيصها، بكتابة الأمر التالي:

$ docker commit $(docker ps -lq) test-image

أصبح لديك صورة عن حاوية أوبنتو المخصصة محفوظة محليًا على خادمك، سجِّل دخول إلى سجل Docker وفق التالي لنحاول نشرها عليه:

$ docker login https://your_domain

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

Login Succeeded

بعد تسجيل الدخول بنجاح عدّل تسمية صورة الحاوية كما يلي:

$ docker tag test-image your_domain/test-image

انشرها الآن على سجلك بكتابة الأمر التالي:

$ docker push your_domain/test-image

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

Using default tag: latest
The push refers to a repository [your_domain/test-image]
1cf9c9034825: Pushed
f4a670ac65b6: Pushed
latest: digest: sha256:95112d0af51e5470d74ead77932954baca3053e04d201ac4639bdf46d5cd515b size: 736

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

سحب الصور من سجل Docker الخاص

سنحاول سحب الصورة نفسها التي نشرتها على السجل في الخطوة السابقة.

اكتب الأمر التالي، وسجل دخول إلى سجل Docker من الخادم الرئيسي باستخدام بيانات المستخدمين الذين أنشأتهم سابقًا:

$ docker login https://your_domain

جرّب سحب الصورة test-image من السجل كما يلي:

$ docker pull your_domain/test-image

حمَّل Docker الآن هذه الصورة إلى خادمك المحلي، شغّل حاوية جديدة باستخدامها عبر كتابة ما يلي:

$ docker run -it your_domain/test-image /bin/bash

يوفر لنا هذا الأمر صدفة shell تفاعلية مع الحاوية المُشغّلة.

اكتب ضمنها الأمر التالي لنستعرض نظام ملفاتها:

root@f7e13d5464d1:/# ls

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

root@f7e13d5464d1:/# SUCCESS  bin  boot  dev  etc  home  lib  lib64  media   mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

اخرج الآن من صدفة الحاوية بكتابة الأمر التالي:

$ exit

أنهينا بذلك إنشاء سجل Docker خاص وآمن لتخزين صور الحاويات التي تخصصها حسب احتياجاتك، وجربنا معًا نشر صورة تجريبية عليه وسحبها منه إلى الخادم المحلي.

الخلاصة

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

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

ترجمة -وبتصرف- للمقال How To Set Up a Private Docker Registry on Ubuntu 22.04 لصاحبيه Young Kim و Savic.

اقرأ أيضًا

• ما هي تقنية Docker؟
• استخدام الأمر docker exec في حاويات Docker
• مدخل إلى دوكر Docker
• تثبيت الأداة دوكر كومبوز Docker Compose واستخدامها ضمن نظام لينكس أوبونتو

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

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

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

متطلبات العمل

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

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

تشغيل حاوية تجريبية

يُستخدم الأمر docker exec كما ذكرنا سابقًا مع الحاويات قيد التشغيل، لذا إن لم يكن لديك حاوية تعمل أنشئ واحدة تجريبية وشغّلها باستخدام الأمر docker run وفق التالي:

$ docker run -d --name container-name alpine watch "date >> /var/log/date.log"

يُنشئ هذا الأمر حاويةً جديدة بالاعتماد صورة image لتوزيعة Alpine الرسمية الموجود في مستودعات دوكر. إذ إن Alpine Linux من أشهر توزيعات لينكس المستخدمة مع الحاويات بسبب خفتها في استخدام الموارد وصغر حجمها.

تشير الراية d- إلى فصل الحاوية عن نافذة الطرفية، فتعمل الحاوية في الخلفية، أما name container-name-- فيُحدد اسم الحاوية، سُميّت الحاوية هنا container-name، اكتب الاسم الذي تريده أو يمكنك عدم كتابة أي اسم وترك دوكر Docker يعطي الحاوية اسمًا عشوائيًا فريدًا.

ويأتي بعد اسم الحاوية اسم الصورة التي ستُنشئ الحاوية انطلاقًا منها، واسمها في حالتنا alpine.

وبعدها اكتب الأمر الذي تريد تشغيله داخل الحاوية، وهو في مثالنا "watch "date >> /var/log/date.log. افتراضيًا يكرر الأمر watch تشغيل الأمر المكتوب بعده أي "date >> /var/log/date.log" كل ثانيتين، ويعرض الأمر date التاريخ والوقت الحاليين على الخادم، كما يلي:

Fri Jan 26 14:57:05 UTC 2024

أما الجزء /var/log/date.log/ << فيعني أن نتيجة تنفيذ الأمر date ستُخزن في ملف نصي يدعى /var/log/date.log/، وبالتالي سيُكتب سطرٌ جديد كل ثانيتين في هذا الملف، وبعد عدة ثواني سيبدو محتواه على الشكل التالي:

Fri Jan 26 15:00:26 UTC 2024
Fri Jan 26 15:00:28 UTC 2024
Fri Jan 26 15:00:30 UTC 2024
Fri Jan 26 15:00:32 UTC 2024
Fri Jan 26 15:00:34 UTC 2024

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

اكتشاف اسم حاوية Docker

بما أن الأمر docker exec يعمل مع الحاويات قيد التشغيل، لذا من المهم معرفة اسم الحاوية أو المعرّف الخاص بها Container ID لتمريره له، ويمكنك معرفة أسماء الحاويات ومعلوماتٍ أخرى عنها بواسطة الأمر docker ps كما يلي:

$ docker ps

يعرض لك هذا الأمر أسماء الحاويات التي تعمل على الخادم، مع معلوماتٍ عامة عنها، مثل: صورة الحاوية، والأمر الذي تنفذه الآن، وحالة تشغيلها وغيرها، ألقِ نظرة على خرج الأمر docker ps:

CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS     NAMES
76aded7112d4   alpine    "watch 'date >> /var…"   11 seconds ago   Up 10 seconds             container-name

ستلاحظ في الخرج السابق وجود اسم الحاوية والمُعرّف الخاص بها، وهما ينوبان عن بعضهما، فيمكنك تمرير أي واحد منهما للأمر docker exec للتعامل مع الحاوية.

وإذا رغبت بتغيير اسم الحاوية مثلًا، فاستخدم الأمر docker rename، وفق التالي:

$ docker rename container-name new-name

الآن بعد أن تعلمنا كيف نحصل على اسم الحاوية، سنعرض بعضًا من الأمثلة العملية على طريقة استخدام docker exec لتنفيذ الأوامر في حاوية قيد التشغيل.

تشغيل صدفة Sell تفاعلية في حاوية Docker

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

تُبقي الراية i- إمكانية إدخال البيانات إلى الحاوية متاحة، بينما تُنشئ الراية t- طرفيةً وهمية pseudo-terminal ترتبط بالصدفة shell، ويمكنك استخدام الرايتين معًا في أمرٍ واحد وفق التالي:

$ docker exec -it container-name sh

ينتج عن الأمر السابق تشغيل الصدفة Shell أو sh في الحاوية المحددة، وفتح مِحث أوامر Shell prompt اعتيادي لاستخدامه. وتستطيع الخروج من الحاوية بكتابة exit ثم الضغط على ENTER.

/ # exit

إذا احتوت صورة الحاوية التي تستخدمها صدفةً Shell متقدمة مثل باش Bash، فيمكنك العمل معها باستبدال الرمز sh في الأمر السابق بالرمز bash.

تشغيل أوامر غير تفاعلية في حاوية Docker

يمكنك استخدام docker exec بلا رايات Flags، لتنفيذ الأوامر التي لا تتطلب تفاعلًا مع حاويات Docker قيد التشغيل، ألقِ نظرة على المثال التالي:

$ docker exec container-name tail /var/log/date.log

يُشغّل السطر السابق الأمر tail /var/log/date.log في الحاوية المسماة container-name ثم يعرض لك النتائج، إذ يُظهِر الأمر tail آخر عشر أسطر من ملف الخرج على الشاشة، والذي يبدو مثل التالي:

Mon Jan 29 14:39:33 UTC 2024
Mon Jan 29 14:39:35 UTC 2024
Mon Jan 29 14:39:37 UTC 2024
Mon Jan 29 14:39:39 UTC 2024
Mon Jan 29 14:39:41 UTC 2024
Mon Jan 29 14:39:43 UTC 2024
Mon Jan 29 14:39:45 UTC 2024
Mon Jan 29 14:39:47 UTC 2024
Mon Jan 29 14:39:49 UTC 2024
Mon Jan 29 14:39:51 UTC 2024

لاحظ أن ما نفذناه هنا يشبه فتح صدفة Shell تفاعلية (كما في المثال السابق docker exec -it container-name sh) ثم استدعاء الأمر tail /var/log/date.log لعرض النتائج، فقد حصلنا في الحالتين على الخرج نفسه، ولكننا في الحالة الأولى (أي التفاعلية) فتحنا الصدفة Shell، ثم نفذنا الأمر، وبعدها أغلقنا الصدفة، أما هنا فتمت العملية بأمرٍ واحد فقط وبدون الحاجة لفتح طرفية وهمية.

تنفيذ الأوامر في مجلد بديل ضمن الحاوية Docker

يمكنك تحديد مجلد العمل أو المجلد الذي تود تنفيذ الأوامر فيه ضمن الحاوية بكتابة مساره بعد الراية workdir-- كما في المثال التالي:

$ docker exec --workdir /tmp container-name pwd

حددنا هنا المجلد tmp/ على أنه مجلد العمل، وسيُنفذ ضمنه الأمر pwd، ووظيفة pwd عرض اسم مجلد العمل الحالي، وستحصل بذلك على الخرج التالي:

/tmp

الذي يؤكد أن tmp/ هو مجلد العمل الحالي الذي نُفِّذ فيه الأمر لأنه ظهر في خرج pwd.

تشغيل الأوامر بصفة مستخدم آخر في حاوية Docker

استخدم الراية user-- إذا رغبت بتنفيذ أمرٍ ما ضمن الحاوية بصفتك مستخدمًا آخر أي بصلاحياته والمحددات الخاصة به، كما في المثال التالي:

$ docker exec --user guest container-name whoami

يُنفّذ السطر السابق الأمر whoami بصفة المستخدم guest، وبما أن الأمر whoami يستعمل عادةً لمعرفة هوية المستخدم الحالي فستحصل على هذا الخرج:

guest

كما تلاحظ فقد أكدّ خرج الأمر whoami أن guest هو المستخدم المُنَفِذ.

تمرير المتغيرات إلى داخل حاوية Docker

تساعدك الراية e- على تمرير قيم متغيرات البيئة environment variables إلى داخل الحاوية لتُستخدم عند تنفيذ الأمر، ألقِ نظرة على المثال التالي:

$ docker exec -e TEST=sammy container-name env

يُسنِد هذا الأمر القيمة sammy إلى المتغير TEST ثم يُشغّل الأمر env في داخل الحاوية، علمًا أن وظيفة الأمر env هي عرض كافة متغيرات البيئة أمامك على الشاشة، مثل التالي:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=76aded7112d4
TEST=sammy
HOME=/root

لاحظ أن المتغير TEST أصبح يحمل القيمة sammy بالفعل.

أما إذا احتجت لتمرير عدة متغيرات فاكتبهم بالترتيب واكتب الراية e- قبل كل متغير منهم، وفق ما يلي:

$ docker exec -e TEST=sammy -e ENVIRONMENT=prod container-name env

تستطيع أيضًا تمرير كافة متغيرات البيئة التي تحتاجها إلى الحاوية ضمن ملفٍ نصي يحتوي على قيمها، وذلك بواسطة الراية env-file--.

لكن أول ما عليك فعله تجهيز ملف المتغيرات، لذا افتح أي محرر نصوص تفضله مثل نانو nano أو غيره، وأنشئ بواسطته ملفًا جديدًا كما يلي:

$ nano .env

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

عرّف الآن متغيرات بيئتك بكتابتها ضمن الملف بهيئة ثنائيات اسم وقيمة KEY=value، وبمعدل متغير واحد في كل سطر، كما في المثال أدناه:

TEST=sammy
ENVIRONMENT=prod

احفظ التغييرات على الملف، وأغلقه، لننتقل للخطوة التالية. إذا كنت تستخدم محرر النصوص نانو nano، فاضغط على CTRL+O ثم ENTER لحفظ التغييرات، وبعدها اضغط على CTRL+X للخروج.

نَفِّذ الآن الأمر docker exec بعد كتابة اسم ملف التغيرات بدقة بعد الراية env-file-- كما يلي:

$ docker exec --env-file .env container-name env

وسيظهر أمامك الخرج التالي:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=76aded7112d4
TEST=sammy
ENVIRONMENT=prod
HOME=/root

لاحظ القيم التي حددناها للمتغيرين إنها مضبوطة تمامًا كما كتبناها ملف المتغيرات.

يمكنك أيضًا تمرير عدة ملفات لمتغيرات البيئة مع تكرار كتابة الراية env-file-- قبل كل واحد منها، وإذا حصل أي تعارض بينها في قيم المتغيرات، فإن الملف اللاحق سيكون ذا أولوية أعلى من الملفات التي تسبقه.

أخطاء شائعة

ستواجه بعض الأخطاء الشائعة عند تعاملك مع الأمر docker exec، سنذكر أبرزها، انظر مثلًا الخطأ التالي:

Error: No such container: container-name

يعني الخطأ No such container أن الحاوية التي تطلبها غير موجودة، أو أنك أخطأت في كتابة اسمها، يمكنك استخدام الأمر docker ps لتحري أسباب الخطأ والتحقق من صحة اسم الحاوية التي تريدها فهو يعرض أسماء جميع الحاويات المُشغلة على الخادم.

وهذا خطأ آخر:

Error response from daemon: Container 2a94aae70ea5dc92a12e30b13d0613dd6ca5919174d73e62e29cb0f79db6e4ab is not running

تعني رسالة not running أن الحاوية موجودة ولكنها متوقفة عن العمل، يمكنك تشغيلها بالأمر docker start container-name.

أما الخطأ الأخير الذي نعرضه فهو:

Error response from daemon: Container container-name is paused, unpause the container before exec

يشرح الخطأ نفسه بدقة، فالرسالة Container is paused تعني أن الحاوية موقفة عن العمل مؤقتًا، يمكنك إزالة الإيقاف المؤقت وإعادة تشغيلها باستخدام الأمر docker unpause container-name.

الخلاصة

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

ترجمة -وبتصرف- للمقال How To Use docker exec to Run Commands in a Docker Container لصاحبه Brian Boucheron.

اقرأ أيضًا

• مدخل إلى دوكر Docker
• أساسيات تنسيق الحاويات
• ما هي تقنية Docker؟
• تثبيت الأداة دوكر كومبوز واستخدامها ضمن نظام أوبونتو

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

لماذا نستخدم مينيكوندا؟

لعدة أسباب حيث يستبدل مينيكوندا إصدار بايثون الذي يوفره مدير حزم نظام التشغيل، بإصدار بايثون يُثبته هو في مكان منفصل وله بيئته الخاصة، فنحصل على طبقة عزل إضافية عند استخدامه ضمن حاوية دوكر، ما يوفر لنا مزايا إضافية، فبما أننا نستخدم كوندا المُثبت من قبل مينيكوندا، يمكن استخدام تلك الأداة لتحديد إصدار بايثون الذي يحتاجه التطبيق، ما يفيد المطورين خصوصًا للعمل على عدة نسخ من بايثون معًا على نفس الجهاز، حيث يمكن مثلًا استخدام عدة إصدارات مختلفة من بايثون 3، مثل 3.6 أو 3.7 أو 3.8 أو 3.9 أو إصدارات أقدم منها، ومثلًا لو كان الإصدار الافتراضي الذي نستخدمه هو بايثون 3.9، ونعمل على تطبيق يحتاج لإصدار بايثون 3.7 واعتمادياته الخاصة، يمكن الاستفادة من كوندا لتغيير إصدار بايثون وتثبيت كافة اعتمادياته وذلك بتنفيذ الأمر conda install python=3.7.

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

المستلزمات

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

ولاختبار عملية تشغيل التطبيق باستخدام مينيكوندا داخل دوكر، سنستخدم تطبيق بسيط بالاسم python-app.py يطبع عبارة "Hello World!‎"، وبعدها يمكن تبديل ذلك التطبيق بتطبيق بايثون كامل يستخدم العديد من مكتبات بايثون، والاستفادة من بيئة مينيكوندا التي توفر عدة نسخ من الاعتماديات.

الخطوة الأولى: جلب صورة دوكر (اختياري)

سنستخدم صورة بايثون ذات الوسم slim بدلًا من وسم لينكس apline الخفيفة، لأنها تقدم أداء أفضل لتشغيل التطبيقات، وحجمها تقريبًا 40 ميجابايت مبنية على نسخة ديبيان Buster وإصدار بايثون 3.9.1، هذه الخطوة اختيارية والهدف منها توضيح الفرق بين استخدام نسخة جاهزة أو إنشاء نسخة مخصصة يدويًا باستخدام ملف دوكر Dockerfile، ويمكن تنزيل آخر إصدار من صورة بايثون slim باستخدام أمر docker pull كالتالي:

docker pull python:slim

الخطوة الثانية: إنشاء ملف دوكر Dockerfile بالتخصيصات المطلوبة

ننشئ أولًا مجلد جديد لاحتواء تطبيق دوكر، ثم نُنشئ داخله ملف جديد فارغ ونسميه Dockerfile باستخدام الأمر touch كالتالي:

mkdir python-docker
cd python-docker
touch Dockerfile

سنشرح خطوات عملية بناء صورة دوكر خطوة بخطوة، بعدها سنذكر المحتوى الكامل النهائي لملف Dockerfile.

تحضير الصورة الأساسية

التحديث إلى آخر إصدارات من الحزم الافتراضية باستخدام صورة بايثون slim:

FROM python:slim
RUN apt-get update && apt-get -y upgrade \

تثبيت حزم الاعتماديات الخارجية

نثبت الاعتماديات الخارجية المكتوبة بغير لغة بايثون بحسب ما يحتاجه التطبيق، مثل g++‎:

  && apt-get install -y --no-install-recommends \
    git \
    wget \
    g++ \
    gcc \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

يمكن الاستفادة من Git و Wget لجلب تطبيقات بايثون من المستودعات والعناوين المختلفة، أخيرًا يمكننا تقليص حجم صورة دوكر الناتجة عبر مسح قوائم الحزم باستخدام الأمر rm -rf /var/lib/apt/lists/*‎.

تثبيت مينيكوندا

يُعدل مينيكوندا بعد تثبيته الملف ‎.bashrc ليبدل إصدار بايثون المستخدم إلى الإصدار الخاص به:

ENV PATH="/root/miniconda3/bin:${PATH}"
ARG PATH="/root/miniconda3/bin:${PATH}"
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh \
    && mkdir /root/.conda \
    && bash Miniconda3-latest-Linux-x86_64.sh -b \
    && rm -f Miniconda3-latest-Linux-x86_64.sh \

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

إعداد مينيكوندا مع صدفة باش

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

    && echo "Running $(conda --version)" && \
    conda init bash && \

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

نعيد تحميل باش داخل دوكر للتبديل من إصدار بايثون الافتراضي المثبت على نظام التشغيل الأساسي المٌستخدم في ديبيان، إلى إصدار بايثون الخاص بمينيكوندا:

    . /root/.bashrc && \

ونحدث الحزم الافتراضية داخل حزمة مينيكوندا:

    conda update conda && \

تحضير بيئة كوندا للتطبيق

نُنشئ ونُفعل بيئة كوندا منفصلة خاصة بتطبيق بايثون:

    conda create -n python-app && \
    conda activate python-app && \

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

    conda install python=3.6 pip && \

تثبيت تطبيق بايثون

بحسب طريقة استخدام التطبيق، يمكن تنفيذ أحد أمرين، الأول تثبيته باستخدام pip والذي بدوره يستدعي الملف setup.py ضمن مستودع التطبيق:

    git clone replace-me-with-repo-url
    cd repo-name
    pip install -e .

الثاني تنفيذه مباشرة باستخدام الأمر python:

    git clone replace-me-with-repo-url
    cd repo-name
    python python-app.py

لتجربة العملية بشكل كامل وفهم كيف يمكن تشغيل التطبيق مباشرةً عبر تشغيل حاوية أو داخل صدفة باش باستخدام دوكر، سنستخدم التطبيق المثال الذي ذكرناه سابقًا python-app.py، باتباع الطريقة الثانية ننشئ ملف التطبيق python-app.py:

    echo 'print("Hello World!")' > python-app.py

الملف السابق سيطبع عبارة "Hello World!‎" عند تنفيذه باستخدام الأمرpython python-app.py.

تحديث ملف ‎.bashrc للتطبيق مثل مينيكوندا

كما ذكرنا سابقًا، يُحدث مثبت مينيكوندا ملف ‎.bashrc تلقائيًا بعد تنفيذ الأمر conda init bash، يمكننا تنفيذ أمر مشابه لتطبيقنا، بحيث كلما دخلنا إلى سطر أوامر باش داخل الحاوية سيتم تفعيل البيئة، ويمكن استخدام اسم التطبيق كأمر تشغيل له، سنستخدم الاسم python-app للدلالة على التطبيق:

RUN echo 'conda activate python-app \n\
alias python-app="python python-app.py"' >> /root/.bashrc

تحضير التطبيق للتنفيذ النهائي

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

ENTRYPOINT [ "/bin/bash", "-l", "-c" ]
CMD ["python python-app.py"]

ملف Dockerfile النهائي

باستخدام برنامج محرر نصوص مثل Vim أو Nano أو باستخدام الأمر cat نضيف الأسطر التي شرحناها سابقًا إلى ملف Dockerfile:

FROM python:slim
RUN apt-get update && apt-get -y upgrade \
  && apt-get install -y --no-install-recommends \
    git \
    wget \
    g++ \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*
ENV PATH="/root/miniconda3/bin:${PATH}"
ARG PATH="/root/miniconda3/bin:${PATH}"
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh \
    && mkdir /root/.conda \
    && bash Miniconda3-latest-Linux-x86_64.sh -b \
    && rm -f Miniconda3-latest-Linux-x86_64.sh \
    && echo "Running $(conda --version)" && \
    conda init bash && \
    . /root/.bashrc && \
    conda update conda && \
    conda create -n python-app && \
    conda activate python-app && \
    conda install python=3.6 pip && \
    echo 'print("Hello World!")' > python-app.py
RUN echo 'conda activate python-app \n\
alias python-app="python python-app.py"' >> /root/.bashrc
ENTRYPOINT [ "/bin/bash", "-l", "-c" ]
CMD ["python python-app.py"]

لتشغيل تطبيق مختلف ضمن الحاوية، نبدل السطر التالي:

echo 'print("Hello World!")' > python-app.py

بإحدى الطريقتين المذكورتين سابقًا ضمن قسم "تثبيت تطبيق بايثون".

الخطوة الثالثة: بناء صورة تطبيق بايثون اعتمادا على ملف Dockerfile

أمر بناء صورة معدلة اعتمادًا على ملف Dockerfile هو كالتالي:

docker build -t python-app PATH_to_Dockerfile

الخيار ‎-t يُمكننا من وسم الصورة الناتجة باسم تطبيقنا، بحيث عينا له القيمة python-app في الأمر السابق،

بفرض أن ملف Dockerfile موجود ضمن المجلد الحالي يمكننا إنشاء صورة دوكر جديدة لتطبيق بايثون كالتالي:

docker build -t python-app .

avimanyu@iborg-desktop:~/python-docker$ docker build -t python-app .
Sending build context to Docker daemon   2.56kB
Step 1/8 : FROM python:slim
 ---> 677f7ac99e48
Step 2/8 : RUN apt-get update && apt-get -y upgrade   && apt-get install -y --no-install-recommends     git     wget     g++     ca-certificates     && rm -rf /var/lib/apt/lists/*
 ---> Using cache
 ---> 15ee9c47c83b
Step 3/8 : ENV PATH="/root/miniconda3/bin:${PATH}"
 ---> Using cache
 ---> cfd5ed6b5ec9
Step 4/8 : ARG PATH="/root/miniconda3/bin:${PATH}"
 ---> Using cache
 ---> e70d06b5ff10
Step 5/8 : RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh     && mkdir /root/.conda     && bash Miniconda3-latest-Linux-x86_64.sh -b     && rm -f Miniconda3-latest-Linux-x86_64.sh     && echo "Running $(conda --version)" &&     conda init bash &&     . /root/.bashrc &&     conda update conda &&     conda create -n python-app &&     conda activate python-app &&     conda install python=3.6 pip &&     echo 'print("Hello World!")' > python-app.py
 ---> Using cache
 ---> 8a7957a6abb2
Step 6/8 : RUN echo 'conda activate python-app \nalias python-app="python python-app.py"' >> /root/.bashrc
 ---> Running in e3193e93b631
Removing intermediate container e3193e93b631
 ---> 948f45eb6024
Step 7/8 : ENTRYPOINT [ "/bin/bash", "-l", "-c" ]
 ---> Running in 621624951dcf
Removing intermediate container 621624951dcf
 ---> 6e8824889502
Step 8/8 : CMD ["python python-app.py"]
 ---> Running in dc97f9d0d8fe
Removing intermediate container dc97f9d0d8fe
 ---> 01bae0a9903c
Successfully built 01bae0a9903c
Successfully tagged python-app:latest

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

docker run python-app
avimanyu@iborg-desktop:~/python-docker$ docker run python-app
Hello World!

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

docker run -ti python-app bash
avimanyu@iborg-desktop:~/python-docker$ docker run -ti python-app bash
(python-app) root@2ceec4c9eaa4:/# 

وكما نلاحظ دخلنا إلى بيئة كوندا المفعلة التي أنشأناها سابقًا عبر ملف Dockerfile، استخدمنا الخيار ‎-ti لإنشاء طرفية تفاعلية لاستخدامها، يمكننا أيضًا استخدام الاسم بديل الذي عيناه للتطبيق سابقًا لتشغيله كالتالي:

(python-app) root@2ceec4c9eaa4:/# python-app
Hello World!

لنتحقق أيضًا من استخدامنا لإصدار بايثون الخاص بمينيكوندا وليس الإصدار الافتراضي الخاص بنظام التشغيل:

(python-app) root@2ceec4c9eaa4:/# python --version
Python 3.6.12 :: Anaconda, Inc.

كما ذكرنا سابقًا مينيكوندا هو نسخة مصغرة من أناكوندا، وبعد الانتهاء من التحضير بشكل كامل يمكننا دفع الصورة النهائية للتطبيق إلى Docker Hub في حال كان التطبيق نسخة مفتوحة المصدر ومُستضافة على أحد استضافات المستودعات مثل GitHub أو GitLab أو Gitea أو Bitbucket أو أي مستودع آخر.

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

ختامًا

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

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

ترجمة -وبتصرف- للمقال How to Dockerize Python Applications With Miniconda [A Hybrid Approach] لصاحبه Avimanyu Bandyopadhyay.

اقرأ أيضًا

• مدخل إلى لغة بايثون البرمجية
• مدخل إلى دوكر Docker
• كيفية تثبيت دوكر واستخدامه على دبيان
• مقدّمة عن المُكوّنات المُشترَكة في Docker

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

لجهة التوسع الأفقي يمكنك استخدام أكثر من خادم تطبيق لأداء مهمة تشغيل جانغو مع خادم WSGI HTTP الخاص به (وهو في الغالب Gunicorn أو uWSGI)، وحول توجيه الحركة يمكنك إعداد خادم خاص يوزع الطلبات بين خوادم التطبيق مثل Nginx فهو قادر على القيام بدور الوكيل العكسي reverse proxying و موازن الحمل load balancing، بالإضافة إلى تأمين التخزين المؤقت Cache لمكونات وأصول التطبيق الساكنة static assets، علاوةً على أنه يدعم بروتوكول أمان طبقة النقل TLS لتكون كافة اتصالات التطبيق آمنة عبر HTTPS.

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

ستتعلم في هذا المقال كيفية توسيع تطبيق جانغو Polls -هو اسم التطبيق- المغلف في حاوية توسيعًا أفقيًا بإعداد خادمين للتطبيق يُشغل كل منهما حاوية تتضمن جانغو وخادم Gunicorn، وكيفية تأمينه بتفعيل HTTPS وإعداد خادم ثالث يؤدي وظيفة الوكيل العكسي ويُشغل حاويتين واحدة تتضمن Nginx والأخرى تتضمن عميل Certbot الذي سيوفر لخادم Nginx شهادات TLS مصدقة من Let’s Encrypt وقادرة على منح تطبيقك تقييم عالي بنتائج اختبار SSL Labs، سيتلقى هذا الوكيل العكسي كافة الطلبات الخارجية الواردة ويحولها إلى خادمي تطبيق جانغو للإجابة عليها، وزيادة في الأمان سنقيّد الاتصال الخارجي بحيث يتم عبر الوكيل العكسي حصرًا.

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

• بناء تطبيق جانغو بخادم Gunicorn ووضعه ضمن حاوية دوكر
• توسيع تطبيق جانغو وتأمينه عبر حاوية دوكر وخادم Nginx وخدمة Let's Encrypt
• نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس

متطلبات بيئة العمل

ستحتاج المتطلبات التالية لتتمكن من التطبيق العملي للمقال:

1. ثلاثة خوادم عليها نظام تشغيل أوبنتو (استعملنا في المقال إصدار 18.04 واستعن بمقال التهيئة الأولية لخادم أوبونتو 18.04):

• اثنان منها خوادم تطبيق لزوم تشغيل تطبيقك (جانغو/Gunicorn).
• خادم واحد يؤدي وظيفة الوكيل لزوم تشغيل Nginx و Certbot.
• مستخدم عادي -غير مسؤول- يتمتع بصلاحية sudo وجدار ناري فعال على الخوادم الثلاثة.

2. تثبيت دوكر على الخوادم الثلاثة، اطلع على كيفية تثبيت دوكر واستخدامه على دبيان لإنجاز المهمة إذ طريقة التثبيت نفسها في النظامين.
3. حجز اسم نطاق لتطبيقك، سنعتمد في مقالنا على الاسم your_domain.com، مع العلم بإمكانية حصولك على اسم نطاق مجاني من Freenom.
4. ربط اسم النطاق بعنوان الـ IP العام للخادم الوكيل عبر إضافة سجل DNS من النوع A، يمكنك الحصول على تفاصيل إضافية حول الموضوع بالاطلاع على القسم الخاص بخدمة اسم النطاق DNS على أكاديمية حسوب.
5. خدمة تخزين كائني متوافقة مع S3 ومع إضافة django-storages مثل DigitalOcean Space وظيفتها تأمين المساحة التخزينية اللازمة لملفات تطبيق جانغو الساكنة، مع مجموعة مفاتيح الوصول الخاصة بإدارة هذه المساحة، استرشد بكيفية إعداد مساحة على DigitalOcean Space وعدّل بما يلائم خدمة التخزين التي اخترتها.
6. نظام إدارة قواعد بيانات متوافق مع جانغو مع إنشاء قاعدة بيانات ومستخدم خاص بالتطبيق، نحن اخترنا خادم PostgreSQL، اهتم بالتفاصيل التالية أثناء إنجازك لهذه النقطة لتتمكن من متابعة خطوات المقال:

• استخدم الاسم polls لقاعدة البيانات والاسم sammy لمستخدم قاعدة البيانات (هذه الأسماء ليست ملزمة ولكننا استخدمناها في المقال واستخدامك لها سيسهل عليك المتابعة)، لمزيد من التفاصيل حول الإنشاء استرشد بالخطوة /1/ من مقالنا السابق [بناء تطبيق جانغو بخادم Gunicorn ووضعه ضمن حاوية دوكر]()، مع العلم أن هذه المهمة يمكن إنجازها من أي خادم من الخوادم الثلاثة لبيئة العمل.
• اعتمدنا في المقال على نظام إدارة قواعد البيانات من نوع Managed PostgreSQL cluster الذي توفره DigitalOcean.
• لكن يمكنك تثبيت برنامج PostgreSQL وتشغيله وإعداده بنفسك مع الاستعانة بالفيديو التعليمي تثبيت وإعداد قاعدة بيانات PostgreSQL.

الخطوة 1: إعداد خادم التطبيق الأول

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

تنويه: في حال كنت مستمرًا معنا من المقال السابق [بناء تطبيق جانغو بخادم Gunicorn ووضعه ضمن حاوية دوكر]() فهذه الخطوة ستكون جاهزة لديك ويمكنك الانتقال للخطوة /2/ وهي تجهيز الخادم الثاني.

سنبدأ بتسجيل الدخول إلى خادم التطبيق الأول واستنساخ polls-docker من قسم تطبيقات جانغو Polls في مستودع GitHub فهذا القسم يتضمن عينات تجريبية من التطبيق Polls مجهزة خصيصًا لتوثيقات جانغو التعليمية.

أما القسم polls-docker من المستودع فيتضمن نسخًا معدّلة مسبقًا من تطبيق Polls ومجهزة للعمل بفعالية في بيئة الحاويات، راجع مقالنا السابق بناء تطبيق جانغو بخادم Gunicorn ووضعه ضمن حاوية دوكر لمزيد من المعلومات.

إليك تعليمة الاستنساخ اللازم تنفيذها:

git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

توجه بعدها إلى المجلد django-polls عبر الأمر التالي:

cd django-polls

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

استعرض الملف Dockerfile عبر تعليمة لينكس cat:

cat Dockerfile

وستحصل على الخرج التالي وهو عبارة عن البيانات المكتوبة ضمن الملف Dockerfile:

FROM python:3.7.4-alpine3.10

ADD django-polls/requirements.txt /app/requirements.txt

RUN set -ex \
    && apk add --no-cache --virtual .build-deps postgresql-dev build-base \
    && python -m venv /env \
    && /env/bin/pip install --upgrade pip \
    && /env/bin/pip install --no-cache-dir -r /app/requirements.txt \
    && runDeps="$(scanelf --needed --nobanner --recursive /env \
        | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
        | sort -u \
        | xargs -r apk info --installed \
        | sort -u)" \
    && apk add --virtual rundeps $runDeps \
    && apk del .build-deps

ADD django-polls /app
WORKDIR /app

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

EXPOSE 8000

CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi"]

انظر تعليمات الملف السابق بالترتيب وتابع الشرح الآتي.

سيستخدم الملف صورة دوكر بإصدار بايثون 3.7.4، ويثبت اعتماديات وحزم بايثون اللازمة لكل من جانغو وخادم gunicorn وفق ملف متطلبات التطبيق django-polls/requirements.txt ومن ثم يحذف الملفات غير اللازمة بعد انتهاء التثبيت، وينسخ بعد ذلك كود التطبيق إلى الصورة ويسند قيمة المتغير PATH، وأخيرًا سيحدد البوابة 8000 لاستقبال حركة البيانات الواردة إلى الحاوية، ويشغل خادم gunicorn مع عمال workers عدد /3/ عبر البوابة 8000.

لننتقل إلى بناء صورة الحاوية باستخدام docker build:

docker build -t polls .

سميّنا الصورة polls باستخدام الراية t- ومررنا المسار الحالي . كمسار context للتعليمة build فهو يتضمن كافة الملفات اللازمة لعملية البناء.

بعد انتهاء عملية البناء استخدم الأمر docker images لاستعراض الصور المتاحة:

docker images

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

REPOSITORY          TAG                    IMAGE ID             CREATED              SIZE
polls                           latest                  80ec4f33aae1         2 weeks ago          197MB
python                   3.7.4-alpine3.10     f309434dea3a       8 months ago        98.7MB

تشغيل الصورة هي الخطوة التالية لعملية البناء، إلا أنها تتطلب ضبط متغيرات البيئة الموجودة ضمن الملف env وهو أحد لوازم تعليمة التشغيل docker run، لنعدّل عليه: افتح الملف env الموجود ضمن المجلد django-polls باستخدام محرر النصوص nano:

nano env

سيظهر أمامك الملف بالشكل التالي:

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

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

1. المفتاح السري DJANGO_SECRET_KEY: اختر له قيمة فريدة صعبة التخمين كما توصي توثيقات Docker نقدم لك في الخطوة /5/ من مقال كيفية إعداد تطبيق جانغو عبر DigitalOcean Managed Databases and Spaces إحدى طرق جانغو لتوليد المفاتيح.
2. DJANGO_ALLOWED_HOSTS: أسند له اسم النطاق الخاص بك your_domain.com، أو يمكنك وضع الرمز * لأغراض الاختبار فقط وليس ضمن بيئة العمل الفعلية فهذا الرمز يسمح لأي عنوان IP بالوصول، يحميك هذا المحدد من الهجمات المعتمدة على حقن ترويسة HTTP وفي حال أردت المزيد من المعلومات اطلع على توثيقات جانغو الخاصة بهذا المحدد ضمن Core Settings
3. DATABASE_USERNAME: ضع اسم مستخدم قاعدة البيانات PostgreSQL الذي أنشأته أثناء إعدادك لمتطلبات العمل.
4. DATABASE_NAME: ضع القيمة polls أو الاسم الذي اخترته لقاعدة البيانات أثناء إعدادك لمتطلبات العمل.
5. كذلك الأمر لكلمة المرور DATABASE_PASSWORD.
6. ضع اسم مضيف قاعدة البيانات DATABASE_HOST ورقم بوابة الاتصال معها DATABASE_PORT
7. أما المحددات STATIC_ACCESS_KEY_ID و STATIC_SECRET_KEY و STATIC_BUCKET_NAME و STATIC_ENDPOINT_URL فهي تتعلق بخدمة التخزين الكائني الخارجية، اضبطها بما يتناسب مع الخدمة التي تستخدمها.

احفظ التغيرات على الملف env بعد الانتهاء وأغلقه استعدادًا لتنفيذ أمر تشغيل الحاوية عبر التعليمة docker run التي سنكتبها بطريقة تسمح بتجاوز CMD (التي تحدد افتراضيات بدء التشغيل) وتنشئ أثناء التشغيل مخطط قاعدة البيانات باستخدام كل من manage.py makemigrations و manage.py migrate وفق ما يلي:

docker run --env-file env polls sh -c "python manage.py makemigrations && python manage.py migrate"

لنشرح الأمر السابق، شغلنا صورة الحاوية polls:latest ومررنا لها متغيرات البيئة التي ضبطناها للتو ضمن الملف env، وتجاوزنا الأمر الافتراضي في ملف Dockerfile لننفذ الأمر التالي بدلًا منه الذي أنشأ مخطط قاعدة البيانات بالمواصفات المحددة في كود التطبيق:

sh -c "python manage.py makemigrations && python manage.py migrate"

إن كنت تنفذ docker run للمرة الأولى فستحصل على الخرج التالي:

No changes detected
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

مع العلم أن جانغو لن يجري أي عملية عندما تنفذ migrate في المرات القادمة طالما لم يطرأ أي تغيير على مخطط قاعدة بيانات التطبيق.

نفذ بعدها أمر تشغيل جديد للحاوية مع استدعاء سطر الأوامر الخاص بالصدفة Shell كما يلي:

docker run -i -t --env-file env polls sh

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

python manage.py createsuperuser

استكمل بياناته وهي اسم المستخدم وكلمة المرور والبريد الإلكتروني، واضغط بعدها على الاختصار Ctrl+D للخروج من الحاوية وإنهاء عملها.

أما العملية الأخيرة فهي جمع الملفات الساكنة الخاصة بالتطبيق collectstatic ورفعها على خدمة التخزين الكائني وتتم وفق الأمر التالي علمًا أنها قد تستغرق بعض الوقت:

docker run --env-file env django-polls:v0 sh -c "python manage.py collectstatic --noinput"

يظهر بعدها الخرج التالي:

121 static files copied.

يمكنك الآن تشغيل التطبيق:

docker run --env-file env -p 80:8000 polls

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

[2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0
[2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync
[2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7
[2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8
[2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

مع العلم أن التشغيل هذه المرة وفق الإعدادات الافتراضية المنصوص عليها في ملف Dockerfile وهي:

gunicorn --bind :8000 --workers 3 mysite.wsgi:application

وأن البوابة أو المنفذ 8000 للحاوية فُتحت لتستقبل حركة البيانات القادمة من المنفذ 80 للخادم أوبونتو.

يمكنك الآن كتابة عنوان URL الخاص بالتطبيق polls بمتصفح الإنترنت واستعراضه، لاحظ أنك ستحصل على الخطأ 404 (لم يتم العثور على الصفحة) في حال اكتفيت بالعنوان:

http://APP_SERVER_1_IP/

بسبب عدم وجود بيانات للتطبيق تحت الجذر / لذا اكتب العنوان التالي لتحصل على واجهة polls:

http://APP_SERVER_1_IP/polls

** تنويه **: إذا كنت تستخدم جدارًا ناريًا من النوع UFW فإنك ستلاحظ وجود ثغرة أمنية في عمل حاوية دوكر وهي أن دوكر يتجاهل كافة السياسات الأمنية الموجودة على هذا النوع من الجدران النارية ويسمح بالاتصالات بغض النظر عنها، فقد مكّن الاتصال مع البوابة 80 على الخادم دون أن نضبط مسبقًا أي إعداد على الجدار الناري، هذه الثغرة في الواقع موثقة على GitHub Issue وتعالجها الخطوة /5/ من مقالنا عبر تصحيح إعدادات الجدار الناري UFW، أما في حال كنت تستخدم جدارًا ناريًا أقوى وأكثر تطورًا كالذي توفره DigitalOcean’s Cloud Firewalls على سبيل المثال يمكنك تخطي هذا التحذير.

اكتب الرابط التالي http://APP_SERVER_1_ip/admin للوصول إلى واجهة الدخول للوحة التحكم الخاصة بالتطبيق:

أدخل بيانات المستخدم مدير التطبيق المنشأ سابقًا باستخدام الأمر createsuperuser وستظهر أمامك واجهة الإدارة والتحكم الخاصة بالتطبيق.

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

بعد أن تنتهي من التصفح اضغط Ctrl+c في نافذة كتابة الأوامر السطرية التي تشغل حاوية دوكر لتنهي عمل الحاوية ثم شغلها مجددًا بالنمط المنفصل detached الذي يسمح لها أن تعمل بالخلفية ويمكنك من تسجيل الخروج من جلسة ssh.

اكتب الأمر التالي لتشغيل النمط المنفصل:

docker run -d --rm --name polls --env-file env -p 80:8000 polls

تشير الراية d- إلى النمط المنفصل، بينما تشير الراية rm-- إلى تنظيف نظام ملفات الحاوية بعد إغلاقها، أما polls فهو اسم الحاوية.

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

الخطوة 2: إعداد خادم التطبيق الثاني

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

سجل الدخول إلى خادم التطبيقات الثاني وابدأ باستنساخ القسم polls-docker من مستودع django-polls على GitHub:

git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

توجه إلى المسار التالي:

cd django-polls

أنشئ صورة التطبيق باستخدام docker build:

docker build -t polls .

افتح الملف env بمحرر النصوص الذي تفضله:

nano env

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

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

اضبط قيم الملف بما يناسب بيئتك ثم احفظ التغييرات على الملف وأغلقه.

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

docker run -d --rm --name polls --env-file env -p 80:8000 polls

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

http://APP_SERVER_2_IP/polls 

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

أنهينا تجهيز خادمي تطبيق جانغو لننتقل للخطوة التالية ونجهز حاوية الوكيل العكسي.

الخطوة 3: إعداد حاوية دوكر للخادم Nginx

يتمتع خادم الويب Nginx بالعديد من المزايا أهمها قدرته على أداء وظائف متعددة مثل الوكيل العكسي وموازنة الحمل والتخزين لملفات الموقع، سيؤدي منها في هذه البيئة وظيفة الوكيل العكسي لحماية الواجهات الخلفية لخادمي جانغو وموازن الحمل لتوزيع الطلبات بينهما، كما سيؤمن تشفير الاتصالات مع خوادم التطبيق باستخدام شهادة TLS التي يوفرها Certbot ما يعني أنه سيجبر العميل على استخدام HTTPS عبر إعادة توجيه كافة الطلبات من نوع HTTP إلى المنفذ 443، ومن ثم إيصال طلبات HTTPS إلى خوادم جانغو بعد فك تشفيرها، أما وظيفة التخزين فلن نحتاجها إذ الآلية التي استخدمناها لإفراغ ملفات جانغو على وحدة التخزين الكائني تفي بالغرض.

ونوّد أن نبين لك أن التصميم الذي اخترناه في هذا المقال والمؤلف من خادمي تطبيق كل منهما في حاوية مع حاوية ثالثة تتضمن Nginx هو واحد من عدة خيارات متاحة لكل منها مزايا مختلفة من حيث الأداء والحماية، فعلى سبيل المثال كان الممكن بناء Nginx ضمن إحدى حاويتي التطبيق ليقوم بدور الوكيل محليًا لخادم التطبيق الموجود معه في الحاوية نفسها وللخادم في الحاوية الثانية، وفي احتمالٍ آخر يمكنك بناء حاويتي Nginx فتصبح البنية حاوية Nginx مقابل كل حاوية تطبيق ومن ثم استخدام موازن حمل سحابي من أي مزود خدمة مثل DigitalOcean، أما المفاضلة بين هذه التصاميم المختلفة أنجزها بناءً على تحليل متطلباتك ونتائج اختبار الحمل Load Test الذي يبين لك نقاط الاختناق في كل بنية لتوسعها، فبنية مقالنا مثلًا تتمتع بالمرونة لجهة قابليتها للتوسع بإضافة حاوية Nginx ثانية أو أكثر في أي مرحلة تظهر فيها اختناقات الشبكة بسبب خادم Nginx الوحيد، كذلك يمكننا الاعتماد على موزان حمل سحابي بسرعة أعلى أو موازن حمل من رتبة الطبقة الرابعة L4 مثل HAProxy. والآن بعد أن أعطينا فكرة عن الاحتمالات المتعددة لتصميم البنية لنرجع إلى تطبيقنا العملي.

سجل الدخول إلى الوكيل العكسي Nginx وأنشئ مسارًا يدعى config كما يلي:

mkdir conf

ومن ثم أنشئ ملفًا نصيًا باسم nginx.conf باستعمال أحد محررات النصوص مثل nano:

nano conf/nginx.conf

والصق ضمن هذا الملف الإعدادات التالية:

upstream django {
    server APP_SERVER_1_IP;
    server APP_SERVER_2_IP;
}

server {
    listen 80 default_server;
    return 444;
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name your_domain.com;

    # SSL
    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;

    ssl_session_cache shared:le_nginx_SSL:10m;
    ssl_session_timeout 1440m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

    client_max_body_size 4G;
    keepalive_timeout 5;

        location / {
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_pass http://django;
        }

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/html;
    }

}

جهزنا الإعدادات السابقة بالاعتماد على عدة مصادر تتحدث عن إعداد Nginx مثل GitHub\Certbot و Gunicorn و Docker\Nginx ودراستها وتعديلها لتناسب البيئة، هذه العملية في الواقع خارج نطاق مقالنا لذا ننصحك بالاطلاع على المقال فهم بنية ملف إعدادات nginx وسياقات الإعدادات من أكاديمية حسوب والمقال الذي يتحدث عن خوارزميات اختيار كتل Server و Location ضمن الملف من DigitalOcean لتفهم المزيد عن الإعدادات، أو الاستعانة ببعض الأدوات الخاصة بتجهيز ملف Nginx مثل NGINXConfig على سبيل المثال لا الحصر.

لنشرح الآن دلالات هذه الإعدادات وكيفية عملها حيث أنها تتضمن السياقات الرئيسية upstream و server و location وهي تُعنى بإعادة توجيه طلبات HTTP إلى HTTPS ومن ثم إيصالها إلى خادمي التطبيق مع موازنة الحمل بينهما.

سياقات الملف conf/nginx.conf بالترتيب هي: سياق الخوادم العليا upstream وهو وحيد، يليه ثلاثة سياقات متتالية تسمى سياق الخادم server، وأخيرًا سياق الموقع location وهو مكرر مرتين متتاليتين في نهاية الملف.

يحدد سياق الخوادم العليا upstream الخوادم التي ستتلقى طلبات الوكيل عبر عملية التوجيه proxy_pass:

upstream django {
    server APP_SERVER_1_IP;
    server APP_SERVER_2_IP;
}
. . .

أطلقنا الاسم django على هذا السياق وعرفنا ضمنه خادمي التطبيق عبر كتابة عنوان الـ IP الخاص بكل خادم، أما في حال كنت تستخدم شبكة سحابية افتراضية خاصة VPC للربط بين الخادمين فاستبدل هذه العناوين بعناوين الخوادم الخاصة Private IP وفق إعدادات الشبكة VPC، ويمكنك الاستعانة بالمثال لمزيد من التفاصيل حول تفعيل هذه الشبكة.

بعد توجيه الطلبات من سياق الخوادم العليا، يلتقط أول سياق خادم الطلبات التي لا تخص نطاقك وينهيها، وتعدّ طلبات HTTP المباشرة لخوادم التطبيق مثالًا على الحالات التي يتعامل معها هذا السياق:

. . .
server {
    listen 80 default_server;
    return 444;
}
. . .

أما ثاني سياق من نوع خادم فهو يتلقى الطلبات الواردة إلى نطاقك عبر HTTP ويعيد توجيهها إلى HTTPS عبر توجيه HTTP 301، ليعالجها بعد ذلك سياق الخادم الأخير:

. . .
server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com;
    return 301 https://$server_name$request_uri;
}
. . .

تحدد أسطر التوجيه التالية مسارات شهادة TLS والمفتاح الخاص Secret Key، علمًا أن Certbot سيؤمن هذه الملفات، ومن ثم ستُوصل إلى داخل الحاوية عبر التعليمة mount كما سنرى في المراحل التالية:

. . .
ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
. . .

أما محددات اتصال SSL فتُضبط وفقًا للقيم الافتراضية التي توصي بها Certbot كما يلي:

. . .
    ssl_session_cache shared:le_nginx_SSL:10m;
    ssl_session_timeout 1440m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
. . .

إن رغبت بمعلوماتٍ إضافية عن هذه المحددات وطريقة ضبطها فإننا نرشّح لك مقالين حول الموضوع من Nginx و Mozilla.

استرشدنا بتوثيق Gunicorn الخاص بإعدادات Nginx لضبط عدد الاتصالات الأعظمي المسموح به client_max_body_size وزمن جلسة الاتصال keepalive_timeout وهي المدة الزمنية العظمى التي يتم بعدها قطع الاتصال مع العميل وتقدر بالثانية:

. . .
client_max_body_size 4G;
keepalive_timeout 5;
. . .

لننتقل الآن للسياقات الأخيرة ضمن الملف وهي سياقات الموقع.

يوجه أول سياق موقع Nginx أثناء تلقيمه وعكسه الطلبات إلى خوادم التطبيق المعرّفة ضمن سياق الخوادم العليا upstream وذلك عبر بروتوكول HTTP، مع المحافظة على معلومات ترويسة HTTP لاتصال العميل مثل عنوان الـ IP الأصلي وبروتوكول الاتصال المستخدم وعنوان الهدف:

. . .
location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://django;
}
. . .

اطلع على توثيق Gunicorn وتوثيق النموذج ngx_http_proxy_module لمزيدٍ من المعلومات.

يُسجل سياق الموقع الثاني الطلبات ضمن المسار /well-known/acme-challenge/ لاستخدامها من قبل Certbot للتحقق من اسم النطاق وفق تحدي HTTP-01 وهو أحد أنواع تحديات Let’s Encrypt التي تستخدمها للاختبار والتحقق.

. . .
location ^~ /.well-known/acme-challenge/ {
        root /var/www/html;
}

أغلق الآن ملف الإعدادات بعد حفظ التغييرات، حيث أنه سيُستخدم لتشغيل الحاوية.

لننفذ الآن أمر تشغيل الحاوية وفق الصيغة التالية، بالاعتماد على الصورة nginx:1.19.0 وهي إحدى صور دوكر الرسمية المخصصة لخادم Nginx:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

ستلاحظ أثناء التشغيل ظهور خطأ مفاده عدم وجود الشهادات TLS المذكورة ضمن ملف الإعدادات nginx.conf، ومع ذلك سيكمل دوكر بناء الحاوية وتشغيلها، أما الخطأ سيُعالج في الخطوة التالية بتوفير الشهادات المطلوبة باستخدام Certbot و Let’s Encrypt.

بالرجوع لأمر التشغيل سترى أننا أطلقنا الاسم nginx على الحاوية، وربطنا المنفذ 80 والمنفذ 443 للمضيف بالمنافذ التي تحمل الأرقام نفسها في الحاوية، واستخدمنا الراية v- لوصل ملف الإعدادات nginx.conf الذي ضبطناه مسبقًا إلى المسار etc/nginx/conf.d/nginx.conf/ داخل الحاوية بحيث تعتمده الصورة مع الانتباه إلى التعليمة تضمنت الراية ro التي تشير إلى "read only" أي أن الملف سيكون للقراءة فقط بالنسبة الحاوية فلا يمكن تعديله من داخلها، بالإضافة لذلك وصلنا مسار الجذر لتطبيق الويب إلى المسار var/www/html/ المقابل ضمن الحاوية، أما السطر الأخير في أمر التشغيل وهو nginx:1.19.0 فسيرشد دوكر إلى الصورة المطلوبة على Dockerhub لاستخدامها.

الخطوة 4: إعداد Certbot وتجديد الشهادة من Let’s Encrypt

Certbot هو عميل Let’s Encrypt الأشهر طورته شركة Electronic Frontier Foundation، وظيفته تزويد خوادم الويب بشهادات TLS مجانية مصدقة من Let’s Encrypt تعطي للمتصفحين الثقة بهوية الموقع.

لنبدأ بالتطبيق العملي انطلاقًا من صورة Certbot المتوفرة على Dockerhub، ولكن تأكد أولًا من وجود سجل DNS من النوع A يرتبط بعنوان Public IP للخادم الوكيل، ثم نفذ أمر التشغيل التالي ليوفر عميل certbot الشهادات اللازمة للاختبار staging مع خوادم Let’s Encrypt:

docker run -it --rm -p 80:80 --name certbot \
         -v "/etc/letsencrypt:/etc/letsencrypt" \
         -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
         certbot/certbot certonly --standalone --staging -d your_domain.com

يشغل الأمر السابق الصورة certbot في الوضع التفاعلي، ويربط البوابة 80 على الخادم المضيف مع البوابة 80 ضمن الحاوية، كما أنه ينشئ المسارين /etc/letsencrypt/ و /var/lib/letsencrypt/ ويوصلهما بنفس المسارات على المضيف.

سيعمل Certbot بموجب الأمر السابق بالنمط المستقل أي بدون خادم Nginx ويتصل بخوادم Let’s Encrypt لإنجاز اختبار التشفير والتحقق من النطاق، وأثناء ذلك سيُطلب منك عنوان بريد إلكتروني وتأكيد الموافقة على شروط الخدمة، أدخل المطلوب وانتظر اكتمال العملية وفي حال نجح التحقق من نطاقك ستحصل على الخرج التالي الذي يخبرك بمكان تخزين الشهادة:

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for stubb.dev
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/your_domain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/your_domain.com/privkey.pem
   Your cert will expire on 2020-09-15. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

يمكنك استعراض ملف الشهادة باستخدام cat:

sudo cat /etc/letsencrypt/live/your_domain.com/fullchain.pem

سنعيد الآن تشغيل الحاوية nginx بنفس أمر التشغيل المستخدم في الخطوة /3/ ولكن مع إضافة مسارات Let’s Encrypt التي بنيناها توًا أثناء تشغيل حاوية certbot:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /etc/letsencrypt:/etc/letsencrypt \
    -v /var/lib/letsencrypt:/var/lib/letsencrypt \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

فور إقلاع الحاوية nginx يمكنك أن تجرب فتح التطبيق من خلال المتصفح بوضع الرابط

http://your_domain.com

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

اضغط الآن على الاختصار Ctrl+c للخروج من حاوية Nginx وشغل عميل Cerbot مجددًا ولكن مع حذف الراية الخاص بالاختبار staging--:

docker run -it --rm -p 80:80 --name certbot \
         -v "/etc/letsencrypt:/etc/letsencrypt" \
         -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
         certbot/certbot certonly --standalone -d your_domain.com

ستظهر لك رسالة لاختيار الإجراء الذي ترغب بتنفيذه تجديد الشهادة أو استبدالها، اضغط على الرقم 2 لخيار التجديد ومن ثم زر الإدخال Enter وستحصل بذلك على شهادة TLS فعالة production، ثم شغل الآن حاوية nginx بالاعتماد على هذه الشهادة وفق التالي:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /etc/letsencrypt:/etc/letsencrypt \
    -v /var/lib/letsencrypt:/var/lib/letsencrypt \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

استعرض التطبيق مجددًا بكتابة الرابط في المتصفح:

http://your_domain.com

لاحظ إعادة توجيه طلبك إلى HTTPS وظهور رسالة "لم يتم العثور على الصفحة" بسبب عدم إعداد توجيه افتراضي للتطبيق Polls، استخدم إذًا الرابط التالي:

https://your_domain.com/polls

وذلك لاستعراض واجهة التطبيق التي تشبه الصورة التالية:

زودنا تطبيقنا لغاية الآن بشهادة TLS عبر حاوية Certbot ووكيل عكسي وموازن حمل لتوجيه وموازنة الطلبات الخارجية الواردة إلى خوادم التطبيق، و قبل الانتقال للخطوة /5/ الختامية يتبقى لدينا موضوع أخير وهو تجهيز آلية مناسبة لتجديد صلاحية TLS حيث أن الشهادات التي تعطيها Let’s Encrypt تحتاج إلى تجديد دوري كل 90 يومًا.

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

/var/www/html/.well-known/acme-challenge/

كذلك ستصل طلبات التحقق من Let’s Encrypt لهذا المسار وفق قواعد التوجيه الموجودة في سياقات الموقع ضمن ملف إعدادات Nginx، وعند إتمام عملية التجديد سنحتاج إلى إعادة تحميل Nginx ليستخدم الشهادات الجديدة الصالحة.

يلجأ المستخدمون عادةً إلى أتمتة هذه العملية حتى ينجزها Certbot تلقائيًا وذلك بعدة أساليب أشهرها إضافة العملية على قائمة المهام المجدولة لنظام التشغيل لينكس عبر تعليمة cron، يمكنك الاطلاع على هذه العملية ضمن مقالٍ آخر حول تأمين Node.js من DigitalOcean.

لننهي عمل حاوية Nginx بالضغط على الاختصار Ctrl+c ونعيد تشغيلها في الوضع المنفصل مع الراية d- وفق التالي:

docker run --rm --name nginx -d -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /etc/letsencrypt:/etc/letsencrypt \
    -v /var/lib/letsencrypt:/var/lib/letsencrypt \
  -v /var/www/html:/var/www/html \
    nginx:1.19.0

بينما يعمل خادم Nginx في الخلفية، سنشغل الحاوية certbot مع كل من إضافة webroot-- التي ستحدد مسار الجذر لخادم الويب، والراية dry-run-- لمحاكاة عملية التجديد والتأكد أن كافة الخيارات صحيحة دون القيام بالتجديد فعلًا:

docker run -it --rm --name certbot \
    -v "/etc/letsencrypt:/etc/letsencrypt" \
  -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
  -v "/var/www/html:/var/www/html" \
  certbot/certbot renew --webroot -w /var/www/html --dry-run

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

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for your_domain.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/your_domain.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/your_domain.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

يتوجب علينا بعد ذلك إعادة تحميل Nginx ليستخدم الشهادة المجددة وذلك وفق الأمر التالي:

docker kill -s HUP nginx

حيث ترسل التعليمة HUP إشارة إلى خادم Nginx داخل الحاوية ليعيد تحميل الإعدادات ويستخدم الإعدادات الجديدة بما فيها الشهادات المجددة.

لننتقل الآن للخطوة الأخيرة وهي حماية خوادم الواجهات الخلفية للتطبيق عبر تقيّد الاتصالات الخارجية معها بالخادم الوكيل فقط.

الخطوة 5: منع الوصول الخارجي إلى خادمي تطبيق جانغو

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

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

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

لنبدأ الآن بتعديل إعدادات الجدار الناري UFW المشروحة في مستودع ufw-docker في GitHub لمنع الاتصالات الخارجية مع بوابات المضيف التي فتحها دوكر، فقد مررنا الراية p 80:8000- لحاويات خوادم التطبيق أثناء تشغيلها، ما يعني أن البوابة 80 على المضيف فُتحت ووُجّهت إلى البوابة 8000 على الحاوية وهي بذلك أصبحت متاحة أمام الاتصالات الخارجية أيضًا حيث أنها تمكننا من فتح الرابط:

http://your_app_server_1_IP

سجل الدخول إلى خادم التطبيق الأول وافتح الملف etc/ufw/after.rules/ بامتيازات sudo:

sudo nano /etc/ufw/after.rules

أدخل كلمة المرور واضغط زر الإدخال Enter وستظهر لك محتويات الملف after.rules وهي الإعدادات الخاصة بالجدار الناري UFW:

#
# rules.input-after
#
# Rules that should be run after the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-after-input
#   ufw-after-output
#   ufw-after-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
# End required lines

# don't log noisy services by default
-A ufw-after-input -p udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 68 -j ufw-skip-to-policy-input

# don't log noisy broadcast
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

الصق التعليمات التالية في نهاية الملف السابق (ومصدرها مستودع ufw-docker كما ذكرنا):

. . .

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

تُقيّد التعليمات السابقة الوصول العام إلى البوابات التي فتحها دوكر وتسمح بالوصول لعناوين الشبكة الخاصة فقط وهي هنا 10.0.0.0/8 و 172.16.0.0/12 و 192.168.0.0/16 في حال كنت تستخدم الشبكات الخاصة مثل VPC وبذلك فإن Droplets البوابة الخاصة بهذه الشبكة ستتمكن من الوصول إلى البوابات المفتوحة بينما تُمنع المصادر الخارجية من ذلك، لتعرف المزيد عن إعدادات UFW في هذه الحالة انظر ufw-docker how-it-works.

وفي حال أنك وضعت العناوين العامة Public IP لكل من خادمي التطبيق ضمن سياق الخوادم العليا في ملف إعدادات Nginx ولم تعتمد VPC، فعليك إذًا تعديل إعدادات UFW والسماح صراحةً بحركة البيانات القادمة من الخادم الوكيل Nginx إلى خوادم التطبيق عبر البوابة 80 وذلك عبر إنشاء سياسة خاصة بذلك باستخدام التعليمة allow، استعن لكتابتها بالمقال أساسيات IPTables - قواعد وأوامر شائعة للجدار الناري، واحفظ بعدها التغيرات وأغلق الملف.

أعد تشغيل الجدار الناري ufw ليأخذ الإعدادات الجديدة عبر الأمر:

sudo systemctl restart ufw

تصفح بعدها موقع تطبيقك:

http://APP_SERVER_1_IP

ولاحظ أنه لم يعد متاحًا فقد منعت الاتصالات المباشرة مع خادم التطبيق عبر البوابة 80.

سجل الخروج من الخادم الأول، وكرر الخطوات نفسها على خادم التطبيق الثاني وذلك عبر فتح الملف etc/ufw/after.rules/ بصلاحيات sudo:

sudo nano /etc/ufw/after.rules

ولصق التعليمات التالية في نهايته:

. . .
# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

أغلق الملف بعد حفظ التغييرات، ومن ثم أعد تشغيل الجدار الناري:

sudo systemctl restart ufw

وتصفح موقع الخادم ولاحظ أنه لم يعد متاحًا فقد منعت الاتصالات المباشرة مع هذا الخادم أيضًا.:

http://APP_SERVER_2_IP

افتح الآن الرابط التالي للتأكد من استمرار قدرة الخادم الوكيل على الوصول إلى التطبيق:

https://your_domain_here/polls

ولاحظ أن الوصول ممكن وواجهة التطبيق ستظهر أمامك في المتصفح.

الخاتمة

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

ونقترح عليك بعض الأفكار لتطوير إدارة هذه البيئة منها استخدام أداة التمهيد systemd لإدارة نظامك بشكلٍ أفضل والاطلاع على توثيق دوكر الخاص بالتشغيل التلقائي للحاويات لخيارات متخصصة في التشغيل التلقائي للحاويات، والاستعانة بإحدى أدوات تكوين الحاويات مثل Ansible أو Chef لتسهيل العمل في بعض البيئات التي يستخدم فيها أكثر من مضيف الحاوية نفسها.

دون أن ننسى إمكانية استخدام سجل الصور من Docker Hub وكذلك خط أنابيب pipeline لتسهيل نشر واختبار الصور على خوادم متعددة عوضًا عن إعادة بنائها وضبط إعداداتها مجددًا على كل خادم.

ترجمة -وبتصرف- للمقال How To Scale and Secure a Django Application with Docker, Nginx, and Let's Encrypt لصاحبه Hanif Jetha.

اقرأ أيضًا

• كيف تضبط جدار IPTables لحماية البيانات المنقولة بين خواديمك
• الهجمات الأمنية Security Attacks في الشبكات الحاسوبية
• رموز الإجابة في HTTP
• كيف تؤمّن خادم ويب NGINX

يُعّد جانغو Django واحدًا من أقوى أطر العمل البرمجية التي تسهل عملية تطوير تطبيقات الويب المبنية باستعمال بايثون Python، وذلك لما يتمتع به من مميزاتٍ مفيدة مثل استخدامه تقنية ORM أي ربط الكائنات العلاقية object-relational mapper وتوفيره آلية للتحقق من هوية المستخدمين وواجهة مرنة قابلة للتخصيص لإدارة تطبيقك، بالإضافة إلى امتلاكه خاصية التخزين المؤقت وتشجيعه على تصميم الكود النظيف من خلال مصمم عناوين URL Dispatcher ونظام القوالب Template system.

سنعرض في هذا المقال التعليمي كيفية بناء تطبيق جانغو اسمه Polls قابل للتوسع والنقل بحاويات دوكر Docker، وما يلزم من تعديلات ليعمل بفعالية داخل الحاوية ويتكيف مع متغيرات بيئة التشغيل، كما سنتطرق إلى ضبط تسجيل أحداث التطبيق، وتخزين أو تفريغ أصوله الساكنة static assets وهي صفحات جافاسكريبت وملفات التنسيق CSS في مساحة التخزين الكائني object storage لما له من أثر إيجابي على إدارتها إدارة مركزية سلسة ومنظمة بالأخص في بيئة متعددة الحاويات.

وسننشئ بعد تنفيذ التعديلات المطلوبة -المستوحاة من منهجية Twelve-Factor الخاصة بتطوير تطبيقات ويب سحابية قابلة للتوسع والعمل ضمن الحاويات- على عينة من جانغو Polls صورة التطبيق image ونشغلّها ضمن حاوية دوكر.

بالنتيجة ستغدو في نهاية هذا المقال قادرًا على وضع تطبيق جانغو في حاوية قابلة للنقل، وفي مقالات لاحقة ستتعلم استخدام Docker Compose مع جانغو وخادم Nginx كوكيل عكسي، ومن ثم تطبيق هذه البنى التي تعرفت عليها في حاويات عنقودية مثل كوبيرنتس Kubernetes.

أخيرًا ننصحك بمتابعة خطوات العمل الواردة هنا بالتسلسل لضمان فهم كافة التغييرات التي سنُجريها على التطبيق، ولكن في حال رغبت بتخطي ذلك فيمكنك الحصول على كود التطبيق المعدل من القسم الخاص بتطبيقات polls-docker من مستودع GitHub.

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

• بناء تطبيق جانغو بخادم Gunicorn ووضعه ضمن حاوية دوكر
• توسيع تطبيق جانغو وتأمينه عبر حاوية دوكر وخادم Nginx وخدمة Let's Encrypt
• نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس

متطلبات بيئة العمل

ستحتاج المتطلبات التالية لتتمكن من التطبيق العملي لهذا المقال:

1. تهيئة خادم بنظام تشغيل أوبونتو (استعملنا في المقال إصدار 18.04)، يمكنك الاستعانة بالمقال التهيئة الأولية لخادم أوبونتو 18.04 لتهيئته.
2. تثبيت دوكر على الخادم، استعن بمقال كيفية تثبيت دوكر واستخدامه على دبيان فآلية العمل متشابهة في النظامين، دون أن تنسى إضافة مستخدم أوبونتو الخاص بك إلى مجموعة العمل دوكر ليأخذ صلاحيات العمل اللازمة.
3. توفير خدمة تخزين كائني متوافقة مع S3 تؤمن المساحة التخزينية اللازمة لملفات وأصول تطبيق جانغو الساكنة بالإضافة إلى مجموعة من مفاتيح الوصول لإدارة هذه المساحة، وقد استُخدمت خدمة DigitalOcean Space من ديجيتال أوشن DigitalOcean في هذا المقال ويمكنك اختيار خدمة التخزين من المزود الأنسب لك مع إجراء تغييرات بسيطة تلائمها على خطوات الإعداد.
4. نظام إدارة قواعد بيانات متوافق مع جانغو لإنشاء قاعدة بيانات التطبيق، وقد اخترنا DigitalOcean Managed PostgreSQL cluster استرشد بخطواتنا مع تغيير ما يلزم لقاعدة البيانات الخاصة بك.

الخطوة 1: إنشاء قاعدة البيانات PostgreSQL مع مستخدم قاعدة البيانات

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

sudo apt update
sudo apt install postgresql-client

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

تتطلب هذه العملية معرفة محددات الاتصال مع PostgreSQL cluster مثل عنوان المضيف واسم قاعدة البيانات ورقم البوابة كذلك اسم المستخدم وكلمة المرور، ويمكنك الحصول على كافة هذه البيانات من لوحة التحكم الخاصة بخدمة PostgreSQL cluster ضمن مربع خاص بمحددات الاتصال إن كنت تستخدم نظام إدارة قواعد بيانات سحابي (مثل DigitalOcean أو غيره).

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

psql -U username -h host -p port -d database --set=sslmode=require

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

أنشئ قاعدة بيانات خاصة بمشروعك باسم polls وفق التعليمة التالية (مع التنويه إلى أن كافة تعليمات psql يجب أن تنتهي بفاصلة منقوطة):

CREATE DATABASE polls;

ثم توجه إلى قاعدة البيانات polls الخاصة بك كما يلي:

\c polls;

وأنشئ ضمنها مستخدم قاعدة بيانات لمشروعك باسم sammy مثلًا -أو أي اسم- كما يلي واحرص على حمايته بكلمة مرور قوية:

CREATE USER sammy WITH PASSWORD 'password';

اضبط بعد ذلك القيم الافتراضية لمحددات اتصال المستخدم المنشأ بالتوافق مع توصيات جانغو بحيث لا يتطلب الأمر الاستعلام عنها وإعادة تعيينها مع كل تأسيس جديد للاتصال ما سينعكس إيجابًا على تسريع عمليات قاعدة البيانات، والمحددات المطلوب ضبطها هي: الترميز encoding الذي يأخذ القيمة الافتراضية UTF-8، وآلية عزل العمليات transaction isolation scheme الذي يضبط إلى القيمة "read committed" ومهمته منع قراءة العمليات غير المكتملة uncommitted transactions، وأخيرًا المنطقة الزمنية نثبتها على UTC، وفق التعليمات التالية:

ALTER ROLE sammy SET client_encoding TO 'utf8';
ALTER ROLE sammy SET default_transaction_isolation TO 'read committed';
ALTER ROLE sammy SET timezone TO 'UTC';

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

GRANT ALL PRIVILEGES ON DATABASE polls TO sammy;

وبعدها اخرج من موجه أوامر PostgreSQL باستخدام:

\q

جهزنا بذلك قاعدة البيانات ليُديرها تطبيق جانغو، لننتقل للخطوة الثانية المتمثلة بنسخ كود التطبيق Polls من GitHub وتحديد حزم اعتماديات بايثون اللازمة له.

الخطوة 2: استنساخ مستودع التطبيق والتصريح عن اعتماديات عمله

سنستخدم لعملية الاستنساخ مستودع التطبيق django-polls الذي يتضمن الكود الكامل لتطبيق Polls المجهز لأغراض البرنامج التعليمي في مشروع جانغو.

بدايةً سجل الدخول إلى خادم أوبونتو وأنشئ مجلدًا يدعى polls-project ومن ثم استخدم الأمر git لاستنساخ مستودع django-polls من GitHub:

mkdir polls-project
cd polls-project
git clone https://github.com/do-community/django-polls.git

انتقل إلى django-polls واستعرض محتوياته بتعليمة ls:

cd django-polls
ls

وسينتج الخرج التالي:

LICENSE  README.md  manage.py  mysite  polls  templates

الذي يبين لك محتويات تطبيق django-polls، وهي العناصر المبينة أدناه، نعددها لك بإيجاز ويمكنك تعلم المزيد عنها بالاطلاع على التوثيق الخاص بإنشاء المشاريع من توثيقات جانغو الرسمية:

1. manage.py: أداة سطر الأوامر الرئيسية لتنفيذ أوامر معالجة التطبيق.
2. polls: يتضمن أكواد التطبيق polls.
3. mysite: يتضمن أكواد وإعدادات جانغو project-scope.
4. templates: يتضمن قوالب خاصة بواجهة الإدارة.

أنشئ بعدها ملفًا نصيًا باسم requirements.txt ضمن نفس المسار polls-project/django-polls الذي تكلمنا عنه، وافتحه باستخدام محرر النصوص والصق ضمنه اعتماديات بايثون التالية، ثم احفظ التغييرات على الملف وأغلقه:

boto3==1.9.252
botocore==1.12.252
Django==2.2.6
django-storages==1.7.2
docutils==0.15.2
gunicorn==19.9.0
jmespath==0.9.4
psycopg2==2.8.3
python-dateutil==2.8.0
pytz==2019.3
s3transfer==0.2.1
six==1.12.0
sqlparse==0.3.0
urllib3==1.25.6

كما تلاحظ فقد أوردنا بدقة كافة اعتماديات بايثون التي يحتاج إليها المشروع ومن بينها إضافة django-storages الخاصة بتخزين ملفات وأصول الموقع الساكنة على مساحة التخزين الكائني، وإضافة gunicorn الخاصة بخادم WSGI، كذلك مُحول psycopg2 لمواءمة التخاطب مع قاعدة بيانات PostgreSQL.

والآن بعد أن أنهينا استنساخ التطبيق وحددنا ما يلزمه من اعتماديات لنبدأ بتعديله ليصبح قابلًا للنقل.

الخطوة 3: تكييف جانغو مع متغيرات البيئة

توصي منهجية Twelve-Factor باستخراج بيانات الإعدادات المدمجة مع كود التطبيق التي لا يمكن تعديلها إلاّ بتعديل الكود، وفصلها عن الكود ما يسمح للتطبيق بالتكيّف وتغيير سلوكه تبعًا لمتغيرات بيئة التشغيل، يوافقها في ذلك توصيات إعداد الحاويات لدى كلٍ من دوكر وكوبيرنتس Kubernetes، لذا سنتبع هذا النمط ونعدّل ملف الإعدادات django-polls/mysite/settings.py الخاص بتطبيق جانغو -وهو وحدة بايثون- بحيث يحصل على البيانات من بيئة التشغيل الفعلية المحلية عوضًا عن قراءتها من الكود، وذلك باستخدام الدالة getenv مع الوحدة os. لنبدأ بالتطبيق عمليًا!

سنجعل المحددات المدمجة مع الكود ضمن الملف settings.py تأخذ قيمها من متغيرات البيئة عبر استدعاء الدالة os.getenv وتحديد اسم المتغير المرتبط ضمن قوسين، مع العلم بإمكانية تمرير قيمة ثانية للدالة تسمى بالقيمة الافتراضية أو الاحتياطية تُرجعها الدالة في حال كان المتغير غير معرف، لاحظ التالي:

…
SECRET_KEY = os.getenv('DJANGO_SECRET_KEY')
DEBUG = os.getenv('DJANGO_DEBUG', False)
ALLOWED_HOSTS = os.getenv('DJANGO_ALLOWED_HOSTS', '127.0.0.1').split(',')
…

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

بنفس الطريقة للمتغير أو المحدد DEBUG سيبحث عن متغير بيئة يدعى DJANGO_DEBUG ويأخذ قيمته، وفي حال لم يكن معرفًا فإنه سيأخذ القيمة الاحتياطية false التي ستحمينا من فقدان أي بيانات قد تكون حساسة ما لم نضبط المتغير إلى قيمة true عمدًا.

أما بالنسبة للمتغير أو المحدد ALLOWED_HOSTS فسيُحضر قيمة متغير البيئة المرتبط به DJANGO_ALLOWED_HOSTS ويأخذ قيمته بعد فصله إلى قائمة بايثون باستخدام الدالة ()split مع اعتماد , كفاصل، وفي حال أن المتغير لم يكن معرفًا يأخذ المحدد القيمة 127.0.0.1 الاحتياطية.

فور انتهائك من تعديل المحددات الثلاثة السابقة انتقل لتعديل محدد قاعدة البيانات DATABASES ضمن نفس الملف بحيث يأخذ أيضًا قيمته الافتراضية default من متغيرات البيئة، وذلك وفق التالي:

. . . 
# Database
# https://docs.djangoproject.com/en/2.1/ref/settings/#databases

DATABASES = {
     'default': {
         'ENGINE': 'django.db.backends.{}'.format(
             os.getenv('DATABASE_ENGINE', 'sqlite3')
         ),
         'NAME': os.getenv('DATABASE_NAME', 'polls'),
         'USER': os.getenv('DATABASE_USERNAME', 'myprojectuser'),
         'PASSWORD': os.getenv('DATABASE_PASSWORD', 'password'),
         'HOST': os.getenv('DATABASE_HOST', '127.0.0.1'),
         'PORT': os.getenv('DATABASE_PORT', 5432),
         'OPTIONS': json.loads(
             os.getenv('DATABASE_OPTIONS', '{}')
         ),
     }
 }
 . . .

لاحظ أننا استخدمنا json.loads لتعيين قيمة محدد قاعدة البيانات وفق الصيغة:

DATABASES['default']['OPTIONS']

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

دون أن تنسى تفعيل مكتبة json ضمن ملف الإعدادات settings.py وفق التالي حتى تتمكن من استخدام هذا النوع من المتغيرات:

"""
Django settings for mysite project.

Generated by 'django-admin startproject' using Django 2.1.

For more information on this file, see
https://docs.djangoproject.com/en/2.1/topics/settings/

For the full list of settings and their values, see
https://docs.djangoproject.com/en/2.1/ref/settings/
"""
import os
import json
. . .

نشير أيضًا إلى محدد آخر يستدعي الاهتمام هو اسم قاعدة البيانات:

DATABASES['default']['NAME']

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

وفي ختام التعديل لا بد لنا من الإشارة إلى أن الملف setting.py هو في النهاية ملف بايثون وبالتالي يمكنك قراءته والتعديل عليه بالطريقة التي تفضلها وما اتبعناه لهذا الغرض كان إحدى سبل التعديل المتاحة.

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

الخطوة 4: تفريغ المكونات الساكنة Offloading Static Assets

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

أما عن ضبط المحددات الخاصة بهذه الوحدة سنترك بعضها مدمجًا مع الكود hard-coded ونمرر بعضها الآخر لحاويات تطبيق جانغو عبر متغيرات البيئة بنفس الطريقة التي اتبعناها في الخطوة /3/ السابقة للتعامل مع محددات قاعدة البيانات.

يتطلب هذا النوع من التخزين تثبيت حزمة django-storages التي تدعم وجود واجهات خلفية بعيدة للتطبيق تُخزن عليها المكونات والأصول الساكنة بما فيها وحدات التخزين الكائني المتوافقة مع S3 مثل DigitalOcean Space المستخدمة في مقالنا أو غيرها، ويمكنك الاستعانة بمقالة أجنبية أخرى تشرح عملية التفريغ في الخطوة رقم 7 منها.

سنبدأ بتعديل الملف django-polls/mysite/settings.py وهو نفس الملف الذي تعاملنا معه في الفقرة السابقة بإضافة التطبيق storages على قائمة التطبيقات التي يستخدمها جانغو وذلك من خلال المحدد INSTALLED_APPS كما يلي:

. . .
INSTALLED_APPS = [
    . . .
    'django.contrib.staticfiles',
    'storages',
]
. . .

تذكر أن التطبيق storages هو أحد الاعتماديات التي حددناها في الملف requirements.txt الذي ورد في الخطوة /1/ من الإعداد (وذلك من خلال django-storages).

وبعد INSTALLED_APPS سنعدّل المحدد STATIC_URL كما يلي:

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/

# Moving static assets to DigitalOcean Spaces as per:
# https://www.digitalocean.com/community/tutorials/how-to-set-up-object-storage-with-django
AWS_ACCESS_KEY_ID = os.getenv('STATIC_ACCESS_KEY_ID')
AWS_SECRET_ACCESS_KEY = os.getenv('STATIC_SECRET_KEY')

AWS_STORAGE_BUCKET_NAME= os.getenv('STATIC_BUCKET_NAME')
AWS_S3_ENDPOINT_URL = os.getenv('STATIC_ENDPOINT_URL')
AWS_S3_OBJECT_PARAMETERS = {
    'CacheControl': 'max-age=86400',
}
AWS_LOCATION = 'static'
AWS_DEFAULT_ACL = 'public-read'

STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

STATIC_URL='{}/{}/'.format(AWS_S3_ENDPOINT_URL, AWS_LOCATION)
STATIC_ROOT = 'static/'

كما أسلفنا في مقدمة الفقرة، فإن بعض المحددات ستبقى مدمجة مع الكود hard-coded وهي:

1. STATICFILES_STORAGE: يحدد الواجهة الخلفية التي يستخدمها جانغو لتفريغ الملفات الساكنة والقيمة S3Boto3Storage لهذا المحدد ستعمل مع كافة خدمات التخزين المتوافقة مع S3 بما فيها DigitalOcean Spaces.
2. AWS_S3_OBJECT_PARAMETERS: يحدد معايير التخزين المؤقت cache control الخاصة بمكونات التطبيق الساكنة.
3. AWS_LOCATION: يحدد مسار تخزين كامل الملفات الساكنة على خدمة التخزين الكائني وهذا المسار يسمى static.
4. AWS_DEFAULT_ACL: يحدد قائمة التحكم بالوصول ACL لملفات التطبيق الساكنة، واختيار القيمة public-read لهذا المحدد يعني أن الملفات قابلة للقراءة من قبل العامة.
5. STATIC_URL: يحدد العنوان الرئيس للملفات الساكنة Base URL ويتشكل بجمع مكونين الأول هو endpoint URL ويشير إلى خدمة التخزين الكائني والثاني هو مسار وجود الملفات الساكنة للتطبيق.
6. STATIC_ROOT: يحدد المسار المحلي لتجميع الساكنة قبل نسخها إلى خدمة التخزين الكائني.

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

1. AWS_ACCESS_KEY_ID: يأخذ قيمته من متغير البيئة STATIC_ACCESS_KEY_ID الذي يشير إلى معرف مفتاح الوصول الخاص بخدمة التخزين (وهي DigitalOcean Spaces في حالتنا).
2. AWS_SECRET_ACCESS_KEY: يأخذ قيمته من المتغير STATIC_SECRET_KEY ويشير إلى المفتاح السري لخدمة التخزين.
3. AWS_STORAGE_BUCKET_NAME: يأخذ قيمته من المتغير STATIC_BUCKET_NAME ويدل على الموقع الذي ستُرفع ملفات جانغو الساكنة إليه على خدمة التخزين.
4. AWS_S3_ENDPOINT_URL: يأخذ قيمته من المحدد STATIC_ENDPOINT_URL ويستخدم للوصول إلى خدمة التخزين الكائني، فسيكون شكله من قبيل هذا العنوان https://nyc3.digitaloceanspaces.com في خدمة DigitalOcean Spaces على سبيل المثال بالطبع مع بعض الاختلافات المتعلقة بالمنطقة التي تحوي ملفاتك.

لا تنسَ حفظ التغيرات على الملف settings.py قبل إغلاقه.

ننهي بذلك الضبط المتعلق بالمكونات الساكنة، وبموجبه سيرفع جانغو ملفاته إلى وحدة التخزين الكائني البعيدة في كل مرة تشغل فيها manager.py collectionstatic لتُجمَّع الملفات الساكنة لمشروعك.

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

لننتقل الآن للخطوة التالية وهي ضبط تسجيل أحداث جانغو ضمن مجرى قياسي للخرج والخطأ STDOUT و STDERR تتعامل معه حاوية دوكر من خلال docker logs، وهذا سيكون تعديلنا الأخير على settings.py.

الخطوة 5: ضبط تسجيل الأحداث

إذا كنت تعتمد خادم التطوير المدمج في إطار العمل جانغو ليؤدي دور خادم HTTP لتطبيقك، وفعلت خيار التنقيح بإعطاء DEBUG القيمة true فإن جانغو سيُسجل الأحداث تلقائيًا في مجرى خرج قياسي STDOUT ومجرى خطأ قياسي STDERR، أما الإخلال بأي من الشرطين سواءً باستخدام خادم HTTP مغاير لخادم التطوير أو بإعطاء القيمة false للمحدد DEBUG، وكلاهما شائع في بيئة العمل الفعلية، فستتغير آلية التسجيل للتطبيق فبدلًا من تسجيل كافة الأحداث التي تحمل مستوى الخطورة INFO وما فوق ضمن المجرى القياسي، فإنه سيبعث الأحداث التي تحمل المستوى ERROR أو CRITICAL إلى البريد الإلكتروني لمدير النظام.

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

من هذه النقطة تبرز الحاجة لتعديل تسجيل أحداث جانغو ليتماشى مع هذه البنية ويعطي ملفات الخرج المرغوبة، والتطبيق مرن من هذه الناحية، فهو يستخدم وحدة التسجيل logging من مكاتب بايثون القياسية التي تتيح تعريف قاموس مخصص للتسجيل بالتفاصيل والصيغ التي نريدها وذلك باستخدام الدالة logging.config.dictConfig.

لنبدأ التطبيق العملي! افتح الملف django-polls/mysite/settings.py عبر محرر النصوص، واكتب ضمنه تعليمة import إضافية خاصة بـ logging.config ستسمح لك بتجاوز سلوك التسجيل الإفتراضي لتطبيق جانغو عبر تمرير قاموس تسجيل الأحداث التي ترغب بها للدالة dictConfig، كما يلي:

import json
import os
import logging.config
. . .

ثم انتقل إلى نهاية الملف والصق الكود التالي الخاص بإعدادات تسجيل الأحداث:

. . .
# Logging Configuration

# Clear prev config
LOGGING_CONFIG = None

# Get loglevel from env
LOGLEVEL = os.getenv('DJANGO_LOGLEVEL', 'info').upper()

logging.config.dictConfig({
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'console': {
            'format': '%(asctime)s %(levelname)s [%(name)s:%(lineno)s] %(module)s %(process)d %(thread)d %(message)s',
        },
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'console',
        },
    },
    'loggers': {
        '': {
            'level': LOGLEVEL,
            'handlers': ['console',],
        },
    },
})

لنناقش التعليمات السابقة: أعطينا المحدد LOGGING_CONFIG القيمة none وذلك لتعطيل النمط الإفتراضي لتسجيل جانغو، ومنحنا LOGLEVEL قيمة افتراضية هي info مع ترك المجال مفتوح لتجاوزها عند الحاجة بتمرير أي قيمة أخرى نريدها عن طريق متغير البيئة DJANGO_LOGLEVEL.

وأخيرًا استخدمنا الدالة dictConfig لتعيين قاموس تسجيل الأحداث المرغوب الذي ستعتمده الوحدة logging.config، حددنا في القاموس طريقة تنسيق النص عبر formatters بحيث يتضمن مستوى خطورة الحدث ونوع الخط وغيرها من التفضيلات، كذلك حددنا الخرج عن طريق إعداد handlers، ومن ثم وضحنا كل سوية حدث بأي handler ترتبط باستخدام المسجلين loggers.

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

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

الخطوة 6: كتابة الملف Dockerfile لحاوية التطبيق

نقدم لك في هذه الفقرة إحدى أبسط الطرق لبناء صورة الحاوية container image اللازمة لتشغيل تطبيق جانغو مع خادم Gunicorn WSGI الخاص به، وكل ما يلزم العملية من إعدادات، مع العلم بوجود طرق أخرى يمكنك اتباعها.

اختيار صورة الحاوية المناسبة للبناء عليها

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

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

تنويه: ستلاحظ أثناء استعراضك صور الحاويات المعتمدة على لغة بايثون أن كل صورة تحمل أكثر من وسم tag وأن الوسوم نفسها توضع على صورٍ مختلفة، فمثلًا الوسم 3alpine يشير إلى تثبيت أحدث إصدار من بايثون 3 على أحدث إصدار من Alpine وفي حال نزل إصدار جديد من أحدهما فسيُعاد تعيين الوسم على الصورة الجديدة أيضًا، لذا اختر الصورة التي تحمل الوسوم الأكثر تحديدًا لتحصل على أقرب صورة للبيئة التي ترغب بتحقيقها، وفي مثالنا الحالي سنستخدم الصورة ذات الوسم 3.7.4-alpine3.10.

سنحدد المستودع ووسم الصورة في ملف Dockerfile الخاص بتطبيقنا وذلك باستخدام التعليمة from، لنخرج أولًا من مجلد التطبيق django-polls حيث كنا نطبق التعليمات في الخطوات السابقة وذلك وفق الأمر التالي:

cd ..

أصبحنا الآن في المجلد الأب polls-project لننشئ ضمنه ملف نصي باستخدام المحرر ونسميه Dockerfile ونكتب فيه التعليمة التالية التي تعدّ نقطة البداية في إنشاء صورة الحاوية التي نجهزها للتطبيق:

FROM python:3.7.4-alpine3.10

كتابة التعليمات التنفيذية الخاصة بإعداد التطبيق للحاوية

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

نضيف الكود التالي إلى الملف Dockerfile بعد تعليمة from السابقة:

. . .

ADD django-polls/requirements.txt /app/requirements.txt

RUN set -ex \
    && apk add --no-cache --virtual .build-deps postgresql-dev build-base \
    && python -m venv /env \
    && /env/bin/pip install --upgrade pip \
    && /env/bin/pip install --no-cache-dir -r /app/requirements.txt \
    && runDeps="$(scanelf --needed --nobanner --recursive /env \
        | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
        | sort -u \
        | xargs -r apk info --installed \
        | sort -u)" \
    && apk add --virtual rundeps $runDeps \
    && apk del .build-deps

ADD django-polls /app
WORKDIR /app

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

EXPOSE 8000

سنقدم فيما يلي شرحًا لبعض ما ورد ضمن الكود السابق ولمزيد من المعلومات يمكنك الاطلاع على ملف Dockerfile جاهز لتطبيق جانغو.

تتضمن التعليمة الأولى نسخ الملف requirements.txt إلى المسار app/requirements.txt/ بحيث تصبح اعتماديات التطبيق اللازمة موجودة ضمن نظام ملفات الصورة ليتم استخدامها في تنزيل كافة حزم بايثون الضرورية لعمل التطبيق، لاحظ أننا وضعنا هذه التعليمة في خطوة منفصلة وذلك ليقوم دوكر بتخزين الصورة التي تتضمن requirements.txt في طبقة منفصلة ما يتيح له إعادة استخدامها عند الحاجة عوضًا عن بنائها من جديد (بالطبع على فرض أن الاعتماديات لم تتغير)، ذلك أن دوكر ينشئ طبقة للصورة على نظام الملفات بعد تنفيذ كل تعليمة ADD أو RUN أو COPY.

أما التعليمة الثانية RUN فهي تشتمل على مجموعة من أوامر لينكس يجمع بينها الإشارة && لتنفيذها على التوالي نوردها بإيجاز:

• تثبيت PostgreSQL وبناء اعتماديتها باستخدام apk مدير حزم Alpine.
• إنشاء البيئة الافتراضية.
• تثبيت اعتماديات بايثون المذكورة في الملف requirements.txt وذلك باستخدام pip.
• إعداد قائمة بالحزم المطلوبة للتشغيل من خلال تحليل متطلبات حزم بايثون المثبتة.
• إزالة تثبيت أي اعتماديات مبنية ولم تعد لازمة.

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

أما التعليمة الثالثة بعد Run كانت ADD وهي تهدف إلى نسخ كود التطبيق ومسار العمل WORKDIR وذلك لضبط مسار العمل في الصورة على مسار التطبيق.

تعرّف التعليمة الرابعة ENV اثنين من متغيرات البيئة التي ستكون متاحة ضمن الحاوية، المتغير الأول هو VIRTUAL_ENV ويأخذ القيمة env/ أما المتغير الثاني PATH يضبط على المسار env/bin/، وتحاكي هذه العملية الطريقة التقليدية المتبعة لتفعيل البيئة الافتراضية للتطبيق عبر سكريبت env/bin/activate/.

أما العملية الأخيرة في هذه المرحلة فهي تحديد البوابة 8000 للاتصال مع الحاوية في وقت التشغيل عبر تعليمة EXPOSE.

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

تحديد الأمر الافتراضي

يُكتب الأمر الافتراضي لحاوية دوكر في الملف Dockerfile باستخدام تعليمة ENTRYPOINT أو تعليمة CMD أو كلاهما معًا، ويحدد هذا الأمر ما سيُنفذ افتراضيًا عند بدء تشغيل الحاوية.

في حال استخدمنا ENTRYPOINT و CMD معًا فإن الأولى ستحدد الأمر التنفيذي (الإجراء) الذي سينفذ عند تشغيل الحاوية والثانية ستحدد قائمة الوسطاء arguments اللازمة له.

علمًا أن المستخدم يستطيع بسهولة تجاوز الوسطاء المعرّفين في CMD وذلك بتمرير وسطاء غيرهم لأمر تشغيل الحاوية كما يلي:

docker run <image> <arguments>

بينما لا يمكنه بنفس السهولة تجاوز الأمر التنفيذي الوارد في ENTRYPOINT لذا يلجأ الأغلبية لجعل الأمر التنفيذي المعطى لـ ENTRYPOINT على هيئة سكريبت يهيئ البيئة وينفذ الإجراءات التي تتناسب مع قائمة الوسطاء التي يتلقاها.

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

• استخدام ENTRYPOINT لوحدها يحدد الأمر التنفيذي للحاوية فقط دون تحديد قائمة الوسطاء.
• أما استخدام CMD لوحدها يتيح تحديد الأمر command والوسطاء arguments مع إمكانية تجاوز الوسطاء لاحقًا عبر docker run كما أسلفنا.

لنطبق عمليًا على الصورة التي نبنيها ونناقش المتطلبات التي ستقودنا لاختيار التعليمة المناسبة لبدء التشغيل.

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

تكتب CMD عمومًا بثلاث صيغ:

1. تمرير الوسطاء لتعليمة ENTRYPOINT:

CMD ["argument 1", "argument 2", . . . ,"argument n"]

2. بصيغة exec:

CMD ["command", "argument 1", "argument 2", . . . ,"argument n"]

3. بصيغة shell:

CMD command "argument 1" "argument 2" . . . "argument n"

تستخدم CMD في الصيغة الأولى مع ENTRYPOINT لتمرير قائمة الوسطاء فقط كما ذكرنا، أما في الصيغتين الثانية والثالثة تكون مسؤولة عن تحديد الأمر الذي سينفذ وكذلك الوسطاء، والفرق بينهما أن صيغة exec (وهي الصيغة الموصى بها) تنفذ الأمر المحدد مباشرةً وتمرر قائمة الوسطاء دون القيام بأي عمليات أو معالجة في الصدفة shell، أما في صيغة الصدفة shell فإن قائمة الوسطاء تُمرر إلى sh -c، وقد تكون ضرورية لك في الحالات التي تحتاج فيها لتبديل أحد متغيرات البيئة التي يستخدمها الأمر.

بالنتيجة اعتمدنا الشكل النهائي التالي لتحديد افتراضات تشغيل الصورة، وكُتب ضمن Dockerfile كما يلي:

. . .
CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi:application"]

وبموجبه تشغل الحاوية gunicorn على الجهاز المحلي localhost افتراضيًا وذلك عبر البوابة 8000 باستخدام عمال workers عدد 3، كما أنها تشغل الدالة application الموجودة ضمن الملف wsgi.py في المسار mysite.

وبذلك أصبحنا جاهزين للمرحلة التالية وهي استخدام الأمر docker build لبناء صورة التطبيق والأمر docker run لتشغيل الحاوية.

بناء صورة دوكر

يبني docker build الصورة باستخدام كل من ملف dockerfile الذي يتضمن إعدادات البناء، وسياق "context" الذي يشير إلى مسار مجموعة الملفات التي يجب أن تتوفر لعفريت دوكر Docker daemon لينجز عملية البناء.

المتغير "context" يطابق في معظم الأحيان المسار الحالي الذي نكون فيه عند تنفيذ الأمر docker build ويُشار إلى المسار الحالي في لينكس برمز النقطة . .

للتنفيذ العملي، ابحث عن مسار الملف Dockerfile ونفذ ضمنه التالي مع تمرير اسم الصورة بعد الراية t- بالإضافة إلى تمرير المسار الحالي:

docker build -t django-polls:v0 .

لاحظ أننا أعطينا الاسم django-polls للصورة أما v0 فهي تشير للإصدار رقم 0 من الصورة، حيث أن عفريت دوكر الذي يعمل في الخلفية يبني الصورة عبر سلسلة من الطبقات بناءً على بنية تعليمات ملف Dockerfile.

سنحصل على الخرج التالي فور إكتمال تنفيذ الأمر docker build:

Successfully built 8260b58f5713
Successfully tagged django-polls:v0

نظريًا يمكنك تشغيل الحاوية عبر الأمر docker run بعد انتهاء عملية البناء بنجاح، ولكن في الواقع سيفشل الأمر run ما لم تعرف داخل الحاوية كافة متغيرات البيئة التي حددناها خارجيًا في الخطوات السابقة مثل SECRET_KEY ومحددات قاعدة البيانات ضمن الملف setting.py وغيرها، وهو ما سنقوم به في الخطوة التالية.

الخطوة 7: ضبط متغيرات بيئة التشغيل واختبار التطبيق

يوفر دوكر عدة طرق لتعريف المتغيرات داخل الحاوية، ولكون حالتنا تتطلب إعادة تعريف كامل المتغيرات التي عملنا عليها في الخطوة /1/، سنتبع الطريقة env-file التي تتيح تمرير ملف يتضمن كامل متغيرات البيئة وقيمة كل منها.

لتنفيذ ذلك سننشئ ملفًا نصيًا يدعى env ضمن المجلد polls-project مع لصق القائمة التالية ضمنه وهي تحتوي كامل المتغيرات وقيمها:

DJANGO_SECRET_KEY=your_secret_key
DEBUG=True
DJANGO_ALLOWED_HOSTS=your_server_IP_address
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=sammy
DATABASE_PASSWORD=your_database_password
DATABASE_HOST=your_database_host
DATABASE_PORT=your_database_port
STATIC_ACCESS_KEY_ID=your_space_access_key_id
STATIC_SECRET_KEY=your_space_secret_key
STATIC_BUCKET_NAME=your_space_name
STATIC_ENDPOINT_URL=https://nyc3.digitaloceanspaces.com
DJANGO_LOGLEVEL=info

لا تنسَ تغيير القيم المطلوبة بما يناسب إعداداتك وفق التالي:

1. بالنسبة للمفتاح السري DJANGO_SECRET_KEY اختر له قيمة فريدة صعبة التخمين كما توصي توثيقات دوكر تقدم لك الخطوة /5/ من مقال كيفية إعداد تطبيق جانغو عبر DigitalOcean Managed Databases and Spaces الأجنبي إحدى طرق جانغو لتوليد المفاتيح.
2. ضع عنوان IP الخاص بالخادم أوبونتو مقابل DJANGO_ALLOWED_HOSTS ويمكنك وضع الرمز * لأغراض الاختبار فقط وليس ضمن بيئة العمل الفعلية فهو يسمح باتصال أي عنوان IP.
3. اكتب اسم مستخدم قاعدة البيانات وكلمة المرور كما حددتهما في الخطوات السابقة مقابل DATABASE_USERNAME و DATABASE_PASSWORD.
4. كذلك الأمر بالنسبة لاعدادات الاتصال مع قاعدة البيانات من حيث اسم مضيف قاعدة البيانات وبوابة اتصال قاعدة البيانات ضع هذه البيانات مقال كل من DATABASE_HOST و DATABASE_PORT.
5. أما المحددات STATIC_ACCESS_KEY_ID و STATIC_SECRET_KEY و STATIC_BUCKET_NAME و STATIC_ENDPOINT_URL فهي تتعلق بخدمة التخزين الكائني الخارجية، اضبطها بما يتناسب مع الخدمة التي تستخدمها.

قبل تشغيل الأمر docker run احفظ التغيرات على الملف السابق env وتأكد أن المحدد DEBUG يحمل القيمة false وأن سجلات الأحداث مضبوطة بحيث تعطي التفاصيل المرغوبة.

وبعدها نفذ أمر التشغيل للإصدار v0 من الصورة django-polls بطريقة تتجاوز الإعدادات الافتراضية التي حددناها سابقًا ضمن الملف Dockerfile (باستخدام CMD) وتنشئ أثناء التشغيل مخطط قاعدة البيانات الخاص بالتطبيق عبر manage.py makemigrations و manage.py migrate:

docker run --env-file env django-polls:v0 sh -c "python manage.py makemigrations && python manage.py migrate"

سيظهر الخرج التالي بعد التنفيذ:

No changes detected
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

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

docker run -i -t --env-file env django-polls:v0 sh

تظهر عندها نافذة صدفة shell ضمن الحاوية وننشئ من خلالها المستخدم الذي يحمل صلاحية مدير تطبيق جانغو:

python manage.py createsuperuser

يلي ذلك إدخال بيانات المستخدم وهي اسم المستخدم وكلمة المرور والبريد الإلكتروني، ومن ثم الخروج من الحاوية وإنهاء عملها باستخدام الأمر Ctrl+D.

أما العملية الأخيرة هي جمع الملفات الساكنة الخاصة بالتطبيق collectstatic ورفعها على خدمة التخزين الكائني:

docker run --env-file env django-polls:v0 sh -c "python manage.py collectstatic --noinput"

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

121 static files copied.

يمكننا الآن تشغيل التطبيق بالإعدادات الافتراضية المحددة ضمن Dockerfile:

docker run --env-file env -p 80:8000 django-polls:v0

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

[2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0
[2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync
[2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7
[2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8
[2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

كما ذكرنا فإن التشغيل هذه المرة تم وفق الإعدادات الافتراضية ضمن ملف Dockerfile وهي كما حددناها سابقًا:

gunicorn --bind :8000 --workers 3 mysite.wsgi:application

وبذلك فإن البوابة 80 الخاصة بالخادم أوبونتو ستوجه الحركة إلى البوابة 8000 في الحاوية django-polls:v0.

يمكنك الآن فتح التطبيق polls عبر متصفح الإنترنت بكتابة عنوان URL الخاص به، وانتبه أنك ستحصل على الخطأ 404 (لم يتم العثور على الصفحة) في حال اكتفيت بالعنوان التالي مثلًا:

 http://your_server_ip/ 

بسبب عدم وجود بيانات للتطبيق تحت الجذر / ، لذا اكتب العنوان التالي:

http://your_server_ip/polls

اكتب الرابط http://your_server_ip/admin للوصول إلى واجهة الدخول للوحة التحكم الخاصة بالتطبيق:

أدخل بيانات المستخدم مدير التطبيق المنشأ سابقًا باستخدام الأمر createsuperuser وستظهر أمامك واجهة الإدارة والتحكم الخاصة بالتطبيق.

لاحظ أن تسليم المكونات الساكنة للتطبيق admin و polls يتم من خدمة التخزين الكائني ويمكنك اتباع اختبار جودة والتأكد من صحة إحضار الملفات.

اضغط Ctrl+c في نافذة كتابة الأوامر السطرية التي تشغل حاوية دوكر لإنهاء عمل الحاوية.

خاتمة

استعرضنا في هذا المقال طريقة تكييف تطبيق جانغو ليعمل بفعالية ضمن بيئة تطوير سحابية أصلية cloud-native معتمدة على الحاويات container-based، وكتابة ملف Dockerfile محلي ومبسط لصورة الحاوية ومن ثم تشغيله عبر محرك دوكر، ويمكنك رؤية التغييرات التي طبقناها وتأثيراتها باستعراض قسم polls-docker من مستودع GitHub فهو يتضمن كافة تعديلات التطبيق polls التي ناقشناها في هذا المقال.

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

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

أخيرًا يمكنك تسجيل الحاوية التي أعددتها على Dockerhub وجعلها متوفرة لأي نظام يحتوي دوكر سواء أكان خوادم أوبونتو أو بيئات افتراضية أو نظم حاويات عنقودية مثل Kubernetes.

ترجمة -وبتصرف- للمقال How to Build a Django and Gunicorn Application with Docker لصاحبيه Hanif Jetha و Justin Ellingwood.

اقرأ أيضًا

• ما هي تقنية Docker؟
• التعامل مع قواعد البيانات
• نظام كوبيرنتس Kubernetes وكيفية عمله
• مدخل إلى صدفة باش Bash

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

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

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

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

يجب توفير ما يلي:

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

ملاحظة: نعمل على تثبيت Docker Compose v1، والذي يستخدم "docker-compose"، ولكن بدءًا من Docker Compose v2، انتقل Docker نحو استخدام أمر الإضافة "compose" كما هو موثّق في أحدث إصدار Ubuntu 22.04، بعيدًا عن "docker-compose" الأصلي. وعلى الرغم من اختلاف طريقة التثبيت إلا أن الاستخدام الفعلي قد لا يتعدى لدى كثيرٍ من المستخدمين التخلص من الرمز "-" بين الكلمتين ليتحول الاستدعاء "docker-compose" إلى "docker compose". نجد ضمن وثائق Docker الرسمية مزيدًا من المعلومات حول توافق الأوامر بين "compose" الجديد و "Docker-compose" القديم.

الخطوة 1 - تثبيت الأداة دوكر كومبوز

نرغب بتثبيت أحدث إصدار مستقر من الأداة دوكر كومبوز، لذلك سنستخدم المستودع الرسمي GitHub من أجل ذلك.

نبدأ بالتحقق من توفر أحدث إصدار ضمن صفحة الإصدارات الخاصة بهم. تجدر الإشارة إلى أن أحدث إصدار مستقر في وقت كتابة هذا المقال هو "1.29.2".

نبدأ تحميل الإصدار "1.29.2" وحفظ الملف القابل للتنفيذ في "/usr/local/bin/docker-compose/"، مما سيجعل هذا البرنامج متاحًا للاستخدام عند الحاجة باستدعاء الأمر docker-compose.

ننفذ الأمر التالي لتحقيق ذلك:

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

نعرّف الأذونات الصحيحة ليصبح الأمر docker-compose قابلاً للتنفيذ كما يلي:

$ sudo chmod +x /usr/local/bin/docker-compose

نتحقق من نجاح عملية التثبيت، بتنفيذ الأمر التالي:

$ docker-compose --version

يظهر على الشاشة خرجٌ مشابهٌ لما يلي:

docker-compose version 1.29.2, build 5becea4c

انتهت عند هذه المرحلة عملية تثبيت الأداة دوكر كومبوز بنجاح. نبدأ الآن بإعداد ملف "docker-compose.yml" للحصول على بيئة محتواة وتشغيلها باستخدام هذه الأداة.

الخطوة 2 - إعداد ملف docker-compose.yml

نستطيع إنشاء أية بيئة نرغب بها عبر إعداد ملف "docker-compose.yml" ولتوضيح كيفية إعداد هذا الملف والعمل مع دوكر كومبوز، سننشئ بيئة خادم ويب باستخدام صورة Nginx الرسمية من Docker-Hub ، الذي يعرّف بأنه سجل دوكر العام. ستخدّم هذه البيئة المحتواة ملف HTML واحد ساكن static، أي لا يتضمن محتويات متغيرة.

أنشئ مجلّدًا جديدًا في مجلدك الافتراضي، ثم انتقل إليه:

$ mkdir ~/compose-demo
$ cd ~/compose-demo

ثم اضبط مجلد التطبيق ليكون المجلد الجذر لبيئة خادم Nginx على النحو التالي:

$ mkdir app

أنشئ الملف "index.html" باستخدام محرر النصوص المفضل عن طريق إنشاء ملف جديد داخل مجلد "app" على النحو التالي:

$ nano app/index.html

نضيف المحتوى التالي إلى هذا الملف:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Docker Compose Demo</title>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/kognise/water.css@latest/dist/dark.min.css">
</head>
<body>

    <h1>This is a Docker Compose Demo Page.</h1>
    <p>This content is being served by an Nginx container.</p>

</body>
</html>

نحفظ ونغلق الملف عند الانتهاء ويكون ذلك عند استخدام محرر النصوص نانو nano، بالضغط على الاختصار "CTRL + X"، ثم الزر "Y" ثم زر الإدخال "ENTER" للتأكيد.

أنشئ بعد ذلك الملف "docker-compose.yml" بتنفيذ الأمر التالي:

$ nano docker-compose.yml

أضف المحتوى التالي إلى ملف "docker-compose.yml":

version: '3.7'
services:
  web:
    image: nginx:alpine
    ports:
      - "8000:80"
    volumes:
      - ./app:/usr/share/nginx/html

يبدأ ملف "docker-compose.yml" عادةً بتحديد رقم الإصدار "version". إذ يُعلم هذا الرقم الأداة دوكر كومبوز أي إصدار من الإعدادات سيُستخدم.

نجد بعد رقم الإصدار جزء الخدمات "services"، إذ تُعد هنا الخدمات التي تشكّل هذه البيئة. يتضمن تطبيقنا الحالي خدمةً واحدةً فقط نسميها "web"، وتستخدم هذه الخدمة صورة "nginx: alpine" وتضبط إعادة توجيه المنفذ باستخدام الموجّه "ports"، ويعني ذلك إعادة توجيه جميع الطلبات الواردة إلى المنفذ "8000" من الجهاز المضيف (النظام الذي يُشغِّل أداة دوكر كومبوز) إلى حاوية "web" عبر المنفذ "80" حيث يعمل خادم Nginx.

ينشئ الموجّه "volumes" وحدة تخزين مشتركة بين الجهاز المضيف والحاوية. نختار مشاركة المجلد "app" الموجود محليًا مع الحاوية، إذ أنّ مسار تخزين المجلد داخل الحاوية هو "usr/share/nginx/html/" والذي يصبح الصفحة الافتراضية لخادم Nginx.

احفظ الملف واغلقه.

انتهى إعداد صفحة توضيحية وملف "docker-compose.yml" لإنشاء بيئة خادم ويب محتواة. نحتاج لاختبار هذه البيئة وتشغيلها باستخدام أداة دوكر كومبوز.

الخطوة 3 - تشغيل أداة دوكر كومبوز

نستدعي أداة دوكر كومبوز بعد الانتهاء من إعداد الملف "docker-compose.yml"، وعندها يمكن إرسال الطلب إلى الخادم. يبدأ الأمر بتحميل صور دوكر الضرورية وإنشاء حاوية لخدمة "web"، وفي النهاية تشغيل البيئة الحاوية بالنمط المخفي، وذلك بتنفيذ الأمر التالي:

$ docker-compose up –d

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

Creating network "compose-demo_default" with the default driver
Pulling web (nginx:alpine)... 
alpine: Pulling from library/nginx 
cbdbe7a5bc2a: Pull complete
 10c113fb0c77: Pull complete 
9ba64393807b: Pull complete
 c829a9c40ab2: Pull complete 
61d685417b2f: Pull complete 
Digest: sha256:57254039c6313fe8c53f1acbf15657ec9616a813397b74b063e32443427c5502
 Status: Downloaded newer image for nginx:alpine 
Creating compose-demo_web_1 ... done

ملاحظة: في حال طباعة ما يدل على أنه توجد مشكلة في الأذونات، فهذا يعني أنّ أداة دوكر غير قادرة على العمل دون صلاحية sudo ويجب حل هذه المشكلة أولًا قبل متابعة العمل.

أصبحت البيئة جاهزة وتعمل في الخلفية، نتحقق من أن الحاوية نشطة عبر تنفيذ الأمر:

$ docker-compose ps

تظهر معلومات حول الحاويات قيد التشغيل وحالتها، إضافةً إلى عمليات إعادة توجيه المنافذ المستخدمة حاليًا:

      Name                     Command               State          Ports        
----------------------------------------------------------------------------------
compose-demo_web_1   /docker-entrypoint.sh ngin ...   Up      0.0.0.0:8000->80/tcp

نستطيع الوصول إلى التطبيق التوضيحي من خلال طلب الرابط "localhost:8000" ضمن متصفح الويب في حال كان تشغيل العرض التوضيحي على الجهاز المحلي، أو "yourserverdomainorIP: 8000" في حال كان تشغيل العرض التوضيحي على خادم بعيد.

يظهر ضمن المتصفح محتوى كما يلي:

تحافظ وحدة التخزين المشتركة التي اعددناها داخل ملف "docker-compose.yml" على مزامنة ملفات مجلد "app" الموجود محليًا مع المجلّد الموجود ضمن الحاوية، أي أنّ أية تغييرات على ملف "index.html" ستنعكس تلقائيًا على المتصفح عند إعادة تحميل الصفحة.

الخطوة 4 - التعرف على أوامر الأداة دوكر كومبوز

تستخدم أوامر الأداة دوكر كومبوز لإدارة البيئة المحتوية والتفاعل معها. نتحقق من السجلات المُتشأة عن عمل حاوية خادم Nginx، باستخدام الأمر logs:

$ docker-compose logs

يظهر محتوًى مشابه لما يلي:

Attaching to compose-demo_web_1
web_1  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
web_1  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
web_1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
web_1  | 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf
web_1  | 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
web_1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
web_1  | /docker-entrypoint.sh: Configuration complete; ready for start up
web_1  | 172.22.0.1 - - [02/Jun/2020:10:47:13 +0000] "GET / HTTP/1.1" 200 353 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" "-"