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

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

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

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

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

معاملة البنية التحتية ككود

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

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

إليك ما يبدو عليه تعريف بسيط للبنية التحتية في Terraform:

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServer"
  }
}

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

لماذا تفشل البنية التحتية اليدوية على نطاق واسع

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

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

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

سير عمل Terraform يبدأ من هنا

هنا يبدأ سير عمل Terraform. قبل تشغيل أي أوامر، يكتب الفريق تعريفات البنية التحتية في ملفات التكوين. تصبح هذه الملفات مصدر الحقيقة — ليس لوحة التحكم السحابية، ولا الملاحظات الشخصية، ولا ذاكرة شخص ما.

يتبع سير العمل دورة بسيطة:

1. اكتب — حدد البنية التحتية الخاصة بك في ملفات التكوين. صف الخوادم، الشبكات، قواعد البيانات، والموارد الأخرى التي تحتاجها.

2. خطط — اطلب من Terraform أن يظهر لك ما سيتغير قبل تطبيقه. هذا يمنحك فرصة للمراجعة واكتشاف الأخطاء.

3. طبق — نفذ التغييرات. يقارن Terraform تكوينك بالحالة الحالية للبنية التحتية ويقوم فقط بالتغييرات اللازمة للوصول إلى حالتك المرغوبة.

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

ما الذي تغيره البنية التحتية ككود

عندما تتبنى البنية التحتية ككود، تتغير عدة أشياء في طريقة عمل فريقك:

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

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

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

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

نقطة بداية عملية

إذا كنت جديدًا في البنية التحتية ككود، إليك قائمة مهام بسيطة للبدء:

• اختر قطعة صغيرة واحدة من البنية التحتية التي تديرها حاليًا يدويًا — ربما خادم واحد أو مثيل قاعدة بيانات.
• اكتب تكوينها في Terraform أو أداة IaC التي تختارها.
• قم بتشغيل خطة لترى ما الذي سيغيره Terraform.
• طبق التكوين وتحقق من أن النتيجة تطابق ما تتوقعه.
• أضف ملفات التكوين إلى مستودعك.
• احذف المورد اليدوي وأعد إنشائه باستخدام ملفات التكوين فقط.

هذا التمرين يثبت لك وللفريق أن النهج يعمل. بمجرد أن تفعلها مرة واحدة، ستبدأ في رؤية أجزاء أخرى من البنية التحتية التي يجب إدارتها بنفس الطريقة.

الخلاصة

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