صور AMI وEC2 Image Builder

مجموعة Auto Scaling تضيف نسخة أثناء ذروة حركة. تُقلِع النسخة في 40 ثانية تقريباً، ثم تقضي 8 دقائق أخرى داخل user data: ترقيع نظام التشغيل، وسحب ثلاثة agents، وبناء اعتمادية من مصدرها. وحين تجتاز فحص الصحة تكون الذروة قد انتهت. والأسوأ أن النسخة التي أُطلِقت الثلاثاء الماضي ثبّتت إصدارات حزم تختلف قليلاً عن نسخة اليوم، لأن كلتيهما حلّت latest مقابل مستودع تحرّك بينهما.

للمشكلتين علاج واحد: نفّذ ذلك العمل مرة واحدة قبل الإطلاق، واحفظ النتيجة صورةً.

ما الذي تحويه صورة AMI فعلاً

صورة Amazon Machine Image ليست ملفاً تستطيع تنزيله. هي سجلّ داخل EC2 يشير إلى لقطة EBS واحدة أو أكثر، ويحمل البيانات الوصفية اللازمة لتحويل تلك اللقطات إلى نسخة قابلة للإقلاع:

• خريطة أجهزة الكتل (block device mapping): أي لقطة تصير وحدة الجذر، وما حجمها، وأي وحدات إضافية تُربَط، وهل تُحذَف عند إنهاء النسخة.
• بيانات الإقلاع والمنصّة: معمارية المعالج (x86_64 أو arm64)، ونوع المحاكاة، ونوع وحدة الجذر، ووضع الإقلاع.
• صلاحيات الإطلاق: أي الحسابات أو المؤسّسات أو الوحدات التنظيمية يجوز لها الإطلاق منها.

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

الصورة مورد منطقة. اللقطات تسكن منطقة واحدة، فمعرّف الصورة لا معنى له إلا داخل تلك المنطقة. والإطلاق في منطقة ثانية يقتضي نسخ الصورة إليها، وتحصل النسخة على معرّف مختلف. ولهذا ينكسر قالب CloudFormation يثبّت معرّف صورة بداخله لحظة ينشره أحد في مكان آخر.

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

والخصائص الخمس مثبّتة عند الإنشاء. لا تحوّل صورة x86_64 إلى arm64، ولا صورة مبنية على instance store إلى صورة مبنية على EBS. وحين تحتاج تركيبة أخرى تبني صورة جديدة.

التضمين أم التهيئة: القرار الذي يحكم كل ما بعده

كل قطعة إعداد يحتاجها خادم تصل بإحدى طريقتين. التضمين (baking) يضعها داخل الصورة وقت البناء. والتهيئة عند الإطلاق (bootstrapping) تطبّقها لحظة الإقلاع عبر user data أو ارتباط Systems Manager أو أداة إدارة إعدادات.

لا شيء يجبرك على اختيار واحدة منهما. السؤال المفيد هو أي نصف من إعداداتك يذهب إلى أين.

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

والصورة المبنية بهذه الطريقة تُسمّى عادةً صورة ذهبية (golden AMI): أساس مقوّى ومرقّع ومحمّل مسبقاً تطلق منه كل أحمال العمل في المؤسّسة.

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

لماذا تتوقّف الصور الذهبية المبنية باليد عن العمل

الصورة الذهبية الأولى سهلة. تطلق نسخة، وترقّعها، وتثبّت ما تحتاجه، وتشغّل create-image، وتكتب معرّف الصورة في صفحة wiki.

الشهر الثاني هو موضع الانهيار. تظهر ثغرات جديدة فتحتاج الصورة إعادة بناء، والشخص الذي بناها في إجازة ولم يدوّن الخطوة الرابعة قطّ. ولم يختبر أحد الصورة الجديدة قبل أن تبدأ مجموعة Auto Scaling الإطلاق منها. والصورة موجودة في us-east-1 وحدها ومنطقة التعافي تحتاجها أيضاً. ولا سجلّ لما تغيّر بين الإصدار الثالث والرابع.

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

موارد Image Builder الخمسة

يقسم Image Builder بناء الصورة إلى خمسة موارد، وحين ترى ما يملكه كل واحد منها تكفّ الخدمة عن الشعور بالضخامة.

اثنان من هذه الموارد يستحقّان نظرة أقرب.

المكوّنات هي موضع تخصيصك الفعلي. المكوّن مستند YAML عادي يشغّله AWSTOE على نسخة البناء، وله نوعان: build components تخصّص النسخة قبل اللقطة، وtest components تتحقّق منها بعدها. وتنشر AWS مكوّنات مُدارة للأعمال الشائعة، منها update-linux ومجموعات التقوية وفق معايير STIG، وتكتب أنت ما يخصّك.

name: InstallAndVerifyNginx
description: تثبيت nginx والتأكد من استجابته على المنفذ 80
schemaVersion: 1.0
phases:
  - name: build
    steps:
      - name: InstallNginx
        action: ExecuteBash
        inputs:
          commands:
            - dnf install -y nginx
            - systemctl enable nginx
  - name: validate
    steps:
      - name: ConfirmBinary
        action: ExecuteBash
        inputs:
          commands:
            - nginx -v

أسماء الأطوار ليست زينة. يقرّر Image Builder متى يعمل المكوّن من الأطوار التي يعرّفها: يعمل في مرحلة البناء إن عرّف build أو validate، ويعمل في مرحلة الاختبار إن عرّف test وحده. ولا يستطيع مكوّن أن يجلس على المرحلتين معاً، ولا تستطيع تمرير قيمة أنتجها طور build إلى خطوة في test، لأن المرحلتين تعملان على نسختين مختلفتين.

وإعداد البنية التحتية هو المورد الذي ينساه الناس حتى يفشل بناء. نسخة البناء تعمل داخل VPC خاصّتك، فهي تحتاج subnet له مسار يصل إلى مستودعات الحزم، ومجموعة أمان تسمح بتلك الحركة، وinstance profile يحمل صلاحيات Image Builder. وهو أيضاً موضع مفتاح التشخيص: تُنهى نسخة البناء افتراضياً حين يفشل البناء، وتعطيل ذلك يبقيها حيّة كي تدخل عليها وتقرأ سجلّات AWSTOE.

ما الذي تفعله تشغيلة واحدة فعلاً

امشِ على بناء واحد من أوله إلى آخره، لأن الترتيب نفسه يفسّر عدة إجابات في الاختبار.

1. مرحلة البناء. يطلق Image Builder نسخة EC2 من الصورة الأساس داخل الـ subnet المحدّد في إعداد البنية التحتية. ويشغّل AWSTOE طور build لكل build component بترتيب الوصفة، ثم طور validate لكلٍّ منها. وإن فشلت أي خطوة توقّف البناء هنا.
2. اللقطة. بعد تطبيق التخصيصات يوقف Image Builder النسخة ويأخذ لقطة، فتنتج الصورة المرشّحة.
3. مرحلة الاختبار. في مسار AMI يطلق Image Builder نسخة جديدة من الصورة المرشّحة ويشغّل طور test لكل مكوّن في الوصفة. هذا إطلاق حقيقي للمنتج الحقيقي لا إعادة فحص لنسخة البناء، ولهذا يمسك خدمةً تفشل في الإقلاع الأول.
4. التوزيع. لا ينسخ Image Builder الصورة إلى كل منطقة في إعدادات التوزيع إلا إن نجحت كل الاختبارات، ثم يطبّق مفتاح KMS المُعدّ، ويضبط صلاحيات الإطلاق، ويحدّث اختيارياً launch template ليشير إلى معرّف الصورة الجديد.

والخيار الأخير يستحقّ وقفة. يستطيع التوزيع كتابة معرّف الصورة الجديد داخل إصدار محدّد من launch template، فتلتقط مجموعة Auto Scaling موجّهة إلى $Latest أو $Default من ذلك القالب الصورةَ الجديدة دون أن يعدّل أحد شيئاً.

والخدمة نفسها مجانية. تدفع ثمن نسخ EC2 للبناء والاختبار أثناء عملها، ولقطات EBS التي تشغلها الصور، وتخزين السجلّات في S3، وAmazon Inspector إن فعّلت فحص الثغرات أثناء البناء، وتخزين ECR لمخرجات صور الحاويات.

الجدولة: ابنِ على الساعة أم على التغيير

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

• ابنِ في الموعد المجدول دائماً. كل فتحة مجدولة تنتج بناءً، تغيّر شيء قبلها أو لم يتغيّر. تحصل على صورة طازجة على وتيرة ثابتة وتدفع ثمن بناء في كل مرة.
• ابنِ في الموعد المجدول فقط إن توفّرت تحديثات للاعتماديات. يفحص Image Builder هل للصورة الأساس أو لأي مكوّن إصدار دلالي أحدث، ويتخطّى البناء إن لم يتحرّك شيء.

ولا يعمل الخيار الثاني إلا إن استخدمت وصفتك الإصدار الدلالي للصورة الأساس والمكوّنات، وهو ما يعني في الـ Console اختيار «استخدم أحدث إصدار متاح» بدل تثبيت سلسلة إصدار بعينها. ثبّت كل شيء على إصدارات صمّاء ولا يبقى لدى Image Builder ما يقارنه، فيعيد البناء في كل مرة أو لا يكتشف تحديثاً أبداً، بحسب طريقة كتابة الوصفة.

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

توزيع النتيجة ومشاركتها

تتولّى إعدادات التوزيع العمل العابر للمناطق والحسابات الذي يفعله الناس يدوياً لولاها.

داخل حسابك ينسخ التوزيع الصورة إلى كل منطقة هدف. أما عبر الحسابات فأمامك خياران يختلفان في الملكية:

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

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

وسلوكان أصغر يستحقّان المعرفة. لست مضطراً إلى مشاركة اللقطات الداعمة على حدة، لأن EC2 يمنح صلاحية الإطلاق عليها نيابةً عنك. والوسوم التي عرّفتها أنت لا تسافر مع صورة مشتركة، فيرى الحساب المستقبِل صورة بلا وسوم.

تقاعد الصورة: ثلاثة أفعال ليست مترادفة

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

اقرأ الجدول سلّم تصعيد. Deprecate إشارة: كفّوا عن اختيار هذه الصورة، ولا شيء ينكسر. وDisable إيقاف: تفشل الإطلاقات، وتستطيع التراجع. وDeregister حذف.

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

ثم فخّ الكلفة. إلغاء تسجيل صورة لا يحذف لقطاتها الداعمة افتراضياً. والفريق الذي يلغي تسجيل 40 صورة راكدة ويتوقّع هبوط فاتورة التخزين ستفاجئه النتيجة، لأن اللقطات ما زالت هناك. مرّر --delete-associated-snapshots مع أمر إلغاء التسجيل، أو نظّفها بعده. واللقطة التي تشير إليها أكثر من صورة تبقى محفوظة على أي حال.

ولست مضطراً إلى فعل أي من هذا يدوياً. سياسات دورة الحياة في Image Builder تطبّق إجراءات deprecate وdisable والحذف على الصور التي أنتجها خط أنابيب، بقواعد قائمة على العمر والعدد مع قواعد استثناء تحمي الصور التي يجب أن تبقى. وAmazon Data Lifecycle Manager يغطّي الأرض نفسها لصور AMI المبنية على EBS عموماً، بما فيها صور لم تبنِها بـ Image Builder.

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

• «أوقف الإطلاقات الآن مع إمكانية التراجع» هو disable. و«علّمها قديمة مع إبقائها تعمل» هو deprecate. و«احذفها» هو deregister. والخيارات التي تخلط الآثار هي المشتّتات.
• إن قال النصّ إن مجموعة Auto Scaling ما زالت تطلق من صورة قديمة بعد أن أعلنها الفريق deprecated، فهذا هو السلوك المتوقّع لا خلل. الإعلان القديم يخفي الصورة من القوائم ولا يمنع إطلاقاً بالمعرّف أبداً.
• إلغاء التسجيل وحده لا يوقف فاتورة اللقطات. وأي إجابة تعامله تنظيفاً كاملاً خاطئة.
• مشاركة صورة مشفّرة تحتاج مفتاح KMS تديره أنت مع منح للحساب الهدف. وإن ذكر النصّ المفتاح الافتراضي الذي تديره AWS فالمشاركة مستحيلة، والجواب يمرّ بنسخة بمفتاحك.
• خط أنابيب يسقط في اختباراته لا يوزّع شيئاً. وإن سأل سؤال لماذا لم تظهر صورة جديدة في منطقة التعافي، فـ test component فاشل مشتبه به أول، إلى جانب غياب المنطقة عن إعدادات التوزيع أصلاً.
• «ابنِ فقط حين تُرقَّع الصورة الأساس» هو إعداد تحديثات الاعتماديات في الجدول، وهو معتمد على الإصدار الدلالي في الوصفة.
• Image Builder نفسه مجاني. والرسوم تأتي من نسخ البناء والاختبار واللقطات والسجلّات وInspector وECR.
• انتبه لانقسام التضمين مقابل التهيئة في نصوص السيناريوهات. أوقات الإطلاق الطويلة تشير إلى التضمين، والإعدادات الخاصة بكل بيئة تشير إلى التهيئة عند الإطلاق.

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

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