بايثون لأتمتة DevOps

Python في صندوق أدوات DevOps

18 دقيقة الدرس 1 من 28

Python في صندوق أدوات DevOps

كل مهندس DevOps محترف يحمل صندوق أدوات ذهنياً مُقسَّماً إلى ثلاث طبقات: المنصة (Linux والشبكات والحاويات)، والـ pipeline (أنظمة CI/CD وأدوات IaC)، والغراء. Python هو ذلك الغراء. إنه اللغة التي تقرأ إعداد YAML وتستدعي ثلاث APIs سحابية وتُحوّل النتيجة وتكتب تقريراً وتُرسل تنبيه Slack — كل ذلك في سكريبت واحد يمكنك قراءته بعد ستة أشهر وتفهمه. يشرح هذا الدرس بالضبط لماذا تسود Python أتمتة العمليات وكيف تُعيّن بيئة احترافية قابلة للتكرار منذ اليوم الأول.

لماذا أصبحت Python لغة العمليات

لم تفز Python في مجال العمليات بالصدفة. خصائص ملموسة محددة تجعلها الأداة الصحيحة لعمل البنية التحتية:

بطاريات مدمجة لمهام العمليات: المكتبة القياسية تحتوي على os وpathlib وsubprocess وjson وlogging وargparse وsocket وhttp.client وthreading — اللبنات الأساسية لتقريباً كل سكريبت عمليات — دون تثبيت أي شيء.
SDKs سحابية من الدرجة الأولى: AWS (boto3) وGCP (google-cloud-*) وAzure (azure-sdk-for-python) وكل بائع SaaS رئيسي يشحن SDKs Python رسمية. هذه يصونها مزودو السحابة أنفسهم لا أغلفة طرف ثالث.
Ansible وSaltStack وFabric وAirflow كلها Python: فهم اللغة يتيح لك كتابة وحدات مخصصة وتوسيع الأدوات الموجودة وتشخيص الأعطال من المصدر بدلاً من معاملتها كصناديق سوداء.
مقروء للجميع في الفريق: سطر Shell واحد يربط عشرة أنابيب سريع في الكتابة ومستحيل المراجعة. سكريبت Python بأسماء متغيرات وصفية ودوال وتوثيق يمكن مراجعة كوده واختباره وتعديله بأمان من أي مهندس.
موجود في كل مكان على خوادم Linux: Python 3 تأتي مع كل توزيعة Linux رئيسية. يمكنك تشغيل سكريبت عمليات على نسخة EC2 طازجة دون أي خطوات تجهيز.

الفكرة الأساسية: في شركات كـ Google وMeta وStripe، الحد بين "مهندس DevOps" و"مهندس برمجيات" ضبابي عمداً. كود العمليات يخضع لنفس معيار الجودة ككود المنتج — مراجعة واختبار وإدارة إصدارات. Python تُتيح ذلك المعيار. سكريبتات Shell لا تصمد عنده.

السكريبتات مقابل الأدوات: فهم الطيف

قبل كتابة سطر واحد، قرر ما الذي تبنيه. هذا التمييز يُشكّل كل قرار تصميم يليه.

A script هو ملف واحد يُشغَّل مرة أو بجدول زمني ويحل مشكلة ضيقة واحدة: تدوير مفتاح SSH، أرشفة سجلات قديمة، التحقق من أن جميع pods في namespace بحالة Running. السكريبتات لا تحتوي اختبارات ولا تغليف ولا إصدار يتجاوز git blame. تناسب المهام البسيطة منخفضة الخطورة التي تعمل بشكل غير متكرر.

A tool هو حزمة Python قابلة للتوزيع والتثبيت مع نقطة دخول CLI واختبارات ورقم إصدار وتوثيق. هذا ما يتحول إليه السكريبت حين يحتاج أشخاص آخرون إلى تشغيله، أو حين يحتاج للتعامل مع حالات الحواف بسلاسة، أو حين يؤثر الفشل على الإنتاج. فكر في AWS CLI وkubectl وgh — هذه أدوات مبنية بـ Python (أو مُصرَّفة منها) يشغّلها آلاف المهندسين يومياً.

القاعدة الاستهدافية على نطاق واسع: ابدأ كسكريبت، أعد هيكلته كأداة حين يتبناه الفريق الثاني. يتبع هذا الدرس التعليمي تلك المنحنى — الدروس المبكرة هي سكريبتات، والدروس اللاحقة (الدرس 6) تبني أداة CLI حقيقية.

طيف Python للعمليات: سكريبت المهمة الواحدة يتطور إلى مكتبة وحدات مشتركة، ثم إلى أداة CLI ذات إصدارات مع توسع التبني.

إعداد البيئة: لماذا venv غير قابل للتفاوض

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

A virtual environment (venv) هو مجلد معزول يحتوي على نسخة Python الخاصة به ومجلد site-packages الخاص به. الحزم المثبتة داخل venv لا تمس نظام Python أبداً وغير مرئية للـ venvs الأخرى على نفس الجهاز. هذا هو الحد الأدنى من النظافة لأي عمل Python جاد، سواء أكان عمليات أم غيرها.

# --- إنشاء وتفعيل venv (Linux / macOS) ---

# إنشاء venv باسم .venv في مجلد المشروع الحالي
python3 -m venv .venv

# تفعيله — موجّه Shell سيُظهر (.venv) عند التفعيل
source .venv/bin/activate

# تحقق: 'which python' يشير الآن داخل .venv لا /usr/bin/python3
which python
# المتوقع: /path/to/project/.venv/bin/python

# تثبيت الحزم — يذهب فقط داخل venv
pip install boto3 pyyaml requests

# تجميد الإصدارات الدقيقة لأي شخص يمكنه إعادة إنتاج هذه البيئة
pip freeze > requirements.txt

# إلغاء التفعيل عند الانتهاء
deactivate

# --- إعادة إنتاج البيئة على جهاز آخر (أو CI) ---
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

ممارسة احترافية: سمّ مجلد venv دائماً .venv (بالنقطة) وأضفه إلى .gitignore. هذا هو الاتفاق الذي يستخدمه VS Code وPyCharm ومعظم قوالب CI. يُبقي جذر المشروع نظيفاً ويمنع commit غير مقصود لمئات الملفات الثنائية. أضف .venv/ إلى ~/.gitignore_global العالمي أيضاً حتى لا تنسى أبداً.

عصر pyproject.toml

لأي شيء يتجاوز سكريبتاً واحداً، المعيار الحديث لـ Python هو pyproject.toml بدلاً من setup.py القديم أو requirements.txt العاري. إنه ملف واحد يُعلن بيانات نظام البناء وتبعيات المشروع بتنسيق موحد (PEP 517/518). الأدوات الرئيسية كـ pip وpoetry وuv وhatch كلها تقرأه.

# pyproject.toml — هيكل مشروع ops-cli الأدنى
[build-system]
requires = ["setuptools>=68", "wheel"]
build-backend = "setuptools.backends.legacy:build"

[project]
name = "ops-cli"
version = "0.1.0"
description = "Internal infrastructure automation tooling"
requires-python = ">=3.11"
dependencies = [
    "boto3>=1.34",
    "pyyaml>=6.0",
    "requests>=2.31",
    "click>=8.1",
    "rich>=13.7",
]

[project.scripts]
ops = "ops_cli.main:cli"

[tool.setuptools.packages.find]
where = ["src"]

# تثبيت المشروع في وضع قابل للتعديل (التغييرات على src/ تسري فوراً)
# pip install -e .

مصيدة إنتاجية: لا تُثبّت الإصدارات أبداً بـ == في pyproject.toml الخاص بمكتبة — استخدم حدوداً دنيا بـ >= فقط. التثبيت الصارم في مكتبة مشتركة يُسبب جحيم التبعيات حين يحتاج مشروع مستهلك إلى إصدار مختلف من نفس الحزمة. احتفظ بتثبيت == لملفات requirements.txt للتطبيق أو ملفات القفل، حيث تتحكم في البيئة بالكامل. أدوات كـ pip-compile أو uv lock تولّد ملفات قفل قابلة للتكرار دون تلويث بيانات الحزمة.

إدارة إصدار Python في الإنتاج

نظام Python على الخادم مملوك لمدير حزم نظام التشغيل. ترقيته للحصول على ميزة لغة جديدة قد يكسر الأدوات المساعدة للنظام التي تعتمد على الإصدار القديم. النهج الاحترافي هو تثبيت إصدارات Python بشكل مستقل باستخدام pyenv أو، في الحاويات، تثبيت إصدار CPython الدقيق في صورة Dockerfile الأساسية.

في pipeline CI، حدد دائماً إصدار Python صراحةً. لا تعتمد أبداً على "أي Python مثبت على الـ runner" — هذا يتغير دون إشعار حين تُحدَّث صورة الـ runner، وفجأة يكسر سكريبتك لأنه استخدم تعبير match يتطلب 3.10+ لكن الـ runner يملك 3.8.

# .github/workflows/ops-script.yml — ثبّت دائماً إصدار Python في CI
name: Ops Automation

on:
  schedule:
    - cron: "0 6 * * 1-5"    # صباح أيام الأسبوع 06:00 UTC
  workflow_dispatch:           # السماح بالتشغيل اليدوي

jobs:
  run-script:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"      # إصدار فرعي دقيق لا "3.x"
          cache: "pip"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run automation script
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_DEFAULT_REGION: us-east-1
        run: python scripts/weekly_cost_report.py

عقلية Python للعمليات

سكريبتات العمليات في الإنتاج تفشل بطرق لا تفشل بها البرامج التفاعلية. سكريبت يعمل في 03:00 يوم السبت يمكنه الفشل بصمت أو إفساد الحالة أو إطلاق حادثة متسلسلة قبل أن يلاحظ أحد. التحول الذهني من "يكتب كوداً" إلى "يكتب كود عمليات" يستلزم استيعاب بعض المبادئ التي ستطبقها طوال هذا الدرس التعليمي:

افشل بصوت عالٍ لا بصمت: استثناء غير معالج مع تتبع كامل أفضل من سكريبت يبتلع خطأ ويخرج بـ 0. أنظمة المراقبة تكتشف رموز الخروج غير الصفرية؛ لا تستطيع اكتشاف الفشل الصامت.
قابلية التكرار (Idempotency): تشغيل السكريبت مرتين يجب أن ينتج نفس نتيجة تشغيله مرة واحدة. هذا يجعل إعادة المحاولات آمنة، وهو أمر ضروري لأي عملية يمكن مقاطعتها (انتهاء مهلة الشبكة، SIGTERM من runner CI وصل لحد المهلة).
التسجيل المنظَّم بدلاً من جُمَل print: print("done") غير مرئية لمجمّعي السجلات. سطر سجل بتنسيق JSON مع طابع زمني وخطورة وحقول سياق قابل للاستعلام في Datadog أو CloudWatch Logs أو أي SIEM.
بيانات الاعتماد من البيئة لا من الكود: مفاتيح API مُرمَّزة في الكود هي حادثة أمنية P0 تنتظر حدوثها. ستُمارس هذا النمط مراراً عبر هذا الدرس التعليمي.

ما يأتي بعد ذلك: الدرس 2 يتعمق في المنطقة العملية الأولى — التعامل مع الملفات والمسارات والعمليات الفرعية. هذا هو المكان الذي تقضي فيه معظم سكريبتات العمليات غالبية سطورها. بحلول الدرس 6 ستملك ما يكفي من اللبنات لتجميع أداة CLI بجودة إنتاجية، وبحلول الدرس 7 ستستدعي SDKs السحابية لأتمتة مهام بنية تحتية حقيقية. كل نمط ستستخدمه هناك يعتمد على نظافة البيئة والنموذج الذهني الذي تُرسيه هنا.