https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/ملاحظات هندسية، وأخبار الكتالوج، وأدلّة عملية من فريق imaxe.cloud.2026-08-22T15:25:49Z© 2026 imaxe.cloudHugoفريق imaxehttps://www.imaxe.cloud/https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/arm64-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7/2026-08-04T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/arm64-por-defecto_hu_99c180b1a81b7f6a.webp" alt="تفصيل مجهري لسيليكون معالج" width="1200" height="675"></p><p>تُبنى كل صورة AMI لمعمارية معالج محدّدة: إمّا x86_64 (إنتل أو AMD) أو ARM64 (aarch64، معمارية AWS Graviton وما يعادلها). لا توجد صورة «تصلح للاثنتين»: فالثنائيات مختلفة. لذلك كان علينا، عند إعداد كتالوجنا، أن نقرّر أيّهما سيكون الخيار الافتراضي.</p> <p>نظرنا في الكلفة والأداء والكفاءة ونضج المنظومة ووجهة السوق. وكانت الخلاصة واضحة: <strong>ARM64 اليوم هو الرهان الأفضل لمعظم الأحمال.</strong> وعلى هذا الأساس نبني صورنا.</p> <h2 id="لماذا-يفوز-arm64-لدى-الأغلبية">لماذا يفوز ARM64 لدى الأغلبية</h2> <h3 id="1-نسبة-سعر-إلى-أداء-أفضل">1. نسبة سعر إلى أداء أفضل</h3> <p>هذه هي الحجّة الحاسمة. تقدّم نسخ ARM (Graviton) باستمرار <strong>أداءً أعلى لكل يورو</strong> من نظيراتها x86 عبر طيف واسع من الأحمال: الويب وواجهات البرمجة والخدمات المصغّرة والحاويات وقواعد البيانات والطوابير. عمليًا، يترجَم الانتقال إلى ARM عادةً إلى وفورات في حدود <strong>20 % إلى 40 %</strong> من كلفة الحوسبة. وفي سحابة تزداد كلفتها، هذا هامش أكبر من أن يُتجاهل.</p> <h3 id="2-كفاءة-أعلى-وطاقة-أقل">2. كفاءة أعلى وطاقة أقل</h3> <p>وُلدت معالجات ARM وهي تُحسّن الاستهلاك. وهذا يعني عملًا أكبر لكل واط، وكلفة طاقة أقل، و<strong>بصمة كربونية أخفّ</strong> لكل وحدة حوسبة. وإن كانت الاستدامة ضمن أهدافك —أو أهداف عملائك— فإن ARM يلعب لصالحك.</p> <h3 id="3-المنظومة-صارت-ناضجة">3. المنظومة صارت ناضجة</h3> <p>قبل سنوات قليلة كان سؤال «هل توجد نسخة ARM؟» مشروعًا. أمّا اليوم فإن الغالبية العظمى من برمجيات الخوادم —أنظمة التشغيل واللغات وبيئات التشغيل وقواعد البيانات وصور الحاويات الشائعة— تدعم ARM64 دعمًا من الدرجة الأولى. لقد تحوّل التوافق من استثناء إلى قاعدة.</p> <h3 id="4-الأمان-ذاته-ونموذج-التشغيل-ذاته">4. الأمان ذاته ونموذج التشغيل ذاته</h3> <p>تغيير المعمارية لا يغيّر طريقة عملك: الإعداد والتحصين وcloud-init ونصوص التزويد وخطّ إنتاجك تبقى كما هي. لا يطلب منك ARM64 التنازل عن شيء في تشغيلك ولا في وضعك الأمني.</p> <h2 id="المقارنة-في-جدول-واحد">المقارنة في جدول واحد</h2> <table> <thead> <tr> <th>المعيار</th> <th>ARM64 (Graviton)</th> <th>x86_64 (Intel/AMD)</th> </tr> </thead> <tbody> <tr> <td>السعر مقابل الأداء</td> <td>أفضل في معظم الأحمال</td> <td>جيد، لكن أغلى لكل وحدة</td> </tr> <tr> <td>كفاءة الطاقة</td> <td>عالية جدًا</td> <td>أقل</td> </tr> <tr> <td>توافق البرمجيات</td> <td>ممتاز وواسع اليوم</td> <td>الأقصى، شامل</td> </tr> <tr> <td>الثنائيات المملوكة القديمة</td> <td>أحيانًا بلا نسخة ARM</td> <td>دعم كامل</td> </tr> <tr> <td>وجهة السوق</td> <td>متنامية واستراتيجية</td> <td>راسخة</td> </tr> <tr> <td>الكلفة المعتادة</td> <td>أقل: بين 20 % و40 %</td> <td>أعلى</td> </tr> </tbody> </table> <p><em>للأحمال الحديثة يفوز ARM64 في ما يهمّ أكثر: الكلفة والكفاءة والمستقبل.</em></p> <h2 id="متى-يظل-x86_64-منطقيا">متى يظلّ x86_64 منطقيًا</h2> <p>الصراحة جزء من حسن الاختيار. ثمة حالات يبقى فيها x86_64 هو الخيار الصحيح، ولا نريد لأحد أن يفرض على نفسه انتقالًا يعقّد حياته:</p> <ul> <li><strong>برمجيات مملوكة أو ثنائيات</strong> لا توجد إلا مُصرَّفة لـ x86.</li> <li><strong>تبعيات أصيلة</strong> —امتدادات مُصرَّفة— بلا بناء متاح لـ ARM.</li> <li><strong>أدوات قديمة</strong> أو تكاملات طرف ثالث مرتبطة بـ x86.</li> <li><strong>أحمال شديدة الخصوصية</strong> مُحسَّنة يدويًا لتعليمات x86.</li> </ul> <h2 id="قرارنا-arm64-افتراضيا-وx86_64-حسب-الطلب">قرارنا: ARM64 افتراضيًا وx86_64 حسب الطلب</h2> <p>لكل ما سبق، <strong>تُبنى صورنا على ARM64 افتراضيًا.</strong> نعتقد أن هذا ما يقدّم أكبر قيمة للأغلبية: تدفع أقل مقابل العمل نفسه، وتستهلك طاقة أقل، وتركب المعمارية التي ترسم مسار السحابة.</p> <p>لكننا نعلم أن ليست كل الأحمال تناسبها. لذلك <strong>إن احتجت x86_64 فيكفي أن تطلب: نجهّز لك صورة حسب الطلب</strong> بالإعداد نفسه والتحصين نفسه والجودة نفسها، مبنية لـ x86_64. المنتج ذاته والأساس ذاته، بالمعمارية التي تقتضيها حالتك.</p> <h2 id="كيف-تقرر-في-30-ثانية">كيف تقرّر في 30 ثانية</h2> <ul> <li>منظومة حديثة —ويب، واجهات برمجة، حاويات، لغات مفسَّرة، قواعد بيانات شائعة—: <strong>ARM64</strong> بلا تردّد.</li> <li>هل لديك ثنائي مملوك أو تبعية لا تعمل إلا على x86؟ <strong>اطلب منّا نسخة x86_64.</strong></li> <li>غير متأكد؟ ابدأ بـ ARM64 وجرّب؛ وإن لم يناسبك شيء، نصنع لك x86_64 وانتهى الأمر.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل صوركم بمعمارية ARM64 أم x86_64؟</strong></p> <p>نبنيها افتراضيًا على ARM64 (Graviton)، لأنها تقدّم أفضل نسبة سعر إلى أداء لمعظم الأحمال. وإن احتجت x86_64 نجهّز لك واحدة حسب الطلب بالإعداد والجودة نفسيهما.</p> <p><strong>هل عليّ تغيير تطبيقي لاستخدام ARM64؟</strong></p> <p>في معظم الحالات لا. اللغات المفسَّرة والبرمجيات الحديثة تعمل على ARM دون تغيير. الاحتكاك الوحيد يكون مع ثنائيات مملوكة أو تبعيات أصيلة بلا نسخة ARM؛ وفي تلك الحالات نقدّم لك نسخة x86_64.</p> <p><strong>كيف أطلب صورة x86_64 حسب الطلب؟</strong></p> <p>يكفي أن تطلبها. ننطلق من الأساس نفسه والتحصين نفسه ونبني الصورة لـ x86_64، فتحصل على المنتج ذاته تمامًا بالمعمارية التي تحتاجها.</p> <p><strong>هل سأوفّر فعلًا مع ARM64؟</strong></p> <p>للأحمال المناسبة، من المعتاد توفير 20 % إلى 40 % من كلفة الحوسبة، إضافةً إلى استهلاك طاقة أقل. وسبيل التأكد في حالتك هو تشغيل حِملك والمقارنة.</p> <p><em>في imaxe.cloud نراهن على ARM64 لأننا نراه الأفضل لفاتورتك ولأدائك وللكوكب. وإن احتجت x86_64 فيكفي أن تطلب: نصنعها لك حسب الطلب.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AA%D8%AD%D8%B3%D9%8A%D9%86-%D8%AD%D8%AC%D9%85-%D9%88%D8%A7%D9%82%D9%84%D8%A7%D8%B9-ami/2026-07-31T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/optimizar-tamano-arranque-ami_hu_69b1788d3fbcbc6c.webp" alt="ساعة إيقاف جيب على خلفية سوداء" width="1200" height="675"></p><p>يبدو حجم الصورة وزمن إقلاعها تفصيلًا تقنيًا، لكنهما يمسّان ثلاثة أمور تهمّ العمل فعلًا: <strong>سرعة التوسّع التلقائي</strong> —كم تستغرق للاستجابة لذروة—، و<strong>الكلفة</strong> —التخزين والحوسبة العاطلة في انتظار الإقلاع— و<strong>الأمن</strong>: برمجيات أقل تعني سطح هجوم أصغر.</p> <p>الصورة النحيفة السريعة هي، في الغالب الأعم، صورة أفضل.</p> <h2 id="تنحيف-الصورة-الأقل-أفضل">تنحيف الصورة: الأقل أفضل</h2> <ul> <li><strong>انطلق من أساس أدنى</strong>: استخدم نسخ <em>minimal</em> من نظام التشغيل بدل التثبيتات الكاملة.</li> <li><strong>ثبّت ما يلزم فقط</strong>: كل حزمة زائدة وزن وصيانة وسطح هجوم.</li> <li><strong>نظّف بعد البناء</strong>: احذف مخابئ الحزم (<code>dnf clean all</code> و<code>apt-get clean</code>) والسجلات والوثائق والملفات المؤقتة قبل الختم.</li> <li><strong>أزل أدوات البناء</strong>: إن كنت قد صرّفت شيئًا، فانزع المصرِّفات وتبعيات التطوير.</li> <li><strong>راجع حجم الوحدة التخزينية</strong>: لا تجرّ قرصًا بسعة 100 غيغابايت وبرمجياتك تشغل 8.</li> </ul> <h2 id="تسريع-الإقلاع">تسريع الإقلاع</h2> <ul> <li><strong>اخبز ولا تثبّت عند الإقلاع</strong>: كل ما تثبّته في user-data هو زمن إقلاع؛ انقله إلى الصورة.</li> <li><strong>خدمات دنيا عند البدء</strong>: عطّل ما لا تحتاجه في الإقلاع الأول.</li> <li><strong>حمّل التبعيات مسبقًا</strong>: وجود المشغّلات وبيئات التشغيل والحاويات الأساسية يجنّبك التنزيلات الأولى.</li> <li><strong>حسّن cloud-init</strong>: user-data صغير وحيادي التكرار يُقلع أسرع.</li> <li><strong>اللقطات والتزويد</strong>: استفد من خيارات السحابة لترطيب الوحدات التخزينية بسرعة أكبر.</li> </ul> <h2 id="الأثر-بالأرقام">الأثر بالأرقام</h2> <table> <thead> <tr> <th>الرافعة</th> <th>الأثر في التوسّع التلقائي</th> <th>الأثر في الكلفة والأمن</th> </tr> </thead> <tbody> <tr> <td>صورة أصغر</td> <td>نسخ وإطلاقات أسرع</td> <td>كلفة لقطات أقل وثغرات أقل</td> </tr> <tr> <td>إقلاع أسرع</td> <td>تستجيب للذروات مبكرًا</td> <td>حوسبة مدفوعة أقل بلا خدمة</td> </tr> <tr> <td>حزم أقل</td> <td>أقلّ ما يُحمَّل ويُهيَّأ</td> <td>سطح هجوم مُقلَّص</td> </tr> </tbody> </table> <p><em>تحسين الصورة يرفع الأداء ويخفض الكلفة ويعزّز الأمن في آن معًا.</em></p> <h2 id="لا-تفرط-في-الكبح">لا تُفرِط في الكبح</h2> <p>التحسين ليس بترًا. فحذف الزائد قد يكسر تبعيات دقيقة أو يعقّد التشخيص. والانضباط الصحيح: قِس الحجم وزمن الإقلاع ضمن خطّ إنتاجك، واقتطع بحكمة، وتحقّق دومًا في بيئة التهيئة، ووثّق ما أزلته ولماذا. عامل هذه المؤشرات كدلائل على جودة الصورة، لا كهوس.</p> <h2 id="قائمة-تحقق-للتحسين">قائمة تحقّق للتحسين</h2> <ul> <li>أساس أدنى لنظام التشغيل.</li> <li>الحزم الضرورية فقط.</li> <li>تنظيف المخابئ والسجلات والملفات المؤقتة قبل الختم.</li> <li>بلا أدوات تصريف في الصورة النهائية.</li> <li>user-data صغير؛ والثقيل مخبوز.</li> <li>حجم وحدة تخزينية مضبوط على الواقع.</li> <li>مؤشرات الحجم والإقلاع داخل خطّ الإنتاج.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>كم يمكن أن أسرّع الإقلاع بتحسين الصورة؟</strong></p> <p>يعتمد على نقطة البداية، لكن نقل عمليات التثبيت من user-data إلى الصورة وتقليل خدمات البدء يقصّر الإقلاع عادةً بشكل ملحوظ جدًا، وهو ما يحسّن مباشرةً قدرة توسّعك التلقائي على الاستجابة.</p> <p><strong>هل الصورة الأصغر أكثر أمانًا؟</strong></p> <p>عمومًا نعم: برمجيات مثبَّتة أقل تعني ثغرات محتملة أقل وسطح هجوم أضيق، فضلًا عن سهولة تدقيقها.</p> <p><strong>هل يستحق استخدام نظام تشغيل أدنى؟</strong></p> <p>لمعظم أحمال الخوادم نعم: يُقلع أسرع ويشغل أقل وهو أكثر أمانًا. فقط تجنّب التقليص إلى حدّ يعسّر التشخيص أو يكسر تبعيات تحتاجها فعلًا.</p> <p><em>في imaxe.cloud نحرص على أن تكون صورنا خفيفة وسريعة الإقلاع وسهلة الصيانة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%B5%D9%88%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-gpu-2026/2026-07-28T00:00:00Z2026-08-22T15:25:49Z

بناء بيئة ذكاء اصطناعي على وحدات GPU يدويًا مهرجانٌ من المشغّلات وإصدارات CUDA وأطر عمل لا تتوافق. وصورة مُعدّة جيدًا لوحدات GPU توفّر عليك أيامًا من العناء. هذا ما ينبغي أن تحمله صورة للذكاء الاصطناعي في 2026.

<p><img src="https://www.imaxe.cloud/blog-covers/imagenes-ia-gpu-2026_hu_57244b43363ee40d.webp" alt="بطاقة رسوميات بمشتّتها الحراري ومراوحها" width="1200" height="675"></p><p>مع كون الذكاء الاصطناعي في الإنتاج موضوع 2026 الكبير، تُطلق فرق أكثر فأكثر نسخًا مزوّدة بوحدات GPU لتدريب النماذج وتشغيل الاستدلال. لكن وحدة GPU لا تعمل وحدها: فهي تحتاج كومة برمجية محدّدة جدًا —<strong>مشغّل NVIDIA وCUDA وcuDNN وأطر العمل</strong>— بإصدارات يجب أن تتوافق فيما بينها. وإعداد ذلك كله يدويًا على كل نسخة بطيء وهشّ.</p> <p>من هنا تأتي قيمة <strong>صورة جاهزة لوحدات GPU</strong>: تغلّف تلك الكومة المُتحقَّق منها مرة واحدة وتُقلع جاهزةً للعمل.</p> <h2 id="ماذا-ينبغي-أن-تحمل-صورة-للذكاء-الاصطناعي">ماذا ينبغي أن تحمل صورة للذكاء الاصطناعي</h2> <ul> <li><strong>مشغّل NVIDIA</strong> متوافق مع وحدة GPU المستهدَفة، كتلك التي في عائلات النسخ المُسرَّعة.</li> <li><strong>CUDA وcuDNN</strong> بإصدارات متوائمة مع أطر العمل التي ستستخدمها.</li> <li><strong>أطر عمل</strong> مثل PyTorch أو TensorFlow، أو الأفضل <strong>NVIDIA Container Toolkit</strong> لتشغيلها داخل حاويات.</li> <li><strong>أدوات MLOps</strong> ومراقبة وحدات GPU، مثل DCGM، مثبّتة مسبقًا.</li> <li><strong>تحسين الإقلاع</strong>: مشغّلات محمَّلة مسبقًا كي لا تضيّع دقائق —ومالًا مدفوعًا لوحدة GPU— في كل إطلاق.</li> </ul> <h2 id="أن-تبني-أم-تستخدم-صورة-جاهزة">أن تبني أم تستخدم صورة جاهزة</h2> <table> <thead> <tr> <th>الخيار</th> <th>الميزة</th> <th>المقابل</th> </tr> </thead> <tbody> <tr> <td>صورة GPU رسمية (NVIDIA GPU-Optimized وDeep Learning)</td> <td>كومة مُتحقَّق منها ومصانة</td> <td>تحكّم أقل بالإصدارات</td> </tr> <tr> <td>صورة مخصّصة</td> <td>تحكّم كامل بالإصدارات والتحصين</td> <td>الصيانة على عاتقك</td> </tr> <tr> <td>حاويات GPU فوق صورة أساسية</td> <td>قابلية النقل وإمكان التكرار</td> <td>تتطلّب الأدوات وعُقدًا فيها المشغّل</td> </tr> </tbody> </table> <p><em>اختر بحسب مقدار التحكّم بالإصدارات والصيانة الذي تريد تحمّله.</em></p> <h2 id="الكلفة-هي-الحاكم-وحدة-gpu-باهظة">الكلفة هي الحاكم: وحدة GPU باهظة</h2> <p>زمن وحدة GPU هو أغلى مورد في فاتورة الذكاء الاصطناعي لديك، وخفض <strong>الخمول في وحدات GPU</strong> من أولويات 2026. والصورة تؤثّر في هذا مباشرة:</p> <ul> <li><strong>إقلاع سريع</strong>: صورة بمشغّلات وتبعيات جاهزة تتفادى دقائق من وحدة GPU مدفوعة بلا عمل.</li> <li><strong>حاويات GPU</strong>: تحزم بيئة النموذج لإعادة إنتاجها فورًا على أي عقدة فيها المشغّل.</li> <li><strong>الاستدلال على الحافة</strong>: صور خفيفة لتقريب النماذج من البيانات وخفض الكمون والكلفة.</li> <li><strong>التوسّع والنسخ الفورية</strong>: امزج صورًا جاهزة بنسخ spot لتخفيض كلفة الأحمال المحتمِلة للانقطاع.</li> </ul> <h2 id="ممارسات-جيدة">ممارسات جيدة</h2> <ul> <li>ثبّت ووثّق <strong>إصدارات</strong> المشغّل وCUDA وإطار العمل: فالتوافق هشّ.</li> <li>أبقِ الصورة <strong>محدَّثة</strong> أمام ترقيعات أمان المشغّل ونظام التشغيل.</li> <li>افصل <strong>طبقة المنصّة</strong> —المشغّل والأدوات— عن <strong>طبقة النموذج</strong> —الحاوية— كي تكرّر بسرعة.</li> <li>قِس <strong>كلفة الاستدلال الواحد</strong> وحسّن الصورة ونوع النسخة تبعًا لذلك.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل أستخدم صورة Deep Learning رسمية أم أبني صورتي؟</strong></p> <p>الصور الرسمية لوحدات GPU توفّر وقتًا هائلًا وتأتي بالكومة المُتحقَّق منها. ابنِ صورتك إن احتجت إصدارات بعينها أو تحصينًا خاصًا أو امتثالًا صارمًا.</p> <p><strong>لماذا يهمّ الإقلاع السريع كثيرًا مع وحدات GPU؟</strong></p> <p>لأن وحدة GPU أغلى مورد: فكل دقيقة تقضيها نسخة GPU في تثبيت المشغّلات مالٌ مدفوع بلا إنتاج. وصورة بكل شيء مثبَّت مسبقًا تقلّص ذلك الهدر.</p> <p><strong>حاويات أم تثبيت مباشر للذكاء الاصطناعي على GPU؟</strong></p> <p>حاويات GPU مع NVIDIA Container Toolkit تمنح إمكان التكرار وقابلية النقل، وهي الممارسة الموصى بها. وتشترط أن تحمل العقدة المشغّل، وهو ما تحلّه صورة أساسية جيدة.</p> <p><em>في imaxe.cloud نتابع عن كثب تطوّر أحمال الذكاء الاصطناعي كي توفّر عليك صورنا جحيم المشغّلات والإقلاع البطيء.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AA%D9%88%D9%81%D9%8A%D8%B1-arm-graviton/2026-07-24T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/arm-graviton-ahorro_hu_564873198e07c9a3.webp" alt="شريحة Exynos مركّبة على لوحة أم" width="1200" height="675"></p><p>أصبحت المعالجات المبنية على ARM، مثل <strong>AWS Graviton</strong>، خيارًا من الدرجة الأولى لأحمال الإنتاج. عرضها بسيط وقوي: <strong>نسبة سعر إلى أداء أفضل</strong> من بدائل x86 التقليدية لكثير من الأحمال، مع استهلاك طاقة أقل.</p> <p>وفي سياق سحابي يزداد كلفةً —وهو أحد كبرى اتجاهات 2026— يمثّل الانتقال إلى ARM واحدًا من أنجع روافع التوفير ضمن استراتيجية FinOps.</p> <h2 id="كم-يمكن-أن-توفر">كم يمكن أن توفّر</h2> <p>تتباين الأرقام بحسب الحِمل، لكن القطاع يبلّغ باستمرار عن وفورات معتبرة عند الانتقال إلى Graviton، في حدود <strong>20 % إلى 40 %</strong> من كلفة الحوسبة للأحمال المناسبة، بفضل سعر أفضل لكل vCPU وكفاءة أعلى. ليست سحرًا: عليك التحقق بحِملك الحقيقي، لكن الإمكانات كبيرة وغالبًا ما تكون أموالًا متروكة على الطاولة.</p> <h2 id="ما-ينتقل-بسلاسة-وما-يحتاج-عناية">ما ينتقل بسلاسة وما يحتاج عناية</h2> <table> <thead> <tr> <th>ينتقل بسلاسة</th> <th>يحتاج تحقّقًا</th> </tr> </thead> <tbody> <tr> <td>اللغات المفسَّرة: Python وNode وJava وGo</td> <td>ثنائيات مُصرَّفة لـ x86 فقط</td> </tr> <tr> <td>الحاويات ذات الصور متعددة المعماريات</td> <td>تبعيات أصيلة بلا بناء لـ ARM</td> </tr> <tr> <td>الويب وواجهات البرمجة والخدمات المصغّرة</td> <td>برمجيات مملوكة بلا نسخة ARM</td> </tr> <tr> <td>قواعد البيانات وذواكر التخزين الشائعة</td> <td>مشغّلات أو امتدادات خاصة</td> </tr> </tbody> </table> <p><em>معظم الأحمال الحديثة تنتقل بلا دراما؛ راقب التبعيات الأصيلة.</em></p> <h2 id="دور-الصور-متعددة-المعماريات">دور الصور متعددة المعماريات</h2> <p>مفتاح انتقال نظيف هو بناء صورك لـ <strong>كلتا المعماريتين</strong>، x86_64 وarm64. في عالم الحاويات تتيح الصور <em>multi-arch</em> أن يعمل الوسم نفسه على أيٍّ منهما. وفي عالم صور AMI يحسن أن يكون خطّ إنتاجك —Packer أو EC2 Image Builder— جاهزًا لإنتاج الصورة بمعمارية arm64 إلى جانب x86، بإعادة استخدام المزوّدات نفسها.</p> <h2 id="خطة-انتقال-في-خمس-خطوات">خطة انتقال في خمس خطوات</h2> <ol> <li><strong>افحص جردًا</strong> أحمالك واكتشف التبعيات التي قد لا تتوفّر لها نسخة ARM.</li> <li><strong>ابنِ صور arm64</strong> في خطّ إنتاجك، بالتوازي مع صور x86.</li> <li><strong>اختبر</strong> في بيئة التهيئة: الأداء والتوافق والنتائج الوظيفية.</li> <li><strong>انتقل على مراحل</strong> بأسلوب canary أو blue/green، مع قياس الكلفة والأداء الفعليين.</li> <li><strong>حسِّن</strong>: اضبط نوع نسخة Graviton بما يلائم ملمح الحِمل.</li> </ol> <h2 id="arm-أيضا-في-azure-وgcp">ARM أيضًا في Azure وGCP</h2> <p>الاتجاه لا يخصّ AWS وحدها. فـ Azure تقدّم آلات مبنية على ARM —Cobalt وأخرى من الشركاء— ولدى Google Cloud نسخ ARM مثل Axion وTau T2A. وإذا صمّمت صورك كشيفرة ولمعماريات متعددة، تكسب حرية اقتناص أفضل نسبة سعر إلى أداء في أي سحابة.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>كم سأوفّر تحديدًا مع Graviton؟</strong></p> <p>يعتمد على حِملك، لكن من المعتاد رؤية وفورات من 20 % إلى 40 % في كلفة الحوسبة للأحمال المناسبة. والسبيل الوحيد لليقين هو تشغيل حِملك الحقيقي على نسخ ARM والمقارنة.</p> <p><strong>هل عليّ إعادة كتابة تطبيقي لأجل ARM؟</strong></p> <p>نادرًا. اللغات المفسَّرة ومعظم البرمجيات الحديثة تعمل على ARM دون تغيير. يظهر العمل مع الثنائيات المُصرَّفة لـ x86 فقط أو التبعيات الأصيلة بلا نسخة ARM.</p> <p><strong>هل يمكن أن تكون لديّ صور تعمل على x86 وARM معًا؟</strong></p> <p>نعم: بصور حاويات متعددة المعماريات وخطوط إنتاج AMI تُخرِج النسختين. هكذا تنتقل تدريجيًا دون أن تحبس نفسك.</p> <p><em>في imaxe.cloud نصمّم صورنا لاستثمار أفضل ما في كل معمارية ومساعدتك على تحسين الكلفة والأداء.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AA%D8%B1%D8%AD%D9%8A%D9%84-ami-%D8%A8%D8%AF%D9%88%D9%86-%D8%AA%D9%88%D9%82%D9%81/2026-07-21T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/migrar-ami-sin-downtime_hu_1ed2f0ccb833f256.webp" alt="ذراع تحويل مسار بجوار سكة حديد" width="1200" height="675"></p><p>تغيير الصورة التي تستخدمها نسخك يعادل تبديل أساس خدمتك وهي ما تزال تعمل. فإن أسأت الأمر كانت النتيجة انقطاعات؛ وإن أحسنته كان شبه غير مرئي للمستخدم. والخبر الجيد أن هناك أنماطًا مجرَّبة تجعل هذا الانتقال آمنًا وقابلًا للعكس.</p> <p>والأساس المشترك ألّا تعدّل نسخًا حيّة، بل أن <strong>تُطلق نسخًا جديدة بالصورة الجديدة</strong> وتنقل حركة المرور بصورة مضبوطة.</p> <h2 id="قبل-الانتقال-هيئ-الأرضية">قبل الانتقال: هيّئ الأرضية</h2> <ul> <li><strong>اختبر الصورة الجديدة</strong> في بيئة تهيئة مطابقة للإنتاج.</li> <li><strong>فحوص سلامة موثوقة</strong>: عرّف اختبارات تؤكّد أن النسخة الجديدة سليمة فعلًا.</li> <li><strong>خطة تراجع</strong>: أبقِ الإصدار السابق وإجراء العودة إليه جاهزَين.</li> <li><strong>قابلية الرصد</strong>: مقاييس وتنبيهات لاكتشاف التراجعات فورًا.</li> </ul> <h2 id="استراتيجيات-انتقال-بلا-توقف">استراتيجيات انتقال بلا توقّف</h2> <table> <thead> <tr> <th>الاستراتيجية</th> <th>كيف تعمل</th> <th>مثالية لـ</th> </tr> </thead> <tbody> <tr> <td>تحديث تدريجي</td> <td>يستبدل النسخ على دفعات، شيئًا فشيئًا</td> <td>خدمات ضمن مجموعة توسّع تلقائي</td> </tr> <tr> <td>Blue/Green</td> <td>تُقيم بيئة جديدة ثم تحوّل حركة المرور دفعة واحدة</td> <td>انتقالات بتراجع فوري</td> </tr> <tr> <td>Canary</td> <td>ترسل نسبة صغيرة من حركة المرور إلى الإصدار الجديد</td> <td>التحقّق في الإنتاج بمخاطرة منخفضة</td> </tr> </tbody> </table> <p><em>ثلاثة أنماط لتغيير الصورة دون قطع الخدمة.</em></p> <h3 id="تحديث-تدريجي">تحديث تدريجي</h3> <p>تحدّث قالب الإطلاق بالصورة الجديدة، فتستبدل مجموعة التوسّع التلقائي النسخ على موجات: تُطلق جديدة، وتنتظر اجتيازها فحص السلامة، ثم تسحب القديمة. بسيط وبلا بنية إضافية، وإن تعايش الإصداران فترةً من الوقت.</p> <h3 id="bluegreen">Blue/Green</h3> <p>تُقيم بيئة موازية (<em>green</em>) بالصورة الجديدة بينما تواصل الحالية (<em>blue</em>) الخدمة. وحين تُعتمد green، تعيد توجيه حركة المرور في موزّع الأحمال أو في نظام أسماء النطاقات. وإن أخفق شيء، عدت إلى blue في ثوانٍ. إنه النمط الأسرع تراجعًا، مقابل مضاعفة الموارد مؤقتًا.</p> <h3 id="canary">Canary</h3> <p>ترسل جزءًا صغيرًا من حركة المرور إلى نسخ بالصورة الجديدة وتراقب. فإن ثبتت المقاييس، رفعت النسبة تدريجيًا حتى 100 %. وهذا يقلّص نطاق أثر أي مشكلة غير متوقّعة.</p> <h2 id="بعد-الانتقال">بعد الانتقال</h2> <ul> <li>راقب المقاييس والسجلات مدةً معقولة قبل اعتماد الانتقال ناجحًا.</li> <li>علّم الصورة القديمة بأنها <strong>مهملة</strong> كي لا يُعاد إطلاقها بالخطأ.</li> <li>وثّق الإصدار المنشور وسبب التغيير.</li> <li>لا تحذف الصورة السابقة فورًا: احتفظ بها تحسّبًا للحاجة إلى التراجع.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>أي استراتيجية أفضل لانعدام التوقّف؟</strong></p> <p>يوفّر blue/green أسرع تراجع؛ والتحديث التدريجي أبسط وأقل كلفة؛ وcanary يقلّل المخاطرة بالتحقّق في الإنتاج. والاختيار يعتمد على تحمّلك للمخاطر وعلى ميزانية بنيتك التحتية.</p> <p><strong>هل عليّ مضاعفة البنية التحتية للانتقال؟</strong></p> <p>فقط مع blue/green، وبشكل مؤقت. أما مع التحديث التدريجي أو canary فتعيد استخدام المجموعة نفسها وتستبدل النسخ تباعًا، دون مضاعفة البيئة كلها.</p> <p><strong>كيف أضمن إمكان العودة؟</strong></p> <p>احتفظ بالصورة السابقة وقالب إطلاقها، وعرّف فحوص سلامة موثوقة، واختبر إجراء التراجع قبل بدء الانتقال.</p> <p><em>في imaxe.cloud نرقّم إصدارات صورنا كي يكون الانتقال بين الإصدارات متوقَّعًا وقابلًا للعكس.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/byol-%D9%85%D9%82%D8%A7%D8%A8%D9%84-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%B3%D8%A7%D8%B9%D8%A9/2026-07-17T00:00:00Z2026-08-22T15:25:49Z

هل تُحضر ترخيصك الخاص أم تدفع بالساعة عند استخدام صورة؟ الجواب يغيّر فاتورتك ومرونتك والتزاماتك القانونية. يساعدك هذا الدليل على اختيار النموذج الذي يناسبك فعلًا.

<p><img src="https://www.imaxe.cloud/blog-covers/byol-vs-pago-por-hora_hu_5e9a1e84b468f504.webp" alt="عملات معدنية وأوراق نقدية باليورو على طاولة" width="1200" height="675"></p><p>عندما تُطلق نسخة من صورة AMI، قد تكون هناك —إلى جانب كلفة الحوسبة أي نسخة EC2— كلفة مرتبطة بـ<strong>برمجيات</strong> الصورة. وتنتظم تلك الكلفة أساسًا في ثلاثة نماذج: مجاني (مفتوح المصدر)، والدفع بالساعة مضمَّنًا مع النسخة، وBYOL (أحضر ترخيصك الخاص).</p> <p>فهم الفرق يجنّبك مفاجآت الفاتورة ومشكلات الامتثال للتراخيص.</p> <h2 id="النماذج-بوضوح">النماذج بوضوح</h2> <table> <thead> <tr> <th>النموذج</th> <th>كيف تدفع</th> <th>الميزة الأساسية</th> </tr> </thead> <tbody> <tr> <td>مجاني أو مفتوح المصدر</td> <td>تدفع ثمن النسخة فقط</td> <td>كلفة دنيا بلا ترخيص برمجيات</td> </tr> <tr> <td>الدفع بالساعة (PAYG)</td> <td>تُفوتر البرمجيات بساعة الاستخدام</td> <td>بلا التزام: توسّع ثم أطفئ</td> </tr> <tr> <td>BYOL</td> <td>تعيد استخدام ترخيص تملكه أصلًا</td> <td>تستثمر ما أنفقته سابقًا وتحتفظ بالتحكّم</td> </tr> </tbody> </table> <p><em>نماذج كلفة البرمجيات الثلاثة في صورة الآلة.</em></p> <h2 id="الدفع-بالساعة-المرونة-قبل-كل-شيء">الدفع بالساعة: المرونة قبل كل شيء</h2> <p>في نموذج الدفع حسب الاستخدام تُضاف كلفة البرمجيات إلى كلفة النسخة وتُفوتر بالساعة أو بالثانية. وهو مثالي حين يكون حِملك متغيّرًا أو غير متوقَّع: لا التزام مبدئي، وتتوسّع عند الحاجة، وتتوقّف عن الدفع بمجرد الإطفاء. المقابل أن الاستخدام المكثّف والثابت قد يكلّف على المدى الطويل أكثر من استهلاك ترخيص تملكه.</p> <ul> <li><strong>لصالحه</strong>: صفر استثمار مبدئي، مرونة كاملة، وصيانة ودعم مشمولان غالبًا.</li> <li><strong>ضدّه</strong>: كلفة بالساعة قد تتجاوز، عند التشغيل على مدار الساعة، كلفة ترخيص مُستهلَك.</li> </ul> <h2 id="byol-استثمر-ما-لديك-أصلا">BYOL: استثمر ما لديك أصلًا</h2> <p>مع <strong>Bring Your Own License</strong> تعيد استخدام ترخيص تملكه —من اتفاق مؤسسي مثلًا— فوق صورة في السحابة. قد يخفّض ذلك التكاليف إن كنت قد استثمرت في التراخيص، لكنه يحمل مسؤوليات: عليك الالتزام بشروط الشركة المصنّعة، ومراقبة قابلية نقل الترخيص إلى السحابة، وإدارة الامتثال بنفسك.</p> <ul> <li><strong>لصالحه</strong>: يستثمر إنفاقًا سابقًا، وفورات محتملة مع الاستخدام الثابت، واستمرارية مع مزوّدك.</li> <li><strong>ضدّه</strong>: تعقيد الامتثال، وخطر تدقيق الشركة المصنّعة، والإدارة على عاتقك.</li> </ul> <h2 id="تكاليف-خفية-عليك-مراقبتها">تكاليف خفيّة عليك مراقبتها</h2> <ul> <li><strong>التخزين</strong>: لقطات EBS الخاصة بالصورة لها كلفة، حتى لو كانت البرمجيات مجانية.</li> <li><strong>نقل البيانات</strong> بين المناطق أو نحو الإنترنت.</li> <li><strong>الدعم</strong>: هل هو مشمول في سعر الساعة أم منفصل؟</li> <li><strong>نوع النسخة</strong>: قد تتطلّب البرمجيات نسخًا أكبر، فترتفع كلفة الحوسبة.</li> <li><strong>قابلية نقل الترخيص</strong>: بعض تراخيص BYOL تشترط استضافة مخصّصة، وهي أغلى.</li> </ul> <h2 id="كيف-تقرر">كيف تقرّر</h2> <p>القاعدة العملية: للأحمال <strong>المتغيّرة أو قصيرة الأمد</strong> يفوز الدفع بالساعة عادةً بالمرونة. أما للأحمال <strong>الثابتة على مدار الساعة وطويلة العمر</strong> فقد يخفّض استهلاك ترخيص أو حجز طاقة الكلفة الإجمالية. احسب بملمح استخدامك الحقيقي —لا بأسوأ الحالات— ولا تنسَ إدراج التكاليف الخفيّة.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>أيّهما أرخص، BYOL أم الدفع بالساعة؟</strong></p> <p>يعتمد على استخدامك. يفوز الدفع بالساعة مع الأحمال المتغيّرة أو المتقطّعة؛ وقد يكون BYOL أجدى مع استخدام ثابت على مدار الساعة إن كانت لديك تراخيص تستهلكها أصلًا.</p> <p><strong>هل تعني البرمجيات المجانية في صورة AMI كلفة صفرية؟</strong></p> <p>ليس تمامًا: حتى لو كانت البرمجيات مفتوحة المصدر، تظل تدفع ثمن النسخة وتخزين اللقطات ونقل البيانات.</p> <p><strong>ما المخاطر القانونية في BYOL؟</strong></p> <p>عليك الالتزام بشروط الشركة المصنّعة بشأن الاستخدام في السحابة وقابلية نقل الترخيص. وقد يظهر أي إخلال في تدقيق، لذا يُستحسن مراجعة الشروط جيدًا.</p> <p><em>في imaxe.cloud نساعدك على فهم نموذج كلفة كل صورة كي تختار وأرقامك واضحة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D9%81%D9%8A-ami/2026-07-14T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/gestion-secretos-ami_hu_ed7ffbea445a9c3c.webp" alt="باب مصفّح لخزنة مصرف" width="1200" height="675"></p><p>حين تضمّن بيانات اعتماد داخل صورة AMI، فإنها تنتشر مع كل نسخة من الصورة، وتبقى محفورة في اللقطات، وقد تنتهي في حسابات أو مناطق لم تتخيّلها يومًا. يكفي أن يستخرجها شخص لديه إذن قراءة على الصورة. ولأن الصور تُحفظ بإصداراتها، قد يعيش السرّ طويلًا بعد أن ظننت أنك دوّرته.</p> <p>القاعدة الذهبية: <strong>الصورة تحدّد الآلة؛ أما الأسرار فتُسلَّم وقت التشغيل</strong>.</p> <h2 id="أين-ينبغي-أن-تعيش-الأسرار">أين ينبغي أن تعيش الأسرار</h2> <table> <thead> <tr> <th>الخدمة</th> <th>السحابة أو البيئة</th> <th>مثالية لـ</th> </tr> </thead> <tbody> <tr> <td>AWS Secrets Manager</td> <td>AWS</td> <td>بيانات اعتماد قابلة للتدوير وتكامل أصيل</td> </tr> <tr> <td>AWS SSM Parameter Store</td> <td>AWS</td> <td>معاملات وأسرار بسيطة بكلفة منخفضة</td> </tr> <tr> <td>HashiCorp Vault</td> <td>متعدّد السحابات</td> <td>أسرار ديناميكية وتحكّم دقيق</td> </tr> <tr> <td>Azure Key Vault / Google Secret Manager</td> <td>Azure / GCP</td> <td>نظائر أصيلة في كل سحابة</td> </tr> </tbody> </table> <p><em>احفظ الأسرار في مدير مخصّص، لا في الصورة ولا في user-data بنصّ صريح.</em></p> <h2 id="النمط-الصحيح-هوية-لا-كلمات-مرور">النمط الصحيح: هوية لا كلمات مرور</h2> <p>أأمن طريقة لتصل نسخة إلى الموارد ليست منحها كلمة مرور، بل منحها <strong>هوية</strong>. ففي AWS، يتيح <strong>دور IAM</strong> مرتبط بالنسخة الحصول على بيانات اعتماد مؤقتة تُدوَّر تلقائيًا، دون أن يسافر أي مفتاح داخل الصورة.</p> <ul> <li><strong>أدوار IAM للنسخ</strong>: تتقمّص النسخة دورًا وتحصل على بيانات اعتماد مؤقتة.</li> <li><strong>IRSA في Kubernetes</strong>: هوية لكل حاوية، بلا مفاتيح مشتركة على العقدة.</li> <li><strong>أسرار ديناميكية مع Vault</strong>: بيانات اعتماد قصيرة العمر تُولَّد عند الطلب.</li> <li><strong>حقن وقت التشغيل</strong>: يقرأ التطبيق السرّ من المدير عند الإقلاع، لا من ملف مخبوز.</li> </ul> <h2 id="احم-البيانات-الوصفية-imdsv2">احمِ البيانات الوصفية: IMDSv2</h2> <p>تُجلَب بيانات الاعتماد المؤقتة للدور عبر خدمة البيانات الوصفية للنسخة. وقد يحاول مهاجم يستغلّ ثغرة SSRF سرقتها. يشترط <strong>IMDSv2</strong> رمز جلسة ويخفّف من هذا الصنف من الهجمات: اجعله إلزاميًا في عمليات إطلاقك.</p> <h2 id="نظافة-لا-تترك-آثارا-في-الصورة">نظافة: لا تترك آثارًا في الصورة</h2> <ul> <li>قبل ختم الصورة، <strong>احذف</strong> سجلات الصدفة والسجلات الحاوية على بيانات اعتماد ومفاتيح SSH المؤقتة وملفات الإعداد التي تحوي أسرارًا.</li> <li>افحص الصورة بحثًا عن <strong>أسرار</strong> بأدوات مثل gitleaks أو trufflehog مهيّأة لأنظمة الملفات.</li> <li>لا تترك <strong>مفاتيح مصرّحًا بها</strong> زائدة في <code>~/.ssh/authorized_keys</code>.</li> <li>تجنّب <strong>الصور العامة</strong> التي تحوي أسرارًا: وإن نشرت، فتأكّد أنك لا تسرّب شيئًا.</li> </ul> <h2 id="قائمة-تحقق-سريعة">قائمة تحقّق سريعة</h2> <ul> <li>صفر أسرار مخبوزة في الصورة.</li> <li>مدير أسرار مع أدوار أو هوية موحّدة.</li> <li>IMDSv2 إلزامي.</li> <li>فحص للأسرار داخل خطّ الإنتاج.</li> <li>تنظيف الآثار قبل الختم.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>وماذا لو احتاج تطبيقي السرّ عند الإقلاع؟</strong></p> <p>فليقرأه من مدير الأسرار وقت التشغيل مستخدمًا هوية النسخة. هكذا لا يسافر السرّ داخل الصورة أبدًا ويمكن تدويره دون إعادة بناء.</p> <p><strong>هل استخدام user-data لتمرير الأسرار آمن؟</strong></p> <p>ليس بنصّ صريح: فهو مقروء من البيانات الوصفية. استخدمه على الأكثر للإشارة إلى أي سرّ يُجلَب من المدير، مع حماية البيانات الوصفية بـ IMDSv2.</p> <p><strong>كيف أكتشف إن كانت الصورة تحوي أسرارًا مخبوزة؟</strong></p> <p>بفحصها بأدوات كشف الأسرار على نظام ملفاتها، ومراجعة ملفات الإعداد والسجلات والمفاتيح المصرّح بها قبل استخدامها.</p> <p><em>في imaxe.cloud نبني صورًا خالية من بيانات الاعتماد ومصمّمة للتكامل مع مديري الأسرار والهوية الموحّدة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/sbom-%D9%84%D8%B5%D9%88%D8%B1-%D8%A7%D9%84%D8%A7%D8%AC%D9%87%D8%B2%D8%A9/2026-07-10T00:00:00Z2026-08-22T15:25:49Z

حين تظهر الثغرة الحرجة التالية سيكون السؤال: «هل أنا متأثّر؟». بلا SBOM يستغرق الجواب أيامًا من البحث اليدوي. ومعه، ثوانٍ. نشرح ما هو وكيف تولّده لصورك.

<p><img src="https://www.imaxe.cloud/blog-covers/sbom-imagenes-de-maquina_hu_ffc36a1f6a89fff9.webp" alt="رفوف مستودع بمنصّات مكدّسة ومجرودة" width="1200" height="675"></p><p><strong>SBOM</strong> (<em>Software Bill of Materials</em>) هو «قائمة مكوّنات» برمجياتك: الجرد الكامل للحزم والمكتبات والإصدارات والتبعيات التي تحتويها الصورة. وكبطاقة القيمة الغذائية، يخبرك بدقّة بما في الداخل.</p> <p>وتتّضح قيمته يوم ظهور ثغرة حرجة: فبدل تتبّع عشرات الصور يدويًا، تستعلم من SBOM فتعرف خلال ثوانٍ أي الصور تحوي المكوّن المصاب وبأي إصدار.</p> <h2 id="لماذا-يهم-صورك">لماذا يهمّ صورك</h2> <ul> <li><strong>استجابة سريعة للثغرات</strong>: تعرف فورًا إن كانت ثغرة جديدة تمسّك.</li> <li><strong>أمن سلسلة التوريد</strong>: تعرف من أين جاء كل مكوّن.</li> <li><strong>الامتثال</strong>: تطلبه أطر وعملاء أكثر فأكثر كدليل.</li> <li><strong>الشفافية</strong>: إن كنت تنشر صورًا، فإن SBOM يبني ثقة من يستخدمها.</li> </ul> <h2 id="الصيغ-المعيارية">الصيغ المعيارية</h2> <table> <thead> <tr> <th>الصيغة</th> <th>المصدر</th> <th>ملاحظات</th> </tr> </thead> <tbody> <tr> <td>SPDX</td> <td>مؤسسة لينكس / ISO</td> <td>معيار ISO، شائع الاستخدام في الامتثال</td> </tr> <tr> <td>CycloneDX</td> <td>OWASP</td> <td>موجَّه للأمن، غنيّ لتحليل الثغرات</td> </tr> </tbody> </table> <p><em>الصيغتان الأكثر شيوعًا لـ SBOM؛ وكثير من الأدوات تصدّر إليهما معًا.</em></p> <h2 id="كيف-تولد-sbom-لصورة-خطوة-بخطوة">كيف تولّد SBOM لصورة، خطوة بخطوة</h2> <ol> <li><strong>اختر الأداة</strong>: يُعدّ Syft من Anchore معيارًا فعليًا لتوليد SBOM للصور وأنظمة الملفات؛ وثمة خيارات أصيلة في السحابة أيضًا.</li> <li><strong>ولّده داخل خطّ الإنتاج</strong>: أثناء بناء الصورة، افحص نظام الملفات وأخرج SBOM، بصيغتَي CycloneDX وSPDX مثلًا.</li> <li><strong>حلّل الثغرات</strong>: مرّر SBOM عبر Grype أو Trivy لمطابقته مع قواعد بيانات الثغرات.</li> <li><strong>وقّع وأرشِف</strong>: وقّع SBOM —بـ cosign مثلًا— واحفظه كمخرج مرتبط بإصدار الصورة.</li> <li><strong>استعلم عند الحاجة</strong>: أمام ثغرة جديدة، راجع نسخ SBOM المؤرشفة لتعرف نطاق الأثر.</li> </ol> <h2 id="السياق-التنظيمي-لعام-2026">السياق التنظيمي لعام 2026</h2> <p>يكتسب SBOM ثقلًا منذ سنوات كممارسة جيدة لأمن سلسلة التوريد. غير أن المشهد التنظيمي دقيق: ففي الولايات المتحدة راجعت الإدارة عام 2026 متطلبات إثبات البرمجيات الموروثة نحو نهج أكثر استنادًا إلى المخاطر، بينما تدفع في الاتحاد الأوروبي أنظمة مثل قانون المرونة السيبرانية نحو شفافية البرمجيات وجرد المكوّنات. والخلاصة العملية: بصرف النظر عن تقلّبات التنظيم، امتلاك SBOM ميزة دفاعية وتجارية يُستحسن تبنّيها.</p> <h2 id="ممارسات-جيدة">ممارسات جيدة</h2> <ul> <li>ولّد SBOM <strong>آليًا</strong> في كل عملية بناء، لا يدويًا.</li> <li>احفظه <strong>مُرقَّم الإصدار</strong> إلى جانب الصورة التي يخصّها.</li> <li>ادمجه مع <strong>فحص الثغرات</strong> كي يصبح قابلًا للتنفيذ.</li> <li>وقّعه لضمان <strong>سلامته</strong> ومصدره.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل SBOM هو نفسه فحص الثغرات؟</strong></p> <p>لا. فـ SBOM جرد للمكوّنات؛ أما الفحص فيطابق ذلك الجرد مع قواعد الثغرات لاكتشافها. وهما متكاملان: أولًا تعرف ما لديك، ثم تعرف إن كان مصابًا.</p> <p><strong>SPDX أم CycloneDX؟</strong></p> <p>SPDX معيار ISO شائع في الامتثال؛ وCycloneDX أكثر توجّهًا للأمن. وكثير من الأدوات تصدّر إليهما معًا، فلا داعي لاختيار واحد فقط.</p> <p><strong>هل أحتاج SBOM إن كنت أستهلك صور الآخرين فقط؟</strong></p> <p>نعم. فطلب SBOM للصور التي تستخدمها أو توليده يتيح لك تقييم مخاطرها والاستجابة سريعًا للثغرات، حتى وإن لم تكن أنت من بناها.</p> <p><em>في imaxe.cloud نراهن على التتبّع: فجرد برمجيات صورنا وتوثيقها جزء من بنائها كما ينبغي.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/cloud-init-user-data/2026-07-07T00:00:00Z2026-08-22T15:25:49Z

صورة golden AMI تحلّ الثابت؛ وcloud-init يحلّ المتغيّر. إتقان user-data وcloud-init هو ما يتيح لك استخدام الصورة ذاتها في ألف سيناريو دون إعادة خبزها. إليك الدليل العملي.

<p><img src="https://www.imaxe.cloud/blog-covers/cloud-init-user-data_hu_6c8986f026962556.webp" alt="حاسوب محمول يعرض تحديث النظام في طرفية" width="1200" height="675"></p><p><strong>cloud-init</strong> هو المعيار الفعلي لتهيئة النسخ السحابية خلال إقلاعها الأول. فحين تُطلق نسخة وتمرّر إليها نصّ <strong>user-data</strong>، يكون cloud-init هو من يفسّره وينفّذه: ينشئ المستخدمين ويكتب الملفات ويثبّت الحزم ويركّب الأقراص ويشغّل الخدمات.</p> <p>المزيج المثالي واضح: <strong>صورة golden AMI</strong> تحتوي ما لا يتغيّر —نظام التشغيل وبيئة التشغيل والتحصين— بينما يقدّم <strong>user-data</strong> ما يتغيّر بحسب البيئة أو النسخة: الإعداد والأسرار المحقونة والدور. هكذا تعيد استخدام صورة واحدة في سياقات كثيرة.</p> <h2 id="طريقتان-لكتابة-user-data">طريقتان لكتابة user-data</h2> <p>يقبل user-data صيغًا عدة؛ وأشهرها اثنتان: نصّ الصدفة وcloud-config.</p> <ul> <li><strong>نصّ الصدفة</strong>: يبدأ بـ <code>#!/bin/bash</code>. بسيط ومباشر للمهام السريعة.</li> <li><strong>cloud-config</strong>: يبدأ بـ <code>#cloud-config</code> ويستخدم YAML تصريحيًا. أنظف وأسهل قراءةً وأكثر حيادًا تكراريًا لتهيئة المستخدمين والحزم والملفات والأوامر.</li> </ul> <h3 id="مثال-على-cloud-config">مثال على cloud-config</h3> <p>يعلن ملف <code>#cloud-config</code> النموذجي أقسامًا مثل <code>packages:</code> (الحزم المطلوب تثبيتها) و<code>write_files:</code> (ملفات الإعداد) و<code>runcmd:</code> (الأوامر الختامية) و<code>users:</code> (الحسابات والمفاتيح). ولأنه تصريحي، فمراجعته وصيانته أسهل من نصّ طويل.</p> <h2 id="ممارسات-جيدة">ممارسات جيدة</h2> <ul> <li><strong>أبقِ user-data صغيرًا</strong>: إن كبر أكثر من اللازم فالأرجح أن مكانه داخل الصورة مخبوزًا.</li> <li><strong>الحياد التكراري</strong>: صمّم الأوامر بحيث لا تُفسد شيئًا عند إعادة تنفيذها.</li> <li><strong>لا تضع أسرارًا بنصّ صريح</strong> في user-data أبدًا: فهو مقروء من بيانات النسخة الوصفية. احقنها وقت التشغيل من Secrets Manager أو Parameter Store أو Vault.</li> <li><strong>احمِ الوصول إلى البيانات الوصفية</strong>: استخدم IMDSv2 للحدّ من سرقة بيانات الاعتماد عبر SSRF.</li> <li><strong>سجّل وصحّح</strong>: سجلات cloud-init (<code>/var/log/cloud-init-output.log</code>) خير صديق لك حين يفشل شيء ما.</li> </ul> <h2 id="الخبز-أم-الإقلاع-أين-يوضع-كل-شيء">الخبز أم الإقلاع: أين يوضع كل شيء</h2> <table> <thead> <tr> <th>يوضع في الصورة (خبز)</th> <th>يوضع في user-data (إقلاع)</th> </tr> </thead> <tbody> <tr> <td>نظام التشغيل والترقيعات</td> <td>إعداد خاص بالبيئة</td> </tr> <tr> <td>بيئة التشغيل والوكلاء والتحصين</td> <td>متغيّرات ومعاملات لكل نسخة</td> </tr> <tr> <td>برمجيات ثابتة وثقيلة</td> <td>التسجيل في العنقود والاكتشاف</td> </tr> <tr> <td>كل ما يطول تثبيته</td> <td>حقن الأسرار وقت التشغيل</td> </tr> </tbody> </table> <p><em>القاعدة الذهبية: الثابت والبطيء يُخبَز؛ والمتغيّر والخفيف يوضع عند الإقلاع.</em></p> <h2 id="أخطاء-شائعة-تكلف-ساعات">أخطاء شائعة تكلّف ساعات</h2> <ul> <li>وضع ما ينبغي أن يكون في الصورة داخل user-data، فتصبح عمليات الإقلاع بطيئة وهشّة.</li> <li>كشف أسرار بنصّ صريح في البيانات الوصفية.</li> <li>افتراض أن user-data يُعاد تنفيذه عند كل إقلاع: افتراضيًا لا يعمل إلا في الأول.</li> <li>إهمال مراجعة سجلات cloud-init حين «لا تفعل النسخة ما ينبغي».</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل يُنفَّذ user-data عند كل إعادة تشغيل؟</strong></p> <p>افتراضيًا في الإقلاع الأول فقط. يمكن ضبط cloud-init لتنفيذ أجزاء بعينها عند كل إقلاع، لكن يُستحسن فعل ذلك بوعي وبحياد تكراري.</p> <p><strong>هل تمرير كلمات المرور في user-data آمن؟</strong></p> <p>لا. فـ user-data مقروء من بيانات النسخة الوصفية. استخدم مدير أسرار واحقنها وقت التشغيل، واحمِ البيانات الوصفية بـ IMDSv2.</p> <p><strong>هل يعمل cloud-init في AWS فقط؟</strong></p> <p>لا. cloud-init متعدّد المنصّات ويعمل في AWS وAzure وGCP وغيرها، ما يجعله مثاليًا لأتمتة الإقلاع بصورة قابلة للنقل.</p> <p><em>في imaxe.cloud نصمّم صورًا مهيّأة للاندماج مع cloud-init، بحيث تخدمك صورة واحدة في سيناريوهات كثيرة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AA%D9%82%D9%88%D9%8A%D8%A9-ami-%D9%83%D9%88%D8%A8%D8%B1%D9%86%D9%8A%D8%AA%D8%B3/2026-07-03T00:00:00Z2026-08-22T15:25:49Z

أمان Kubernetes لا يتجاوز أمان العُقد التي يعمل عليها. صورة AMI مُحصَّنة ومُحدَّثة ومُحسَّنة هي الأساس الذي تغفل عنه فرق كثيرة. نشرح كيف تبني الصورة الأساسية المثالية لـ EKS وللعناقيد ذاتية الإدارة.

<p><img src="https://www.imaxe.cloud/blog-covers/ami-endurecida-kubernetes_hu_448c2b0b32cba86a.webp" alt="منظر جوي لمحطة حاويات بريمرهافن" width="1200" height="675"></p><p>من السهل الاعتقاد بأن أمان المضيف يفقد أهميته عند العمل بالحاويات. الحقيقة عكس ذلك تمامًا: كل عقدة Kubernetes هي جهاز يقلع من صورة، وأي اختراق للمضيف يعرّض جميع الحاويات التي يستضيفها للخطر. لذلك فإن <strong>صورة AMI الخاصة بالعقدة</strong> قطعة أمنية حرجة.</p> <p>أمامك ثلاثة مسارات: استخدام صور AMI المُحسَّنة الرسمية كما هي، أو اتخاذها أساسًا وتخصيصها، أو بناء صورتك الخاصة. للإنتاج الجاد، التخصيص أو البناء فوق أساس مُحصَّن هو الخيار الموصى به.</p> <h2 id="ما-يجب-أن-تحمله-صورة-عقدة-جيدة">ما يجب أن تحمله صورة عقدة جيدة</h2> <ul> <li><strong>أساس مُحسَّن</strong> لبيئة تشغيل الحاويات، مع ضبط صحيح لـ containerd وkubelet.</li> <li><strong>تحصين CIS</strong> لنظام التشغيل، وعند اللزوم لمعيار CIS Benchmark for Kubernetes نفسه.</li> <li><strong>ترقيعات محدَّثة</strong> للنواة والمكوّنات، مع إعادة بناء دورية.</li> <li><strong>الوكلاء الضروريون</strong> —السجلات والمقاييس والأمن— مثبَّتون مسبقًا لإقلاع سريع.</li> <li><strong>بلا أسرار أو بيانات اعتماد مخبوزة</strong>؛ الهوية عبر IAM Roles for Service Accounts (IRSA) أو ما يعادلها.</li> <li><strong>إعداد بحدّه الأدنى</strong>: احذف الحزم والخدمات التي لا تحتاجها العقدة.</li> </ul> <h2 id="خيارات-الصور-لـ-eks">خيارات الصور لـ EKS</h2> <table> <thead> <tr> <th>الخيار</th> <th>الميزة</th> <th>متى تختاره</th> </tr> </thead> <tbody> <tr> <td>صورة EKS المُحسَّنة (AL2023)</td> <td>رسمية وتصونها AWS</td> <td>نقطة انطلاق عامة</td> </tr> <tr> <td>Bottlerocket</td> <td>نظام أدنى موجَّه للحاويات، غير قابل للتغيير</td> <td>أقصى أمان وأصغر سطح هجوم</td> </tr> <tr> <td>صورة AMI مخصّصة</td> <td>تحكّم كامل في التحصين والوكلاء</td> <td>متطلبات امتثال صارمة</td> </tr> </tbody> </table> <p><em>اختر أساس العقدة وفق توازنك بين التحكّم والراحة.</em></p> <h2 id="bottlerocket-الحاويات-أولا">Bottlerocket: الحاويات أولًا</h2> <p>Bottlerocket نظام تشغيل مُبسَّط من AWS مصمَّم حصريًا لتشغيل الحاويات. سطح هجومه ضئيل جدًا، وهو غير قابل للتغيير ويُحدَّث بالصورة —لا بالترقيع الساخن— وهو ما ينسجم تمامًا مع فلسفة البنية التحتية غير القابلة للتغيير. إن كانت أولويتك أمان العقدة بأقل جهد صيانة، فهو يستحق تقييمًا جادًا.</p> <h2 id="تحديث-العقد-بلا-ألم">تحديث العُقد بلا ألم</h2> <p>صورة العقدة المُحصَّنة لا تنفع إلا إذا أبقيت العُقد محدَّثة. هنا يتألق النمط غير القابل للتغيير:</p> <ul> <li><strong>استبدل ولا ترقّع</strong>: انشر إصدار AMI جديدًا وأدِر العُقد.</li> <li><strong>تحديث تدريجي لمجموعة العُقد</strong>: أفرغها بـ <em>cordon</em> و<em>drain</em> واستبدلها عقدة بعقدة.</li> <li><strong>Managed Node Groups</strong> أو Karpenter لأتمتة الاستبدال بصور AMI جديدة.</li> <li><strong>PodDisruptionBudgets</strong> كي لا تمسّ الدورة توافر خدماتك.</li> </ul> <h2 id="أخطاء-شائعة">أخطاء شائعة</h2> <ul> <li>استخدام الصورة المُحسَّنة الافتراضية لشهور دون تحديثها.</li> <li>خبز بيانات اعتماد العنقود داخل الصورة بدل استخدام الهوية الموحَّدة.</li> <li>نسيان تحصين kubelet نفسه وصلاحيات نظام الملفات.</li> <li>عدم تقييد وصول SSH إلى العُقد: المثالي هو صفر SSH ووصول عبر SSM فقط.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل أحتاج صورة مخصّصة أم تكفيني صورة EKS المُحسَّنة؟</strong></p> <p>للبداية، الصورة المُحسَّنة الرسمية نقطة انطلاق جيدة. وإن كانت لديك متطلبات امتثال أو أمان صارمة، فخصّصها أو ابنِ صورتك بتحصين ووكلاء من عندك.</p> <p><strong>هل يحلّ Bottlerocket محلّ صورة Linux عادية؟</strong></p> <p>للعُقد التي تشغّل حاويات فقط، نعم: سطح هجوم أصغر وتحديث غير قابل للتغيير. لكنه لا يناسب الأحمال التي تحتاج نظام تشغيل عام الأغراض.</p> <p><strong>كيف أحدّث العُقد عند نشر صورة AMI جديدة؟</strong></p> <p>بتحديث تدريجي لمجموعة العُقد: تُفرَّغ وتُستبدل تدريجيًا مع احترام PodDisruptionBudgets كي لا تتأثر الخدمة.</p> <p><em>في imaxe.cloud نصمّم صورًا أساسية مُحصَّنة صالحة لأن تكون أساسًا مثاليًا لعُقد Kubernetes لديك.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%A7%D8%B9%D8%A7%D8%AF%D8%A9-%D8%A8%D9%86%D8%A7%D8%A1-ami-%D8%A8%D8%B9%D8%AF-cve/2026-06-30T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/reconstruir-ami-ante-cve_hu_920b537b3bf25409.webp" alt="زرّ إنذار حريق يدوي بضوئه الأحمر" width="1200" height="675"></p><p>بين لحظة نشر ثغرة حرجة ولحظة إصلاحها على كل نسخك تمتدّ <strong>نافذة التعرّض</strong>. وكلما طالت، زاد الوقت المتاح للمهاجم لاستغلالها. في نموذج الترقيع التقليدي خادمًا خادمًا تُقاس تلك النافذة بالأيام أو الأسابيع. أما في نموذج الصور غير القابلة للتغيير والمؤتمت جيدًا، فبالساعات.</p> <p>والمفتاح أن تتعامل مع الاستجابة للثغرة كعملية هندسية قابلة للتكرار، لا كسباق يدوي في اللحظة الأخيرة.</p> <h2 id="معمارية-الاستجابة-الآلية">معمارية الاستجابة الآلية</h2> <p>الهدف أن تولد—أمام ثغرة حرجة تمسّك—صورة جديدة مُرقَّعة، ويجري التحقّق منها، وتبقى جاهزة للنشر بأقل تدخّل بشري. وتتكوّن الدارة من أربع قطع.</p> <h3 id="1-الاكتشاف">1. الاكتشاف</h3> <ul> <li><strong>فحص مستمر</strong> لصورك السارية بـ Amazon Inspector أو Trivy أو Grype.</li> <li><strong>تدفّقات الثغرات</strong> —قاعدة NVD وتنبيهات مزوّد نظام التشغيل— التي تغذّي التنبيهات.</li> <li><strong>SBOM</strong> لكل صورة كي تعرف خلال ثوانٍ إن كان المكوّن المصاب موجودًا.</li> </ul> <h3 id="2-الإطلاق">2. الإطلاق</h3> <ul> <li>تنبيه بخطورة حرجة أو عالية يُطلق خطّ إعادة البناء، عبر EventBridge نحو CodeBuild مثلًا، أو بخطّاف ويب إلى نظام التكامل لديك.</li> <li>ويمكن اشتراط موافقة بشرية للإنتاج، مع إبقاء البناء والتحقّق آليَّين تمامًا.</li> </ul> <h3 id="3-إعادة-البناء-والتحقق">3. إعادة البناء والتحقّق</h3> <ul> <li>يعيد خطّ الإنتاج —Packer أو EC2 Image Builder— بناء الصورة من الأساس المحدَّث، مطبّقًا <code>dnf</code>/<code>apt update</code> والتحصين المعتاد.</li> <li><strong>يُعاد فحص</strong> الصورة الجديدة: فلا معنى للنشر إن كانت الثغرة لا تزال موجودة.</li> <li>تُنفَّذ <strong>الاختبارات</strong>: الإقلاع واختبارات الدخان وInSpec، كي لا ينكسر شيء.</li> </ul> <h3 id="4-التوزيع-والنشر">4. التوزيع والنشر</h3> <ul> <li>تُرقَّم إصدارات الصورة الجديدة، وتُنسخ إلى المناطق اللازمة، ويُحدَّث المؤشّر في SSM Parameter Store.</li> <li>يُحدَّث <strong>قالب الإطلاق</strong>، وتقوم مجموعة التوسّع التلقائي بتحديث تدريجي أو بنشر blue/green.</li> <li>وتُعلَّم الصور المصابة بأنها <strong>مهملة</strong> كي لا يُطلقها أحد بالخطأ.</li> </ul> <h2 id="المؤشر-المفتاح-زمن-الإصلاح-الوسطي-للترقيعات">المؤشر المفتاح: زمن الإصلاح الوسطي للترقيعات</h2> <p>قِس <strong>متوسط الزمن من نشر ثغرة حرجة حتى تعمل منظومتك كلها بالصورة المصحَّحة</strong>. إنه المؤشر الذي يلخّص نضجك. وخفضه من أسابيع إلى ساعات من أكبر عوائد الاستثمار في خطّ إنتاج للصور.</p> <table> <thead> <tr> <th>مستوى النضج</th> <th>الزمن المعتاد</th> <th>كيف يجري الترقيع</th> </tr> </thead> <tbody> <tr> <td>يدوي</td> <td>أيام أو أسابيع</td> <td>SSH خادمًا خادمًا</td> </tr> <tr> <td>نصف آلي</td> <td>ساعات إلى يوم أو يومين</td> <td>إعادة بناء يدوية وتحديث تدريجي</td> </tr> <tr> <td>آلي</td> <td>ساعات</td> <td>إطلاق وإعادة بناء ونشر</td> </tr> </tbody> </table> <p><em>أتمتة خطّ الإنتاج تقلّص نافذة التعرّض تقليصًا حادًا.</em></p> <h2 id="ممارسات-جيدة">ممارسات جيدة</h2> <ul> <li><strong>تدرّب على السيناريو</strong>: اختبر الدارة بثغرة محاكاة قبل أن تحتاجها فعلًا.</li> <li><strong>نشر تدريجي</strong>: canary أو تحديث تدريجي لرصد التراجعات دون إسقاط الخدمة.</li> <li><strong>تراجع جاهز</strong>: احتفظ بالإصدار السابق واحتفظ بخطة عودة فورية.</li> <li><strong>التواصل</strong>: سجّل أي ثغرة دفعت إلى كل إعادة بناء؛ فذلك دليل امتثال.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل عليّ إعادة البناء عند أي ثغرة؟</strong></p> <p>لا. رتّب الأولويات بحسب الخطورة وقابلية الاستغلال، وبحسب وجود المكوّن المصاب فعليًا في صورتك: وهنا يكون SBOM حاسمًا. الحرجة والعالية القابلة للاستغلال تبرّر إعادة بناء عاجلة؛ وما عداها ينتظر الدورة المعتادة.</p> <p><strong>كيف أتفادى كسر الإنتاج عند نشر الصورة الجديدة؟</strong></p> <p>بتحقّق آلي —اختبارات دخان وInSpec— قبل النشر، وبعمليات نشر تدريجية: canary أو تحديث تدريجي أو blue/green، مع تراجع جاهز.</p> <p><strong>هل يمكنني أتمتة ذلك خارج AWS؟</strong></p> <p>نعم. النمط —اكتشاف، إطلاق، إعادة بناء، نشر— صالح في Azure وGCP بنظائرهما؛ ويمنح Packer قابلية النقل في مرحلة البناء.</p> <p><em>في imaxe.cloud نعيد بناء صورنا وفحصها بسرعة أمام الثغرات الجديدة كي تنطلق من أساس محدَّث.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%B5%D9%88%D8%B1-aws-azure-gcp/2026-06-26T00:00:00Z2026-08-22T15:25:49Z

AMI وManaged Image وCustom Image: لكل سحابة اسمها وقواعدها للشيء نفسه، أي قالب تُقلع منه الآلات. وإن كنت تعمل على أكثر من سحابة، فإن فهم الفروق يوفّر عليك المفاجآت.

<p><img src="https://www.imaxe.cloud/blog-covers/aws-azure-gcp-imagenes_hu_4cc3e453ad41116a.webp" alt="لوحات توصيل ومبدّلات إيثرنت في خزانة مقاس 19 بوصة" width="1200" height="675"></p><p>تحلّ السحابات الثلاث الكبرى المشكلة نفسها —امتلاك قالب قابل لإعادة الاستخدام لإطلاق آلات متطابقة— بمقاربات وتسميات خاصة بكل منها. ومعرفة المقابلات هي الخطوة الأولى نحو استراتيجية سحابات متعددة بلا احتكاك.</p> <p>في AWS تُسمّى <strong>AMI</strong> (Amazon Machine Image)؛ وفي Azure <strong>Managed Image</strong>، وقبل ذلك <strong>Azure Compute Gallery</strong> (المعروفة سابقًا بـ Shared Image Gallery)؛ وفي Google Cloud <strong>Custom Image</strong>. جميعها تغلّف قرص إقلاع مُهيّأ مسبقًا، لكنها تختلف في كيفية ترقيم إصداراتها ومشاركتها وتوزيعها.</p> <h2 id="المقابلات-في-لمحة">المقابلات في لمحة</h2> <table> <thead> <tr> <th>المفهوم</th> <th>AWS</th> <th>Azure</th> <th>Google Cloud</th> </tr> </thead> <tbody> <tr> <td>صورة الآلة</td> <td>AMI</td> <td>Managed Image</td> <td>Custom Image</td> </tr> <tr> <td>الكتالوج أو المعرض</td> <td>لا يوجد أصيل: وسوم وSSM</td> <td>Azure Compute Gallery</td> <td>Image Family</td> </tr> <tr> <td>ترقيم الإصدارات المُدار</td> <td>يدوي، بالاسم والوسوم</td> <td>أصيل داخل المعرض</td> <td>Image Family: الأحدث لكل عائلة</td> </tr> <tr> <td>التوزيع عبر المناطق</td> <td>نسخ صورة AMI</td> <td>نسخ متماثلة في المعرض</td> <td>صور عالمية افتراضيًا</td> </tr> <tr> <td>المخزن الأساسي</td> <td>لقطات EBS</td> <td>Managed Disks</td> <td>Persistent Disk</td> </tr> <tr> <td>التشفير</td> <td>KMS</td> <td>مفاتيح المنصة أو العميل</td> <td>تديرها Google أو CMEK</td> </tr> </tbody> </table> <p><em>مقابلات وظيفية لصور الآلات في السحابات الثلاث الكبرى.</em></p> <h2 id="aws-ami-المعيار-الفعلي">AWS AMI: المعيار الفعلي</h2> <p>صورة AMI هي على الأرجح أشهر صيغ الصور وأوسعها منظومةً. قوتها في النضج: كتالوج ضخم وتكامل مع EC2 Image Builder والمتجر ومجتمع هائل. أما نقطة ضعفها التاريخية فهي غياب معرض صور أصيل بترقيم إصدارات مُدار: إذ يُحلّ الترقيم والتوزيع عبر المناطق بأعراف تسمية ووسوم وSSM Parameter Store ونسخ صريحة بين المناطق.</p> <h2 id="azure-compute-gallery-ترقيم-ونسخ-متماثلة-جاهزة">Azure Compute Gallery: ترقيم ونسخ متماثلة جاهزة</h2> <p>راهنت Azure بقوة على حوكمة الصور. يقدّم <strong>Compute Gallery</strong> أصلًا تعريفات للصور وإصدارات ونسخًا متماثلة تلقائية إلى عدة مناطق، إضافةً إلى تحكّم دقيق بالوصول. وللمؤسسات الكبيرة التي تحتاج توزيع الصور بترتيب بحسب الفرق والمناطق، هذا نموذج مريح جدًا. المقابل هو منحنى مفاهيمي أشدّ انحدارًا بعض الشيء.</p> <h2 id="gcp-custom-image-بساطة-عالمية">GCP Custom Image: بساطة عالمية</h2> <p>تتميّز Google Cloud بالبساطة. فصورها <strong>عالمية</strong> افتراضيًا —لا حاجة لنسخها منطقةً منطقة— ومفهوم <strong>Image Family</strong> يحلّ ترقيم الإصدارات بأناقة: تشير إلى العائلة فتحصل دائمًا على أحدث صورة غير مهملة. إنه نموذج مقتصد يقلّل الاحتكاك، وجذّاب بخاصة للفرق التي تقدّر البساطة التشغيلية.</p> <h2 id="استراتيجية-السحابات-المتعددة-قالب-واحد-وثلاث-صور">استراتيجية السحابات المتعددة: قالب واحد وثلاث صور</h2> <p>إن كنت تنشر أو تنشئ في أكثر من سحابة، فإن صيانة ثلاث عمليات بناء منفصلة عذاب. وحلّ القطاع هو <strong>Packer</strong>: قالب واحد بمزوّدات مشتركة وكتلة source لكل سحابة، قادر على توليد صورة AMI وManaged Image وCustom Image بالتوازي من التعريف ذاته.</p> <ul> <li><strong>أعد استخدام</strong> نصوص التثبيت والتحصين نفسها في السحابات الثلاث.</li> <li><strong>قلّل</strong> الانحراف بين البيئات: الإعداد نفسه وثلاث وجهات.</li> <li><strong>رقّم الإصدارات</strong> باتساق عبر مخطط موحّد للأسماء والبيانات الوصفية.</li> <li><strong>أتمِت</strong> النشر في كل معرض: Gallery وImage Family والوسوم وSSM.</li> </ul> <h2 id="أيها-تختار">أيّها تختار؟</h2> <p>لا فائز مطلق؛ الأمر رهن سياقك. إن كنت تبحث عن المنظومة والنضج فـ AWS. وإن احتجت حوكمة صور مؤسسية بترقيم ونسخ متماثلة أصيلة فمعرض Azure يتألّق. وإن كنت تقدّر البساطة والامتداد العالمي بلا نسخ فـ GCP. أما إن كنت تعيش في أكثر من سحابة، فالجواب ليس منصة بل <strong>ممارسة</strong>: صِف صورك كشيفرة وابنِها بصورة قابلة للنقل.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل يمكنني نقل صورة AMI من AWS إلى Azure أو GCP مباشرة؟</strong></p> <p>ليس مباشرة: الصيغ والمخازن الأساسية مختلفة. المعتاد هو إعادة بناء الصورة في كل سحابة من قالب مشترك، بـ Packer مثلًا، أو استيراد القرص عبر عمليات الاستيراد لدى كل مزوّد.</p> <p><strong>أي سحابة لديها أفضل ترقيم لإصدارات الصور؟</strong></p> <p>يقدّم Azure Compute Gallery أكمل ترقيم مُدار جاهز؛ وتحلّها GCP بأناقة عبر Image Families؛ أما AWS فتتطلّب أعرافًا خاصة أكثر، وإن كانت مرنة جدًا.</p> <p><strong>هل تستحق استراتيجية صور متعددة السحابات العناء؟</strong></p> <p>إن كنت تعمل على أكثر من سحابة لأسباب تتعلق بسيادة البيانات أو المرونة أو تفادي التبعية لمزوّد واحد، فنعم. والمفتاح هو استخدام الصور كشيفرة كي لا يتضاعف جهد الصيانة.</p> <p><em>في imaxe.cloud نفكّر في قابلية النقل منذ التصميم كي لا تعتمد عمليات نشرك على سحابة واحدة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%A7%D8%AA%D8%AC%D8%A7%D9%87%D8%A7%D8%AA-%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D8%A9-2026/2026-06-23T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/tendencias-cloud-2026_hu_c649ca0919e5a33f.webp" alt="ممرّ خوادم في مركز بيانات CERN" width="1200" height="675"></p><p>الخبر الكبير الأول في 2026 غير مريح: انتهى عصر الانخفاضات المتواصلة في الأسعار. فضغط كلفة الطاقة، والاستثمار الضخم في الذكاء الاصطناعي، والطلب على وحدات GPU، كلها تدفع التعرفة إلى أعلى. وصارت التخفيضات استثناءً لا قاعدة.</p> <p>وهذا التحوّل العميق يحكم كل ما عداه. فحين كانت السحابة رخيصة كان الهدر مُحتمَلًا؛ وحين تغلو تصبح الكفاءة أولوية إدارية. لذلك تدور اتجاهات العام حول إنجاز المزيد بموارد أقل والأتمتة بحكمة.</p> <h2 id="1-البنية-غير-القابلة-للتغيير-معيارا">1. البنية غير القابلة للتغيير معيارًا</h2> <p>يترسّخ نموذج «ابنِ صورة واستبدل» ممارسةً افتراضية. فبدل ترقيع خوادم حيّة، تخبز الفرق صورًا مُرقَّمة الإصدارات وتنشر باستبدال النسخ. وهذا يمنح عمليات نشر متوقَّعة، وتراجعات نظيفة، وسطح هجوم أصغر. وتقع <strong>صور golden AMI</strong> والصور المحكومة جيدًا في قلب هذا النهج.</p> <h2 id="2-finops-يصعد-إلى-مجلس-الإدارة">2. FinOps يصعد إلى مجلس الإدارة</h2> <p>يكفّ ضبط تكاليف السحابة عن كونه شأن فريق تقني ليصير أولوية عمل. وأكثر الروافع استخدامًا هذا العام:</p> <ul> <li><strong>الوسم والوضوح</strong> لكل حِمل، لمعرفة من ينفق وعلى ماذا.</li> <li><strong>النسخ المحجوزة وspot</strong> للعمل على كلفة الوحدة.</li> <li><strong>تحسين الصور</strong>: صور خفيفة، وإقلاع سريع، وتنظيف اللقطات اليتيمة — وهي كلفة خفيّة كلاسيكية.</li> <li><strong>الملاءمة المستمرة للحجم</strong> وإطفاء الموارد العاطلة.</li> <li><strong>تبنّي ARM وGraviton</strong> لأفضلية نسبة السعر إلى الأداء.</li> </ul> <h2 id="3-الذكاء-الاصطناعي-من-التجريب-إلى-العائد">3. الذكاء الاصطناعي: من التجريب إلى العائد</h2> <p>بعد الحمّى الأولى، 2026 هو عام عصر عائد الذكاء الاصطناعي. ينتقل التركيز إلى تقليص زمن خمول وحدات GPU، وتحسين الاستدلال، ونقل النماذج إلى الحافة. ويظهر كذلك نمط <strong>شبكات وكلاء الذكاء الاصطناعي</strong>: مراكز تحكم اتصال الوكلاء فيما بينهم، وتفرض ضبط التكاليف، وتوجّه الطلبات إلى أرخص نموذج قادر على إنجاز المهمة.</p> <h2 id="4-تعدد-السحابات-والحافة-بواقعية">4. تعدّد السحابات والحافة، بواقعية</h2> <p>يعمّ تعدّد السحابات، لكن بواقعية: لا لأنه موضة، بل لتفادي التبعية لمزوّد واحد، وتلبية متطلبات سيادة البيانات، والإفادة من أفضل ما في كل سحابة. وتزداد قيمة قابلية نقل صور الآلات —قالب واحد يولّد صورًا لعدة سحابات. وبالتوازي تنمو <strong>الحافة</strong> لتقريب الحوسبة من البيانات، بدفع من الذكاء الاصطناعي وإنترنت الأشياء.</p> <h2 id="5-التنظيم-عام-الامتثال">5. التنظيم: عام الامتثال</h2> <p>يزداد الإطار التنظيمي تشدّدًا. ففي 2026 تدخل حيّز النفاذ مراحل مهمة من تنظيم الذكاء الاصطناعي الأوروبي وتوجيهات مسؤولية جديدة، وتتعزّز متطلبات حوكمة السحابة في ولايات قضائية عدّة. والنتيجة المباشرة للبنية التحتية: يصبح التتبّع —أي برمجيات تشغّلها وكيف تؤمّنها وكيف تثبت ذلك— إلزاميًا. ولم تعد سلاسل الصور القابلة للتدقيق وSBOM ترفًا.</p> <h2 id="ماذا-يعني-هذا-لبنيتك-التحتية">ماذا يعني هذا لبنيتك التحتية</h2> <table> <thead> <tr> <th>الاتجاه</th> <th>الأثر العملي</th> <th>الإجراء الموصى به</th> </tr> </thead> <tbody> <tr> <td>سحابة أغلى</td> <td>كل مورد محسوب</td> <td>FinOps وصور كفؤة</td> </tr> <tr> <td>عدم القابلية للتغيير</td> <td>انحراف أقل وتحكّم أكبر</td> <td>خطوط إنتاج golden AMI</td> </tr> <tr> <td>ذكاء اصطناعي في الإنتاج</td> <td>تحسين الاستدلال والكلفة</td> <td>GPU مشتركة وحافة ووكلاء</td> </tr> <tr> <td>تعدّد السحابات</td> <td>تفادي التبعية</td> <td>صور قابلة للنقل بـ Packer</td> </tr> <tr> <td>التنظيم</td> <td>تتبّع إلزامي</td> <td>SBOM وسلاسل قابلة للتدقيق</td> </tr> </tbody> </table> <p><em>من الاتجاه إلى إجراء ملموس في يومك.</em></p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل سيرتفع سعر السحابة فعلًا في 2026؟</strong></p> <p>يشير المحلّلون إلى ضغط صعودي بفعل كلفة الطاقة ووحدات GPU، مع تحوّل التخفيضات إلى استثناء. ولهذا يكتسب FinOps وكفاءة الموارد هذا الثقل هذا العام.</p> <p><strong>ما شبكة وكلاء الذكاء الاصطناعي؟</strong></p> <p>هي معمارية يحكم فيها مركز واحد اتصال وكلاء الذكاء الاصطناعي، فارضًا الأمن وضبط التكاليف وتوجيه الطلبات إلى النموذج الأنسب والأوفر.</p> <p><strong>لماذا صارت عدم القابلية للتغيير اتجاهًا وهي ليست جديدة؟</strong></p> <p>لأن السياق يجعلها شبه إلزامية: تكاليف صاعدة، وتنظيم متطلّب، وحاجة إلى عمليات نشر قابلة للتدقيق، كلها تفرض نموذج الصور المُرقَّمة والاستبدال معيارًا.</p> <p><em>في imaxe.cloud نتابع هذه الاتجاهات عن كثب كي تنسجم صورنا مع السحابة القادمة: كفؤة وقابلة للنقل وقابلة للتدقيق.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/ami-%D9%85%D9%82%D8%A7%D8%A8%D9%84-%D8%A7%D9%84%D8%AD%D8%A7%D9%88%D9%8A%D8%A7%D8%AA/2026-06-19T00:00:00Z2026-08-22T15:25:49Z

صورة آلة أم حاوية؟ السؤال مطروح بصيغة خاطئة: هما لا يتنافسان بل يتكاملان. فهم ما يحلّه كلٌّ منهما يوفّر عليك الهندسة الزائدة ويساعدك على اختيار الأداة الملائمة لكل حِمل.

<p><img src="https://www.imaxe.cloud/blog-covers/amis-vs-contenedores_hu_9942fe419781baec.webp" alt="حاويات شحن مكدّسة في ميناء روتردام" width="1200" height="675"></p><p>تحزم <strong>صورة AMI</strong> نظام تشغيل كاملًا إلى جانب برمجياتك: إنها قالب آلة افتراضية بأكملها. أما <strong>الحاوية</strong> فتحزم تطبيقك وتبعياته فقط، وتشارك نواة المضيف. الفارق في الحجم وفي نموذج العزل يفسّر كل شيء تقريبًا.</p> <p>ليست معركة: عمليًا تعمل الحاويات <strong>فوق</strong> آلات افتراضية تُقلع من صورة AMI. السؤال المفيد ليس أيّهما ينتصر، بل أي طبقة يحلّها كلٌّ منهما.</p> <h2 id="مقارنة-مباشرة">مقارنة مباشرة</h2> <table> <thead> <tr> <th>البُعد</th> <th>صورة AMI (آلة افتراضية)</th> <th>حاوية</th> </tr> </thead> <tbody> <tr> <td>ماذا تتضمّن</td> <td>نظام تشغيل كامل مع البرمجيات</td> <td>التطبيق وتبعياته</td> </tr> <tr> <td>العزل</td> <td>قوي، عبر مُشرف الأجهزة</td> <td>على مستوى العملية، بنواة مشتركة</td> </tr> <tr> <td>الحجم</td> <td>جيجابايتات</td> <td>ميجابايتات</td> </tr> <tr> <td>الإقلاع</td> <td>ثوانٍ إلى دقائق</td> <td>أجزاء من الثانية إلى ثوانٍ</td> </tr> <tr> <td>الكثافة</td> <td>أقل: آلة افتراضية لكل نسخة</td> <td>عالية: كثير منها على مضيف واحد</td> </tr> <tr> <td>قابلية النقل</td> <td>مرتبطة بالسحابة أو بمُشرف الأجهزة</td> <td>عالية جدًا: أي مضيف فيه بيئة تشغيل</td> </tr> <tr> <td>صيانة النظام</td> <td>أنت من يديرها</td> <td>تُورَّث من المضيف أو الصورة الأساسية</td> </tr> <tr> <td>الحالة المثالية</td> <td>تطبيقات متراصّة، مضيفات، آلات مخصّصة</td> <td>خدمات مصغّرة، توسّع سريع</td> </tr> </tbody> </table> <p><em>صور AMI والحاويات تحلّ مشكلات مختلفة في طبقات مختلفة.</em></p> <h2 id="متى-تختار-صورة-ami">متى تختار صورة AMI</h2> <ul> <li><strong>عزل قوي إلزامي</strong>: أحمال متعددة المستأجرين أو متطلبات تنظيمية صارمة يكون فيها عزل مُشرف الأجهزة شرطًا.</li> <li><strong>برمجيات تتوقّع آلة كاملة</strong>: قواعد البيانات، التطبيقات القديمة، أجهزة الشبكة أو الأمن.</li> <li><strong>تحكّم كامل بنظام التشغيل</strong>: حين تحتاج وحدات نواة أو مشغّلات خاصة أو ضبطًا دقيقًا للنظام.</li> <li><strong>أساس عُقدك</strong>: حتى في عالم الحاويات، تُقلع عُقد Kubernetes لديك من صورة AMI.</li> </ul> <h2 id="متى-تختار-الحاويات">متى تختار الحاويات</h2> <ul> <li><strong>الخدمات المصغّرة</strong> التي تتوسّع وتُنشر باستقلالية.</li> <li><strong>دورات نشر سريعة</strong> مع التكامل والتسليم المستمرين.</li> <li><strong>كثافة عالية</strong> لاستغلال العتاد بأحمال صغيرة كثيرة.</li> <li><strong>قابلية النقل</strong> بين بيئات التطوير والاختبار وعدة سحابات.</li> </ul> <h2 id="الجواب-الناضج-اجمع-بينهما">الجواب الناضج: اجمع بينهما</h2> <p>الفرق المتقدّمة لا تختار أحدهما، بل تُطبّق طبقات. تبني <strong>صورة golden AMI مُحصَّنة</strong> كأساس للمضيف —مُرقَّعة، بتحصين CIS ووكلاء أمن— وتشغّل حاوياتها فوقها. هكذا تحصل على أفضل ما في العالمين: أمان المضيف والتحكّم به على مستوى صورة الآلة، ورشاقة الحاويات وكثافتها على مستوى التطبيق.</p> <ul> <li>عُقد Kubernetes أو ECS مبنية على صورة AMI مُحصَّنة ومُرقَّمة الإصدارات.</li> <li>تحديث المضيف باستبدال الصورة (غير قابل للتغيير) لا بالترقيع الساخن.</li> <li>الحاويات لدورة الحياة السريعة للتطبيق.</li> </ul> <h2 id="microvms-الحد-الفاصل-يتلاشى">MicroVMs: الحدّ الفاصل يتلاشى</h2> <p>تقنيات مثل Firecracker —التي تقف خلف AWS Lambda وFargate— تنشئ <strong>آلات افتراضية مصغّرة</strong>: عزل قوي كآلة افتراضية مع أزمنة إقلاع بأجزاء من الثانية، أقرب إلى الحاوية. إنها إشارة إلى أن المستقبل ليس «آلة افتراضية أم حاوية»، بل طيف متصل تختار فيه النقطة المناسبة بين العزل والرشاقة لكل حِمل.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل تجعل الحاويات صور AMI عتيقة؟</strong></p> <p>لا. الحاويات تعمل على آلات تُقلع من صور. وتبقى صورة AMI المُحصَّنة الأساس المثالي للعُقد التي تشغّل حاوياتك.</p> <p><strong>أيّهما أكثر أمانًا، الآلة الافتراضية أم الحاوية؟</strong></p> <p>الآلة الافتراضية توفّر عزلًا أقوى بحكم التصميم. أما الحاويات فتتشارك النواة، ولذلك تحتاج ضوابط إضافية. وللأحمال شديدة الحساسية، الجمع بين آلة افتراضية وحاوية مُحصَّنة هو المعتاد.</p> <p><strong>هل يمكنني الانتقال من صور AMI إلى الحاويات بسهولة؟</strong></p> <p>يعتمد على التطبيق. الخدمات عديمة الحالة والمُجزّأة تنتقل بسلاسة؛ أما التطبيقات المتراصّة شديدة الارتباط بنظام التشغيل فتتطلّب جهدًا أكبر. وغالبًا ما يُفضَّل نهج هجين وتدريجي.</p> <p><em>في imaxe.cloud نؤمن بالأداة المناسبة لكل حِمل: لذلك تصلح صورنا مضيفًا مباشرًا وأساسًا مُحصَّنًا لحاوياتك في آن واحد.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%A7%D8%AE%D8%AA%D9%8A%D8%A7%D8%B1-ami-%D9%85%D9%88%D8%AB%D9%88%D9%82%D8%A9/2026-06-16T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/elegir-ami-de-confianza_hu_ab14e41f927a6439.webp" alt="عدسة مكبّرة تفحص طابعًا بريديًا" width="1200" height="675"></p><p>إطلاق نسخة من صورة AMI يعني عمليًا تشغيل برمجيات حزمها شخص آخر داخل حسابك. فإن احتوت الصورة على برمجيات خبيثة أو مُعدِّني عملات مشفّرة أو مفاتيح مضمّنة أو حتى حزمًا غير مُرقَّعة، دخل ذلك الخطر مباشرةً إلى بنيتك التحتية. وقد وُثِّقت حالات لصور عامة خبيثة صُمِّمت لهذا الغرض بالذات.</p> <p>الحلّ ليس الارتياب، بل <strong>عملية تحقّق</strong> قابلة للتكرار. فاختيار صورة AMI بعناية يشبه توظيف شخص: تتحقّق من الهوية والمراجع والحالة قبل أن تسلّمه المفاتيح.</p> <h2 id="الأركان-الخمسة-لصورة-ami-موثوقة">الأركان الخمسة لصورة AMI موثوقة</h2> <p>قيّم كل صورة مرشّحة وفق هذه المحاور الخمسة. وإن أخفقت في أكثر من واحد، فابحث عن غيرها.</p> <h3 id="1-المصدر-من-ينشرها">1. المصدر: من ينشرها؟</h3> <ul> <li>تحقّق من <strong>owner ID</strong> للحساب الناشر؛ واحذر المالكين المجهولين أو غير المعروفين.</li> <li>فضّل صور المزوّدين الرسميين أو الشركاء المعتمَدين أو ناشرين ذوي سمعة قابلة للإثبات.</li> <li>تأكّد من أن الاسم والوصف يطابقان مصدرًا مشروعًا: انتبه للتقليد عبر <em>typosquatting</em>.</li> </ul> <h3 id="2-الأمان-ماذا-تحمل-في-داخلها">2. الأمان: ماذا تحمل في داخلها؟</h3> <ul> <li>هل هي <strong>مُحصَّنة</strong> (بمعيار CIS أو ما يعادله) أم أساس بلا حماية؟</li> <li>هل <strong>اللقطات مشفّرة</strong>؟</li> <li>افحصها بنفسك قبل الإنتاج بـ Inspector أو Trivy أو ما شابه لاكتشاف الثغرات والأسرار.</li> <li>تحقّق من خلوّها من <strong>مفاتيح SSH مصرّح بها</strong> مجهولة أو مستخدمين زائدين.</li> </ul> <h3 id="3-الصيانة-هل-هي-حية">3. الصيانة: هل هي حيّة؟</h3> <ul> <li>ما <strong>وتيرة تحديثها</strong>؟ صورة بلا إصدارات جديدة منذ سنة إشارة إنذار.</li> <li>هل يعلن الناشر عن <strong>الثغرات المُصلَحة</strong> في كل إصدار؟</li> <li>هل توجد <strong>وثائق</strong> واضحة لما تحتويه وكيفية إعدادها؟</li> </ul> <h3 id="4-التوافق-هل-تصلح-لحالتك">4. التوافق: هل تصلح لحالتك؟</h3> <ul> <li>المعمارية الصحيحة (<strong>x86_64</strong> مقابل <strong>ARM/Graviton</strong>) ونوع المحاكاة الافتراضية.</li> <li>توفّرها في منطقتك أو إمكانية نسخها إليها.</li> <li>دعم نوع النسخة الذي تحتاجه وتوافقها مع أتمتتك.</li> </ul> <h3 id="5-الكلفة-والترخيص-ماذا-تدفع-وبأي-شروط">5. الكلفة والترخيص: ماذا تدفع وبأي شروط؟</h3> <ul> <li>نموذج الكلفة: مجانية أو بالساعة أو BYOL.</li> <li>ترخيص البرمجيات المضمّنة والتزاماته.</li> <li>كلفة <strong>اللقطات</strong> والتخزين المرتبط بها.</li> </ul> <h2 id="قائمة-تحقق-سريعة">قائمة تحقّق سريعة</h2> <table> <thead> <tr> <th>الفحص</th> <th>إشارة جيدة</th> <th>إشارة إنذار</th> </tr> </thead> <tbody> <tr> <td>المالك</td> <td>مالك موثَّق ومعروف</td> <td>حساب مجهول أو حديث الإنشاء</td> </tr> <tr> <td>التشفير</td> <td>لقطات مشفّرة</td> <td>بلا تشفير</td> </tr> <tr> <td>التحديث</td> <td>إصدارات حديثة ومتواترة</td> <td>بلا تغيير منذ أكثر من 12 شهرًا</td> </tr> <tr> <td>الوثائق</td> <td>ملاحظات إصدار وثغرات مُعلَنة</td> <td>معدومة أو غير موجودة</td> </tr> <tr> <td>فحصك الخاص</td> <td>بلا ثغرات حرجة ولا أسرار</td> <td>ثغرات أو مفاتيح مضمّنة</td> </tr> <tr> <td>الكلفة</td> <td>نموذج واضح ومتوقَّع</td> <td>تكاليف تخزين خفيّة</td> </tr> </tbody> </table> <p><em>تحقّق من كل بند قبل نقل الصورة إلى الإنتاج.</em></p> <h2 id="ممارسة-جيدة-أعد-الخبز-فوق-ما-تتسلمه">ممارسة جيدة: أعد الخبز فوق ما تتسلّمه</h2> <p>حتى الصورة الموثوقة تشيخ. وأكثر الممارسات أمانًا أن تأخذ صورة أساسية موثوقة و<strong>تعيد خبزها في خطّ إنتاجك</strong>: تطبّق ترقيعاتك وتحصينك وإعدادك، وتشفّرها بمفتاحك وترقّم إصدارها. هكذا ترث ما في الصورة الأصلية من خير وتضيف ضبط جودتك وتتبّعك.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل استخدام صورة AMI عامة من المجتمع آمن؟</strong></p> <p>قد يكون كذلك، لكن عليك التحقّق من المالك والمحتوى والحالة، وفحصها قبل الاستخدام. وللإنتاج يُفضَّل استخدام صورة من ناشر موثوق، أو إعادة خبزها بنفسك.</p> <p><strong>كيف أعرف إن كانت الصورة تحوي بابًا خلفيًا؟</strong></p> <p>لا طريقة معصومة، لكن فحص الصورة ومراجعة المستخدمين والمفاتيح المصرّح بها وتفتيش المهام المجدولة وتحليل حركة الشبكة على نسخة اختبار معزولة يقلّل الخطر كثيرًا.</p> <p><strong>هل أثق بالصور المدفوعة أكثر من المجانية؟</strong></p> <p>السعر لا يضمن الأمان، لكن ناشرًا يصون صوره ويوثّقها —مدفوعة كانت أم لا— يقدّم عادةً ضمانات أكبر من صورة مجهولة مهجورة.</p> <p><em>في imaxe.cloud نبني صورًا بمصدر واضح وتشفير وتحديث مستمر كي تنشر بثقة.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%A7%D9%84%D8%AA%D8%B4%D9%81%D9%8A%D8%B1-%D9%88%D8%A7%D9%84%D8%AA%D8%AD%D8%AF%D9%8A%D8%AB%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D9%8A/2026-06-12T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/cifrado-parches-cumplimiento-cloud_hu_d680a8e49016fa16.webp" alt="آلة التشفير إنيجما ولوحة مفاتيحها ظاهرة" width="1200" height="675"></p><p>تستثمر المؤسسات كثيرًا في حماية الشبكة والتطبيقات، لكنها كثيرًا ما تهمل <strong>الصورة الأساسية</strong> التي يُقلع منها كل شيء. فصورة AMI بحزم قديمة أو بلقطات غير مشفّرة تنشر الخطر إلى كل نسخة تولد منها. والخبر الجيد أن حماية الصورة نقطة تحكّم واحدة وعالية المردود.</p> <p>الثلاثية التي تحلّ ذلك سهلة القول وشاقة الحفاظ: <strong>التشفير</strong> و<strong>الترقيعات</strong> و<strong>الامتثال القابل للإثبات</strong>.</p> <h2 id="1-التشفير-حماية-البيانات-ساكنة-وأثناء-النقل">1. التشفير: حماية البيانات ساكنةً وأثناء النقل</h2> <p>التشفير هو خط الدفاع حين يفشل كل شيء آخر. وهو ينتظم لصور الآلات على مستويات عدة:</p> <ul> <li><strong>لقطات EBS مشفّرة</strong> بـ AWS KMS، أو Azure Disk Encryption وGoogle CMEK في سحابات أخرى.</li> <li><strong>مفاتيح يديرها العميل (CMK)</strong> مع تدوير تلقائي وسياسات وصول دنيا.</li> <li><strong>تشفير افتراضي</strong> مفعَّل على مستوى الحساب كي لا تولد أي صورة بلا تشفير.</li> <li><strong>إدارة الأسرار خارج الصورة</strong>: لا تخبز أبدًا كلمات مرور أو رموزًا؛ احقنها وقت التشغيل عبر Secrets Manager أو Vault أو Parameter Store.</li> </ul> <h2 id="2-الترقيعات-سباق-مع-الثغرات">2. الترقيعات: سباق مع الثغرات</h2> <p>تُنشر ثغرات كل يوم. والصورة آمنة يوم تنشئها، وأقل أمانًا قليلًا كل يوم يمرّ. وإدارة الترقيع في عالم غير قابل للتغيير لا تعني تحديث خوادم حيّة، بل <strong>إعادة الخبز</strong> بوتيرة منتظمة.</p> <ul> <li><strong>إيقاع إعادة البناء</strong>: أعد بناء الصورة الأساسية شهريًا على الأقل، وبشكل عاجل أمام ثغرة حرجة تخصّ منظومتك.</li> <li><strong>فحص داخل خطّ الإنتاج</strong>: ادمج Trivy أو Grype أو Amazon Inspector لاكتشاف الثغرات قبل النشر.</li> <li><strong>بوابة جودة</strong>: امنع النشر إذا ظهرت ثغرات فوق عتبة معيّنة، كالحرجة أو العالية القابلة للاستغلال.</li> <li><strong>SBOM</strong>: ولّد <em>قائمة مكوّنات البرمجيات</em> لتعرف بدقّة ما تحتويه كل صورة وتستجيب بسرعة عند ظهور Log4Shell القادم.</li> </ul> <h2 id="3-الامتثال-أثبت-ولا-تكتف-بالفعل">3. الامتثال: أثبِت ولا تكتفِ بالفعل</h2> <p>في التدقيق لا يكفي أن تكون آمنًا: عليك إثبات ذلك بأدلة. والصور المحكومة جيدًا تولّد ذلك الدليل تلقائيًا.</p> <table> <thead> <tr> <th>الإطار</th> <th>ما يتوقّعه من صورك</th> <th>الدليل الذي يمكنك تقديمه</th> </tr> </thead> <tbody> <tr> <td>SOC 2</td> <td>ضوابط أمنية متّسقة ومراقَبة</td> <td>تقارير التحصين وسجلات البناء</td> </tr> <tr> <td>ISO 27001</td> <td>إدارة الثغرات وضبط التغييرات</td> <td>فحوص الثغرات والترقيم وSBOM</td> </tr> <tr> <td>PCI DSS</td> <td>إعداد آمن وترقيع موثَّق</td> <td>معيار CIS وتاريخ إعادة البناء</td> </tr> <tr> <td>ENS / اللائحة العامة</td> <td>التشفير وتقليل البيانات</td> <td>تشفير KMS وخلوّ الصورة من بيانات شخصية</td> </tr> </tbody> </table> <p><em>كيف تُترجَم ممارسات الصورة الآمنة إلى أدلة امتثال.</em></p> <h2 id="السياق-التنظيمي-الجديد-لعام-2026">السياق التنظيمي الجديد لعام 2026</h2> <p>يزداد المناخ التنظيمي تشدّدًا. ففي 2026 تدخل حيّز النفاذ مراحل أساسية من تنظيم الذكاء الاصطناعي الأوروبي وتوجيهات جديدة لمسؤولية المنتج، وتشدّد ولايات قضائية عدّة متطلبات الحوكمة والامتثال في السحابة. والترجمة العملية: تتبّع ما تشغّله من برمجيات وكيف تؤمّنه لم يعد اختياريًا. وسلسلة صور قابلة للتدقيق هي تأمينك الأفضل.</p> <h2 id="قائمة-تحقق-لأمان-الصورة">قائمة تحقّق لأمان الصورة</h2> <ul> <li>تشفير افتراضي مفعَّل ولقطات بمفتاح CMK.</li> <li>بلا أسرار مخبوزة؛ إدارة خارجية لبيانات الاعتماد.</li> <li>فحص للثغرات في كل بناء مع بوابة جودة.</li> <li>إعادة بناء دورية وعند ظهور ثغرة حرجة.</li> <li>معيار CIS مطبَّق ومُتحقَّق منه.</li> <li>SBOM وسجلات البناء محفوظة كدليل.</li> <li>تقاعد آمن للصور المتقادمة.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>كل كم يجب ترقيع صورة غير قابلة للتغيير؟</strong></p> <p>لا تُرقَّع ساخنة: تُعاد بناؤها. ودورة شهرية حدّ أدنى جيد، مع عمليات بناء استثنائية أمام ثغرات حرجة تمسّ برمجياتك.</p> <p><strong>ما هو SBOM ولماذا أحتاجه؟</strong></p> <p>SBOM هو جرد لكل البرمجيات والتبعيات في صورتك. يتيح لك أن تعرف خلال دقائق إن كانت ثغرة جديدة تمسّك، ويزداد طلبه في مجال الامتثال.</p> <p><strong>هل يؤثّر التشفير في الأداء؟</strong></p> <p>تشفير EBS بـ KMS شفّاف، وأثره في الأداء غير محسوس عمليًا لمعظم الأحمال.</p> <p><em>في imaxe.cloud نطبّق التشفير والفحص والتحديث المستمر على صورنا كي تنطلق من أساس يمكن الدفاع عنه أمام أي تدقيق.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AA%D9%82%D9%88%D9%8A%D8%A9-cis-%D9%84%D8%B5%D9%88%D8%B1-ec2/2026-06-09T00:00:00Z2026-08-22T15:25:49Z

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

<p><img src="https://www.imaxe.cloud/blog-covers/hardening-cis-ami-ec2_hu_8c72206698ec85fc.webp" alt="قفل وسلسلة يغلقان بوابة معدنية" width="1200" height="675"></p><p><strong>معايير CIS</strong> أدلة إعداد آمن ينشرها مركز Center for Internet Security، وتُصاغ بتوافق الخبراء. وهي تغطّي أنظمة التشغيل —Amazon Linux وUbuntu وRHEL وWindows— بمئات التوصيات الملموسة: صلاحيات الملفات، ومعاملات النواة، وسياسات كلمات المرور، والخدمات التي ينبغي تعطيلها، وإعداد التدقيق.</p> <p>تطبيق التحصين على <strong>الصورة</strong> —لا على كل خادم منشور— هو الأكفأ: تحصّن مرة واحدة فتولد كل نسخة آمنة. وهو نهج «الأمان افتراضيًا» الذي تطلبه أطر مثل ISO 27001 وSOC 2 وPCI DSS والأطر الوطنية للأمن.</p> <h2 id="المستويان-l1-وl2-إلى-أي-حد-تشد">المستويان L1 وL2: إلى أي حدّ تشدّ</h2> <p>يعرّف CIS ملفّات بحسب المستوى. وحسن الاختيار يجنّبك كسر التطبيقات بفرط الحماس.</p> <table> <thead> <tr> <th>الملف</th> <th>الهدف</th> <th>متى تستخدمه</th> </tr> </thead> <tbody> <tr> <td>Level 1 (L1)</td> <td>أمان أساسي بلا أثر وظيفي يُذكر</td> <td>نقطة انطلاق لمعظم الأحمال</td> </tr> <tr> <td>Level 2 (L2)</td> <td>دفاع في العمق للبيئات الحسّاسة</td> <td>بيانات منظَّمة ومخاطر عالية؛ قد يحتاج ضبطًا</td> </tr> <tr> <td>STIG</td> <td>متطلبات وزارة الدفاع الأميركية</td> <td>عقود حكومية أو دفاعية</td> </tr> </tbody> </table> <p><em>ملفّات التحصين في CIS ومجال تطبيق كلٍّ منها.</em></p> <h2 id="كيف-تؤتمت-التحصين-داخل-الصورة">كيف تؤتمت التحصين داخل الصورة</h2> <p>التحصين اليدوي لا يتوسّع ولا يقبل التدقيق. وهذه أكثر ثلاث طرق استخدامًا لإدخاله في خطّ البناء:</p> <ul> <li><strong>EC2 Image Builder بمكوّنات CIS</strong>: تقدّم AWS تكاملًا مع مستويات CIS مُدارة تطبّق المعيار وتتحقّق منه أثناء البناء، مع خيار صور CIS Hardened في المتجر.</li> <li><strong>Ansible بدور تحصين</strong>: أعد استخدام أدوار مبنية على CIS للينكس داخل مزوّد في Packer؛ وهي قابلة للنقل بين السحابات.</li> <li><strong>نصوص حيادية التكرار خاصة بك</strong>: لحالات بعينها، بميزة التحكّم الكامل وعيب الصيانة.</li> </ul> <h2 id="ضوابط-عالية-الأثر-لا-ينبغي-أن-تغيب">ضوابط عالية الأثر لا ينبغي أن تغيب</h2> <p>لو اضطررت إلى الترتيب، فهذه الضوابط تعطي أكبر خفض للمخاطر بأقل كلفة:</p> <ul> <li><strong>تعطيل دخول الجذر المباشر عبر SSH</strong> وفرض الدخول بالمفتاح لا بكلمة المرور.</li> <li><strong>إزالة الحزم والخدمات غير الضرورية</strong> لتقليص سطح الهجوم.</li> <li><strong>إعداد جدار حماية المضيف</strong> (firewalld أو nftables) بمنع افتراضي.</li> <li><strong>تفعيل التدقيق</strong> (<code>auditd</code>) وتسجيل الأحداث مركزيًا.</li> <li><strong>تطبيق معاملات نواة آمنة</strong> (<code>sysctl</code>) ضد الانتحال وهجمات الشبكة.</li> <li><strong>سياسات صارمة لكلمات المرور وقفل الحسابات.</strong></li> <li><strong>صلاحيات صحيحة على الملفات الحرجة</strong>: <code>/etc/passwd</code> و<code>/etc/shadow</code> وأدلة الإقلاع.</li> </ul> <h2 id="تحقق-من-أن-التحصين-طبق-فعلا">تحقّق من أن التحصين طُبّق فعلًا</h2> <p>التحصين بلا تحقّق فعل إيمان. أدرج مرحلة تحقّق مؤتمتة تُقيّم الصورة مقابل المعيار وتُفشل البناء إن لم تبلغ العتبة.</p> <ul> <li><strong>CIS-CAT أو InSpec أو OpenSCAP</strong> تفحص النسخة الحديثة الخبز وتنتج تقرير امتثال.</li> <li><strong>عتبة النجاح</strong>: حدّد مثلًا «اجتياز ≥ 95 % من ضوابط L1» كبوابة جودة.</li> <li><strong>دليل للتدقيق</strong>: احفظ التقرير كمخرج للبناء؛ سيكون ذهبًا خالصًا في تدقيقك القادم SOC 2 أو ISO.</li> </ul> <h2 id="التوازن-أمان-بلا-كسر-التطبيق">التوازن: أمان بلا كسر التطبيق</h2> <p>الخطأ الكلاسيكي تطبيق L2 على العمياء ثم اكتشاف أن التطبيق لم يعد يُقلع. والاستراتيجية الحكيمة: ابدأ بـ L1، وقِس، وارفع ضوابط L2 انتقائيًا بالاختبار في بيئة تهيئة. ووثّق كل استثناء مبرَّر؛ فضابط مُعطَّل بسبب مسجَّل مقبول في التدقيق، أما المعطَّل في صمت فلا.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>هل يُبطئ تحصين CIS نسخي؟</strong></p> <p>أثر ملف L1 في الأداء منعدم عمليًا. وبعض ضوابط التدقيق المكثّف في L2 قد تضيف عبئًا، ولذلك تُطبَّق انتقائيًا وتُقاس.</p> <p><strong>هل عليّ شراء صور CIS Hardened أم يمكنني فعلها بنفسي؟</strong></p> <p>يمكنك التحصين بنفسك عبر Ansible أو OpenSCAP أو مكوّنات EC2 Image Builder. وصور CIS Hardened في المتجر توفّر جهدًا وتأتي بتحقّق مضمّن، لكنها ليست ضرورية.</p> <p><strong>هل يكفي التحصين للامتثال لـ ISO 27001 أو PCI DSS؟</strong></p> <p>التحصين ضابط تقني مهم، لكن الامتثال يشمل أيضًا العمليات والسياسات والأدلة. تحصين صورك يقرّبك كثيرًا، لكنه لا يغني عن بقية إطار الامتثال.</p> <p><em>في imaxe.cloud ننطلق من صور مُحصَّنة وفق ممارسات القطاع الجيدة كي تنشر على أساس آمن.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-ami/2026-06-05T00:00:00Z2026-08-22T15:25:49Z

إنشاء صورة AMI سهل؛ أما حوكمتها عبر الزمن فهي ما يفصل فريقًا محترفًا عن مقبرة صور يتيمة وفواتير منتفخة. هذا هو الدليل الكامل لترقيم صورك وتشفيرها وتنظيفها بلا ألم.

<p><img src="https://www.imaxe.cloud/blog-covers/ciclo-de-vida-ami_hu_d04b0e8cea647c79.webp" alt="قرص ورأس قراءة داخل قرص صلب مفتوح" width="1200" height="675"></p><p>تتعامل فرق كثيرة مع صورة AMI كشيء يُنشأ مرة ثم يُنسى. وتظهر المشكلة بعد أشهر: عشرات الصور بلا وسوم، ولقطات EBS لا يعرف أحد إن كان يمكن حذفها، وفاتورة تنمو بلا تفسير. إن إدارة <strong>دورة حياة صورة AMI</strong> تعني معاملتها كقطعة برمجية لها ميلاد وإصدارات ونضج وإهمال وتقاعد.</p> <p>الحوكمة الجيدة للصور تخفّض التكاليف وتحسّن الأمان —فلا يُطلق أحد بالخطأ صورة غير مُرقَّعة عمرها سنة— وتسهّل تدقيقات الامتثال.</p> <h2 id="المرحلة-1--ترقيم-الإصدارات-بمعنى">المرحلة 1 — ترقيم الإصدارات بمعنى</h2> <p>الترقيم هو العمود الفقري. من دونه تصبح «آخر صورة AMI جيدة» حديث ممرّات لا معطى موثوقًا. ننصح بمخطط مقروء ومتّسق.</p> <ul> <li><strong>اسم مُرقَّم</strong>: مثلًا <code>imaxe-ubuntu22-nginx-2026.07.1</code>، بالمنتج والأساس وإصدار التقويم.</li> <li><strong>وسوم إلزامية</strong>: <code>Version</code> و<code>GitCommit</code> و<code>BuildDate</code> و<code>Owner</code> و<code>Environment</code> و<code>CISLevel</code> و<code>Status</code>.</li> <li><strong>غير قابلة للتغيير: إصدار واحد وقطعة واحدة.</strong> لا تعدّل أبدًا صورة منشورة؛ أنشئ إصدارًا جديدًا.</li> <li><strong>سجلّ مركزي</strong>: استخدم AWS Systems Manager Parameter Store لحفظ معرّف «صورة الإنتاج الحالية» كي تقرأها قوالب الإطلاق بالإشارة.</li> </ul> <h2 id="المرحلة-2--تشفير-من-طرف-إلى-طرف">المرحلة 2 — تشفير من طرف إلى طرف</h2> <p>بيانات الصورة تعيش في لقطات EBS. وإن لم تكن مشفّرة فأي نسخة سيئة الحوكمة تسريب محتمل. ينبغي أن يكون التشفير هو القاعدة لا الاستثناء.</p> <ul> <li><strong>تشفير افتراضي</strong>: فعّل <em>EBS encryption by default</em> على مستوى الحساب والمنطقة.</li> <li><strong>مفاتيح تديرها أنت (CMK)</strong>: استخدم مفتاح KMS خاصًا بدل مفتاح AWS الافتراضي للتحكّم في الصلاحيات والتدوير.</li> <li><strong>النسخ يعني إعادة التشفير</strong>: عند نسخ صورة إلى منطقة أو حساب آخر، اغتنم الفرصة لإعادة تشفيرها بمفتاح الوجهة.</li> <li><strong>شارك عبر KMS grants</strong>: إن وزّعت الصورة على حسابات أخرى، امنح الوصول إلى المفتاح بسياسات دنيا.</li> </ul> <h2 id="المرحلة-3--الإهمال-أنذر-قبل-الحذف">المرحلة 3 — الإهمال: أنذر قبل الحذف</h2> <p>تتيح AWS وسم صورة بأنها <strong>مهملة</strong> (<em>deprecated</em>) بتاريخ محدّد. ومن تلك اللحظة تكفّ عن الظهور افتراضيًا في عمليات البحث، لكنها تظلّ تعمل لمن يشير إليها صراحةً. إنها الخطوة الوسطى المتحضّرة بين «سارية» و«محذوفة»: تنذر، وتمنح مهلة للانتقال، وتتفادى كسر عمليات النشر.</p> <h2 id="المرحلة-4--تنظيف-آلي-والكلفة-الخفية-للقطات">المرحلة 4 — تنظيف آلي (والكلفة الخفيّة للّقطات)</h2> <p>هنا يكمن المال. عندما تحذف صورة AMI، فإن لقطات EBS المرتبطة بها <strong>لا تُحذف تلقائيًا</strong>. هذا هو السبب الأول لفواتير تخزين تنمو بشكل غامض. ينبغي لسياسة التقاعد أن تُلغي تسجيل الصورة ثم تحذف لقطاتها اليتيمة.</p> <ul> <li><strong>سياسة احتفاظ</strong>: أبقِ على N إصدارات حديثة (الثلاثة الأخيرة مثلًا) وأحِل الباقي للتقاعد.</li> <li><strong>أتمِت عبر السحابة</strong>: يمكن لـ Amazon Data Lifecycle Manager (DLM) إدارة إنشاء الصور وحذفها بسياسة.</li> <li><strong>اصطَد اللقطات اليتيمة</strong>: دقّق دوريًا في اللقطات التي لا صورة مرتبطة بها واحذفها.</li> <li><strong>لا تحذف على العمياء أبدًا</strong>: تأكّد قبل التقاعد أن لا نسخة عاملة ولا قالب إطلاق نشط يعتمد على الصورة.</li> </ul> <h2 id="جدول-ملخص-لدورة-الحياة">جدول ملخّص لدورة الحياة</h2> <table> <thead> <tr> <th>المرحلة</th> <th>الإجراء الأساسي</th> <th>الأداة أو الخدمة</th> </tr> </thead> <tbody> <tr> <td>الإنشاء</td> <td>بناء قابل للتكرار مع وسوم</td> <td>Packer / EC2 Image Builder</td> </tr> <tr> <td>التشفير</td> <td>لقطات مشفّرة بمفتاح CMK</td> <td>AWS KMS + EBS default encryption</td> </tr> <tr> <td>التوزيع</td> <td>نسخ وإعادة تشفير عبر المناطق أو الحسابات</td> <td>AMI copy / AWS RAM</td> </tr> <tr> <td>السريان</td> <td>سجلّ المعرّف الحالي</td> <td>SSM Parameter Store</td> </tr> <tr> <td>الإهمال</td> <td>الوسم بالإهمال مع تاريخ</td> <td><code>ec2 enable-image-deprecation</code></td> </tr> <tr> <td>التقاعد</td> <td>إلغاء التسجيل وحذف اللقطات</td> <td>DLM / نصوص مجدولة</td> </tr> </tbody> </table> <p><em>مراحل حوكمة الصورة الست وكيفية أتمتتها.</em></p> <h2 id="مؤشرات-ينبغي-مراقبتها">مؤشرات ينبغي مراقبتها</h2> <ul> <li><strong>متوسط عمر</strong> الصور المستخدمة: كلما قلّ كان الترقيع أفضل.</li> <li><strong>عدد اللقطات اليتيمة</strong> وكلفتها الشهرية.</li> <li><strong>نسبة الصور المشفّرة</strong>، والهدف 100 %.</li> <li><strong>الزمن من الثغرة الحرجة إلى نشر الصورة الجديدة</strong>، أي زمن الإصلاح الوسطي للترقيعات.</li> </ul> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>لماذا ترتفع فاتورة EBS وقد حذفت الصور أصلًا؟</strong></p> <p>لأن إلغاء تسجيل الصورة لا يحذف لقطاتها. عليك حذفها صراحةً. دقّق في اللقطات اليتيمة بانتظام؛ فهي غالبًا أكبر كلفة خفيّة.</p> <p><strong>هل مشاركة صورة مشفّرة مع حساب آخر آمنة؟</strong></p> <p>نعم، ما دمت تمنح الوصول إلى مفتاح KMS بمنحة محدّدة وصلاحيات دنيا. فمن دون ذلك الوصول لن يستطيع حساب الوجهة إطلاق الصورة.</p> <p><strong>كم إصدارًا من الصورة ينبغي أن أحتفظ به؟</strong></p> <p>يعتمد على حاجتك للتراجع وعلى الامتثال، لكن الاحتفاظ بإصدارين إلى أربعة إصدارات حديثة عادةً توازن جيد بين أمان التراجع والكلفة.</p> <p><em>في imaxe.cloud نصمّم صورنا بترقيم إصدارات وتشفير منذ المنشأ، كي تكون دورة حياتها متوقَّعة وقابلة للتدقيق.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/%D8%AE%D8%B7-%D8%A7%D9%86%D8%AA%D8%A7%D8%AC-golden-ami-packer/2026-06-02T00:00:00Z2026-08-22T15:25:49Z

صورة golden AMI مبنية جيدًا هي الفرق بين النشر في ثوانٍ بثقة، والتصارع مع خوادم لا تتشابه أبدًا. في هذا الدليل التقني نركّب خطّ إنتاج قابلًا للتكرار بـ Packer وجاهزًا للإنتاج.

<p><img src="https://www.imaxe.cloud/blog-covers/golden-ami-packer-pipeline_hu_cdeb95d898f689f8.webp" alt="خزائن خوادم في غرفة أنظمة" width="1200" height="675"></p><p><strong>صورة golden AMI</strong> («الصورة الذهبية») هي صورة Amazon Machine Image مُهيّأة مسبقًا ومُحصَّنة ومُتحقَّق منها، تعمل قالبًا وحيدًا لإطلاق نسخ EC2 متطابقة. فبدل إقلاع خادم فارغ وتثبيت التبعيات يدويًا في كل مرة، تخبز كل شيء مرة واحدة —نظام تشغيل مُرقَّع ووكلاء وبيئة تشغيل وإعداد وضوابط أمان— وتعيد استخدامه في كل عملية نشر.</p> <p>هذا النهج أساس <strong>البنية التحتية غير القابلة للتغيير</strong>: لا تُرقّع الخوادم وهي تعمل، بل تبني صورة جديدة وتستبدل النسخ. والنتيجة انحراف أقل في الإعداد، وإقلاع أسرع عند التوسّع التلقائي، وعمليات نشر قابلة للتدقيق والتراجع.</p> <h2 id="الصورة-الذهبية-مقابل-التهيئة-عند-الإقلاع">الصورة الذهبية مقابل التهيئة عند الإقلاع</h2> <p>هناك فلسفتان. في <strong>التهيئة عند الإقلاع</strong> تُعِدّ النسخة نفسها عند بدء التشغيل (user-data أو Ansible pull أو cloud-init). وهي مرنة لكنها بطيئة وهشّة: إذا سقط مستودع حزم فشل توسّعك التلقائي. أما في نموذج <strong>الصورة الذهبية (الخبز)</strong> فيجري العمل الثقيل مرة واحدة في خطّ الإنتاج؛ والإقلاع شبه فوري وحتمي. ومعظم الفرق الناضجة تمزج الاثنين: تخبز الثابت وتترك للإقلاع الإعداد الذي يتغيّر بحسب البيئة.</p> <h2 id="لماذا-packer">لماذا Packer</h2> <p>Packer من HashiCorp هو الأداة المعيارية فعليًا لبناء صور الآلات آليًا وعبر عدة سحابات من قالب واحد. تُعرِّف الصورة كشيفرة (HCL2)؛ فيُطلق نسخة مؤقتة، ويطبّق مزوّداتك، وينشئ الصورة، ثم يدمّر الموارد المؤقتة. ويستطيع القالب نفسه توليد صور لـ AWS وAzure وGCP، وهو ما يجعله مثاليًا إن كنت تنشر في أكثر من سحابة.</p> <ul> <li><strong>قابل للتكرار</strong>: الصورة موصوفة في ملف مُرقَّم الإصدارات في Git.</li> <li><strong>متعدّد السحابات</strong>: تدفّق واحد لـ AMI وAzure Managed Image وGCP Custom Image.</li> <li><strong>قابل للدمج</strong>: يندمج في CI/CD (GitHub Actions وGitLab CI وCodePipeline).</li> <li><strong>قابل للتدقيق</strong>: كل عملية بناء تُسجَّل مع بيانها ومخرجاتها.</li> </ul> <h2 id="تشريح-قالب-packer-hcl2">تشريح قالب Packer (HCL2)</h2> <p>ينتظم القالب الحديث في كتل. تُعرِّف كتلة <strong>source</strong> الباني (مثل <code>amazon-ebs</code>) والصورة الأساسية ونوع النسخة والمنطقة. وتسلسل كتلة <strong>build</strong> <strong>المزوّدات</strong> التي تثبّت البرمجيات وتعدّها. أما <strong>المعالِجات اللاحقة</strong> فتنتج مخرجات مثل بيان JSON يحمل معرّف الصورة الناتجة.</p> <h3 id="مثال-أدنى-مشروح">مثال أدنى مشروح</h3> <p><code>source &quot;amazon-ebs&quot; &quot;app&quot;</code> — ينطلق من صورة أساسية رسمية تُبحث ديناميكيًا عبر <code>data &quot;amazon-ami&quot;</code> بترشيح المالك ونمط الاسم، كي لا تثبّت معرّفًا سينتهي أجله.</p> <p><code>provisioner &quot;shell&quot;</code> — ينفّذ نصوص التثبيت والتحديث (<code>dnf update -y</code>، وتثبيت بيئة التشغيل ووكيل CloudWatch ووكيل SSM).</p> <p><code>provisioner &quot;ansible&quot;</code> — إن كانت لديك أدوار Ansible فأعد استخدامها لإعداد الصورة بحياد تكراري.</p> <p><code>post-processor &quot;manifest&quot;</code> — يكتب <code>manifest.json</code> مع <code>artifact_id</code> الذي يقرأه خطّ إنتاجك ليعرف أي صورة وُلدت.</p> <h2 id="خط-الإنتاج-خطوة-بخطوة">خطّ الإنتاج خطوة بخطوة</h2> <p>هذا هو التدفّق الذي نوصي به لنقل صورة ذهبية من الالتزام إلى الإنتاج بأمان وقابلية تكرار:</p> <table> <thead> <tr> <th>الخطوة</th> <th>ماذا يحدث</th> <th>الأداة المعتادة</th> </tr> </thead> <tbody> <tr> <td>1. Commit</td> <td>تعدّل القالب أو النصوص وتدفعها إلى Git</td> <td>Git / مراجعة الطلب</td> </tr> <tr> <td>2. Validate</td> <td>يتحقّق <code>packer fmt</code> و<code>packer validate</code> من الصياغة</td> <td>Packer وCI</td> </tr> <tr> <td>3. Build</td> <td>يُطلق Packer نسخة مؤقتة ويطبّق المزوّدات</td> <td>Packer</td> </tr> <tr> <td>4. Harden</td> <td>يُطبَّق معيار CIS وتُنظَّف بيانات الاعتماد</td> <td>Ansible / CIS</td> </tr> <tr> <td>5. Scan</td> <td>فحص للثغرات وللأسرار</td> <td>Trivy وInspector</td> </tr> <tr> <td>6. Test</td> <td>تُقلَع نسخة ويجري التحقّق منها</td> <td>InSpec / Goss</td> </tr> <tr> <td>7. Tag &amp; version</td> <td>تُوسَم الصورة (الإصدار والالتزام والتاريخ)</td> <td>AWS CLI</td> </tr> <tr> <td>8. Distribute</td> <td>تُشارَك أو تُنسَخ إلى مناطق أو حسابات أخرى</td> <td>AWS RAM / copy</td> </tr> <tr> <td>9. Deploy</td> <td>يُشار إلى الصورة في قالب الإطلاق</td> <td>Terraform / ASG</td> </tr> </tbody> </table> <p><em>تدفّق مرجعي لخطّ إنتاج صورة ذهبية في تسع مراحل.</em></p> <h2 id="ممارسات-تصنع-الفارق">ممارسات تصنع الفارق</h2> <ul> <li><strong>لا تثبّت صورة أساسية بمعرّفها أبدًا</strong>: ابحث عنها ديناميكيًا بالمالك والاسم لترث دومًا أحدث الترقيعات.</li> <li><strong>رقّم إصدار الصورة</strong> بمخطط واضح (مثل <code>app-2026.07.1</code>) واحفظ التزام Git في وسوم الصورة.</li> <li><strong>نظّف قبل الختم</strong>: احذف السجلات وتواريخ الصدفة ومفاتيح SSH المؤقتة ومخابئ الحزم كي لا تسرّب أسرارًا.</li> <li><strong>افحص دائمًا</strong>: ادمج Trivy أو Amazon Inspector كي لا تنشر ثغرات معروفة.</li> <li><strong>شفّر اللقطات</strong> بمفتاح KMS خاص بك منذ الدقيقة الأولى.</li> <li><strong>أتمِت انتهاء الصلاحية</strong>: علّم الإصدارات القديمة بالإهمال واحذفها لضبط التكاليف.</li> </ul> <h2 id="packer-أم-ec2-image-builder-أيهما-أختار">Packer أم EC2 Image Builder: أيّهما أختار؟</h2> <p>إن كنت تعمل حصرًا في AWS وتقدّر التكامل الأصيل مع Inspector ومكوّنات CIS المُدارة وصفر بنية تحتية تصونها، فـ <strong>EC2 Image Builder</strong> خيار متين بلا كلفة ترخيص. أما إن احتجت البناء لعدة سحابات من القالب نفسه، أو كانت لديك منظومة HashiCorp (Terraform وVault)، فسيمنحك <strong>Packer</strong> قابلية نقل أكبر. وهما لا يتعارضان: فرق كثيرة تستخدم Packer لمنطق تعدّد السحابات وImage Builder لخطوط الإنتاج الداخلية في AWS.</p> <h2 id="أسئلة-شائعة">أسئلة شائعة</h2> <p><strong>كل كم ينبغي أن أعيد بناء الصورة الذهبية؟</strong></p> <p>كحدّ أدنى مع كل دورة ترقيع لنظام التشغيل (الشهري إيقاع جيد عادةً)، وكلما ظهرت ثغرة حرجة في منظومتك. ويسمح خطّ الإنتاج المؤتمت بإعادة البناء عند الطلب خلال دقائق.</p> <p><strong>هل أستطيع استخدام قالب Packer نفسه لـ AWS وAzure؟</strong></p> <p>نعم. يدعم Packer عدة بانين في عملية بناء واحدة. تتشارك المزوّدات وتغيّر كتلة source لكل سحابة فقط، فتُنتج صورة AMI وManaged Image وCustom Image بالتوازي.</p> <p><strong>صورة ذهبية أم حاويات؟</strong></p> <p>ليست مسألة أحدهما. فالصور الذهبية مثالية لطبقة المضيف وللأحمال غير المُحوَّاة؛ أما الحاويات فتعيش فوقها. بل إن صورة ذهبية مُحصَّنة أساس ممتاز لعُقد Kubernetes لديك.</p> <p><em>في imaxe.cloud نبني ونصون صورًا أساسية مُحصَّنة ومحدَّثة كي ينطلق خطّ إنتاجك من أساس موثوق.</em></p>https://www.imaxe.cloud/ar/%D9%85%D8%AF%D9%88%D9%86%D8%A9/zabbix-7-lts/2026-05-28T00:00:00Z2026-08-22T15:25:49Z

واجهة أمامية مُجدَّدة، وأدوات SLA، وقارئ SQS مُعاد كتابته. نستعرض جديد خط LTS الجديد وكيفية الترحيل من 6.0 دون فقدان السِّجِل.

<p><img src="https://www.imaxe.cloud/blog-covers/zabbix-7-lts_hu_a2d5ca0fc6cd5b29.webp" alt="شاشات تشخيص في غرفة تحكم" width="1200" height="675"></p>