اكتب البنية التحتية ككود قبل أن تضغط على زر آخر

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

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

هناك طريقة أفضل: اكتب البنية التحتية الخاصة بك ككود.

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

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

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

كتابة أول تكوين لك

Terraform هي واحدة من أكثر أدوات IaC استخدامًا. تكتب ملفات تكوين بامتداد .tf. كل ملف يعلن عن الموارد التي تحتاجها وكيفية اتصالها.

ابدأ بملف يسمى main.tf. أول شيء يجب تعريفه هو المزوّد (provider). المزوّد هو إضافة تسمح لـ Terraform بالتحدث مع منصة معينة مثل AWS أو Google Cloud أو Azure. يخبر Terraform أين ينشئ الموارد وما هي بيانات الاعتماد التي يجب استخدامها.

provider "aws" {
  region = "ap-southeast-1"
}

بمجرد تعيين المزوّد، تقوم بتعريف الموارد. كل مورد يتبع هذا النمط: resource "type" "local_name". الاسم المحلي يُستخدم فقط داخل التكوين الخاص بك. ليس هو الاسم الذي يظهر في لوحة تحكم مزود الخدمة السحابية.

إليك كيفية إنشاء خادم افتراضي، والذي تسميه AWS مثيل EC2:

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

  tags = {
    Name = "app-server"
  }
}

وإليك قاعدة بيانات PostgreSQL باستخدام RDS:

resource "aws_db_instance" "app_database" {
  allocated_storage    = 20
  engine               = "postgres"
  engine_version       = "15"
  instance_class       = "db.t3.micro"
  db_name              = "myapp"
  username             = "admin"
  password             = var.db_password
  skip_final_snapshot  = true
}

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

لماذا يبدو هذا أثقل في البداية

كتابة ملفات التكوين تستغرق وقتًا أطول مقدمًا من النقر عبر لوحة التحكم. تحتاج إلى معرفة أنواع الموارد الدقيقة، والوسائط المطلوبة، وكيفية هيكلة الملفات. تعرض لك لوحة التحكم قوائم منسدلة ومربعات اختيار. ملف التكوين يتوقع منك أن تعرف ما يعنيه ami-0c55b159cbfafe1f0 أو ما يشير إليه db.t3.micro.

لكن هذه التكلفة المقدمة تؤتي ثمارها في اللحظة التي تحتاج فيها إلى تكرار الإعداد. هل تريد بيئة اختبار تعكس الإنتاج؟ انسخ الملفات، غيّر بعض القيم، وشغّل نفس التكوين. هل تريد فهم البنية التحتية التي تعمل؟ اقرأ الملفات بدلاً من البحث في لوحة التحكم. هل تريد مراجعة تغيير قبل حدوثه؟ افتح طلب سحب (pull request) ودع فريقك يعلق على الفرق.

تخزين التكوين في نظام التحكم بالإصدارات

يجب أن تكون ملفات .tf الخاصة بك في مستودع Git. يمكن أن يكون هذا نفس مستودع كود التطبيق أو مستودع بنية تحتية منفصل. في كلتا الحالتين، كل تغيير في البنية التحتية يمر عبر نفس سير العمل مثل تغييرات الكود: كتابة، التزام، مراجعة، دمج، تطبيق.

يمنحك هذا عدة فوائد:

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

ما لا تفعله

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

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

سير العمل العملي

سير العمل النموذجي لـ Terraform له ثلاث مراحل: كتابة، تخطيط، تطبيق.

أولاً، تقوم بكتابة أو تعديل ملفات .tf الخاصة بك. هذا هو المكان الذي تحدد فيه البنية التحتية التي تريدها.

ثانيًا، تقوم بتشغيل terraform plan. هذا الأمر يظهر لك ما سيفعله Terraform دون فعله فعليًا. يطبع فرقًا مفصلاً: أي الموارد سيتم إنشاؤها، وأيها سيتم تعديلها، وأيها سيتم تدميرها. تراجع هذه الخطة قبل المتابعة.

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

قائمة مراجعة سريعة لإعداد IaC الأول

• اختر مزود خدمة سحابية وقم بتثبيت واجهة سطر الأوامر لـ Terraform.
• أنشئ ملف main.tf مع كتلة المزوّد الخاصة بك.
• حدد موردًا واحدًا على الأقل، مثل جهاز افتراضي أو قاعدة بيانات.
• شغّل terraform init لتنزيل إضافة المزوّد.
• شغّل terraform plan لترى ما سيتم إنشاؤه.
• شغّل terraform apply لإنشاء الموارد.
• خزّن جميع ملفات .tf في مستودع Git وادفعها.

القيمة الحقيقية تظهر لاحقًا

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

ابدأ بمورد واحد. اكتبه في ملف. ضعه في Git. ثم أضف المورد التالي. العادة تبني أسرع مما تتوقع، والثقة التي تمنحك إياها تستحق الاحتكاك الأولي.