اجعل تغييرات DNS قابلة للمراجعة قبل جعلها تلقائية
يمكن للبنية الأساسية كرمز أن تمنح سجلات المصادقة مالكًا صريحًا وسجلًا قابلاً للمراجعة وعملية تغيير قابلة للتكرار. ويمكنه أيضًا تكرار الخطأ عبر العديد من الأسماء بسرعة. وبالتالي فإن الهدف هو إجراء تغييرات خاضعة للرقابة على مجموعات السجلات المحددة، مع إبقاء الموافقة على النشر والتحقق DNS منفصلين عن مراجعة التعليمات البرمجية الناجحة.
تستخدم هذه المقالة فرع وثائق Terraform CLI المعروض كـ v1.17.x عند مراجعته في 8 نوفمبر 2026. إنها مناقشة سير عمل، وليست وصفة تكوين خاصة بالموفر أو مطالبة بشأن إصدار مثبت. سيحتاج تصحيح Terraform الدقيق وإصدار البرنامج الإضافي لموفر DNS والواجهة الخلفية والحساب إلى التسجيل من أجل التنفيذ. لم يتم إجراء أي تهيئة للموفر أو خطة أو نشر أو عملية اعتماد أو تغيير DNS هنا.
تحديد ما يملكه المستودع
ابدأ بجرد أسماء المالكين وأنواعهم وحدود مجموعة السجلات الدقيقة. قم بتسمية الفريق المسؤول عنه SPF، كل محدد DKIM, DMARC السياسة والأسماء المستعارة التي يديرها الموفر. قم بتضمين المناطق المفوضة والأهداف الخارجية في خريطة التبعية حتى عندما لا تتم إدارتها بواسطة نفس المستودع. أ CNAME يمكن أن يجعل التكوين المحلي يعتمد على DNS الخاص بمؤسسة أخرى ودورة حياة الخدمة. RFC 1034
قم بحل الملكية المتداخلة قبل استيراد السجلات الموجودة إلى أي أداة. إذا طالبت لوحة DNS ونظامان للتشغيل الآلي بنفس المجموعة، فلن يمنع طلب السحب المرتب أحدهما من التراجع عن عمل الآخر. قم بإنشاء عملية لتحرير دليل الطوارئ والتوفيق بينها بعد ذلك. لا تصف كل تغيير خارجي بأنه انجراف غير مصرح به؛ حدد أولاً ما إذا كان التكوين المعلن لا يزال هو الهدف المعتمد.
لخيالية DKIM عند بدء التشغيل، يجب أن تقوم الخريطة بتوصيل مادة DNS العامة للمحدد الجديد بالمرسل الذي سيوقع باستخدام هذا المحدد. ينتمي مفتاح التوقيع الخاص إلى نظام التوقيع المعتمد، وليس إلى مستودع DNS العام. إن نشر المفتاح العام وحده لا يغير سلوك المرسل. RFC 6376
سجل التبعيات كجزء من التغيير
حافظ على متطلبات إصدار Terraform وإصدارات الموفر المحددة وإصدارات الوحدة ذات الصلة من خلال المراجعة. يوثق HashiCorp أن ملف قفل التبعية يسجل اختيارات الموفر والمجاميع الاختبارية؛ ولا يقوم بتأمين تحديدات الوحدة البعيدة بنفس الطريقة. قم بمراجعة تغييرات التبعية بشكل منفصل عندما يكون ذلك عمليًا سجل التحرير لا يخفي ترقية الموفر. ملف قفل تبعية Terraform
احتفظ بمواد الحالة والاسترداد الحالية ضمن ضوابط الوصول المعتمدة للمؤسسة. الحالة عبارة عن رسم خرائط تستخدمه الأداة، وليست بديلاً لخط أساس منطقة قابلة للقراءة أو خطة عكس على مستوى السجل. احصل على بيانات الموفر والإجابات العامة الحالية المقصودة قبل الانتقال عالي التأثير. قم بتسجيل التبعيات التي لا يستطيع الفريق استعادتها ومن يملك خطوات الاسترداد هذه.
التحقق منفصل عن الخطة الحقيقية
الأمر المقترح التحقق من صحة التضاريس يتحقق من تناسق التكوين في دليل العمل الذي تمت تهيئته بالفعل. ولا يتحقق من صحة واجهة برمجة التطبيقات المباشرة للموفر أو الخدمات البعيدة. وهذا ليس سببًا لتثبيت المكونات الإضافية أو تهيئة الواجهة الخلفية أثناء عملية التوثيق. يجب على المشغل أولاً التأكد من أن البيئة والتبعيات المطلوبة مرخصة بالفعل. التحقق من صحة Terraform
الأمر المقترح خطة التضاريس يقوم بمعاينة التغييرات ويقرأ عادةً الكائنات البعيدة الموجودة. ولا يطبق تغييرات البنية التحتية المقترحة، ولكنه ليس فحصًا نصيًا دون الاتصال بالإنترنت: قد يكون هناك مقدمو خدمات وبيانات اعتماد ومصادر بيانات ووصول إلى الحالة. قم بمراجعة بيئة التكوين والتنفيذ قبل السماح حتى بالخطة. إن غياب النشر لا يجعل معالجة بيانات الاعتماد غير ذات صلة. خطة التضاريس
تعامل مع الخطة المقروءة كدليل على تكوين محدد وحالة ووقت مراقبة. إذا تغيرت حالة الحساب بعد ذلك، فلن يعد من الممكن افتراض أن المعاينة السابقة تصف العملية النهائية. تجنب الوعود الواسعة بأن الخطة الخضراء تثبت السلامة أو إمكانية التنفيذ. إنه لا يثبت أن السياسة المقترحة معقولة ولا أن النظام المتلقي يمكنه استرداد البيانات الناتجة.
قم بمراجعة تأثير DNS الدقيق
يجب أن تحدد ورقة المراجعة المقترحة المنطقة والمالك والنوع والقيمة القديمة والقيمة الجديدة وTTL وكل عملية إنشاء أو تحديث أو حذف. اشرح أي دلالات بديلة في وثائق الموفر المثبت. قد يمثل مورد واحد في التعليمات البرمجية مجموعة سجلات، لذلك يجب على المراجع فهم ما إذا كان من الممكن إزالة القيم غير ذات الصلة. إذا كان هذا التعيين غير واضح، توقف قبل الموافقة على التغيير.
استخدم عمليات التحقق الخاصة بالمصادقة بدلاً من اختبارات بناء الجملة فقط. يجب أن يحافظ بديل SPF المقترح على تصميم الإرسال المعتمد؛ يحتاج تدوير المحدد إلى خطة انتقال المرسل؛ يحتاج تغيير سياسة DMARC إلى قرار مسؤول بشأن التنفيذ. هذه أسئلة مراجعة، وليست إذنًا للأتمتة لاستنتاج خدمات إرسال جديدة أو التزامات السياسة. أبقِ الموافقة مرتبطة بالفرق التبعي الدقيق.
في طرح المحدد الخيالي، اطلب التحقق من تبعية البحث الجديدة قبل انتقال المرسل، والتوثيق عندما يمكن إيقاف المحدد القديم بأمان. لا تقم بتجميع حذف المفتاح السابق مع النشر الأولي فقط للحفاظ على المستودع أنيقًا. يجب أن يتبع التوقيت سير عمل البريد المعتمد والأدلة التي تمت ملاحظتها، وليس رقمًا عامًا منسوخًا في المسار.
قم بحماية عناصر المراجعة بعناية مثل التكوين
قد تحتوي الخطة المحفوظة على قيم حساسة حتى عندما يخفيها الإخراج الطرفي. لا تؤدي العلامات الحساسة لـ Terraform في حد ذاتها إلى إبقاء القيم خارج الحالة وملفات التخطيط. تجنب وضع بيانات الاعتماد أو المفاتيح الخاصة أو العناصر غير المنقحة في طلبات السحب وقنوات الدردشة الواسعة. قم بمشاركة الحد الأدنى فقط من مواد المراجعة مع المراجعين المعتمدين. Terraform البيانات الحساسة
حدد من يمكنه قراءة الحالة ومن يمكنه طلب خطة ومن يمكنه الموافقة على النشر وتنفيذه. لا تحتاج بيئة المراجعة إلى امتيازات كتابة واسعة لمجرد أن بيئة النشر اللاحقة تحتاجها. يعد إنشاء بيانات الاعتماد أو توسيع الأذونات إجراءً أمنيًا معتمدًا، وليس جزءًا ضمنيًا من اعتماد البنية التحتية كرمز.
تعامل مع التراجع والتحقق كعمل جديد
التراجع عن الالتزام يغير النية المعلنة؛ ولا يقوم باستعادة DNS على الفور. يحتاج مقترح التراجع إلى مقارنة جديدة مع السجلات الحالية، وخطة تمت مراجعتها والتحقق من أن القيم القديمة تظل آمنة. يمكن أن تؤدي إعادة تطبيق خط أساس قديم إلى مسح التعديل المتزامن الشرعي أو إحياء تبعية المرسل المتقاعدة. يمكن أن تستمر الإجابات المخزنة مؤقتًا بعد التغييرات الأمامية أو العكسية. RFC 2308
بعد النشر المعتمد بشكل مستقل، احتفظ بأدلة البحث الموثوقة والمتكررة وملاحظات البريد ذات الصلة. قم بإغلاق التغيير فقط عندما تتطابق الحالة الفعلية مع النتيجة المعتمدة أو أن التناقض المتبقي له مالك. لا يزال اختلاف السجل الدقيق لهذه المخطوطة، وخريطة التبعية، واستعادة المواد، ونصوص ما بعد التغيير من متطلبات الإصدار. يعد سير العمل الموثق تحضيرًا لهذا الدليل، وليس دليلاً على نجاح النشر.