لماذا نحتاج Terraform؟

الجمهور: مبتدئ، لا يُشترط أي أساس
المدة: 20 إلى 30 دقيقة
الوحدة: 1/7
الكفاءة المستهدفة: شرح ما يفعله Terraform ولا تفعله وحدة تحكم أو سكربت أو إجراء مكتوب، واستعمال الكلمة الصحيحة (الحالة المرغوبة، state، المزوّد، الانحراف) للتعبير عن ذلك

من يستخدم هذا، ولأي غرض

عندما تفتح Slack صباحًا، فإن الخوادم التي تجيبك لم تُنشأ يدويًا في وحدة تحكم. لقد وُصفت في ملفات نصية، وأُعيدت قراءتها في طلب دمج، ثم بناها Terraform. الأمر نفسه عند GitHub، وعند Decathlon، وفي آلاف الفرق الأصغر. إليك أربع حقائق عامة يمكن التحقق منها، مع مصدرها.

من	ماذا يفعلون بـ Terraform	المصدر
Slack	صياغة واحدة لـ AWS وDigitalOcean وNS1 وGoogle Cloud. قرابة 1 400 ملف state، كلٌّ منها يملكه الفريق الذي يملك الخدمة. يُخزَّن state في S3 مع إدارة الإصدارات، ويُقفَل بـ DynamoDB. تنشر أداة داخلية `terraform plan` في كل pull request قبل الدمج.	How We Use Terraform At Slack، تدوينة هندسية من Slack، 25 أكتوبر 2022
GitHub	« تقريبًا كل مضيفينا، بمن فيهم مضيفو مركز البيانات، يُدارون بـ Terraform ويُبنون بالطريقة نفسها، سواء على Azure أو AWS أو منصة أخرى. » كان تصميم نموذج أولي لخدمة جديدة يستغرق عدة أيام ؛ ومع Terraform، أقل من ساعة.	دراسة حالة HashiCorp — GitHub، من كلام Aaron Brown، مهندس بنية تحتية
Decathlon	قبل : أكثر من أسبوع للحصول على بنية تحتية، وهو الوقت اللازم للمرور بعدة فرق وبقاعدة CMDB. بعد : « ما كان يستغرق أكثر من أسبوع يُنجَز الآن في أقل من 30 دقيقة »، وكل علامة تجارية تبني ما تحتاجه بنفسها.	دراسة حالة HashiCorp — Decathlon، من كلام Kévin Defives، مهندس نظم معلومات
المجتمع بأكمله	يضم Terraform Registry أكثر من 7 200 مزوّد (الإضافات التي تتحدث إلى واجهات API) وأكثر من 24 000 وحدة قابلة لإعادة الاستخدام. تجاوز مزوّد AWS وحده 5 مليارات تنزيل : ثماني سنوات للمليار الأول، وسنتان للمليارات الأربعة التالية.	Terraform Registry (عدّاد API الخاص بالـ Registry، قراءة بتاريخ 15 سبتمبر 2026) · HashiCorp، 24 نوفمبر 2025

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

التعريفات

ستعود ست كلمات في كل درس. نقدّمها هنا بالتعريف الذي تعطيه HashiCorp، مترجمًا، مع الرابط إلى الصفحة الرسمية.

المصطلح	ما هو	المرجع الرسمي
Infrastructure as Code (IaC)	إدارة البنية التحتية في ملف أو أكثر بدلًا من تكوينها يدويًا في واجهة. الآلات الافتراضية، ومجموعات الأمان، وواجهات الشبكة، وbuckets، ومستودعات Git : كل ما يملك API يمكن وصفه في ملف.	مسرد Terraform — Infrastructure as Code
تصريحي (مقابل أمري)	يصف الملف التصريحي النتيجة المتوقعة : « يجب أن يوجد هذا الـ bucket، بهذه الوسوم ». أما السكربت الأمري فيصف الخطوات : « استدعِ `create-bucket`، ثم `put-bucket-tagging`… ». ملفات Terraform تصريحية : أنت لا تكتب الخطوات، بل يستنتجها Terraform.	What is Terraform — التكوين التصريحي
التكافؤ الذاتي (idempotence)	إعادة تشغيل العملية نفسها عدة مرات تعطي النتيجة ذاتها كمرة واحدة. إذا كانت البنية التحتية مطابقة أصلًا للشيفرة، يعلن `terraform plan` أنه لا حاجة لأي إجراء (`No changes. Your infrastructure matches the configuration.`) ولا يمسّ `apply` شيئًا. أما سكربت يسلسل استدعاءات `create-…`، فعند إعادة تشغيله، يفشل على ما هو موجود أصلًا أو ينشئ نسخة مكررة.	مرجع `terraform plan`
الانحراف (drift)	الفارق بين ما يعتقده state وما يوجد فعلًا، لأن أحدًا عدّل موردًا خارج Terraform (في وحدة التحكم، بسكربت، يدويًا). يكشفه Terraform لحظة الخطة بإعادة قراءة البنية التحتية الحقيقية.	درس تطبيقي — Manage resource drift
State	الملف (`terraform.tfstate`) الذي يسجّل فيه Terraform أي كتلة من الشيفرة تقابل أي كائن حقيقي (بمعرّفه وخصائصه). بدونه، لن يعرف Terraform أن bucket موجودًا أصلًا هو « ملكه » وسيعيد إنشاءه. وهو حسّاس : قد يحتوي على كلمات مرور وعناوين.	Terraform state
المزوّد (provider)	إضافة تعرف API منصة (AWS، Azure، Google Cloud، GitHub، أو حتى القرص المحلي) وتعرض كائناتها في صورة أنواع موارد. يُنزّلها Terraform عند `terraform init`. المزوّد هو من يقوم باستدعاءات API، لا Terraform نفسه.	Providers

في صورة واحدة

تخيّل مهندسًا معماريًا مكلَّفًا بمبنى. لديه ثلاثة أشياء في متناول يده.

المخطط : الرسوم الموقَّعة التي تقول ما يجب أن يكون المبنى. في Terraform، هي ملفاتك .tf.
المبنى الحقيقي : ما بُني فعلًا، بعيوبه، وجدرانه التي حرّكها عامل متحمّس، وبابه المضاف دون إخطار. في Terraform، هو حساب AWS الخاص بك، ومؤسستك على GitHub، وقرصك الصلب.
السجل : الدفتر الذي دوّن فيه المهندس، غرفةً غرفةً، ما أمر ببنائه وتحت أي رقم. في Terraform، هو state.

كل مرة يُطلب منه التدخّل، يفعل المهندس الشيء نفسه. يعيد قراءة المخطط. يفتح سجله. يذهب ليرى المبنى. ثم يقارن الثلاثة ويكتب كشف أعمال : هذا الجدار ناقص، يجب بناؤه ؛ هذا الباب ليس في المخطط، يجب إزالته ؛ هذه النافذة في المكان الصحيح، لا نمسّها. يوقّع العميل الكشف، وعندها فقط ينفّذ الحرفيون (المزوّدون) كل سطر. لا أكثر ولا أقل من الكشف.

تعود هذه الصورة في كل الدورة. عندما يتحدث درس عن المخطط والسجل والمبنى، فهو يتحدث عن الشيفرة وstate والبنية التحتية الحقيقية.

الفرق الجوهري بين « المخطط » وterraform plan. في الصورة، المخطط هو رسم المهندس، أي شيفرتك. أما الأمر terraform plan، فهو يُنتج كشف الأعمال : قائمة ما سيتغيّر ليلتحق المبنى بالمخطط. معنيان لكلمة واحدة. في الدورة، نكتب « المخطط (الشيفرة) » أو « الكشف (مخرجات terraform plan) » عند وجود خطر التباس.

ما لا تفعله وحدة تحكم، ولا سكربت، ولا runbook

يمكنك إنشاء bucket S3 بثلاث طرق دون Terraform : بالنقر، أو بتشغيل سكربت، أو باتباع إجراء مكتوب. لكل منها مكانه. ولا يقوم أيٌّ منها بعمل المهندس المعماري.

الطريقة	ما تفعله جيدًا	ما لا تفعله
وحدة التحكم (AWS، Azure، GCP في المتصفح)	الاستكشاف، وفهم خدمة، والنظر إلى كائن محدد، والإصلاح السريع.	إعادة الإنتاج بشكل مطابق. شخصان ينقران « بالطريقة نفسها » يحصلان على نتيجتين. لا تاريخ مقروء لمن غيّر ماذا. لا شيء لإعادة قراءته قبل التأكيد.
سكربت bash أو PowerShell (`aws ec2 run-instances …`، `aws s3api create-bucket …`)	إعادة تشغيل إنشاء بشكل مطابق، وتسلسله في pipeline.	معرفة ما هو موجود أصلًا. عند إعادة تشغيله مرة ثانية، يحاول إعادة الإنشاء ويتوقف على خطأ، أو ينشئ نسخة مكررة. لا يقارن شيئًا، ولا يكشف أن قاعدة عُدّلت يدويًا، ولا يعرف تدمير ما أنشأه دون سكربت ثانٍ مكتوب يدويًا.
runbook (إجراء مكتوب، لقطات شاشة)	نقل نية، وتدريب أحد، والاحتفاظ بأثر القرار.	إثبات أن البنية التحتية ما زالت مطابقة للنص. في اليوم التالي لتعديل في وحدة التحكم، يصبح الـ runbook خاطئًا ولا يعرف أحد ذلك.

يفعل Terraform ما لا تفعله هذه الطرق الثلاث، وبهذا الترتيب : يقرأ الموجود، يقارن بالشيفرة، يعلن ما سيتغيّر، يطبّق فقط ما هو ناقص، يسجّل ما فعله في state، ويعرف تدمير كل شيء بنظافة بـ terraform destroy. ينتهي كل مشروع في الدورة بهذا التدمير : لا يبقى شيء نشطًا، ولا يبقى شيء يُفوتَر.

المشكلة قبل Terraform

تخيّل أن شركة عليها إطلاق تطبيق ويب. قد يلزم إنشاء :

شبكة خاصة ؛
شبكات فرعية وقواعد جدار ناري ؛
خوادم أو عنقود Kubernetes ؛
قاعدة بيانات ؛
موزّع حمل ؛
اسم نطاق وشهادات ؛
حسابات تقنية وأذونات ؛
تخزين ونسخ احتياطية ومراقبة.

يمكنك إنشاء كل شيء يدويًا في وحدة تحكم AWS أو Azure أو Google Cloud. يعمل ذلك في تجربة أولى. ويصبح هشًا بمجرد أن تكبر البيئة.

الصعوبات الست للطريقة اليدوية

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

أعد قراءة جدول الأمثلة الواقعية : تصف Decathlon تكلفة الطريقة اليدوية (أكثر من أسبوع، وعدة فرق، وقاعدة CMDB لملئها من أجل خادم واحد)، وتجيب GitHub على الصعوبة 1 (مضيفون مبنيون « بالطريقة نفسها » في كل مكان)، وSlack على الصعوبة 5 (الكشف يُعاد قراءته في pull request قبل أي دمج).

البنية التحتية كشيفرة (Infrastructure as Code)

تتمثّل البنية التحتية كشيفرة، اختصارًا IaC، في وصف البنية التحتية في ملفات تُعامَل كشيفرة. تعرّف HashiCorp Terraform بأنه أداة IaC تتيح تعريف الموارد السحابية والمحلية في ملفات تكوين مقروءة، يمكنك إدارة إصداراتها وإعادة استخدامها ومشاركتها. المرجع الرسمي — مقدمة إلى Terraform

بدلًا من كتابة إجراء طويل مثل « انقر هنا، اختر هذه المنطقة، ثم أنشئ هذه الشبكة »، تصف الحالة المرغوبة :

hcl

resource "aws_s3_bucket" "documents" {
  bucket = "entreprise-documents-exemple"
}

لا تصف هذه الكتلة كل استدعاء API. إنها تقول : « يجب أن يوجد هذا الـ bucket بهذا التكوين ». هذا هو مخطط المهندس. ثم يحدّد Terraform الأعمال الضرورية.

ما يقدّمه Terraform

1. القابلية للتكرار

تُستخدم الشيفرة نفسها لإنشاء بيئة تطوير أو اختبار أو إنتاج. تُوضع القيم المتغيرة في متغيرات بدلًا من نسخها يدويًا.

2. الرؤية قبل التغيير

يعرض terraform plan الإنشاءات والتعديلات والتدميرات المتوقعة : إنه كشف الأعمال. يراجع الفريق النية قبل أن يمسّ Terraform البنية التحتية. الرموز محدّدة في الوثائق الرسمية. المرجع الرسمي — terraform plan

text

+   création
~   modification sur place
-/+ remplacement (détruire, puis recréer)
-   destruction

(+ إنشاء · ~ تعديل في المكان · -/+ استبدال (تدمير ثم إعادة إنشاء) · - تدمير.)

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

3. تاريخ في Git

تعيش ملفات .tf في Git. يرتبط كل تغيير بفرع، وطلب دمج، ومراجعة، ومؤلف. هذا ما تفعله Slack : يُنشر الكشف في pull request، ولا أحد يدمج دون قراءته.

4. التوحيد

تغلّف المؤسسة قواعدها في وحدات قابلة لإعادة الاستخدام : تشفير إلزامي، ووسوم تكاليف، وسجلات مفعّلة، وشبكة معتمدة، وإصدارات متحكَّم فيها. تتيح الوحدات إعادة استخدام مجموعات قابلة للتكوين من الموارد. المرجع الرسمي — وحدات Terraform

5. أتمتة دورة الحياة

لا يُستخدم Terraform للإنشاء فقط. إنه يقارن التكوين وstate والبنية التحتية الحقيقية ليحدّد ما يضيف أو يعدّل أو يحذف. إنها حركة المهندس : إعادة قراءة المخطط، وفتح السجل، والذهاب لرؤية المبنى.

لماذا تدفع شركة من أجل الأتمتة

يتطلب Terraform استثمارًا أوليًا : تعلّم HCL، وكتابة الوحدات، وتأمين state، وبناء سلسلة موافقات. يصبح هذا الاستثمار مربحًا بمجرد أن يحتاج الفريق إلى تكرار البنية التحتية أو تدقيقها أو تطويرها.

مثال : تملك شركة 30 تطبيقًا وأربع بيئات لكل تطبيق. يدويًا، هذا 120 بيئة للحفاظ عليها. تتيح الوحدات المشتركة وصف النموذج مرة واحدة وتقديم القيم الخاصة بكل تطبيق.

Terraform لا يحلّ مكان الحكم البشري

يؤتمت Terraform نية. إذا طلبت الشيفرة معمارية سيئة، فإن Terraform يعيد إنتاج هذه المعمارية السيئة بكفاءة عالية، وفي كل مكان. يجب دائمًا :

فهم الخطة ؛
تقييد الأذونات ؛
حماية الأسرار وstate ؛
اختبار التغييرات ؛
التخطيط للتراجع والاستعادة ؛
مراقبة التكاليف والتوافر.

لا يبني المهندس ما يريد. إنه يبني ما هو مرسوم. إذا كان الرسم سيئًا، فسيكون المبنى سيئًا أيضًا.

الدورة في صورة واحدة : المخطط، السجل، المبنى

اقرأ المخطط من اليسار إلى اليمين. يدخل المخطط والسجل عند المهندس. يذهب ليرى المبنى. يُنتج كشفًا. توقّعه أنت. ينفّذ الحرفيون، ويحدّث المهندس سجله. في الدورة التالية، إذا لم يتحرّك شيء، يكون الكشف فارغًا : No changes.

الخلاصة

Terraform هو المهندس الذي يقارن المخطط (شيفرتك) والسجل (state) والمبنى (السحابة)، ثم لا يطلب سوى الأعمال الناقصة.
الشيفرة تصريحية : تصف النتيجة، لا الخطوات ؛ وعند إعادة التشغيل دون تغيير، لا يمسّ Terraform شيئًا، وهذا هو التكافؤ الذاتي.
State هو ذاكرة Terraform : بدونه لا يتعرّف على ما بناه ؛ وهو حسّاس ويجب حمايته.
وحدة التحكم تستكشف، والسكربت ينشئ، والـ runbook يروي ؛ وحده Terraform يقرأ الموجود، ويكشف الانحراف، ويعلن التغيير قبل تنفيذه، ويعرف تدمير كل شيء.
يؤتمت Terraform نية ولا يحكم عليها : تُقرأ الخطة سطرًا سطرًا، حتى عندما يبدو تغيير الشيفرة صغيرًا.

أسئلة الفهم

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