بعد توقف دعم AWS لأداة Copilot CLI، قد يؤدي حذف مكدساتها (stacks) بشكل خاطئ إلى حذف قواعد بياناتك وموارد الإنتاج المهمة، لأنها مصممة لتدمير نفسها تلقائياً عند المغادرة.
هل تستخدم AWS Copilot لخدماتك؟ هناك تحذير مهم للغاية يجب أن تعرفه. على الرغم من أن AWS أوقفت دعم Copilot CLI في 12 يونيو 2026 وأرشفة مستودعه بعد عشرة أيام، فإن خدمات ECS التي نشرتها باستخدام Copilot ستستمر في العمل لأن Copilot كان مجرد منشئ لمكدسات CloudFormation.
ولكن، إذا كنت تخطط للانتقال من Copilot – ربما إلى Terraform – واعتمدت خطة بسيطة مثل «إعادة الإنشاء في Terraform ثم حذف مكدسات Copilot»، فقد تكون في ورطة كبيرة. تطبيق هذه الخطة دون حذر كافٍ قد يؤدي إلى حذف كامل لبيانات الإنتاج وقواعد بياناتك!
ماذا يعني هذا بالنسبة لك؟ حسناً، المشكلة تكمن في طريقة عمل Copilot. أولاً، تحتوي موارد Copilot المخصصة على «معالجات حذف» (Delete handlers) مدعومة بـ Lambda، والكثير منها يقوم بعمليات تدميرية عند حذف المكدس. على سبيل المثال، عند حذف المكدس البيئي، يمكنه حذف شهادات ACM وسجلات DNS المرتبطة بها، وحذف سجلات الألياس في Route 53، وحتى إفراغ سلة سجلات وصول ELB بكل إصداراتها. حتى لو قمت بنقل هذه الموارد إلى Terraform أولاً، فإن دالة Lambda هذه ستتصرف بشكل مستقل.
ثانياً، هناك ما يسمى بـ «وحدة التحكم البيئية» (env-controller). كل مكدس خدمة يحمل مورداً مخصصاً يُسمى EnvControllerAction. عندما يتم حذف آخر خدمة تحتاج إلى موارد مشتركة مثل ALB أو NAT gateways أو EFS، تقوم وحدة التحكم هذه بتحديث المكدس البيئي لإزالتها. هذا يعني أن حذف آخر مكدس خدمة لديك قد يؤدي إلى اختفاء موازن التحميل ونظام الملفات الخاص بك.
ثالثاً، بعض الإضافات غير المحمية، مثل Aurora وDynamoDB وS3، تعيش في مكدسات متداخلة لا تحتوي على سياسة حذف (DeletionPolicy). حذف المكدس الأم يعني أن CloudFormation سيحذف قواعد بياناتك هذه بلا رجعة.
رابعاً، حتى العلامة `--retain-resources` التي قد تفكر فيها لا تساعد هنا، فهي تعمل فقط على المكدسات التي فشل حذفها بالفعل. الطريقة الآمنة الوحيدة هي وضع `DeletionPolicy: Retain` و `UpdateReplacePolicy: Retain` على كل مورد في كل مكدس، بما في ذلك المكدسات المتداخلة والمجموعات. هذا سيمنع CloudFormation من استدعاء معالجات الحذف. بعد ذلك، قم باستيراد كل مورد إلى Terraform بقيمه الحالية الدقيقة.
لذلك، إذا كنت تنتقل بعيداً عن AWS Copilot، لا تتعجل. خطط بعناية فائقة لتجنب حذف أي شيء مهم عن طريق الخطأ.
ولكن، إذا كنت تخطط للانتقال من Copilot – ربما إلى Terraform – واعتمدت خطة بسيطة مثل «إعادة الإنشاء في Terraform ثم حذف مكدسات Copilot»، فقد تكون في ورطة كبيرة. تطبيق هذه الخطة دون حذر كافٍ قد يؤدي إلى حذف كامل لبيانات الإنتاج وقواعد بياناتك!
ماذا يعني هذا بالنسبة لك؟ حسناً، المشكلة تكمن في طريقة عمل Copilot. أولاً، تحتوي موارد Copilot المخصصة على «معالجات حذف» (Delete handlers) مدعومة بـ Lambda، والكثير منها يقوم بعمليات تدميرية عند حذف المكدس. على سبيل المثال، عند حذف المكدس البيئي، يمكنه حذف شهادات ACM وسجلات DNS المرتبطة بها، وحذف سجلات الألياس في Route 53، وحتى إفراغ سلة سجلات وصول ELB بكل إصداراتها. حتى لو قمت بنقل هذه الموارد إلى Terraform أولاً، فإن دالة Lambda هذه ستتصرف بشكل مستقل.
ثانياً، هناك ما يسمى بـ «وحدة التحكم البيئية» (env-controller). كل مكدس خدمة يحمل مورداً مخصصاً يُسمى EnvControllerAction. عندما يتم حذف آخر خدمة تحتاج إلى موارد مشتركة مثل ALB أو NAT gateways أو EFS، تقوم وحدة التحكم هذه بتحديث المكدس البيئي لإزالتها. هذا يعني أن حذف آخر مكدس خدمة لديك قد يؤدي إلى اختفاء موازن التحميل ونظام الملفات الخاص بك.
ثالثاً، بعض الإضافات غير المحمية، مثل Aurora وDynamoDB وS3، تعيش في مكدسات متداخلة لا تحتوي على سياسة حذف (DeletionPolicy). حذف المكدس الأم يعني أن CloudFormation سيحذف قواعد بياناتك هذه بلا رجعة.
رابعاً، حتى العلامة `--retain-resources` التي قد تفكر فيها لا تساعد هنا، فهي تعمل فقط على المكدسات التي فشل حذفها بالفعل. الطريقة الآمنة الوحيدة هي وضع `DeletionPolicy: Retain` و `UpdateReplacePolicy: Retain` على كل مورد في كل مكدس، بما في ذلك المكدسات المتداخلة والمجموعات. هذا سيمنع CloudFormation من استدعاء معالجات الحذف. بعد ذلك، قم باستيراد كل مورد إلى Terraform بقيمه الحالية الدقيقة.
لذلك، إذا كنت تنتقل بعيداً عن AWS Copilot، لا تتعجل. خطط بعناية فائقة لتجنب حذف أي شيء مهم عن طريق الخطأ.
