مشروع مصغر: أتمتة إنشاء بيئة إنتاج كاملة (سيرفر + شبكة + IP ثابت) برمجياً

مشروع مصغر: أتمتة إنشاء بيئة إنتاج كاملة برمجياً

في هذا المشروع سنبني نموذجاً عملياً لبيئة إنتاج تتكوّن من سيرفر سحابي، شبكة خاصة، وقاعدة ربط بعنوان Static IP باستخدام منهجية البنية التحتية ككود (IaC): لماذا يجب أن نتخلى عن إنشاء السيرفرات يدوياً؟. الفكرة ليست فقط تشغيل خادم، بل تحويل كامل عملية الإنشاء إلى وصف برمجي قابل للتكرار، والمراجعة، والتنفيذ الآلي.

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

المعمارية المستهدفة للمشروع

سنستخدم Terraform لإنشاء الموارد السحابية، ثم نستخدم Ansible لتهيئة السيرفر بعد إنشائه. بهذه الطريقة نفصل بين طبقة توفير البنية وطبقة إعداد النظام، وهو فصل معماري مهم في البيئات الاحترافية.

• شبكة خاصة من نوع VPC.
• شبكة فرعية Subnet ضمن نطاق محدد.
• سيرفر Ubuntu للإنتاج.
• عنوان Elastic IP أو Reserved IP بحسب المزوّد.
• قواعد جدار حماية تسمح فقط بالمنافذ الضرورية.
• تهيئة تطبيق ويب أساسي باستخدام Nginx.

لماذا ندمج Terraform مع Ansible؟

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

إذا كنت تحتاج تأسيساً أعمق، فراجع تثبيت Terraform وربطه مع مزود خدمة سحابي (AWS أو DigitalOcean) عبر الـ API، ثم ما هو Ansible؟ وكيف تتحكم في 100 سيرفر Linux من حاسوبك المكتبي؟. الجمع بين الأداتين هو النمط الأشهر لبناء بيئات إنتاج صغيرة ومتوسطة بموثوقية عالية.

المرحلة الأولى: تعريف البنية السحابية بملف Terraform

في المثال التالي سنفترض مزوداً سحابياً يدعم إنشاء VPC، شبكة فرعية، مثيلاً حوسبياً، وعنواناً ثابتاً. الملف التالي يوضح الفكرة العامة لمشروع بنيوي واحد يمكن تشغيله ثم تعديله لاحقاً حسب البيئة.

terraform init
terraform plan
terraform apply

# main.tf concept rendered in YAML-style presentation for article readability
terraform:
  required_providers:
    aws:
      source: hashicorp/aws
      version: "~> 5.0"

provider:
  aws:
    region: eu-central-1

resources:
  aws_vpc:
    main:
      cidr_block: "10.0.0.0/16"

  aws_subnet:
    public:
      vpc_id: "${aws_vpc.main.id}"
      cidr_block: "10.0.1.0/24"
      map_public_ip_on_launch: true

  aws_security_group:
    web_sg:
      name: "web-sg"
      description: "Allow SSH and HTTP"
      vpc_id: "${aws_vpc.main.id}"

  aws_instance:
    web:
      ami: "ami-xxxxxxxx"
      instance_type: "t3.micro"
      subnet_id: "${aws_subnet.public.id}"
      vpc_security_group_ids:
        - "${aws_security_group.web_sg.id}"
      key_name: "prod-key"

  aws_eip:
    web_ip:
      instance: "${aws_instance.web.id}"

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

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

حماية حالة البنية

ملف Terraform State هو قلب المشروع، لأنه يسجّل الواقع الفعلي للموارد المنشأة. لذلك يجب فهم إدارة حالة البنية التحتية (Terraform State) وكيف تحافظ عليها من الضياع قبل نقل المشروع إلى فريق أو ربطه بمسار نشر آلي.

المرحلة الثانية: تهيئة السيرفر تلقائياً عبر Ansible

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

all:
  hosts:
    production-web:
      ansible_host: 203.0.113.10
      ansible_user: ubuntu
      ansible_ssh_private_key_file: ~/.ssh/prod-key.pem

- name: Configure production server
  hosts: all
  become: true

  tasks:
    - name: Update apt cache
      apt:
        update_cache: true

    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Ensure nginx is enabled
      service:
        name: nginx
        state: started
        enabled: true

    - name: Deploy index page
      copy:
        dest: /var/www/html/index.html
        content: |
          <h1>Production environment is ready</h1>

هذا النمط يرتبط مباشرة بما تناولناه في أول Playbook لك: تثبيت البرامج (مثل Nginx و Node) آلياً بلغة YAML، كما يمكن توسيعه باستخدام المعالجات (Handlers): إعادة تشغيل الخدمات فقط عند حدوث تغيير في السيرفر لتجنب إعادة تشغيل غير ضرورية.

المرحلة الثالثة: ربط الأتمتة بمسار CI/CD

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

name: provision-production

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

      - name: Terraform Apply
        run: terraform apply -auto-approve

      - name: Run Ansible Playbook
        run: ansible-playbook -i inventory.yml playbook.yml

هذا التسلسل ينسجم مع ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟، ويمكن بناؤه عملياً من خلال مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) ثم تطويره إلى بنية أكثر صرامة عبر إنشاء خط أنابيب (Pipeline) يرفض الأكواد التي تفشل في الاختبارات.

لا تجعل تنفيذ terraform apply متاحاً لكل عملية Push. في بيئات الإنتاج يجب فرض مراجعة بشرية، وحماية الفروع، وتقييد التنفيذ إلى فروع معتمدة فقط.

أفضل الممارسات الأمنية والمعمارية

• استخدم مستخدماً غير root للدخول اليومي.
• اعتمد إعداد الاتصال الآمن (SSH Keys) بدون كلمات مرور بين جهازك والخوادم.
• فعّل قواعد جدار ناري دقيقة كما في أتمتة إعداد جدار الحماية (UFW) وتأمين عدة سيرفرات Linux بضغطة واحدة.
• لا تفتح المنفذ 22 للعالم كله إلا عند الضرورة القصوى.
• افصل بيئة الاختبار عن الإنتاج في حسابات أو مشاريع مستقلة قدر الإمكان.
• خطط مبكراً لموضوع النسخ الاحتياطي، المراقبة، والسجلات Logs.

متى يصبح هذا المشروع ناضجاً للإنتاج الفعلي؟

عندما تضيف وحدات Modules، وملفات متغيرات للبيئات المختلفة، وآلية إدارة أسرار، وقاعدة مراجعة للتغييرات، يكون المشروع قد تجاوز مرحلة التجربة وأصبح أساساً صالحاً للتوسع. يمكن لاحقاً إضافة Load Balancer، قواعد بيانات مُدارة، أو عقد متعددة حسب الضغط المتوقع.

كما أن توسيع المشروع عبر استخدام الوحدات (Modules) في Terraform لتنظيم الكود وإعادة استخدامه يجعل الفريق قادراً على إعادة بناء نفس البيئة لعدة تطبيقات دون نسخ فوضوي للأكواد.

الخلاصة

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