دليل معماري 2026 DevOps والبنية التحتية · 18 دقيقة قراءة

Terraform وInfrastructure as Code في 2026: الدليل الشامل لأتمتة البنية التحتية من الصفر

⚡ الخلاصة السريعة (TL;DR)

Infrastructure as Code (IaC) هو أسلوب إدارة البنية التحتية عبر ملفات كود بدل الإعداد اليدوي، وTerraform ما زال الأداة الأكثر انتشارًا لهذا الغرض. لكن المشهد تغيّر جوهريًا بعد أن غيّرت HashiCorp ترخيص Terraform إلى BSL في 2023 ثم استحوذت IBM على HashiCorp نهاية 2024، ما دفع المجتمع لإطلاق OpenTofu كنسخة مطابقة مرخّصة بـMPL 2.0 تحت مظلة Linux Foundation. في 2026، أصبح OpenTofu خيارًا افتراضيًا معقولًا للمشاريع الجديدة التي لا ترتبط بمنصة HashiCorp التجارية، بينما تبقى Terraform خيارًا صالحًا لمن يعتمد على دعمها الرسمي. أداة ثالثة، Pulumi، تطرح بديلًا مختلفًا جذريًا: كتابة البنية التحتية بلغات برمجة حقيقية بدل لغة HCL التصريحية.

لسنوات طويلة، كانت البنية التحتية تُبنى بالنقر يدويًا عبر لوحات تحكم AWS أو Azure، أو عبر سكربتات مبعثرة لا يتذكر أحد بالضبط ماذا تفعل. Infrastructure as Code غيّر هذه المعادلة جذريًا: البنية التحتية بأكملها -من الخوادم إلى الشبكات إلى قواعد البيانات- تُوصف في ملفات كود، تُراجَع كأي كود آخر، وتُطبَّق بأمر واحد بدل مئات النقرات. لكن دخول 2026 يجلب معه سؤالًا لم يكن مطروحًا قبل ثلاث سنوات: هل ما زال Terraform هو الخيار الافتراضي الصحيح، أم أن المشهد تغيّر بما يكفي لإعادة النظر؟

ما هو Infrastructure as Code ولماذا يهم فريقك

Infrastructure as Code يعني وصف كل مورد تقني -خادم افتراضي، شبكة فرعية، صلاحية وصول، قاعدة بيانات مُدارة- في ملف نصي منظم، بدل إنشائه يدويًا عبر واجهة رسومية. الفائدة الجوهرية ليست "الأتمتة" وحدها، بل قابلية إعادة الإنتاج (Reproducibility): يمكن تكرار بيئة كاملة مطابقة تمامًا -Staging أو بيئة كارثة- بأمر واحد، ومراجعة أي تغيير في البنية التحتية عبر Pull Request قبل تطبيقه فعليًا، تمامًا كمراجعة كود التطبيق.

🔁 قابلية التكرار

إنشاء بيئة مطابقة تمامًا (Dev/Staging/Production) بنفس الملفات، دون اختلافات يدوية خفية تسبب مشاكل لاحقًا.

📝 مراجعة قبل التطبيق

كل تغيير في البنية التحتية يمر عبر مراجعة كود (Code Review) وسجل تاريخي كامل في Git، بدل تغييرات يدوية غير موثّقة.

⚡ استرجاع أسرع من الكوارث

في حال فقدان بيئة كاملة، يمكن إعادة بنائها من الكود خلال دقائق بدل أيام من الإعداد اليدوي.

كيف يعمل Terraform: المفاهيم الأساسية

يعتمد Terraform على لغة تصريحية خاصة به تُسمى HCL (HashiCorp Configuration Language)، حيث تصف "ما تريده" من البنية التحتية النهائية، لا "كيف تصل إليها" خطوة بخطوة. يقارن Terraform هذا الوصف بملف حالة (State File) يسجّل الوضع الحالي الفعلي، ثم يحسب فرق الخطة (Plan) اللازمة للوصول من الحالة الحالية إلى الحالة المطلوبة، قبل تطبيقها فعليًا عبر مزوّدين (Providers) لكل خدمة سحابية.

resource "aws_s3_bucket" "data" {
  bucket = "mycompany-data-${var.environment}"
  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

وصف الحالة المطلوبة (HCL)

←

terraform plan

←

مراجعة الفرق

←

terraform apply

قصة ترخيص Terraform: من MPL إلى BSL إلى انشقاق OpenTofu

هذه القصة أصبحت جزءًا لا يمكن تجاهله من أي قرار تقني حول Terraform في 2026. حتى الإصدار 1.5، كانت Terraform مرخّصة بـMozilla Public License 2.0 (MPL)، وهو ترخيص مفتوح المصدر تقليدي بلا قيود على الاستخدام التجاري المنافس.

أغسطس 2023

غيّرت HashiCorp ترخيص Terraform إلى Business Source License (BSL 1.1)، وهو ترخيص متاح المصدر لكنه يقيّد استخدامه من قِبل شركات تُعتبر منافسة لمنتجات HashiCorp التجارية.

سبتمبر 2023

تبنّت مؤسسة Linux Foundation نسخة مطابقة من آخر إصدار مرخّص بـMPL (الإصدار 1.5) تحت اسم OpenTofu، بحوكمة محايدة مستقلة عن أي شركة واحدة.

فبراير 2025

أتمّت IBM استحواذها على HashiCorp بصفقة بقيمة 6.4 مليار دولار، فأصبحت Terraform رسميًا منتجًا تابعًا لـIBM.

أبريل 2025

انضم OpenTofu إلى مؤسسة Cloud Native Computing Foundation (CNCF) في مستوى Sandbox، مع استثناء خاص للاحتفاظ بترخيص MPL 2.0.

2025–2026

تباعد المشروعان تقنيًا بشكل حقيقي: أضاف OpenTofu ميزات لم تصل بعد إلى Terraform المفتوحة المصدر، مثل تشفير الحالة (State Encryption) المدمج والقيم المؤقتة (Ephemeral Values)، بينما ركّزت HashiCorp على تكامل أعمق مع منصتها التجارية HCP Terraform.

⚠️ صندوق الشفافية الإحصائية: تباين أرقام تبنّي OpenTofu

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

Terraform مقابل OpenTofu: مقارنة تفصيلية

المعيار	Terraform	OpenTofu
الترخيص	Business Source License 1.1 (غير معتمد من OSI)	Mozilla Public License 2.0 (مفتوح المصدر بالكامل)
الحوكمة	IBM / HashiCorp	Linux Foundation / لجنة تقنية مستقلة
لغة الإعداد ونظام الحالة	HCL، متوافق	HCL نفسها، متوافق مع ملفات Terraform
تشفير الحالة المدمج	غير متوفر في النسخة المفتوحة المصدر	مدمج أصليًا في CLI
سجل المزوّدين (Providers)	الأكبر والأكثر نضجًا؛ مزوّدو HashiCorp (Vault، Consul) يحصلون على التحديثات أولًا	يستخدم نفس سجل المزوّدين ومتوافق معه
الأنسب لـ	فرق تعتمد على HCP Terraform أو دعم IBM الرسمي	مشاريع جديدة، جهات تفضّل ترخيصًا مفتوحًا بلا قيود، بيئات تنظيمية حساسة للترخيص

Terraform مقابل Pulumi: DSL تصريحية أم لغة برمجة حقيقية

يطرح Pulumi فلسفة مختلفة جذريًا عن Terraform وOpenTofu: بدل لغة HCL التصريحية المتخصصة، تُكتب البنية التحتية بلغات برمجة عامة كاملة -TypeScript وPython وGo وC# وJava- مع كل ما تتيحه هذه اللغات من حلقات تكرار حقيقية، دوال، فئات، واختبارات وحدة (Unit Tests) تقليدية.

// نفس المثال بلغة Pulumi (TypeScript)
import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("data", {
  bucket: `mycompany-data-${environment}`,
  tags: { Environment: environment, ManagedBy: "pulumi" },
});

المعيار	Terraform / OpenTofu	Pulumi
اللغة	HCL (تصريحية متخصصة)	لغات برمجة عامة (TypeScript، Python، Go...)
حجم سجل المزوّدين	الأكبر في السوق (آلاف المزوّدين)	أصغر نسبيًا، مع إمكانية جسر مزوّدي Terraform
المنطق المعقّد (شروط، حلقات ديناميكية)	محدود بقدرات HCL التعبيرية	طبيعي تمامًا لأنه كود برمجي عادي
منحنى التعلّم لفرق العمليات	أسهل لفرق SRE/DevOps التقليدية	أسهل لفرق تملك خلفية برمجة تطبيقات قوية
سوق التوظيف	أوسع بكثير	أضيق نسبيًا حتى الآن

✅ القاعدة العملية

اختر Terraform أو OpenTofu إذا كان فريقك مكوّنًا أساسًا من مهندسي عمليات (SRE/DevOps) لا يكتبون كود تطبيقات يوميًا. اختر Pulumi إذا كان فريقك يملك ثقافة هندسة برمجيات قوية ويحتاج منطقًا ديناميكيًا معقدًا يصعب التعبير عنه بلغة تصريحية محدودة.

خطوات عملية: أول مشروع Infrastructure as Code

1. تثبيت الأداة والمزوّد

←

2. وصف المورد الأول

←

3. init + plan

←

4. مراجعة ثم apply

←

5. تخزين الحالة عن بُعد

ابدأ دائمًا بمورد واحد بسيط -سلة تخزين أو شبكة فرعية- لفهم دورة العمل الكاملة (init → plan → apply → destroy) قبل الانتقال إلى بنية تحتية إنتاجية معقدة. الخطوة الأهم التي يتجاهلها المبتدئون غالبًا هي نقل ملف الحالة من القرص المحلي إلى تخزين عن بُعد (Remote Backend) مثل S3 مع قفل حالة (State Locking) عبر DynamoDB أو ما يعادله، قبل أن يعمل أكثر من شخص على نفس البنية التحتية.

إدارة الحالة (State) والأخطاء الشائعة فيها

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

❌ حالة محلية بلا قفل

عمل أكثر من شخص على نفس البنية التحتية في نفس الوقت دون قفل حالة يسبب تعارضات وتلفًا محتملًا للملف.

❌ رفع الحالة إلى Git

ملف الحالة قد يحتوي على قيم حساسة بصيغة نصية واضحة؛ رفعه إلى مستودع كود يعني تسريب هذه الأسرار.

❌ تعديل يدوي بعد Terraform

تغيير مورد يدويًا من لوحة تحكم السحابة بعد إنشائه بـTerraform يُحدث انحرافًا (Drift) بين الحالة المسجّلة والواقع الفعلي.

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

تخزين الحالة في backend عن بُعد مع قفل حالة إلزامي قبل أي عمل جماعي.
تفعيل تشفير الحالة (سواء عبر ميزة OpenTofu المدمجة أو حل خارجي) نظرًا لاحتوائها المحتمل على بيانات حساسة.
تقسيم البنية التحتية إلى وحدات (Modules) قابلة لإعادة الاستخدام بدل ملف ضخم واحد.
تشغيل terraform plan تلقائيًا في كل Pull Request عبر CI/CD قبل السماح بالدمج.
منع أي تعديل يدوي مباشر على الموارد المُدارة بالكود، وإجبار كل تغيير على المرور عبر IaC.

أخطاء شائعة عند تبني IaC

❌ تبني الأداة قبل الفهم

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

❌ ملف واحد ضخم بلا وحدات

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

❌ تجاهل قصة الترخيص عند الاختيار

اختيار Terraform أو OpenTofu دون تقييم أثر الترخيص الفعلي على مؤسستك (قيود تنظيمية، علاقة تعاقدية مع IBM، متطلبات مشتريات حكومية).

إطار القرار: أي أداة تختار في 2026

وضعك	التوصية
لديك بنية Terraform قائمة تعمل جيدًا، بلا حساسية تجاه الترخيص	ابقَ على Terraform؛ لا داعٍ للتبديل بدافع الضجيج وحده
مشروع جديد بالكامل، بلا استثمار سابق	OpenTofu خيار افتراضي معقول: نفس اللغة، ترخيص مفتوح بلا لبس، حوكمة محايدة
مؤسسة تخضع لمتطلبات مشتريات تُلزم بترخيص OSI معتمد (شائع في القطاع العام الأوروبي)	OpenTofu غالبًا الخيار الأكثر توافقًا
تعتمد بعمق على منصة HCP Terraform أو Sentinel التجارية	ابقَ على Terraform، أو خطط للانتقال كمشروع منصة كامل لا كتبديل أداة بسيط
فريق هندسة برمجيات قوي يحتاج منطقًا ديناميكيًا معقدًا	ادرس Pulumi كبديل جاد، خصوصًا لبنية تحتية على مستوى التطبيق

هل تحتاج IaC فعلاً لمشروعك؟

🎯 دليل سريع للتقييم الذاتي

إذا كان مشروعك يدير موردًا سحابيًا واحدًا أو موردين فقط بشكل نادر التغيير، فقد يكون الإعداد اليدوي أو سكربت بسيط كافيًا، وIaC قد يضيف تعقيدًا غير مبرر. أما إن كنت تدير بيئات متعددة (Dev/Staging/Production)، أو فريقًا أكبر من شخص واحد يلمس البنية التحتية، أو موارد تتغير بشكل متكرر، فإن الاستثمار في IaC يُسدَّد بسرعة عبر تقليل الأخطاء اليدوية وتسريع الاسترجاع من الكوارث.

الخلاصة

لم يعد قرار "أي أداة IaC" في 2026 قرارًا تقنيًا بحتًا؛ أصبح قرارًا يشمل الترخيص والحوكمة بقدر ما يشمل الميزات. Terraform ما زالت أداة قوية وناضجة بدعم رسمي حقيقي، وOpenTofu نضج بما يكفي ليكون خيارًا افتراضيًا معقولًا وخاليًا من قلق الترخيص للمشاريع الجديدة، بينما يبقى Pulumi خيارًا جادًا لمن يفضّل قوة لغة برمجة حقيقية على بساطة DSL تصريحية. القاعدة الأهم تبقى ثابتة بغض النظر عن الأداة: لا تنتقل من بنية تحتية يدوية إلى IaC دون فهم دورة الحالة أولًا على بيئة تجريبية بسيطة.

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

هل OpenTofu بديل آمن تمامًا لـTerraform؟

من الناحية التقنية، نعم إلى حد كبير؛ يستخدمان نفس لغة HCL ونفس سجل المزوّدين، وتوافقهما مضمون حتى نقطة الانشقاق (الإصدار 1.5) مع استمرار OpenTofu بالتوافق العملي منذ ذلك الحين. الفارق الحقيقي يكمن في الترخيص والحوكمة، لا في التوافق التقني اليومي.

هل ترخيص BSL يمنعني من استخدام Terraform مجانًا؟

لا؛ ترخيص BSL يسمح بالاستخدام المجاني لغالبية الحالات، ويقيّد فقط الجهات التي تبني منتجًا تجاريًا منافسًا مباشرًا لمنتجات HashiCorp نفسها. أغلب الفرق التقنية العادية غير متأثرة عمليًا بهذا القيد.

هل يستحق تعلّم Pulumi إذا كنت أعرف Terraform بالفعل؟

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

هل يمكن الانتقال من Terraform إلى OpenTofu دون إعادة كتابة الكود؟

نعم غالبًا؛ بفضل توافق HCL وصيغة ملف الحالة، الانتقال عادة ما يكون استبدال الأداة التنفيذية (Binary) مع تعديلات طفيفة، لا إعادة كتابة كاملة للبنية التحتية.

ما الفرق بين Terraform وAnsible؟

Terraform مخصص أساسًا لتوفير البنية التحتية نفسها (خوادم، شبكات، خدمات مُدارة)، بينما يتخصص Ansible أكثر في إعداد وتهيئة ما بداخل تلك الخوادم بعد إنشائها. غالبًا ما تُستخدم الأداتان معًا في خط أنابيب واحد.

المصادر

HashiCorp Terraform Official Documentation — developer.hashicorp.com/terraform
OpenTofu Official Documentation — opentofu.org
Pulumi Official Documentation — pulumi.com/docs
Linux Foundation / CNCF — cncf.io

فريق تحرير VEXORA

محتوى تقني عربي متعمق، مبني على مصادر رسمية وتحقق تحريري صارم.

استكشف المزيد من أدلة VEXORA المعمارية

مقارنات تقنية عميقة تساعدك على اتخاذ قرارات هندسية مبنية على بيانات لا على الضجيج.

تصفح المزيد من المقالات

Terraform وInfrastructure as Code (IaC) في 2026: أيهما تختار؟