إدارة الأسطول مع Systems Manager

عندك 400 instance من EC2 وسؤال جوابه على أي واحدة منها يستغرق عشر ثوانٍ: أي إصدار من الوكيل مثبَّت عليها؟ الجواب عبر SSH يكلّفك خادم bastion، ومشكلة توزيع مفاتيح، ومنفذاً داخلاً مفتوحاً على كل security group، وسكربت shell ملفوفاً حول 400 اسم مضيف بلا سجلّ لما جرى وأين. ووُجد Systems Manager كي يكلّف هذا السؤال نداء واجهة واحداً ويخرج بأثر تدقيق.

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

الشروط الثلاثة التي تجعل العقدة مُدارة

كل أداة من أدوات Systems Manager في هذا المجال (Session Manager وRun Command وPatch Manager وState Manager) تعمل على العقد المُدارة (managed nodes)، ولا شيء منها يعمل قبل أن تصير الـ instance واحدة منها. وثلاثة شروط يجب أن تتحقّق معاً.

يجب أن يكون SSM Agent مثبَّتاً وعاملاً على نظام تشغيل مدعوم. ومعظم صور AMI التي توفّرها AWS تأتي به مثبَّتاً مسبقاً، ولهذا يمرّ هذا الشرط عادةً بلا أي عمل منك، ولهذا أيضاً يسهل نسيانه حين يأتي أحدهم بصورة مخصّصة.

يجب أن تحمل العقدة بيانات اعتماد تتيح لها استدعاء واجهة Systems Manager. على EC2 يعني ذلك IAM instance profile أو البديل على مستوى الحساب الذي يشرحه القسم التالي. وعلى خادم داخلي أو جهاز افتراضي يعني دور خدمة IAM وhybrid activation.

يجب أن يستطيع الوكيل الوصول إلى نقطة نهاية Systems Manager على المنفذ 443 كي يسجّل نفسه. وبعد التسجيل تتحقّق الخدمة من صحة العقدة بإشارة كل 5 دقائق.

احفظ الترتيب، لأنه ترتيب التشخيص نفسه في آخر هذا الدرس. ولاحظ اتجاه الاتصال: SSM Agent هو من يبدأ كل اتصال، والاتصال خارج دائماً. أنت لا تفتح منفذاً داخلاً لـ Systems Manager أبداً، وهذه الحقيقة الواحدة هي ما يجعل هذه الأدوات تحسيناً أمنياً على SSH لا مجرّد طبقة راحة فوقه.

طريقتان لمنح الـ instance بيانات اعتماد

الطريقة الكلاسيكية هي IAM instance profile يحمل السياسة المُدارة AmazonSSMManagedInstanceCore. هي لكل instance على حدة، وصريحة، وهي ما يدور حوله أي سؤال عن عقدة واحدة مهيّأة خطأً في الغالب.

وDefault Host Management Configuration هي البديل على مستوى الحساب، وتوصي AWS به حيث تسمح حالة الاستخدام. فعّلها فتصير كل instance في ذلك الحساب وذلك Region تعمل بالإصدار الثاني من خدمة instance metadata مع SSM Agent إصدار 3.2.582.0 أو أحدث عقدة مُدارة تلقائياً بلا instance profile إطلاقاً. وهي تستخدم دور خدمة اسمه AWSSystemsManagerDefaultEC2InstanceManagementRole يحمل السياسة AmazonSSMManagedEC2InstanceDefaultPolicy.

وثلاثة تفاصيل تحسم الأسئلة هنا.

التفعيل لكل Region. تفعيلها في eu-west-1 لا يفعل شيئاً لـ us-east-1. والفرق تكتشف هذا حين يصير نصف أسطولها مُداراً ونصفه لا.

الـ instance profile يغلب. يجرّب SSM Agent صلاحيات الـ instance profile قبل صلاحيات Default Host Management Configuration، فأي instance profile قديم يسمح بـ ssm:UpdateInstanceInformation يُبقي تلك الـ instance على المسار القديم ولا يُستخدم دور الحساب أبداً. فأزل تلك الصلاحية من الـ instance profiles القائمة قبل التفعيل.

الانتشار ليس لحظياً. بعد التفعيل قد تستغرق الـ instances 30 دقيقة كي تلتقط بيانات اعتماد الدور الجديد.

Session Manager: صدفة بلا منفذ داخل

تحتاج صدفة على instance إنتاج في الثانية صباحاً. وSession Manager يعطيك واحدة من الـ Console أو من الـ CLI، بلا منفذ داخل مفتوح، وبلا مفتاح SSH، وبلا خادم bastion.

الاتصال قناة ثنائية الاتجاه بين عميلك وSSM Agent. والحركة مشفّرة بـ TLS 1.2، وطلبات فتح القناة موقّعة بـ Sigv4، وتستطيع إضافة مفتاح KMS فوق ذلك لتشفير بيانات الجلسة زيادة على تشفير TLS الافتراضي. والوصول يُمنح بسياسة IAM بالكامل، وهذا ما يجعل جملة "أعطِ مهندس المناوبة وصولاً إلى الإنتاج طوال مدة مناوبته" تعديلاً على سياسة لا تمريناً في تدوير المفاتيح.

وقدرتان تستحقّان التسمية إلى جانب الصدفة التفاعلية:

port forwarding يعيد توجيه منفذ داخل العقدة إلى منفذ محلّي على جهازك. فقاعدة بيانات تسمع على 5432 داخل subnet خاصة تصير localhost:9999 على حاسوبك المحمول، بلا VPN وبلا عنوان IP عام.

shell profiles القابلة للتهيئة تتيح لك ضبط الصدفة ومتغيّرات البيئة ودليل العمل وأوامر البدء لكل جلسة، وهذه طريقتك كي تهبط الجلسات في مكان متوقّع.

وللتدقيق تستطيع الجلسات أن تبثّ إلى log group في CloudWatch Logs أو إلى bucket في S3، بمفتاح KMS خاص بك أو بدونه، وCloudTrail يسجّل نداءات الواجهة التي بدأتها. وقاعدة EventBridge على بدء الجلسة وانتهائها تستطيع دفع إشعار إلى SNS.

وهنا المفهوم الخاطئ الذي ينجو من أول قراءة لهذه الخدمة. تسجيل الجلسات لا يغطّي port forwarding ولا جلسات SSH. فـ Session Manager في هذين النمطين نفق فقط، وSSH يشفّر كل شيء داخل اتصال TLS، فلا يبقى للخدمة ما تسجّله. وإن طلب سيناريو نسخة مسجَّلة من الأوامر فالجواب يمرّ بالجلسات التفاعلية لا بـ port forwarding.

Run Command: إجراء واحد على الأسطول

Session Manager لعقدة واحدة وإنسان واحد. وRun Command لعقد كثيرة وdocument واحد، ولا يكلّف شيئاً إضافياً.

تختار SSM document من نوع Command (AWS-RunShellScript وAWS-RunPowerShellScript وAWS-RunPatchBaseline وغيرها)، وتختار الأهداف، وتضبط ضوابط المعدّل.

والأهداف تأتي في أربعة أشكال:

# بمعرّف الـ instance
--targets Key=instanceids,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE

# بالوسم
--targets Key=tag:Environment,Values=Production

# باسم مجموعة موارد (واحدة كحدّ أقصى لكل أمر)
--targets Key=resource-groups:Name,Values=web-tier

# بنوع الموارد داخل مجموعات الموارد (5 أنواع كحدّ أقصى)
--targets Key=resource-groups:ResourceTypeFilters,Values=AWS::EC2::Instance

وقاعدتان في الاستهداف بالوسوم تحسمان الأسئلة. معايير Key المتعدّدة تُدمج بعلاقة AND، فـ Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database تضرب العقد التي تحمل الوسمين معاً فقط. ومصفوفة الأهداف تحمل 5 مفاتيح كحدّ أقصى بـ 5 قيم لكل مفتاح.

والآن ضوابط المعدّل، وهي الزوج نفسه الذي قابلته في Automation runbooks:

• --max-concurrency كم عقدة تشغّل الأمر في المرة، رقماً أو نسبة. وقيمتها الافتراضية 50. والتسليم يتصاعد: يذهب الأمر إلى عقدة واحدة، وينتظر الإقرار، ثم إلى عقدتين، ثم يكبر تصاعدياً حتى يبلغ الحدّ.
• --max-errors كم حالة فشل تُحتمل قبل أن يتوقّف Systems Manager عن الإرسال إلى عقد أخرى. وقيمتها الافتراضية 0، أي أن أول فشل يوقف الإرسال.

امشِ بالحساب الذي تعطيه AWS لهذا. أرسل أمراً إلى 50 عقدة بـ --max-errors 10%: العتبة 5، فيتوقّف الإرسال عند وصول الخطأ السادس. والاستدعاءات الجارية أصلاً يُسمح لها بالإكمال، وقد يفشل بعضها أيضاً. وإن طلب سيناريو ألّا يفشل أكثر من N عقدة قطعاً فـ --max-errors N وحدها لا تكفي، وتحتاج معها --max-concurrency 1 كي تسير الاستدعاءات واحداً واحداً.

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets Key=tag:Environment,Values=Production \
  --parameters 'commands=["systemctl restart nginx"]' \
  --max-concurrency 10 \
  --max-errors 1 \
  --output-s3-bucket-name ops-command-output \
  --service-role-arn arn:aws:iam::111122223333:role/SSMRunCommandNotifications \
  --notification-config NotificationArn=arn:aws:sns:eu-west-1:111122223333:ops-alerts,NotificationEvents=Failed,NotificationType=Command

وملاحظتان تشغيليتان عن المخرجات. سجلّ الأوامر متاح مدة تصل إلى 30 يوماً، فأي شيء تحتاجه أطول من ذلك يذهب إلى S3 أو CloudWatch Logs، وهذه أيضاً طريقتك لتجاوز عرض الـ Console المقتطع للمخرجات الطويلة. ولا تمرّر سرّاً في وسائط أمر نصية أبداً: كل نشاط واجهة Systems Manager مسجَّل، فمن يملك وصولاً إلى تلك السجلّات يقرأه. استخدم وسيطاً من نوع SecureString بدلاً منه، وهو موضوع درس لاحق في هذا الموضوع.

Fleet Manager وInventory: أن ترى ما تملك

Fleet Manager هو الواجهة فوق هذا كله. يعرض أي العقد المُدارة عاملة وأيها متوقّفة، ويتيح لك عمل إدارة النظم دون فتح جلسة أصلاً: تصفّح نظام الملفات وقراءة محتويات الملفات، وإدارة سجلّ Windows، وإدارة حسابات المستخدمين والمجموعات في نظام التشغيل، وعرض العمليات العاملة، وعرض ملفات السجلّ على العقدة، والاتصال بـ instance من Windows عبر RDP، وإدارة أقراص EBS المرفقة بها. وكل واحد من هذه الإجراءات محكوم بـ IAM، فتستطيع منح فريق دعم قراءة السجلّات دون منحه صدفة.

وInventory يجيب عن الأسئلة على مستوى الأسطول. يجمع ميتاداتا وفق جدول: التطبيقات وإصداراتها، ومكوّنات AWS، والملفات، وتهيئة الشبكة، وتحديثات Windows، وتفاصيل الـ instance، والخدمات، والوسوم، ومفاتيح سجلّ Windows، وأدوار Windows، وأي جرد مخصّص تُنزله على العقدة كملف JSON. وأقصر فاصل جمع هو كل 30 دقيقة، فتعامل معه كلقطة دورية لا كتغذية لحظية.

وInventory يجمع ميتاداتا فقط. هو لا يقرأ بياناتك.

والقطعة التي تحوّل Inventory إلى أداة تقارير حقيقية هي resource data sync: وجّه كل حساب وكل Region إلى bucket واحد في S3، ثم استعلم عن البيانات المجمَّعة بـ Athena. وهذا هو الفارق بين "أي العقد في هذا Region تعمل بـ OpenSSL 1.0" و"أي العقد في المؤسسة كلها تعمل بـ OpenSSL 1.0".

حين لا تظهر العقدة في القائمة

تأكّدت أن الـ instance عاملة. وهي ليست في قائمة العقد المُدارة. امشِ في الشروط الثلاثة بترتيبها، لأن هذا الترتيب يجد السبب بأقلّ عمل.

ابدأ بالفحص السريع من العقدة نفسها. فـ SSM Agent إصدار 3.1.501.0 وما بعده يأتي بأداة مستقلّة:

ssm-cli get-diagnostics --output table

وعلى Windows Server شغّل ssm-cli.exe get-diagnostics --output table من C:\Program Files\Amazon\SSM. تعيد الأداة صفّاً لكل فحص بحالة Success أو Failed أو Skipped، والصفّ الفاشل يسمّي الشرط.

اربط الصفوف بالأسباب:

ومن جهة الواجهة، يعيد aws ssm describe-instance-associations-status --instance-id i-02573cafcfEXAMPLE مصفوفة InstanceAssociationStatusInfos فارغة إلى أن ينجح التسجيل، فنتيجة فارغة بعد 5 دقائق هي الإشارة نفسها.

ولشرط الاتصال، تصل الـ instance إلى نقاط النهاية العامة عبر مسار HTTPS خارج، أو تصل إلى interface VPC endpoints بدلاً منها:

وسببان آخران يستحقّان الحمل معك لأنهما يبدوان كعلّة برمجية. العقدة التي بقيت حالتها Connection Lost مدة 30 يوماً على الأقل قد تسقط من قائمة Fleet Manager كلياً حتى تُحلّ المشكلة الأصلية. وكل عقدة مُدارة تحتاج شهادة TLS من Amazon Trust Services في مخزن ثقتها، وصورة مخصّصة أو خادم داخلي بلا واحدة يفشل برسالة خطأ SSL في المكان الذي تتوقّع فيه UnknownOperationException من curl -L https://ssm.region.amazonaws.com.

نصائح الاختبار

• أي سؤال بصيغة "الـ instance عاملة لكنها لا تظهر في Systems Manager" يختبر الشروط الثلاثة. اقرأ نصّ السؤال باحثاً عن أيّها أزاله: لا وكيل، أو لا instance profile، أو لا مسار إلى نقاط النهاية.
• subnet خاصة بلا NAT gateway مع شرط Session Manager تعني interface VPC endpoints، وssmmessages هي التي تحمل الجلسة.
• Default Host Management Configuration لكل حساب ولكل Region، وتحتاج IMDSv2، وتخسر أمام instance profile يسمح بـ ssm:UpdateInstanceInformation.
• عبارة "بلا منافذ داخلة، وبلا خادم bastion، وبلا مفاتيح SSH، ومع أثر تدقيق" تشير إلى Session Manager. وإن طلب السؤال نفسه نسخة مسجَّلة من الأوامر فتذكّر أن port forwarding وSSH غير مسجَّلين.
• قيم Run Command الافتراضية: تزامن 50، وعتبة أخطاء 0. والسؤال الذي أوقفت فيه حالة فشل واحدة أمراً على الأسطول كلّه هو سؤال عن --max-errors غير مضبوطة.
• لحصر مجموع حالات الفشل لا مجرّد إيقاف الإرسال، اقرن --max-errors بـ --max-concurrency 1.
• سجلّ الأوامر 30 يوماً. وأي شرط للاحتفاظ بالمخرجات أطول من ذلك يعني S3 أو CloudWatch Logs.
• Inventory ميتاداتا وفق جدول بأرضية 30 دقيقة، وresource data sync إلى S3 هو ما يجعلها قابلة للاستعلام عبر الحسابات والمناطق بـ Athena.

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