دليل عملي لـ Terraform: إتقان البنية التحتية كتعليمات برمجية، وتحسين الكفاءة وخفض التكاليف

# دليل عملي لـ Terraform: إتقان البنية التحتية كتعليمات برمجية، وتحسين الكفاءة وخفض التكاليف Terraform هي أداة شائعة للبنية التحتية كتعليمات برمجية (IaC)، وهي تتيح لك إدارة وأتمتة البنية التحتية السحابية باستخدام ملفات تكوين تعريفية. من خلال التعامل مع البنية التحتية كتعليمات برمجية، يمكن أن تساعدك Terraform على تحسين الكفاءة وتقليل الأخطاء والتحكم بشكل أفضل في بيئتك السحابية. ستجمع هذه المقالة بين المناقشات على X/Twitter لتقديم دليل عملي لـ Terraform، يغطي أفضل الممارسات والنصائح وتوصيات الأدوات، لمساعدتك على استخدام Terraform بشكل أكثر فعالية في الممارسة العملية. ## قيمة ومزايا Terraform * **البنية التحتية كتعليمات برمجية (IaC):** تعريف تكوين البنية التحتية كتعليمات برمجية، وتحقيق التحكم في الإصدار والنشر الآلي والتكرار. * **دعم عبر الأنظمة الأساسية:** يدعم مختلف موفري الخدمات السحابية (AWS وAzure وGCP وما إلى ذلك) بالإضافة إلى البيئات المحلية. * **تكوين تعريفي:** يصف الحالة المطلوبة، وسيقوم Terraform تلقائيًا بتنفيذ الخطوات الضرورية لتحقيق هذه الحالة. * **إدارة الحالة:** يتتبع Terraform حالة البنية التحتية الخاصة بك ويجري التغييرات اللازمة للحفاظ على اتساق التكوين. * **النمطية:** تقسيم البنية التحتية إلى وحدات قابلة لإعادة الاستخدام، مما يبسط التكوين والصيانة. ## FinOps و Terraform: خفض التكاليف السحابية تؤكد تغريدة @@AskYoshik على أهمية مهندسي FinOps، وحقيقة أن رواتبهم أعلى من رواتب مهندسي DevOps، والسبب في ذلك هو أن تحسين التكلفة أصبح أولوية قصوى. فيما يلي بعض النقاط الأساسية حول كيفية استخدام Terraform في FinOps: * **Rightsizing (تعديل حجم الموارد بشكل معقول):** استخدم Terraform لأتمتة تعديل حجم مثيلات AWS EC2 ومجموعات Kubernetes والموارد السحابية الأخرى، مما يضمن أقصى قدر من استخدام الموارد وتجنب الهدر. على سبيل المثال، يمكنك كتابة تكوين Terraform لضبط عدد مثيلات EC2 أو عدد نسخ Kubernetes Pod تلقائيًا بناءً على استخدام وحدة المعالجة المركزية. * **إيقاف تشغيل الموارد تلقائيًا:** بالنسبة للبيئات غير الإنتاجية، مثل بيئات التطوير والاختبار، يمكن إيقاف تشغيل الموارد تلقائيًا خارج ساعات العمل لتوفير التكاليف. يمكن لـ Terraform تحقيق ذلك من خلال CloudWatch Event ووظيفة Lambda. * **استخدام موارد فعالة من حيث التكلفة:** يمكن أن تساعدك Terraform في اختيار أنواع الموارد الأكثر فعالية من حيث التكلفة. على سبيل المثال، يمكنك اختيار Spot Instances لتقليل تكلفة مثيلات EC2، أو اختيار طبقة تخزين أقل تكلفة. * **إدارة العلامات:** استخدم Terraform لإضافة علامات إلى جميع الموارد لتحسين تحليل التكلفة وتتبعها. **نصائح عملية: استخدام Terraform لـ Rightsizing** فيما يلي مثال على استخدام Terraform لضبط عدد مثيلات EC2 تلقائيًا: ```terraform resource "aws_autoscaling_group" "example" { name = "example-asg" max_size = 5 min_size = 1 desired_capacity = 1 health_check_type = "EC2" force_delete = true launch_template { id = aws_launch_template.example.id version = "$Latest" } tag { key = "Name" value = "example-asg" propagate_at_launch = true } ```

هذا مثال على كيفية استخدام Terraform لإعداد مجموعة توسع تلقائي (Auto Scaling Group) مع سياسات توسع تعتمد على CloudWatch Alarms.

المكونات الرئيسية:

• aws_launch_configuration: تحدد مواصفات المثيل (instance) الذي سيتم إطلاقه بواسطة مجموعة التوسع التلقائي.
• aws_autoscaling_group: تحدد مجموعة التوسع التلقائي نفسها، بما في ذلك الحد الأدنى والأقصى لعدد المثيلات، وسياسات التوسع.
• aws_cloudwatch_metric_alarm: تحدد CloudWatch Alarms التي ستشغل سياسات التوسع. في هذا المثال، لدينا alarm لارتفاع استخدام وحدة المعالجة المركزية (CPU) و alarm لانخفاض استخدام وحدة المعالجة المركزية.
• aws_autoscaling_policy: تحدد سياسات التوسع التي سيتم تشغيلها بواسطة CloudWatch Alarms. في هذا المثال، لدينا سياسة للتوسع (scale up) وسياسة للتقليل (scale down).

resource "aws_launch_configuration" "example" {
  name_prefix   = "example-"
  image_id      = "ami-0c55b2464749b54c1" # استبدل بـ AMI مناسب
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "example" {
  name                      = "example-asg"
  launch_configuration    = aws_launch_configuration.example.name
  min_size                = 1
  max_size                = 3
  desired_capacity        = 1
  health_check_type       = "EC2"
  health_check_grace_period = 300

  tag {
    key                 = "Name"
    value               = "example-instance"
    propagate_at_launch = true
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "example-cpu-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 60
  statistic           = "Average"
  threshold           = 70
  alarm_description   = "Alarm when server CPU exceeds 70%" # تنبيه عندما يتجاوز استخدام وحدة المعالجة المركزية للخادم 70%
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.example.name
  }

  alarm_actions = [aws_autoscaling_policy.scale_up.arn]
}

resource "aws_cloudwatch_metric_alarm" "cpu_low" {
  alarm_name          = "example-cpu-low"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 60
  statistic           = "Average"
  threshold           = 30
  alarm_description   = "Alarm when server CPU is below 30%" # تنبيه عندما يكون استخدام وحدة المعالجة المركزية للخادم أقل من 30%
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.example.name
  }

  alarm_actions = [aws_autoscaling_policy.scale_down.arn]
}

resource "aws_autoscaling_policy" "scale_up" {
  name                   = "example-scale-up"
  scaling_adjustment     = 1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.example.name
}

resource "aws_autoscaling_policy" "scale_down" {
  name                   = "example-scale-down"
  scaling_adjustment     = -1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.example.name
}

شرح الكود:

• aws_launch_configuration:
  • name_prefix: بادئة لاسم Launch Configuration.
  • image_id: معرف AMI (Amazon Machine Image) الذي سيتم استخدامه للمثيلات. هام: استبدل هذا بـ AMI مناسب لمنطقتك.
  • instance_type: نوع المثيل (instance type) الذي سيتم استخدامه.
  • lifecycle: يضمن إنشاء Launch Configuration جديد قبل تدمير القديم.
• aws_autoscaling_group:
  • name: اسم مجموعة التوسع التلقائي.
  • launch_configuration: اسم Launch Configuration الذي سيتم استخدامه.
  • min_size: الحد الأدنى لعدد المثيلات في المجموعة.
  • max_size: الحد الأقصى لعدد المثيلات في المجموعة.
  • desired_capacity: العدد المطلوب من المثيلات في المجموعة.
  • health_check_type: نوع فحص الصحة (health check) الذي سيتم استخدامه.
  • health_check_grace_period: الفترة الزمنية التي يجب أن يكون فيها المثيل بصحة جيدة قبل أن يتم اعتباره صحيًا.
  • tag: علامة (tag) سيتم تطبيقها على جميع المثيلات التي تم إطلاقها بواسطة المجموعة.
  • lifecycle: يضمن إنشاء Auto Scaling Group جديد قبل تدمير القديم.
• aws_cloudwatch_metric_alarm (cpu_high):
  • alarm_name: اسم الـ alarm.
  • comparison_operator: عامل المقارنة (comparison operator) الذي سيتم استخدامه.
  • evaluation_periods: عدد الفترات الزمنية التي يجب أن يكون فيها المقياس (metric) فوق الحد (threshold) قبل تشغيل الـ alarm.
  • metric_name: اسم المقياس (metric) الذي سيتم مراقبته.
  • namespace: مساحة الاسم (namespace) للمقياس (metric).
  • period: الفترة الزمنية (بالثواني) التي سيتم خلالها جمع البيانات للمقياس (metric).
  • statistic: الإحصائية (statistic) التي سيتم حسابها للمقياس (metric).
  • threshold: الحد (threshold) الذي سيتم مقارنة المقياس (metric) به.
  • alarm_description: وصف للـ alarm.
  • dimensions: الأبعاد (dimensions) التي سيتم استخدامها لتصفية المقياس (metric).
  • alarm_actions: قائمة بـ ARNs لسياسات التوسع (scaling policies) التي سيتم تشغيلها بواسطة الـ alarm.
• aws_cloudwatch_metric_alarm (cpu_low):
  • مشابه لـ cpu_high، ولكن مع حد (threshold) أقل ووصف مختلف.
• aws_autoscaling_policy (scale_up):
  • name: اسم سياسة التوسع (scaling policy).
  • scaling_adjustment: مقدار التعديل في السعة (capacity).
  • adjustment_type: نوع التعديل (adjustment type).
  • cooldown: الفترة الزمنية (بالثواني) التي يجب أن تنتظرها مجموعة التوسع التلقائي (Auto Scaling Group) بعد تنفيذ سياسة التوسع (scaling policy) قبل تنفيذ سياسة أخرى.
  • autoscaling_group_name: اسم مجموعة التوسع التلقائي (Auto Scaling Group) التي سيتم تطبيق السياسة عليها.
• aws_autoscaling_policy (scale_down):
  • مشابه لـ scale_up، ولكن مع تعديل سلبي في السعة (capacity).

ملاحظات:

• تأكد من استبدال ami-0c55b2464749b54c1 بـ AMI مناسب لمنطقتك.
• يمكنك تعديل قيم min_size و max_size و desired_capacity لتلبية احتياجاتك.
• يمكنك تعديل قيم threshold في CloudWatch Alarms لتلبية احتياجاتك.
• تأكد من أن لديك الأذونات اللازمة لإنشاء هذه الموارد في AWS.

يستخدم هذا المثال `aws_autoscaling_group` لإنشاء مجموعة توسع تلقائي، ويستخدم `aws_cloudwatch_metric_alarm` لمراقبة استخدام وحدة المعالجة المركزية (CPU). عندما يتجاوز استخدام وحدة المعالجة المركزية 70٪، ستزيد سياسة `scale_up` مثيل EC2 واحد، وعندما يقل استخدام وحدة المعالجة المركزية عن 30٪، ستقلل سياسة `scale_down` مثيل EC2 واحد. ## أفضل ممارسات Terraform ذكرت تغريدة @@devops_nk بنية دليل Terraform وكيف تدير الفرق الفعلية البنية التحتية السحابية. فيما يلي بعض أفضل الممارسات: * **هيكل الدليل:** استخدم هيكل دليل واضحًا لعزل تكوينات البيئات المختلفة (dev، staging، prod)، ومنع التأثيرات غير المقصودة على بيئة الإنتاج. ``` environments/ ├── dev/ │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── terraform.tfvars ├── staging/ │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── terraform.tfvars └── prod/ ├── main.tf ├── variables.tf ├── outputs.tf └── terraform.tfvars ``` * **النمذجة:** قسّم البنية التحتية إلى وحدات قابلة لإعادة الاستخدام، مثل وحدة VPC ووحدة EC2 ووحدة قاعدة البيانات وما إلى ذلك. يمكن أن يؤدي ذلك إلى تبسيط التكوين وتحسين إمكانية الصيانة. ```terraform module "vpc" { source = "./modules/vpc" name = "my-vpc" cidr_block = "10.0.0.0/16" } ``` * **استخدام Variables و Outputs:** استخدم `variables.tf` لتعريف المتغيرات، واستخدم `outputs.tf` لإخراج سمات الموارد المهمة، مثل عناوين IP وأسماء DNS. ```terraform # variables.tf variable "instance_type" { type = string default = "t2.micro" } # outputs.tf output "public_ip" { value = aws_instance.example.public_ip } ``` * **إدارة الحالة:** استخدم وظيفة إدارة الحالة عن بُعد في Terraform، مثل Terraform Cloud أو S3 أو Azure Blob Storage، لضمان اتساق الحالة وأمانها. ```terraform terraform { backend "s3" { bucket = "my-terraform-state-bucket" key = "terraform.tfstate" region = "us-east-1" } } ```* **التحكم في الإصدار:** قم بتخزين كود Terraform في مستودع Git، واستخدم استراتيجيات الفروع للتحكم في الإصدار. * **CI/CD:** قم بدمج Terraform في خطوط أنابيب CI/CD لتحقيق النشر والاختبار الآلي. ذكرت العديد من التغريدات GitHub Actions و Jenkins، وهما أداتان شائعتان لـ CI/CD يمكن دمجهما مع Terraform. يعد مشروع @@Abdulraheem183 مثالًا جيدًا يوضح كيفية استخدام GitHub Actions + Docker + Terraform لنشر تطبيق على AWS. * **مراجعة الكود:** قم بإجراء مراجعات للكود لضمان جودة الكود وأمانه. * **استخدام أدوات CLI الخاصة بـ Terraform:** `terraform fmt` لتنسيق الكود، `terraform validate` للتحقق من صحة الكود. ## أدوات Terraform الموصى بها * **Terraform Cloud:** يوفر إدارة الحالة عن بُعد والتعاون ووظائف التشغيل الآلي. * **Terragrunt:** يغلف Terraform، ويوفر دعمًا أفضل لـ DRY (لا تكرر نفسك) وهيكل دليل أسهل للإدارة. * **tfsec:** أداة تحليل الكود الثابت، تُستخدم للكشف عن الثغرات الأمنية في كود Terraform. * **Checkov:** أداة أخرى لتحليل الكود الثابت، تُستخدم للكشف عن الثغرات الأمنية ومشكلات عدم الامتثال في كود Terraform. * **Kiro.dev + MCP (Managed Cloud Platform):** كما ذكر @@RoxsRoss، يمكن لهذه الأدوات إنشاء مخططات معمارية للبنية التحتية تلقائيًا، مما يساعد بشكل كبير في فهم البنية التحتية المعقدة وصيانتها. الروابط: [https://github.com/awslabs/mcp](https://github.com/awslabs/mcp) و [https://kiro.dev](https://kiro.dev) * **hcpt:** ذكر @@nnstt1 أداة CLI قيد التطوير لـ HCP Terraform، والتي تستحق المتابعة. ## قيود وتحديات Terraform * **منحنى التعلم:** لدى Terraform منحنى تعلم معين، خاصة بالنسبة للفرق التي ليس لديها خبرة في IaC. * **إدارة الحالة:** تعد إدارة ملفات حالة Terraform أمرًا بالغ الأهمية، وإذا تضررت ملفات الحالة أو فقدت، فقد يتسبب ذلك في مشاكل خطيرة. * **التعقيد:** بالنسبة للبنية التحتية المعقدة، قد يصبح كود Terraform معقدًا للغاية ويصعب صيانته. ذكر @@Achinedu001_ أنه بعد النشر باستخدام Terraform، أصبحت واجهة المستخدم صداعًا، وتتطلب التنقل بشكل متكرر بين أجزاء مختلفة من وحدة التحكم. وهذا يسلط الضوء على أهمية التصميم المعياري الجيد والهندسة المعمارية الواضحة. * **إدارة التبعيات:** قد تكون إدارة تبعيات وحدات Terraform وموفريها أمرًا صعبًا. ## خاتمةTerraform هي أداة IaC قوية يمكن أن تساعدك على تحسين الكفاءة وخفض التكاليف والتحكم بشكل أفضل في بيئتك السحابية. من خلال اتباع أفضل الممارسات واستخدام الأدوات المناسبة والانتباه إلى قيود Terraform، يمكنك استخدام Terraform بشكل أكثر فعالية والحصول على فوائد كبيرة منه. نأمل أن يساعدك هذا الدليل العملي على إتقان Terraform بشكل أفضل وتطبيقه في مشاريعك الفعلية. # مثال على كود Terraform resource "aws_instance" "example" { ami = "ami-0c55b24647552dd5e" instance_type = "t2.micro" tags = { Name = "ExampleInstance" } }

هذا مثال على فقرة HTML.

هذا مثال على عنصر HTML مضمن. رابط إلى موقع Terraform // مثال على تعليق في كود Terraform variable "region" { type = string description = "The AWS region to deploy to" default = "us-east-1" }