OpenTofu بالشرح: تفرع Terraform، والترحيل، وهل يجب التحول إليها

افتح وحدة Terraform اليوم وستواجه سؤالاً لم يكن موجوداً قبل ثلاث سنوات: هل الملف الثنائي الذي يشغّل هذا الكود هو terraform، أم أنه tofu؟ أتمت IBM عملية استحواذ HashiCorp في 27 فبراير 2025 مقابل 6.4 مليار دولار، وأصبحت OpenTofu مشروع CNCF Sandbox في 23 أبريل 2025، وأصبح مسار الترحيل بين الأداتين موثقاً رسمياً. لم يعد القرار افتراضياً.

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

تتناول هذه المقالة أربعة أمور: ماهية OpenTofu في عام 2026، والميزات التي لا تملكها Terraform، وكيف يبدو الترحيل عملياً، وتوصية واضحة لأشكال القرار الشائعة.

النسخة المختصرة

• OpenTofu هو نسخة مفتوحة المصدر متفرعة من Terraform، برخصة MPL 2.0، تستضيفها Linux Foundation، ومشروع CNCF Sandbox منذ 23 أبريل 2025. تفرّع عن Terraform 1.5.x بعد أن نقلت HashiCorp ترخيص Terraform إلى Business Source License في أغسطس 2023.
• اعتباراً من 26 يوليو 2026، إصدار الصيانة الحالي هو v1.12.5؛ ويضم مستودع GitHub أكثر من 29,000 نجمة، كما أن الموقع الرسمي لمشروع OpenTofu يُدرج أكثر من 3,900 provider وأكثر من 23,600 module.
• يوفر إمكانيات حصرية لـ OpenTofu أو تتصدرها OpenTofu ولا توازيها Terraform حالياً بالطريقة نفسها: تشفير الـ state والخطط من جهة العميل، و provider for_each، والتقييم المبكر للمتغيرات، ووسيطة enabled الوصفية، و dynamic prevent_destroy. الموارد المؤقتة (Ephemeral resources) ليست حصرية لـ OpenTofu؛ فـ Terraform تدعمها منذ الإصدار 1.10.
• بالنسبة لمشروع صغير على Terraform 1.5.x بحالة (state) محلية أو على S3، يمكن أن يكون المسار السهل ترحيلاً قصيراً وقابلاً للتراجع. أما المراجع في CI/CD، وسير العمل الخاص بـ HCP، وتغييرات ملف قفل التبعيات، فهي حيث يتوسع العمل.
• بالنسبة لمشروع IaC جديد في عام 2026، ابدأ بـ OpenTofu. أما بالنسبة لنشر Terraform قائم بالفعل، فانتقل عندما يُقيّدك ترخيص BSL، أو عندما تحتاج ميزة تمتلكها OpenTofu ولا تمتلكها Terraform، أو عندما تكون خارطة الطريق التي تملكها IBM مصدر قلق حقيقي. غير ذلك، فإن العائد مقابل التكلفة ضئيل.

ما هي OpenTofu في عام 2026

OpenTofu هي نسخة مفتوحة المصدر متفرعة من Terraform، تستضيفها Linux Foundation، وقُبلت في CNCF كمشروع Sandbox في 23 أبريل 2025، وهي مرخّصة بموجب Mozilla Public License 2.0. والملف الثنائي هو tofu. لغة الإعداد هي HCL، وهي نفس لغة HCL التي تستخدمها Terraform. بالنسبة لمعظم المشاريع البسيطة إلى المتوسطة، تعمل قاعدة كود Terraform الحالية على OpenTofu دون تعديل.

بدأ التفرع في أغسطس 2023 بعد أن نقلت HashiCorp ترخيص Terraform من MPL 2.0 إلى Business Source License 1.1 في 10 أغسطس 2023. رخصة BSL هي رخصة "مصدر متاح" وليست معتمدة من OSI، وتقيّد الاستخدام الإنتاجي الذي "ينافس عروض HashiCorp التجارية". وفي غضون خمسة أيام، نُشر OpenTF Manifesto وأُعلن عن التفرع. وقدّم إعلان Linux Foundation رسمياً مشروع OpenTofu في 20 سبتمبر 2023.

إعلان Linux Foundation أسماء Harness وGruntwork وSpacelift وenv0 وScalr وDigger وTerrateam وMassdriver وTerramate ضمن الداعمين المؤسسين، مع التزام 18 مهندساً على الأقل بدوام كامل لمدة خمس سنوات كحد أدنى. تفرّعت OpenTofu عن Terraform 1.5.x، آخر إصدار برخصة MPL 2.0.

أين يقف المشروع اليوم: v1.12.5 هو إصدار الصيانة الحالي، ويُدرج الموقع الرسمي أكثر من 3,900 provider وأكثر من 23,600 module. لم تعد مؤشرات التبني مقتصرة على زخم التفرع الاحتجاجي الأولي: فقد دراسة حالة ترحيل Fidelity تصف برنامجاً يشمل أكثر من 50,000 ملف state وأربعة ملايين مورد.

السياق التجاري ذو الصلة: أتمت IBM استحواذها على HashiCorp في 27 فبراير 2025 مقابل 6.4 مليار دولار. أصبحت خارطة طريق Terraform الآن محددة داخل بائع مؤسسي أكبر بكثير. هذا ليس بالضرورة جيداً أو سيئاً للمستخدمين، لكنه جزء من الحساب الذي تجريه الفرق في عام 2026.

أين تختلف OpenTofu عن Terraform

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

من جهة العميل، تشفير الـ (state encryption) (الإصدار v1.7.0، 30 أبريل 2024). يمكن لـ OpenTofu تشفير ملفات الـ state والخطط داخل الأداة نفسها باستخدام PBKDF2 أو AWS KMS أو GCP KMS أو OpenBao. وعادةً ما تُفوّض Terraform التشفير أثناء التخزين إلى الـ backend المختار، بينما تبقى الـ state المحلية نصاً واضحاً. يمكن لتشفير OpenTofu من جهة العميل حماية كائن state مسروق أو خطة مخزّنة مؤقتاً، شريطة ألا يُكشف مفتاح فك التشفير معها. وهو لا يحل محل TLS، أو ضوابط وصول الـ backend، أو انضباط إدارة الأسرار.

يبدو الإعداد تقريباً كما يلي:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

المزوّد for_each (v1.9). يمكنك التكرار عبر إعدادات الـ provider تماماً كما تُكرر عبر الموارد. في الإعدادات متعددة المناطق أو متعددة الحسابات، يزيل هذا فئة كاملة من الحلول البديلة طويلة الأمد. لم تعد بحاجة لإنشاء provider مستعار يدوياً لكل منطقة؛ يمكنك تشغيل كل شيء من كتلة واحدة مبنية على map.

التقييم المبكر للمتغيرات (v1.8). يمكن الآن الإشارة إلى المتغيرات في أماكن كانت مقيدة سابقاً، بما في ذلك وسيطات backend وsource للوحدة. هذا مفيد عندما تدير وحدة جذرية واحدة عدة بيئات تختلف فقط في مجموعة صغيرة من المتغيرات.

الموارد المؤقتة (Ephemeral resources) و enabled الوسيطة الوصفية (الإصدار v1.11.0، 9 ديسمبر 2025). أضافت OpenTofu 1.11 الموارد المؤقتة والوسيطة الوصفية enabled . توجد الموارد المؤقتة فقط ضمن دورة plan/apply واحدة ولا تُحفظ في الـ state، وهو أمر مفيد لبيانات الاعتماد قصيرة العمر. وهي ليست حصرية لـ OpenTofu: فقد قدّمتها Terraform في الإصدار 1.10 وأضافت وسيطات write-only في 1.11. أما القدرة الخاصة بـ OpenTofu هنا فهي enabled، الذي يبدّل كتلة مورد بناءً على تعبير دون الحاجة إلى ألاعيب count الشرط (count).

Dynamic prevent_destroy (v1.12). في Terraform، يقبل إعداد prevent_destroy قيماً حرفية فقط. تتيح لك OpenTofu 1.12 حسابه، بحيث يمكن لوحدة واحدة إبقاء بيئة staging قابلة للحذف مع حماية بيئة الإنتاج.

صف الترخيص هو الفرق البنيوي الذي لا يظهر كميزة. رخصة MPL 2.0 معتمدة من OSI وهي copyleft على مستوى الملف. أما رخصة BSL 1.1 الخاصة بـ Terraform فهي "مصدر متاح"، وتتضمن قيداً إضافياً على الاستخدام، وتتحول إلى MPL 2.0 بعد أربع سنوات من نشر كل عمل مرخّص. بالنسبة لمعظم الفرق، الأثر العملي ضئيل؛ أما بالنسبة للبائعين الذين يبنون شيئاً قريباً من عروض HashiCorp التجارية، فهذا هو بالضبط سبب وجود التفرع.

الترحيل: ما الذي يتعطل فعلياً

دليل الترحيل الرسمي قصير وقابل للتراجع عمداً: انسخ الـ state والكود احتياطياً، ثبّت OpenTofu، شغّل tofu init، وقارن نتيجة tofu plan، واختبر تغييراً صغيراً. الأجزاء الصعبة ليست الأوامر. بل هي مراجع CI/CD المحيطة، وسير عمل HCP الخاص، وتغييرات قفل التبعيات، والمراجعة التنظيمية التي تصاحب تبني تفرع.

المسار السهل

بالنسبة لمشروع لا يستخدم HCP Terraform ولا يحتوي على آلاف المراجع لـ terraform في خطوط الأنابيب، فإن الترحيل مباشر.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan يجب أن يتطابق مع الخطة التي أنتجتها Terraform. إذا ظهر اختلاف غير متوقع، تحقق من إصدارات الـ providers، وإعدادات الـ backend، وأي ميزات في Terraform ظهرت بعد الإصدار 1.5.x قبل التطبيق.

هناك تفصيلان مهمان قبل تشغيل أي شيء. أولاً، تتوافق OpenTofu إلى حد كبير من ناحية الإعداد مع HCL بأسلوب Terraform في الحالات التي يصفها هذا الدليل، لكن الميزات المضافة بعد Terraform 1.5.x لا تزال تحتاج إلى فحص توافق. ثانياً، tofu init -upgrade قد يحدّث .terraform.lock.hcl، بما في ذلك عناوين مصدر الـ providers وسجلات checksum. راجع هذه البيانات الوصفية بمعزل عن انحراف البنية التحتية.

العوائق الحقيقية

هناك ثلاثة أمور يمكن أن تحوّل ترحيلاً سريعاً عبر CLI إلى مشروع منصة أوسع. لا شيء منها خلل برمجي.

مساحات عمل HCP Terraform. تتضمن OpenTofu تكاملات cloud وremote لخدمات remote المتوافقة، بما في ذلك HCP Terraform في سيناريوهات التنفيذ المحلي وتخزين الـ state. الجزء الأصعب هو التنفيذ عن بعد الخاص بـ HCP وميزات المنصة: Sentinel، وrun triggers، وبيانات الاعتماد الديناميكية، وStacks، وأي سلوك خدمة لا تستطيع OpenTofu اختباره أو دعمه بالكامل. إذا كانت هذه العناصر أساسية، جرّب مساحة عمل واحدة أولاً؛ وإذا كنت تغادر HCP، رحّل الـ state وأعد إنشاء ضوابط المنصة تلك.

نصيحة: يمكن أن تكون مغادرة HCP Terraform أكبر تكلفة خفية عندما تعتمد المنظومة على سير عمل خاص بـ HCP. قبل أن تقرر، شغّل terraform state pull > state.json وافحص الحجم وعدد الموارد. مساحة عمل واحدة بها 200 مورد هي مشروع مختلف تماماً عن أسطول من 50 مساحة عمل مع run triggers وpolicy sets. الحالة الثانية هي ترحيل على مستوى هندسة المنصات، وليست مجرد استبدال أداة.

خطوط أنابيب CI/CD المُثبّتة بشكل صريح على terraform. كل مرجع لـ terraform plan, terraform apply، وإلى مسار الملف الثنائي، وصورة Docker، وخطوة GitHub Actions أو GitLab CI يحتاج إلى مراجعة. بالنسبة لـ GitHub Actions، يبدو الاستبدال تقريباً كما يلي:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

هذه هي الحالة البسيطة: سير عمل واحد، مستودع واحد. أما في monorepo يحتوي على composite actions مشتركة، وخطوط أنابيب متعددة، ومكتبة سير عمل قابلة لإعادة الاستخدام، فتتسع مساحة المراجعة كثيراً. العمل ميكانيكي، لكنه قد يستغرق وقتاً أطول من مجرد استبدال أداة CLI.

مراجعة ملف قفل التبعيات. tofu init قد يحدّث .terraform.lock.hcl، بما في ذلك عناوين مصدر الـ providers وسجلات checksum. يمكن لـ OpenTofu 1.12 أيضاً إضافة مجموعات checksum كاملة h1: . تعامل مع الفرق (diff) على أنه بيانات وصفية للتبعيات يجب مراجعتها وحفظها بشكل منفصل، وليس انحرافاً في البنية التحتية.

نصيحة: قد يبدو الفرق (diff) في ملف القفل صاخباً في أول commit. شغّل tofu init -upgrade على فرع نظيف، وقم بعمل commit لملف القفل فقط برسالة واضحة مثل "review OpenTofu lock-file changes"، ثم أعد التأسيس (rebase) لعمل الميزة فوقه. خلط بيانات التبعيات الوصفية مع طلب سحب لميزة يجعل كلا التغييرين أصعب في المراجعة.

مقاومة أصحاب المصلحة. "نحن نعمل الآن بتفرع" تُستقبل بشكل مختلف في المؤسسات المختلفة. الرد الصادق هو أن OpenTofu تظل متوافقة إلى حد كبير من ناحية الإعداد مع HCL بأسلوب Terraform في الحالات التي يصفها هذا الدليل، لذا فإن التبديل عادةً ما يكون قابلاً للتراجع. لو اختفت OpenTofu غداً، لاستطاعت فرق كثيرة إعادة تثبيت Terraform، ومراجعة ملف القفل، ومواصلة استخدام نفس .tf ملفات .tf. تحقق أولاً من الميزات التي ظهرت بعد التفرع؛ هذا التحفظ أكثر مصداقية من الوعد بقابلية تبادل مثالية.

متى يكون الترحيل صعباً فعلياً

هذا المسار السهل لا ينطبق على كل منظومة Terraform.

يصبح الترحيل أصعب بشكل ملحوظ عندما:

• تكون الـ state كبيرة (آلاف الموارد، عشرات مساحات العمل) وتعيش في HCP Terraform.
• تستخدم قاعدة الكود ميزات خاصة بـ HCP بعمق: سياسات Sentinel المدمجة في مساحات العمل، وrun triggers، وبيانات اعتماد provider ديناميكية تديرها HCP. وTerraform Stacks حصرية لـ HCP ولا مكافئ لها في OpenTofu، وهو أمر خارج نطاق هذا المقال.
• تُسمّي عملية تدقيق مؤسسي أو إطار امتثال "Terraform" تحديداً كأداة IaC المعتمدة رسمياً، وهو ما يضيف مشكلة شراء وتوثيق فوق المشكلة التقنية.
• تحتوي مكتبة وحدات كبيرة على قيود إصدار داخلية كانت تُحل استناداً إلى سلوك سجل (registry) خاص بـ Terraform.

ليس على كل فريق أن يترحّل. لا يكون تحليل التكلفة مقابل العائد منطقياً إلا عندما تؤثر قيود BSL فعلياً على حالة استخدامك، أو عندما تفتح ميزة معينة في OpenTofu شيئاً ملموساً، أو عندما تكون خارطة الطريق التي تتحكم بها IBM مصدر قلق حقيقي لمؤسستك. إذا لم ينطبق أي من ذلك، فإن البقاء على Terraform قرار مدافع عنه تماماً.

هل يجب أن تنتقل؟

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

تبنٍ جديد لـ IaC (مشروع من الصفر). ابدأ بـ OpenTofu. الترخيص هو MPL 2.0، والحوكمة تقع تحت مظلة Linux Foundation وCNCF، ولدى المشروع وتيرة إصدارات نشطة. تشمل عوامل تميزه تشفير الـ state من جهة العميل، وprovider for_each, enabled، وdynamic prevent_destroy. لا يوجد أي احتكاك مع BSL يجب التخطيط له. هذه هي التوصية الأقوى في هذه المقالة.

مستخدم Terraform حالي، مشروع صغير إلى متوسط. انتقل إذا تحقق أي من ثلاثة محفزات. أولاً: أنت تبيع أو قد تبيع منتجاً قد يقترب من استثناء BSL "ينافس HashiCorp"؛ والحساب القانوني أوضح مع MPL 2.0. ثانياً: تحتاج إلى تشفير الـ state من جهة العميل، وprovider for_each, enabled، أو dynamic prevent_destroy ، ولم يعد الحل البديل في Terraform يستحق الصيانة. ثالثاً: تفضل حوكمة متعددة الأطراف على خارطة طريق يتحكم بها بائع واحد. إذا لم ينطبق أي مما سبق وكانت Terraform تعمل بسلاسة، فابقَ عليها. الترحيل قابل للتراجع في كثير من الحالات، لكنه ليس مجانياً.

مستخدم مكثف لـ HCP Terraform. تعامل مع هذا كقرار منصة، وليس بالضرورة كترحيل backend. يمكن لـ OpenTofu استخدام backends remote متوافقة، لكن التنفيذ عن بعد الخاص بـ HCP، وSentinel، وrun triggers، وبيانات الاعتماد الديناميكية، وStacks لا تزال بحاجة إلى تقييم ميزة بميزة. إذا كانت هذه الضوابط أساسية، جرّبها أولاً على نطاق محدود. وإذا كنت تغادر HCP لأسباب تتعلق بالترخيص أو التكلفة أو الحوكمة، فخطط للعمل كترحيل منصة.

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

هناك أمر آخر يستحق التطرق إليه مباشرة: الانتقاد المشروع القائل بأن OpenTofu هي جزئياً تحوّط لصالح بائعي SaaS. أثار نقاش على Hacker News حول تغيير BSL قلقاً من أن الأعضاء المؤسسين للمشروع هم منصات Terraform تجارية لديها دافعها الخاص لمرونة الترخيص. أنا آخذ هذا القلق على محمل الجد. عامل التخفيف هو بنية الحوكمة، واستضافة Linux Foundation، ووضع CNCF Sandbox، ورخصة MPL 2.0 على كل ملف، وهذا يجعل إعادة الترخيص مستقبلاً أصعب بكثير مما كانت عليه مع بائع واحد. هذا لا يجعلها مستحيلة. لكنه يجعلها مكلفة بما يكفي لتكون رادعاً حقيقياً.

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

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

تشغيل OpenTofu بنفسك

OpenTofu هي ملف ثنائي لواجهة سطر الأوامر (CLI). المكان الذي تشغّله فيه يحدد الكثير من التكلفة والأمان وما يمكنك فعله به. هناك تقريباً ثلاثة أماكن منطقية لوضعه فيها.

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

عامل CI مُدار (GitHub Actions، GitLab CI، إلخ). المسار الشائع. إجراء opentofu/setup-opentofu هو بديل مباشر لـ hashicorp/setup-terraform. يعمل هذا بشكل جيد لمعظم الفرق والمشاريع. المفاضلات: تمر الأسرار عبر خدمة CI تابعة لجهة خارجية، وقد تنفد دقائق الخطة المجانية في عمليات state الكبيرة، وبيئة العامل (runner) مؤقتة، وهو أمر مفيد عادةً لكنه أحياناً قيد. راجع GitHub vs GitLab إذا كنت لا تزال تختار بين خيارات CI مُستضافة، و Best CI/CD Tools للحصول على نظرة أوسع على المشهد العام.

عامل مستضاف ذاتياً على VPS. مفيد عندما تتوقف مفاضلات CI المُدارة عن الجدوى: يجب أن تبقى الأسرار بعيدة عن خدمة تابعة لجهة خارجية، أو تصبح دقائق CI مكلفة، أو تريد ذاكرات تخزين مؤقت دائمة للـ providers. الإعداد بسيط: VPS يعمل بلينكس، والملف الثنائي لـ OpenTofu، وعامل GitHub Actions أو GitLab Runner، وDocker لعزل المهام. راجع Install Docker on VPS إذا كان هذا الجزء جديداً عليك. بالنسبة لعامل فريق صغير، تُعد 4 جيجابايت من الذاكرة، ومعالجين افتراضيين (vCPU)، و60 جيجابايت من NVMe نقطة بداية معقولة؛ وسّع المعالج والذاكرة والتخزين للخطط الأكبر والتزامن الأعلى.

بالنسبة للفرق التي تحتاج إلى تحكم أكثر إحكاماً في أسرار العامل، أو ذاكرات تخزين مؤقت دائمة للـ providers، أو تكاليف CI يمكن التنبؤ بها، فقد يكون عامل مستضاف ذاتياً على VPS منطقياً. في هذا الإعداد، أعطِ الأولوية لوصول root، وتخزين NVMe سريع، وسهولة تغيير الحجم، ومعالج/ذاكرة كافيين لعمليات الخطط الأكبر.

خوادم Cloudzy Linux VPS تناسب هذا النمط من العامل المستضاف ذاتياً بفضل وصول root، وتخزين NVMe، وحجم مرن، بحيث يمكنك البدء صغيراً ثم توسيع العامل مع نمو أعباء عمل OpenTofu لديك.

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

هل OpenTofu هي نفسها Terraform؟

ليس تماماً. بدأت OpenTofu كتفرع عن Terraform 1.5.x وتظل متوافقة إلى حد كبير من ناحية الإعداد مع HCL بأسلوب Terraform: نفس .tf الملفات، ونفس الـ providers، ونفس سير عمل plan/apply لمشاريع كثيرة. يختلفان في الترخيص وفي الميزات المضافة بعد التفرع. تمتلك OpenTofu تشفير الـ state من جهة العميل، وprovider for_each, enabled، وdynamic prevent_destroy؛ ولدى Terraform ميزاتها الخاصة بعد التفرع، بما في ذلك الموارد المؤقتة.

هل ستدعم OpenTofu كل providers Terraform الخاصة بي؟

بالنسبة للمزودات الرئيسية مثل AWS وGCP وAzure وKubernetes وHelm، فالجواب نعم بشكل عام. OpenTofu Registry تُبلغ عن أكثر من 3,900 provider اعتباراً من يوليو 2026. tofu init قد يحدّث .terraform.lock.hcl قد يحدّث بيانات وصفية. بالنسبة لمزودات متخصصة أو خاصة ببائع معين أو حديثة النشر، تحقق مباشرة من التوفر ودعم الإصدارات قبل التبديل.

هل يمكن أن يُعاد ترخيص OpenTofu نفسها يوماً ما؟

إعادة الترخيص مستقبلاً أصعب مما كانت عليه بالنسبة لـ Terraform، لكنها ليست مستحيلة. رخصة OpenTofu هي MPL 2.0، وتستضيفها Linux Foundation، وهي مشروع CNCF Sandbox منذ 23 أبريل 2025. الحوكمة متعددة الأطراف والترخيص معتمد من OSI. إعادة ترخيص أحادية الجانب من قِبل أي مؤسس منفرد ستتعارض مع ميثاق المؤسسة ومع المساهمات القائمة بموجب MPL 2.0، التي يجب إزالتها أو إعادة كتابتها. القلق مشروع؛ والحواجز البنيوية حقيقية.

ماذا يعني استحواذ IBM على HashiCorp بالنسبة لمستقبل Terraform؟

أتمت IBM استحواذها على HashiCorp في 27 فبراير 2025 مقابل 6.4 مليار دولار. أصبحت خارطة طريق Terraform الآن داخل بائع مؤسسي أكبر. الاستحواذ وحده لا يثبت اتجاه الترخيص أو المنتج مستقبلاً؛ قيّم ملاحظات الإصدار الحالية، وإرشادات الترخيص، وتغييرات منتج HCP بدلاً من معاملة الملكية كتنبؤ.

هل OpenTofu جاهزة للإنتاج في عام 2026؟

نعم. v1.12.5 هو إصدار الصيانة الحالي، والمشروع ضمن CNCF Sandbox، ووصفت Fidelity تبنياً إنتاجياً عبر منظومة IaC تضم أكثر من 50,000 ملف state وأربعة ملايين مورد. الجاهزية للإنتاج لا تعني تطابقاً كاملاً في الميزات: لا تزال الفرق التي تعتمد على قدرات حصرية لـ HCP مثل Terraform Stacks بحاجة إلى قرار توافق منفصل.