Terraform / الموديولات والدورة الواعية بالحالة / الدرس 7
المجموعات وعناوين النسخ المستقرة
اختر مفاتيح التكرار من هوية ثابتة وافهم فرق count و for_each.
في هذه الصفحة
أهداف الدرس
- قارن فهارس count بهويات خريطة أو مجموعة for_each.
- ميز شرط معرفة المفاتيح وراجع الإزالة كتغيير دورة.
التكرار قرار هوية
ينشئ count نسخاً مفهرسة مثل resource.name[0]، وينشئ for_each نسخاً بمفتاح خريطة أو عضو مجموعة. تصبح هذه العناوين ملكية حالة، لا مجرد عدادات حلقة. وقد لا تلائم قائمة العرض الهوية إذا غير الإدراج معنى الفهارس. توضح المفاتيح المستقرة القصد ويجب أن تكون فريدة ودائمة. لا تختَر معرّفات متولدة أو أوقاتاً أو أسراراً دون فهم توقيت معرفتها وكشفها.
أعلن عقد خدمات بمفاتيح
يعلن الجذر التالي مدخلَي كتالوج بأسماء وعدد نسخ صريحين. يستخدم for_each المفتاحين api و worker وتقدم each.value الكائن الموافق. يبقى المورد بيانات تعليمية مدمجة لا أداة خوادم. يجب معرفة المفاتيح عند تحديد النسخ، فلا يلائم معرّف متولد لاحق هذه المرحلة. ينشر المخرج رؤية هوية مقصودة لا نتيجة نشر تطبيق.
terraform {
required_version = ">= 1.16.0, < 1.17.0"
}
variable "services" {
type = map(object({ replicas = number }))
default = {
api = { replicas = 2 }
worker = { replicas = 1 }
}
}
resource "terraform_data" "service" {
for_each = var.services
input = { name = each.key, replicas = each.value.replicas }
}
output "instance_keys" {
value = sort(keys(terraform_data.service))
}
تتضمن العناوين المفتاحين api و worker المعروفين من المدخل لا المعرّفات. يفرز المخرج العرض ولا يفرض ترتيب التنفيذ. لا تُطبق نسخ.
قد تغير الفهارس معنى الارتباط القائم
عندما يشتق count من قائمة متغيرة، يزيح إدخال عنصر أولاً معنى العناصر المرتبطة بالفهارس السابقة. قد تقود المعاملات الناتجة إلى تحديث أو استبدال وفق المخطط؛ فلا يعني إعادة الترتيب حذفاً دائماً، لكنها تستحق الفحص. يوضح المثال تغير الهوية فقط دون خطة أو مخطط أو قراءة حالة. ولا يضمن تشابه مجموعة العناصر أن العملية آمنة.
before = ['api', 'worker']
after = ['metrics', 'api', 'worker']
print(f'count_index_0: {before[0]} -> {after[0]}')
print('stable_keys=' + ','.join(sorted(set(before) & set(after))))
count_index_0: api -> metrics
stable_keys=api,worker
يتغير معنى 0 من api إلى metrics ويبقى المفتاحان. هو فحص نصوص ثابت، ولا يقرر الاستبدال أو يضمن تغيير المفتاح دون ترحيل واع بالحالة.
تهم هوية معلومة وغير حساسة
يجب تحديد هويات for_each قبل الأفعال المعنية، ولا تصلح لها قيم حساسة تنكشف في العناوين. تزيل مجموعة النصوص التكرار ولا تحمل ترتيب مستخدم؛ فتحويل القائمة إليها يغير العقد. أكد أن التفرد وفقد الترتيب مقصودان. افصل المفتاح العلني عن الحمولة الحساسة المدعومة. وإذا لم تحدد المدخلات هوية مستقرة، فأعد الواجهة بدلاً من تخمين نتيجة مستقبلية.
المفتاح المفقود انتقال ملكية مقترح
قد تؤدي إزالة مفتاح إلى إزالة نسخة معلنة واقتراح تدمير وفق الدورة العادية. وتعد إعادة تسميته تغيير عنوان لا تعديل عرض تلقائياً. راجع moved أو ترحيلاً مدعوماً عند وجوب استمرار الهوية. افحص المخرجات والأبناء والسياسة والبيانات قبل اعتماد خريطة جديدة. يفيد فرق المدخل الواضح ولا يعوض مراجعة أفعال الخطة وسياق الملكية لأي تغيير مصرح.
الأخطاء الشائعة وإصلاحها
Invalid for_each argument.
- لماذا يحدث؟
- المفاتيح مجهولة حتى العملية أو بنية غير مدعومة.
- كيف تصلحه؟
- قدم مفاتيح معلومة واجعل المتولد في القيم.
- كيف تتجنب تكراره؟
- راجع الهوية مستقلة عن حساب الحمولة.
يغير ترتيب القائمة معاملات موجودة.
- لماذا يحدث؟
- رُبطت الهوية بترتيب عرض متغير.
- كيف تصلحه؟
- استخدم مفاتيح ثابتة أو ترحيلاً يحفظ العنوان.
- كيف تتجنب تكراره؟
- اختبر الإدراج والإزالة والترتيب قبل الإدارة.
انكشف سر عبر مفتاح نسخة.
- لماذا يحدث؟
- استُخدمت الحمولة الحساسة هوية علنية.
- كيف تصلحه؟
- افصل المفتاح واحم القيمة وعالج الكشف.
- كيف تتجنب تكراره؟
- أبعد الأسرار عن العناوين والتشخيص.
اختبر فهمك
1. هل تتطلب إضافة metrics مفتاحاً جديداً لـ api؟
اعرض الحل المشروح
لا؛ يبقى api مع إضافة مستقل. يوضح ذلك الهوية، وتظل الأفعال متوقفة على القيم والدورة والمزود والحالة؛ فالثبات ليس ضمان غياب التغيير.
2. لماذا تحتاج إعادة worker إلى jobs ترحيلاً صريحاً؟
اعرض الحل المشروح
المفتاح جزء من عنوان الحالة. قد يفسر غياب الانتقال القديم كمزال والجديد كنسخة جديدة. تعبر moved عن الاستمرار حين يلائم الترحيل والمعنى القصد.
أهم ما تعلمته
- توضح المفاتيح الثابتة الهوية وتختلف عقود القوائم والمجموعات.
- راجع المفاتيح كتغييرات دورة واعية بالحالة.