لماذا بدأت فرق Azure أخيرًا في التخلي عن قوالب ARM
By Mirko Peters ·
لسنوات، واجه مهندسو السحابة والمطوّرون الذين يعملون مع Microsoft Azure واقعًا مزدوج الطابع عند تبني البنية التحتية كشيفرة (IaC). فمن ناحية، وفّرت قوالب Azure Resource Manager (ARM) طريقة أصيلة وقوية لتوفير البنية التحتية السحابية وإدارتها بموثوقية. ومن ناحية أخرى، كان كتابة تلك القوالب وصيانتها تعني التعامل مع ملفات JSON مطوّلة، وتداخلات عميقة، وبنى شيفرة متضخمة، وتعارضات دمج مؤلمة في كل مرة يعدّل
Automatically translated with AI from the original post. Read the English original

لسنوات، واجه مهندسو السحابة والمطوّرون الذين يعملون مع Microsoft Azure واقعًا مزدوج الطابع عند تبني البنية التحتية كشيفرة (IaC). فمن ناحية، وفّرت قوالب Azure Resource Manager (ARM) طريقة أصيلة وقوية لتوفير البنية التحتية السحابية وإدارتها بموثوقية. ومن ناحية أخرى، كان كتابة تلك القوالب وصيانتها تعني التعامل مع ملفات JSON مطوّلة، وتداخلات عميقة، وبنى شيفرة متضخمة، وتعارضات دمج مؤلمة في كل مرة يعدّل فيها أحد أعضاء الفريق المستودع. إذا سبق أن قضيت ساعات في تتبّع قوس في غير موضعه أو فاصلة غير مرئية في مستند JSON من ألف سطر، فأنت تعرف تمامًا نوع الإحباط الذي يرافق عمليات النشر التقليدية في Azure.
لحسن الحظ، تطوّر المشهد السحابي. فتتخلى فرق Azure تدريجيًا عن قوالب ARM الخام لصالح Bicep، وهي لغة خاصة بالمجال أنظف وأسهل على البشر، صُمّمت لتجريد نقاط الألم في JSON دون التفريط في موثوقية Azure Resource Manager الكامنة. في هذا الدليل الشامل، سنستعرض أسباب هذا التحول، وكيفية عمل Bicep في الخلفية، ولماذا يمكن للانتقال إليها أن يقلّص قاعدة شيفرة البنية التحتية لديك بنسبة تصل إلى 60%.
مقدمة في إرهاق قوالب ARM
لفهم سبب استحواذ Bicep على اهتمام مجتمع Azure بهذا الشكل، نحتاج أولًا إلى تشخيص السبب الجذري لإرهاق قوالب ARM. عندما عمّمت Azure في البداية النشر القائم على القوالب، كانت JSON المعيار الشامل لتبادل البيانات. غير أن JSON لم تُصمَّم يومًا لتكون لغة برمجة أو أداة لتعريف البنية التحتية. ومع ازدياد حجم البيئات السحابية وتعقيدها، بدت حدود JSON واضحة للعيان.
يتضاعف التعقيد بصورة كبيرة مع قوالب ARM التقليدية. فنشر مؤسسي اعتيادي يشمل الشبكات الافتراضية والشبكات الفرعية وخزائن المفاتيح والهويات المُدارة يتضخم بسرعة إلى ملفات متضخمة تمتد لآلاف الأسطر. ولأن JSON تفتقر إلى بنى تكرار أصيلة أو إمكانات تجزئة متقدمة جاهزة، يلجأ المهندسون غالبًا إلى دوال نسخ معقدة وتداخلات فوضوية. وعندما يحاول أعضاء عديدون في الفريق التعاون على ملف القالب الضخم نفسه، تصبح تعارضات الدمج المتكررة أمرًا حتميًا لا استثناءً. ويشبه تصحيح هذه الملفات البحث عن إبرة في كومة قش رقمية، وهو ما يدفع كثيرًا من الفرق إلى التخلي عن البنية التحتية كشيفرة الآلية بالكامل لصالح النقر اليدوي المعرّض للأخطاء في البوابة، وهو ما ينسف الغاية من أتمتة DevOps تمامًا.
نظرة عامة على Bicep
إدراكًا لهذه الآلام الواسعة الانتشار لدى المطوّرين، قدّمت Microsoft لغة Bicep بوصفها طبقة تجريد شفافة فوق قوالب ARM. فBicep ليست بديلًا عن Azure Resource Manager، بل هي طريقة أذكى وأكثر إيجازًا للتعامل معها. كل ما يمكنك فعله في قالب ARM يمكنك فعله في Bicep، ولكن بجزء صغير من العبء الذهني.
تقوم Bicep في جوهرها على صياغة مبسّطة تكاد تُقرأ كالإنجليزية العادية. فهي تزيل ضجيج صياغة JSON، ولا داعي فيها لعلامات الاقتباس والأقواس والفواصل التي لا تنتهي، وتستبدلها بتعريفات تصريحية نظيفة. ولأن Bicep لغة مُترجمة (compiled)، فإن شيفرتك هي المرجع الأساسي، ثم تُحوَّل إلى قالب ARM قياسي بصيغة JSON أثناء مرحلة النشر. تضمن هذه البنية الذكية توافقًا تامًا بنسبة 100% مع محرك النشر الأساسي في Azure، مع تحسين تجربة المطوّر اليومية بصورة ملحوظة.
كيف تعمل Bicep
يساعد فهم آليات Bicep على توضيح كيفية سدّها للفجوة بين سهولة القراءة للبشر والتنفيذ على الآلات. فعندما تكتب شيفرة البنية التحتية باستخدام Bicep، فإنك تنشئ ملفات تنتهي بالامتداد .bicep. وتستخدم هذه الملفات لغة خاصة بالمجال مُحسّنة تحديدًا لتوفير موارد Azure.
سير العمل بسيط بشكل مُنعش:
- التأليف: تُنشئ ملفات
.bicepوتحررها محليًا باستخدام بيئات التطوير المتكاملة الحديثة مثل Visual Studio Code، مستفيدًا من الإضافات الغنية التي توفر IntelliSense والتحقق من الصياغة والتدقيق اللحظي للشيفرة. - الترجمة: باستخدام أمر واجهة سطر أوامر Bicep
bicep build main.bicep، تُترجم شيفرتك النظيفة إلى قالب ARM قياسي بصيغة JSON. - النشر: تنشر القالب الناتج مباشرةً إلى Azure باستخدام Azure CLI أو Azure PowerShell كما هو معتاد دائماً.
تضمن خطوة التحويل هذه بقاء محرك النشر الأساسي في Azure دون تغيير، ما يعني أن نهج المؤسسة، وعناصر التحكم في الوصول المستندة إلى الأدوار، وفحوصات أمان النشر تستمر في العمل بسلاسة.
فوائد Bicep
يحقق الانتقال من قوالب ARM المعتمدة على JSON إلى Bicep عوائد فورية وقابلة للقياس لمؤسسات الهندسة. وأولها وأهمها الانخفاض الكبير في حجم الشيفرة. تفيد الفرق بانتظام بتقليص الشيفرة بنسبة تصل إلى 50% إلى 60%، أي أسطر أقل للكتابة والمراجعة والصيانة.
علاوةً على ذلك، يعزز Bicep التعاون داخل الفريق بشكل ملحوظ. فمن خلال تقسيم تعريفات البنية التحتية إلى وحدات أصغر قابلة لإعادة الاستخدام، يمكن لأعضاء فريق مختلفين العمل على مكونات منفصلة من البنية المعمارية في الوقت نفسه دون أن يعرقل بعضهم عمل بعض. يصبح التحكم في الإصدارات أنظف بكثير، وتستغرق مراجعات الشيفرة دقائق بدلاً من ساعات، ويتحول تأهيل المهندسين الجدد لمشاريع السحابة إلى تجربة سلسة بدلاً من أن يكون اختباراً قاسياً يُلقى فيه المرء في خضم العمل مباشرةً.
الشروع في استخدام Bicep
لا يتطلب البدء مع Bicep جهداً يُذكر. ولأن Bicep CLI خفيفة الوزن ومتكاملة بشكل أصيل مع Azure CLI، يمكن الشروع في العمل على Windows أو macOS أو Linux خلال دقائق معدودة.
للبدء، تأكد من تثبيت Azure CLI إلى جانب Visual Studio Code. ثبّت الإضافة الرسمية Bicep لـ VS Code لتفعيل ميزات متقدمة مثل إكمال الشيفرة، والتحقق من المعاملات، والاكتشاف التلقائي لأنواع الموارد. وبعد الإعداد، لا تستغرق كتابة أول مورد، مثل Azure Storage Account أو Virtual Network، سوى بضعة أسطر نظيفة، بدلاً من عشرات الأسطر من هيكل JSON الكثيف.
حالات استخدام Bicep
يتألق Bicep بشكل خاص في سيناريوهين رئيسيين للمؤسسات: تطبيقات البنية التحتية كشيفرة (IaC) الأساسية، وعمليات النشر متعددة البيئات.
في مسارات IaC القياسية، يتكامل Bicep بسهولة مع منصات CI/CD مثل GitHub Actions وAzure DevOps، ما يتيح عمليات نشر آلية بالكامل وقابلة للتكرار تقضي على انحراف الإعدادات. أما في البنى متعددة البيئات، مثل التطوير والاختبار والتجهيز والإنتاج، فإن دعم Bicep للمعاملات والقوالب الوحدوية يتيح الحفاظ على قاعدة شيفرة واحدة وموحدة، مع حقن المتغيرات والإعدادات الخاصة بكل بيئة بأمان وعند الحاجة.
الأسئلة المتداولة
ما هو Bicep؟
Bicep لغة شفافة ومفتوحة المصدر خاصة بالمجال، أنشأتها Microsoft لنشر موارد Azure بشكل تصريحي وبصياغة أنظف من قوالب ARM التقليدية.
ما الفرق بين Bicep وقوالب ARM؟
بينما تستخدم قوالب ARM صياغة JSON مطولة يصعب قراءتها وصيانتها، يوفر Bicep صياغة موجزة وسهلة القراءة مع أدوات دعم متقدمة. تُترجم ملفات Bicep إلى قوالب ARM قبل النشر.
هل يمكن تحويل قوالب ARM الحالية إلى Bicep؟
نعم! يمكن فك تجميع قوالب ARM بصيغة JSON الحالية إلى ملفات Bicep بسهولة باستخدام Bicep CLI، والاستفادة فوراً من صياغته المبسطة.
هل Bicep مجاني؟
نعم، Bicep مجاني تماماً ومفتوح المصدر، وتدعمه Microsoft بالكامل كمكوّن من الدرجة الأولى لإدارة البنية التحتية في Azure.
هل يدعم Bicep التقسيم إلى وحدات؟
بالتأكيد. صُمم Bicep منذ البداية ليدعم تصميم الشيفرة الوحدوي، ما يتيح تقسيم عمليات نشر البنية التحتية الكبيرة إلى مكونات قابلة لإعادة الاستخدام وسهلة الإدارة.
لم يعد التخلي عن قوالب ARM القديمة خياراً تجريبياً للفرق الطموحة فحسب، بل أصبح المعيار الأساسي لهندسة Azure الفعّالة والقابلة للتوسع. فمن خلال تقليص تعقيد الشيفرة، وتعزيز التعاون، وتبسيط النشر متعدد البيئات، يمكّن Bicep المحترفين في مجال السحابة من التركيز على بناء برمجيات متميزة بدلاً من الانشغال بملفات الإعدادات.
لاستكشاف هذا الموضوع بعمق والاستماع إلى رؤى عملية حول كيفية تحديث الفرق الحديثة لاستراتيجيات السحابة لديها، يُرجى متابعة حلقة البودكاست ذات الصلة: Bicep - Simply Explained.