إتقان Docker أفضل الممارسات لعام

الملخص

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

---

ماذا ستتعلم

• كيفية هيكلة ملفات Dockerfile للأداء والأمان.
• الفرق بين حاويات التطوير والإنتاج.
• كيفية استخدام البناء متعدد المراحل والتخزين المؤقت بفعالية.
• استراتيجيات مراقبة الحاويات واختبارها وتكاملها مع CI/CD.
• الأخطاء الشائعة — وكيفية تجنبها.

---

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

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

• معرفة أساسية بأوامر Docker (Docker build، Docker run، Docker compose).
• بعض الخبرة بأدوات سطر الأوامر في Linux.
• اختياريًا ولكن مفيدًا: فهم لأنظمة CI/CD مثل GitHub Actions أو GitLab CI.

---

مقدمة: لماذا تهم ممارسات Docker الجيدة

لقد غيرت Docker الطريقة التي نقوم بها بتغليف ونشر التطبيقات. تقوم الحاويات بتغليف كل ما يحتاجه التطبيق — التبعيات، ووقت التشغيل، والتكوين — في صورة قابلة للنقل تعمل في أي مكان¹. ولكن مع القوة العظيمة تأتي مسؤولية كبيرة: يمكن أن تصبح صور Docker السيئة التصميم متضخمة وغير آمنة وصعبة الصيانة.

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

دعونا نبدأ.

---

1. بناء صور Docker فعالة وآمنة

1.1 استخدم أصغر صورة أساسية ممكنة

كل طبقة إضافية في صورة Docker تزيد من سطح الهجوم ووقت البناء. تُعد الصور المستندة إلى Alpine شائعة لأنها صغيرة جدًا (عادة أقل من 10 ميغابايت) ولا تزال توفر بيئة Linux كاملة².

الصورة الأساسية	الحجم (تقريبي)	حالة الاستخدام
ubuntu:22.04	~77 ميغابايت	متعددة الأغراض، سهلة التنقيح
debian:bookworm-slim	~22 ميغابايت	مستقرة، أصغر من Ubuntu
alpine:3.19	~5 ميغابايت	أدنى حد، مثالية للبناءات الإنتاجية

قبل:

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3
COPY . /app
CMD ["python3", "/app/main.py"]

بعد (محسن):

FROM python:3.12-alpine
WORKDIR /app
COPY . .
CMD ["python", "main.py"]

✅ الفوائد: صورة أصغر، تنزيل أسرع، عدد أقل من الثغرات.

1.2 استخدم البناء متعدد المراحل

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

# المرحلة 1: البناء
FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN go build -o app

# المرحلة 2: وقت التشغيل
FROM alpine:3.19
WORKDIR /app
COPY --from=builder /src/app .
CMD ["./app"]

يقلل هذا النهج من حجم الصورة بشكل كبير — غالبًا بنسبة 80% أو أكثر — لأنك لا تحمل المترجمات أو الرؤوس إلى الإنتاج.

1.3 ثبت إصدارات الصور

تجنب استخدام العلامات latest. فهي تتغير مع الوقت ويمكن أن تكسر البناءات بشكل غير متوقع.

FROM node:20.11.1-alpine

التثبيت يضمن إمكانية إعادة الإنتاج — وهو أمر بالغ الأهمية لخطوط أنابيب CI/CD ومراجعات الأمان³.

---

2. التخزين المؤقت للطبقات وأداء البناء

تقوم Docker بتخزين الطبقات مؤقتًا لتسريع البناءات. يمكن أن يؤثر ترتيب التعليمات في ملف Dockerfile الخاص بك على كفاءة التخزين المؤقت.

2.1 الترتيب مهم

ضع الأسطر التي تتغير بشكل متكرر في الأسفل من ملف Dockerfile الخاص بك.

# جيد
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

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

2.2 استخدم .dockerignore

ملف .dockerignore يمنع الملفات غير الضرورية (مثل .git، node_modules، أو بيانات الاختبار) من تضخيم صورة الحاوية الخاصة بك.

مثال:

.git
__pycache__
node_modules
tests
*.log

---

3. أفضل ممارسات الأمان

3.1 التشغيل كمستخدم غير جذر

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

يحد هذا من الضرر في حال تم اختراق الحاوية الخاصة بك⁴.

3.2 فحص الثغرات

استخدم أدوات مثل Trivy، Grype، أو Docker Scout لاكتشاف الثغرات CVE في الصور الأساسية والتبعيات.

trivy image myapp:latest

مثال على المخرجات:

Total: 5 (CRITICAL: 1, HIGH: 2, MEDIUM: 2, LOW: 0)

3.3 الحفاظ على السرية خارج الصور

لا تقم أبدًا بدمج مفاتيح API أو بيانات الاعتماد داخل الصور. استخدم المتغيرات البيئية أو أسرار Docker.

Docker run -e API_KEY=$API_KEY myapp:latest

للنشرات الحساسة (مثل Swarm أو Kubernetes)، استخدم أنظمة إدارة السرية مثل HashiCorp Vault أو AWS Secrets Manager⁵.

3.4 تحديث الصور الأساسية بانتظام

الصور الأساسية القديمة هي مصدر شائع للثغرات. قم بأتمتة عمليات إعادة البناء أسبوعيًا أو شهريًا.

---

4. متى تستخدم Docker ومتى لا تستخدمه

السيناريو	استخدام Docker	تجنب Docker
الخدمات المصغرة أو واجهات برمجة التطبيقات	✅	❌
التناسق في التطوير المحلي	✅	❌
تطبيقات سطح المكتب ذات الواجهة الرسومية	❌	✅
أعباء العمل عالية الأداء على الأجهزة المادية	❌	✅
خطوط أنابيب CI/CD	✅	❌
الوظائف الخالية من الخادم	⚙️ أحيانًا	⚙️ أحيانًا

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

---

5. مثال واقعي: Docker في نطاق واسع

الخدمات واسعة النطاق تعتمد غالبًا على Docker للنشرات المتسقة والترقيع السريع⁶. على سبيل المثال، تقوم الشركات غالبًا بتشغيل خدمات مصغرة محايدة خلف منصات تنسيق مثل Kubernetes أو Amazon ECS.

سير عمل إنتاجي نموذجي:

flowchart TD
    A[المطور يدفع الكود] --> B[خط أنابيب CI/CD]
    B --> C[Docker بناء وفحص]
    C --> D[دفع إلى السجل]
    D --> E[نشر إلى Kubernetes]
    E --> F[مراقبة وتنبيهات]

يضمن هذا الخط:

• البناء والاختبار الآلي.
• فحص الأمان قبل النشر.
• صور غير قابلة للتغيير ومُصدّرة.

---

6. الاختبار وتكامل CI/CD

6.1 مثال: خط أنابيب CI لـ GitHub Actions

إليك خط أنابيب CI بسيط يقوم ببناء وفحص ودفع صورة Docker.

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: Docker build -t myapp:${{ GitHub.sha }} .
      - name: Scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ GitHub.sha }}
      - name: Push to Docker Hub
        run: |
          echo ${{ secrets.DOCKER_PASS }} | Docker login -u ${{ secrets.DOCKER_USER }} --password-stdin
          Docker push myapp:${{ GitHub.sha }}

يضمن ذلك أن كل عملية إيداع تنتج صورة قابلة للتحقق وآمنة.

---

7. المراقبة والتسجيل والرؤية

7.1 التسجيل

أعد توجيه السجلات إلى stdout/stderr حتى يمكن جمعها بواسطة Docker أو أنظمة التنسيق.

import logging, sys
logging.basicConfig(stream=sys.stdout, level=logging.INFO)
logging.info("App started")

تجنب كتابة السجلات إلى ملفات داخل الحاويات — التخزين المؤقت سيفقدها.

7.2 المقاييس وفحوصات الصحة

اعرض نقاط النهاية والمقاييس للرؤية.

HEALTHCHECK CMD curl -f http://localhost:8080/health || exit 1

ادمج مع أدوات المراقبة مثل Prometheus، Datadog، أو Grafana للرؤية.

---

8. الأخطاء الشائعة والحلول

الخطأ	السبب	الحل
الصور المنتفخة	تثبيت حزم غير ضرورية	استخدم عمليات البناء متعددة المراحل والقواعد الدنيا
البناء غير المتسق	استخدام علامات latest	ثبت الإصدارات
فقدان ذاكرة التخزين المؤقتة للبناء	ترتيب خاطئ لملف Dockerfile	ثبت التبعيات قبل نسخ الكود
تسريبات الأمان	الأسرار في الصور	استخدم متغيرات البيئة أو الأسرار
البدء البطيء	نصوص بدء ثقيلة	حسن نقاط الدخول

---

9. استكشاف الأخطاء الشائعة وإصلاحها

خطأ: permission denied

السبب: التشغيل كمستخدم غير جذر دون أذونات مناسبة.
الإصلاح: اضبط ملكية الملف أو استخدم توجيه USER بشكل صحيح.

خطأ: no space left on device

السبب: عدد كبير من الصور/الحاويات المعلقة.
الإصلاح:

Docker system prune -af

خطأ: connection refused

السبب: الخدمة غير مكشوفة أو وضع شبكة خاطئ.
الإصلاح: استخدم EXPOSE وتحقق من Docker network ls.

---

10. جرب بنفسك: بناء صورة جاهزة للإنتاج

خطوة بخطوة

1. أنشئ تطبيق Flask بسيط:

   from flask import Flask
   app = Flask(__name__)
   
   @app.route('/')
   def home():
       return 'Hello from Docker!'
   
   if __name__ == '__main__':
       app.run(host='0.0.0.0', port=8080)
   

2. أنشئ ملف Dockerfile:

   FROM python:3.12-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   USER 1001
   EXPOSE 8080
   CMD ["python", "app.py"]
   

3. ابن وشغّل:

   Docker build -t flask-demo .
   Docker run -p 8080:8080 flask-demo
   

4. زر http://localhost:8080 — أنت الآن تشغل حاوية آمنة وجاهزة للإنتاج!

---

11. الأخطاء الشائعة التي يرتكبها الجميع

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

---

12. رؤى الأداء والقابلية للتوسع

• إعادة استخدام الطبقات: ترتيب الطبقات بذكاء يقلل أوقات البناء بنسبة 60–80% في التطوير التكراري².
• البناء المتوازي: استخدم BuildKit (DOCKER_BUILDKIT=1) لبناء الطبقات بشكل متزامن.
• التخزين المؤقت للمسجل: استخدم مسجلات محلية أو مرايا لتقليل زمن الاستجابة الشبكي.
• حدود الموارد: استخدم العلامات --memory و --cpus لمنع الجيران الضوضائيين في الإنتاج.

---

13. الأمان في الإنتاج

اتبع مبدأ أقل امتياز. اجمع بين Docker و:

• ملفات تعريف AppArmor أو SELinux للعزل.
• أنظمة الملفات الجذرية للقراءة فقط (العلامة --read-only).
• تقسيم الشبكة لعزل الحاويات الحساسة.

استخدم Docker Content Trust (DCT) لتوقيع وتحقق من الصور⁷.

export DOCKER_CONTENT_TRUST=1

---

14. اختبار الحاويات

اختبار الوحدة

استخدم حاويات خفيفة لبيئات اختبار معزولة.

Docker run --rm myapp pytest tests/

اختبار التكامل

ابدأ الخدمات المعتمدة باستخدام Docker compose.

version: '3'
services:
  db:
    image: postgres:16
  app:
    build: .
    depends_on:
      - db

---

15. قائمة جاهزية الإنتاج

✅ استخدم صور قاعدة محددة ودقيقة.
✅ شغّل كمستخدم غير root.
✅ افحص الصور بانتظام.
✅ أوتومتة البناء والنشر.
✅ راقب السجلات والمقاييس.
✅ استخدم فحوصات الصحة وسياسات إعادة التشغيل.
✅ اجعل الأسرار خارجية.

---

الخاتمة

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

هذه الممارسات الجيدة ليست نظرية؛ بل هي ما يحافظ على استقرار أنظمة الإنتاج عند نطاق واسع.

---

🧭 النقاط الرئيسية

• الأصغر آمن hơn: استخدم صور قاعدة دقيقة وبناء متعدد المراحل.
• أوتومتة كل شيء: خطوط أنابيب CI/CD تقلل من الأخطاء البشرية.
• الأمان أولاً: شغّل كمستخدم غير root، افحص الصور، وأدر الأسرار بشكل صحيح.
• راقب واختبر: القدرة على الملاحظة ضرورية للاستقرار طويل الأمد.

---

الأسئلة الشائعة

س1: هل يجب أن أستخدم Alpine لجميع الصور؟
ليس دائماً. يمكن أن تسبب musl libc في Alpine مشكلات توافق مع بعض الملفات الثنائية. استخدمها عندما تتحكم في المكدس الكامل.

س2: كم مرة يجب أن أعيد بناء الصور؟
مرة واحدة على الأقل أسبوعياً، أو كلما تلقت الصور الأساسية تحديثات أمنية.

س3: هل لا تزال Docker ذات صلة مع Kubernetes؟
بالتأكيد. تبقى Docker المعيار لبناء وتوزيع صور الحاويات، رغم أن Kubernetes يستخدم الآن containerd داخلياً⁸.

س4: كيف أتعامل مع البيانات المستمرة؟
استخدم الأحجام أو التخزين الخارجي — يجب أن تبقى الحاويات بلا حالة.

س5: هل يمكنني تشغيل Docker في الإنتاج بأمان؟
نعم، مع العزل المناسب والفحص والمراقبة.

---

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

• نفذ بناءات متعددة المراحل في مشاريعك الحالية.
• أضف فحص Trivy أو Grype إلى خط أنابيب CI الخاص بك.
• راجع ملفات Dockerfile الخاصة بك من حيث الأمان والأداء.
• اشترك في المدونة الرسمية لـ Docker للحصول على التحديثات.

---

الحواشي

1. وثائق Docker – ما هي الحاوية؟ https://docs.Docker.com/get-started/overview/ ↩

2. الصور الرسمية لـ Docker – مقارنة حجم الصورة الأساسية https://hub.Docker.com/_/alpine ↩ ↩²

3. وثائق Docker – أفضل الممارسات لكتابة ملفات Dockerfile https://docs.Docker.com/develop/develop-images/dockerfile_best-practices/ ↩

4. OWASP – ورقة غش أمن Docker https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html ↩

5. وثائق HashiCorp Vault – إدارة الأسرار للحاويات https://developer.hashicorp.com/vault/docs ↩

6. CNCF – نظرة عامة على مشهد التقنيات السحابية الأصلية https://landscape.cncf.io/ ↩

7. وثائق ثقة محتوى Docker https://docs.Docker.com/engine/security/trust/ ↩

8. وثائق Kubernetes – محركات تشغيل الحاويات https://Kubernetes.io/docs/setup/production-environment/container-runtimes/ ↩