من وحدات Terraform متفرقة إلى Stack EKS متماسك في الإمارات

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

تتناول هذه المقالة مسار التجميع الكامل من وحدة الشبكة إلى مخرجات SSM، مع تسع خطوات مرتبة يبني فيها كل خطوة على مخرجات سابقتها. سنراجع طبقة الشبكة وأدوار IAM، وما يجب أن يتولاه eks terraform module وما يجب ألا يتولاه، ووحدات VPC CNI وCoreDNS وkube-proxy وEBS CSI وPod Identity agent. ثم نكشف اللحامات الثلاثة التي تسرّب الانحراف إلى الإنتاج، ونشرح كيف يُثبَّت الإصدار ويتحقق التوافق، ولماذا لا يكفي امتلاك وحدات متفرقة دون واجهات متسقة وعقد SSM واضح بين الـ stacks.

الخلفية: من يملك ماذا في عنقود aws eks

في Amazon EKS، تقسيم المسؤولية واضح ومحدد: AWS تتولى إدارة الـ control plane ضمن نموذج الخدمة المُدارة، بينما يبقى قرار متى تُنفَّذ الترقيات وتُثبَّت الإصدارات على عاتق فريقك، وهو ما يصفه المقال المرجعي المنشور في مايو 2026. هذا التقسيم يجعل تثبيت الإصدارات شرطاً تشغيلياً لا تفضيلاً هندسياً: أنت من يحدد لحظة تحرك العنقود ولحظة تحرك الإضافات.

معظم الفرق الإماراتية تملك بالفعل eks terraform module لعنقود، ووحدة شبكة، ووحدة إضافات، ومع ذلك لا يوجد تعريف مكتوب لما تنتظره كل وحدة من غيرها. الفجوة ليست في التغطية الوظيفية، إذ يمكن لأي فريق أن يجد وحدات AWS جاهزة تغطي العنقود والشبكة والإضافات، بل في التركيب: من يمرر ماذا، بأي اسم، وبأي نوع، وبأي إصدار، وهل يمكن اختبار ذلك قبل الإنتاج.

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

لماذا تنكسر بيئة EKS الإنتاجية عند لحامات الوحدات

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

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

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

مسار التجميع: تسع خطوات من وحدة الشبكة إلى مخرجات SSM

إن وعي أن الانحراف يسكن في اللحامات يفرض سؤالاً عملياً: ما الترتيب الذي يجعل هذه اللحامات مرئية وقابلة للاختبار؟ يبني المقال المرجعي (مايو 2026) المسار في تسع خطوات متتابعة، كل واحدة تستهلك مخرجات سابقتها صراحةً:

1. الشبكة. وحدة VPC تنتج معرّفات الشبكات الفرعية والبوابات، ومخرجاتها تغذي كل ما يأتي بعدها بلا استثناء.

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

3. أدوار IAM، ثم 4. مجموعة سجلات CloudWatch. كلاهما يُمرَّر إلى وحدة العنقود كمدخلات صريحة، لا كموارد تنشئها الوحدة خلف الكواليس.

5. العنقود. يستهلك eks terraform module الشبكة والأدوار ومجموعة السجلات، ويُخرج نقطة النهاية وبيانات الشهادة التي تعتمد عليها الطبقات الأعلى.

6. العُقد العاملة. شبكات فرعية خاصة خلف NAT، تُستهلك فيها وسوم الشبكة ومخرجات العنقود معاً.

7. الإضافات. VPC CNI وCoreDNS وkube-proxy وEBS CSI driver وPod Identity agent، وتُطبَّق بعد العُقد لأنها تعتمد على هوية تلك العُقد.

8. مستودع ECR. خطوة صغيرة ظاهرياً، لكن اسمه وسياسة دورة حياته يغذيان خطوط بناء الصور لاحقاً.

9. مخرجات SSM. تُجمَّع مخرجات المسار في معامل SSM مشفّر يستهلكه ما بعده من الـ stacks.

القاعدة العملية: ترتيب الوحدات داخل terraform aws modules eks aws عقد تسلسلي، وليس تنظيماً لملفات فقط. أي إعادة ترتيب هي تغيير معماري يستوجب إعادة اختبار اللحامات كلها. ولمعرفة كيف تتوزع هذه الطبقات في بيئة إنتاج كاملة، راجع بنية Terraform AWS Stack الإنتاجية: الطبقات والتكامل.

من الشبكة إلى أدوار IAM: الطبقة التي تحمل الوسوم والمفاتيح

بعد استعراض التسلسل، تبدأ المخاطر الفعلية من مخرجات وحدة الشبكة. لا يكفي تسليم vpc_id؛ الطبقات الأعلى تكتشف الشبكات الفرعية عبر الوسوم، لذا يجب أن تُخرج الوحدة معرّفات الشبكات الفرعية مع وسومها ككائن واحد، لأن الاعتماد على التسميات، مثل اسم "private-a"، هش أمام أي إعادة تسمية.

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

أدوار IAM تُصمَّم كواجهة صريحة بين طبقتين: دور العنقود، ودور العُقد، وأدوار الإضافات منفصلة. خلطها يمر في terraform plan ثم يفشل وقت التشغيل كخطأ صلاحيات، غالباً بعد النشر.

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

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

العنقود والعُقد: ما يجب أن يفعله eks terraform module وما يجب ألا يفعله

بعد أن أصبحت الشبكة والأدوار ومجموعة السجلات مدخلات واضحة، يأتي دور eks terraform module كطبقة تجميع لا كمالك للبنية. يجب أن تكون وحدة العنقود رقيقة: تستهلك هذه الواجهات كمدخلات صريحة، ولا تُعيد تعريف موارد الشبكة أو أدوار IAM داخلها، وإلا تكرمت المصادر وظهر الانحراف عند أول تعديل.

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

• مفتاح KMS المُدار من العميل لأسرار EKS يجب أن يكون مدخلاً معرّفاً في الوحدة، لا قيمة مضمّنة داخلها، وإلا فقدت القدرة على تدوير المفاتيح أو ربط العنقود بمفتاح جديد دون إعادة إنشاء.

• أي إعداد افتراضي غير معرّف صراحة في وحدة العنقود سيظهر مفعوله عند ترقية الوحدة، وسيظهر غالباً على الإنتاج لا على بيئة الاختبار.

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

وحدات الإضافات: VPC CNI وCoreDNS وkube-proxy وEBS CSI وPod Identity agent

بعد أن ثبّتت افتراضات وحدة العنقود والعُقد، تنتقل نقطة الخطر إلى طبقة الإضافات، وهي من أكثر النقاط التي تصدر فيها تغييرات جذرية. دورة إصدار VPC CNI وCoreDNS وkube-proxy وEBS CSI وPod Identity agent مستقلة عن دورة إصدار وحدة العنقود، لذلك قد تتغير إحداها دون الأخرى ويظهر عدم التوافق بعد الترقية لا قبلها.

اختيار إدارة الإضافات كوحدات منفصلة أم كمكونات داخل terraform eks module ليس تفصيلاً تنظيمياً: الأول يضع عقد الواجهة في مستودع مستقل ويمنحك تحكماً أدق، والثاني يخفي العقد داخل الوحدة وينقل ملكيته إلى مؤلفها. في الحالتين، اجعل التحقق من توافق إصدار العنقود مع إصدارات الإضافات خطوة صريحة في خط الأنابيب، لا مراجعة بشرية متأخرة.

Pod Identity agent يستحق معاملة خاصة: يُفترض أنه يعمل كعامل يربط هويات الـ pods بطبقة العنقود، وأي تغيير في طريقة تسجيله أو في دوره يعني تعديل عقد بين طبقة العنقود وطبقة التطبيقات. وثّق هذا العقد واختبره كما تختبر مخرجات الشبكة.

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

ECR ومخرجات SSM: تسليم الواجهة إلى الـ stacks التالية

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

الخطوة الأخيرة في مسار التجميع كما يصفه المقال المرجعي هي تجميع المخرجات، من معرّف العنقود ونقطة النهاية إلى اسم مستودع ECR وأدوار IAM ومفاتيح KMS، في معامل SSM مشفّر بمفتاح KMS مُدار من العميل. هذه الحزمة هي العقد البيني الحقيقي: نظام أسماء وأنواع وقيم في مكان واحد، بدل تمرير مخرجات يدوياً بين المستودعات أو نسخها في ملفات tfvars.

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

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

اللحامات الثلاثة التي تسرّب الانحراف إلى الإنتاج

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

اللحام الأول: الوسوم والشبكات الفرعية. تُسلَّم بنية تحتية سليمة ظاهرياً مع خطة نظيفة، بينما لا يتحقق أحد من المتطلبات الموثقة للأدوار الأعلى. توثّق AWS أن اكتشاف موازن الأحمال يعتمد على وسوم محددة في الشبكات الفرعية، مثل kubernetes.io/role/elb للشبكات العامة وkubernetes.io/role/internal-elb للخاصة (توثيق AWS)، وهو العطل الذي وصفناه سابقاً بأنه يظهر لاحقاً كـ Ingress عالق بلا سبب واضح.

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

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

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

وسم الشبكات الفرعية: العطل الذي لا يظهر في خطة العنقود

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

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

حزمة SSM: عقد بيني بين الـ stacks

بعد أن ضمنت أن وسوم الشبكات الفرعية تصل سليمة، ينتقل السؤال إلى بقية الواجهة: كيف يعرف الـ stack التالي ما أنتجته طبقة البنية التحتية؟ هنا تأتي حزمة مخرجات SSM، وهي الفارق العملي بين مجلد وحدات وStack له عقد معلن. الحزمة تنقل التوصيل من كود صريح إلى معامل يقرأه المستهلك وقت التشغيل، وهذا ثمنها الحقيقي: التغيير يصبح غير مرئي في خطة المستهلك.

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

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

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

تثبيت الإصدارات: كيف تُثبَّت وكيف يُتحقق من التوافق

بعد ضبط عقد الحزمة وأسماء مفاتيحها، يبقى سؤال يحمي هذا العقد من التغيير الصامت: كيف تُثبَّت الإصدارات، ومن يتحقق من توافقها؟

الممارسة الشائعة هي استبدال النطاق المفتوح (مثل >= 5.0) برقم صريح، مع مسار رفع واحد: طلب تغيير يوثّق سبب الرفع وما تغيّر في الواجهات، ويُسجَّل في سجل التغييرات. ولهذا يجب أن يثبّت الفريق النطاق، لأن تركه مفتوحاً يجعل terraform init قد يختار إصداراً مختلفاً لكل مهندس.

لكن تثبيت الوحدة لا يكفي. إذا ظلت إصدارات الإضافات (VPC CNI، CoreDNS، kube-proxy، EBS CSI، Pod Identity agent) أو إصدار Kubernetes متحركة داخل الوحدة أو تُحدَّث تلقائياً، فأنت تثبت الغلاف وتترك المحتوى يتحرك. افحص كل متغير يقبل نطاقاً، وكل إعداد تلقائي للترقية.

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

يجب أن يُثبَّت المزوّد وتجزئات التحقق عبر ملف .terraform.lock.hcl بحيث يصبح البناء قابلاً لإعادة الإنتاج. لكن ملف القفل لا يثبت إصدارات الوحدات نفسها، لذا ثبّتها في الكود وفي ملف القفل معاً، وراجع ما يظهر في صفحة الوحدة قبل قبول أي إصدار.

في سياق terraform eks module، القيمة الحقيقية للتثبيت هي إثبات أن ما عمل أمس في بيئتك سيعمل اليوم.

خط أساس أمني وحالة وهوية في أي Stack EKS

بعد أن ثبّت الإصدارات وأثبتت التوافق، يبقى سؤال الخط الأساس: هل الـ Stack نفسه يُدار بحدود أمنية وهوية قابلة للتدقيق؟ في أي aws eks stack إنتاجي، يجب أن تضع العُقد في شبكات فرعية خاصة خلف NAT، بلا عناوين عامة وبلا مسار مباشر إلى الإنترنت. وأضف VPC endpoints لتوجيه حركة واجهات AWS بعيداً عن الإنترنت العام، ووثّق كل نقطة نهاية تعتمد عليها وحدات eks terraform module لديك، لأن غيابها يظهر كعطل صامت لا كخطأ خطة. استخدم مفاتيح KMS مُدارة من العميل لأسرار EKS وسجلات CloudWatch وECR ومعامل SSM، ومررها كمدخلات صريحة إلى الوحدات لا كقيم مضمنة، حتى يبقى التدوير ممكناً. وعلى مستوى الهوية، استخدم GitHub OIDC لتجنّب بيانات اعتماد طويلة الأمد، واحتفظ بحالة Terraform بعيدة على S3 كأساس تشغيلي لا تحسين. وأخيراً، أضف الفحص الساكن مثل Checkov وتقدير التكلفة على طلبات السحب مثل Infracost كطبقة تحقق مكمّلة، لا بديلاً عن اختبار عقد الواجهة بين وحداتك.

قائمة تحقق محايدة قبل قبول أي Stack لا مجرد وحدات

بعد تثبيت خط الأساس الأمني والحالة البعيدة، يبقى سؤال القبول: هل ما أمامك Stack متماسك أم مجلد وحدات؟ استخدم هذه القائمة قبل الشراء أو التبني.

• واجهات متسقة: أسماء المدخلات والمخرجات موحدة وموثقة، ولكل مخرج مستهلك معروف في المخطط. المخرج بلا مستهلك دين تقني أو حقل ميت.

• إصدارات مثبتة: كل وحدة وإضافة لها رقم صريح، وسياسة رفع مكتوبة، وسجل تغييرات يوضح ما تحرك بين إصدارين.

• تركيبات مُتحقَّق منها: جدول يربط إصدار العنقود بإصدارات VPC CNI وCoreDNS وkube-proxy وEBS CSI وPod Identity agent، لا عبارة عامة بأنها تعمل معاً.

• عقود قابلة للاختبار: اختبار في خط الأنابيب يتحقق من وسوم الشبكات الفرعية المطلوبة، ومن وجود مفاتيح حزمة SSM وأنواعها قبل الاستهلاك.

• قابلية إعادة الإنتاج: ملف قفل، وحالة بعيدة، وبصمة لحزمة المخرجات، تسمح لمهندس آخر ببناء نفس البيئة دون تخمين.

لأي Stack تشتريه أو تبنيه، اطلب هذه العناصر نفسها. وتقدّم IaC Bazaar كتالوجاً من وحدات Terraform وOpenTofu وAnsible تصفها بأنها متحقَّق منها أمنياً وموقّعة بـ cosign، مع stacks منسّقة لـ AWS وEKS وGKE، وتنزيل لكل وحدة بدءاً من 29 دولاراً ودون اشتراك. هذه ادعاءات الشركة عن منتجاتها، ويبقى تقييمها خاضعاً للمعايير أعلاه.

الخطوات التالية: ما تفعله هذا الأسبوع

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

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

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

إذا أردت تقصير الطريق، تقدم IaC Bazaar وحدات Terraform وOpenTofu وAnsible تصفها بأنها مفحوصة وموقّعة بـ cosign، مع stacks منسّقة لـ EKS. لكن هذه ادعاءات الشركة، ومعاييرك وحدها هي التي تحمي بيئتك.

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

Conclusion

الخلاصة أن قوة Stack EKS لا تأتي من عدد الوحدات بل من وضوح العقود بينها، وهي العقود التي وثّقناها في الخطوات أعلاه. لا تقبل Stack بلا مصفوفة توافق مختبرة، وإثبات فحص وتوقيع، وخط أساس أمني وحالة وهوية واضحة. الخطوة التالية هذا الأسبوع: أنشئ جدول عقود وحداتك الحالي وأضف الاختبارين إلى خط الأنابيب قبل أي شراء. وإذا أردت تقصير الطريق، تقدم IaC Bazaar وحدات Terraform وOpenTofu وAnsible توصف بأنها مفحوصة وموقّعة بـ cosign مع stacks منسقة لـ EKS، لكن قيّمها بمعاييرك. الهدف أن تبني Stack تعرف عقوده وتختبرها وتثبت إصداراتها بثقة.