هل سئمت من العبث بملف Dockerfile؟ تعد ملفات Dockerfiles وصور Docker طريقة رائعة لتعبئة تطبيقك للاستخدام في حاويات قابلة لإعادة الاستخدام. ومع ذلك، فإن كتابة وصيانة ملف Dockerfile ليس أمرًا بديهيًا دائمًا، ويستغرق وقتًا كان من الممكن استخدامه لإضافة ميزات إلى تطبيقك. أدخل Cloud Native Buildpacks. توجد حزم البناء لجمع كل ما يحتاجه تطبيقك للتشغيل ووضعه في صورة مبادرة الحاويات المفتوحة (OCI) - لا يلزم وجود ملف Dockerfile.
بالنسبة لجميع المطورين الذين يحتاجون إلى عملية بناء حاويات سهلة الاستخدام وتوفر عليهم الوقت والجهد، فقد تكون Cloud Native Buildpacks هي الحل الذي يبحثون عنه. هل أنت مهتم؟ سأخبرك بالمزيد.
ما هي حزم البناء السحابية الأصلية؟
بشكل عام، تأخذ حزمة البناء كود التطبيق وتجعله قابلاً للتشغيل من خلال عملية البناء. بعد ذلك، تأخذ حزم البناء السحابية الأصلية كود مصدر التطبيق وتحوله إلى صور OCI قابلة للتشغيل والتكرار، وتنفذ متطلباتك الخاصة بأمان الصورة وتحسين الأداء وترتيب بناء الحاوية. الأمر أشبه بالحصول على ملف Dockerfile الذي تحتاجه بالضبط — فقط لا تحتاج إلى كتابته.
في حين أن معظم المطورين يستطيعون كتابة ملفات Dockerfile، إلا أن قِلة منهم خبراء في Docker أو البنية الأساسية. تحتوي العديد من التطبيقات على ملفات Dockerfiles التي تم تجميعها من مقتطفات التعليمات البرمجية الموجودة عبر الويب — غالبًا ما تكون مزيجًا من Copilot وStack Overflow وChatGPT. يمكن أن تؤدي أخطاء ملفات Dockerfile إلى تطبيقات غير آمنة وقليلة الأداء.
تتحمل حزم البناء السحابية الأصلية هذا العبء، حيث تطبق تلقائيًا أفضل الممارسات لكل لغة أو إطار عمل. ثم يمكن للمنشئ استخدام أي عدد من حزم البناء ، والكشف تلقائيًا عن حزم البناء المطلوبة وتطبيقها لبناء تطبيق. فيما يلي حزم البناء التي يدعمها منشئ Heroku حاليًا:
$ pack builder inspect heroku/builder:24 Inspecting builder: heroku/builder:24 REMOTE: Description: Ubuntu 24.04 AMD64+ARM64 base image with buildpacks for .NET, Go, Java, Node.js, PHP, Python, Ruby & Scala. ... Buildpacks: ID NAME VERSION heroku/deb-packages Heroku .deb Packages 0.0.3 heroku/dotnet Heroku .NET 0.1.10 heroku/go Heroku Go 0.5.2 heroku/gradle Heroku Gradle 6.0.4 heroku/java Heroku Java 6.0.4 heroku/jvm Heroku OpenJDK 6.0.4 heroku/maven Heroku Maven 6.0.4 heroku/nodejs Heroku Node.js 3.4.5 heroku/nodejs-corepack Heroku Node.js Corepack 3.4.5 heroku/nodejs-engine Heroku Node.js Engine 3.4.5 heroku/nodejs-npm-engine Heroku Node.js npm Engine 3.4.5 heroku/nodejs-npm-install Heroku Node.js npm Install 3.4.5 heroku/nodejs-pnpm-engine Heroku Node.js pnpm Engine 3.4.5 heroku/nodejs-pnpm-install Heroku Node.js pnpm install 3.4.5 heroku/nodejs-yarn Heroku Node.js Yarn 3.4.5 heroku/php Heroku PHP 0.2.0 heroku/procfile Heroku Procfile 4.0.0 heroku/python Heroku Python 0.23.0 heroku/ruby Heroku Ruby 5.0.1 heroku/sbt Heroku sbt 6.0.4 heroku/scala Heroku Scala 6.0.4
كما تقدم شركات أخرى مثل Paketo أو Google Cloud مجموعة متنوعة من حزم البناء. وبشكل عام، فإن نظام Cloud Native Buildpacks ينمو وينضج، وهو أمر مثير للمطورين!
بالنسبة لأولئك منكم الذين يعرفون Heroku، فقد استمتعتم بالفعل بتجربة buildpack . باستخدام git push heroku main ، تمكنت من النشر مباشرة على Heroku، دون الحاجة إلى Dockerfile. تعتمد Cloud Native Buildpacks على تجربة buildpack Heroku، حيث تأخذ ما كان في السابق تنفيذًا خاصًا بالبائع وتحوله إلى معيار CNCF يمكن استخدامه على أي منصة سحابية.
باختصار، تتيح Cloud Native Buildpacks للمطورين ما يلي:
- نشر التطبيقات بسهولة أكبر من أي وقت مضى
- ... بطريقة قياسية دون قفل
- ... كل ذلك مع تطبيق أفضل ممارسات الحاويات
- ... وبدون إجبار المطورين على العبث بملفات Dockerfiles.
حالات الاستخدام
يبدو الأمر رائعًا، أليس كذلك؟ مع كل هذه المزايا، دعنا نلقي نظرة على بعض الحالات المحددة التي قد تستفيد فيها من استخدام Cloud Native Buildpacks.
أي مكان تحتاج فيه عادةً إلى ملف Dockerfile هو فرصة لاستخدام حزمة بناء. تتضمن الأمثلة ما يلي:
- تطبيق ويب Node.js
- خدمة صغيرة بلغة بايثون
- تطبيق غير متجانس يستخدم لغات أو أطر عمل متعددة
- إنشاء تطبيقات للنشر على منصات سحابية مثل AWS وAzure وHeroku
هناك شيء يجب ملاحظته وهو: في حين أن حزم البناء إعلانية ، فإن ملفات Docker هي إجرائية . مع حزمة البناء، يمكنك ببساطة إعلان أنك تريد بناء تطبيق معين باستخدام منشئ أو حزمة بناء معينة. على النقيض من ذلك، يتطلب ملف Dockerfile منك تحديد الأوامر والترتيب الذي يتم به تشغيل هذه الأوامر لبناء تطبيقك. على هذا النحو، لا تقدم حزم البناء حاليًا مستوى القدرة على التكوين المتاح داخل ملف Dockerfile، لذلك قد لا تلبي احتياجات بعض حالات الاستخدام الأكثر تقدمًا.
مع ذلك، لا يوجد تقييد للبائعين في حزم البناء السحابية الأصلية. فهي ببساطة تبني صورة OCI. هل تحتاج إلى المزيد من التخصيصات والخيارات غير المتوفرة في حزمة البناء؟ ما عليك سوى استبدال المنشئ في خط أنابيب البناء الخاص بك بملف Dockerfile وبناء صورة OCI قياسية، وستكون جاهزًا للبدء.
شرح بسيط
دعنا نلقي نظرة سريعة على كيفية استخدام Cloud Native Buildpacks.
للبدء في استخدام حزم البناء كمطور تطبيقات، يجب أن تكون خطوتك الأولى هي تثبيت أداة Pack CLI . تتيح لك هذه الأداة إنشاء تطبيق باستخدام حزم البناء. اتبع تعليمات التثبيت لنظام التشغيل الخاص بك.
بالإضافة إلى ذلك، إذا لم يكن لديك بالفعل، فستحتاج إلى برنامج Docker لكي يتمكن المنشئ من بناء تطبيقك، ولكي تتمكن من تشغيل صورتك. بعد تثبيت هاتين الأداتين، تكون جاهزًا للبدء.
إنشاء تطبيق نموذجي
بفضل إمكانية الوصول إلى أداة pack ، يمكنك تجربتها من خلال إنشاء تطبيق نموذجي. سأقوم بتشغيل هذا داخل تطبيق Next.js. هل تحتاج إلى تطبيق نموذجي لاختبار حزمة البناء عليه؟ إليك دليل كامل لتطبيقات Next.js النموذجية . يمكنك أيضًا تجربة أي تطبيق لديك.
بمجرد أن يصبح تطبيقك جاهزًا، ابدأ برؤية أداة البناء التي تقترحها أداة الحزمة. في غلافك، انتقل إلى دليل التطبيق وقم بتشغيل هذا الأمر:
$ pack builder suggest
في تثبيت Ubuntu الخاص بي، لتطبيق Next.js، تقترح أداة pack المنشئين التاليين:
دعنا نجرب حزمة بناء Heroku المقترحة ( heroku/builder:24 ). لاستخدام هذه الحزمة، قم بتشغيل الأمر التالي:
$ pack build my-app --builder heroku/builder:24
سيختلف وقت البناء وفقًا لحجم التطبيق؛ بالنسبة لي، استغرق بناء التطبيق 30 ثانية. وبذلك، أصبحت صورتي جاهزة للاستخدام. يمكننا تشغيل الصورة بالخطوات التالية:
$ docker run -p 3000:3000 my-app
النتيجة تبدو مثل هذا:
وهذا كل شيء! لقد نجحنا في إنشاء صورة OCI لتطبيق Next.js الخاص بنا — دون استخدام Dockerfile.
تكوينات إضافية
ماذا لو كنت بحاجة إلى تكوين شيء ما داخل حزمة البناء؟ لهذا، يجب عليك الرجوع إلى حزمة البناء التي حددها منشئ التطبيق. على سبيل المثال، بالنسبة لتطبيق Next.js الخاص بي، يمكنني أن أرى في السجلات أن منشئ التطبيق حدد حزمتي بناء: nodejs-engine و nodejs-yarn .
لنفترض أنني أريد تحديد إصدار yarn المستخدم بواسطة حزمة البناء. أولاً، سأنتقل إلى ملف readme الخاص بحزمة بناء nodejs-yarn ، حيث أرى أنه يمكنني تحديد إصدار yarn في ملف package.json الخاص بي باستخدام مفتاح packageManager . سأعدل ملفي ليبدو بهذا الشكل:
{ "packageManager": "[email protected]" }
من هناك، كل ما سأحتاج إلى فعله هو تشغيل pack build my-app --builder heroku/builder:24 مرة أخرى.
خاتمة
تُعد حزم البناء السحابية الأصلية طريقة جديدة ومثيرة لبناء صور الحاويات لتطبيقاتنا. من خلال إزالة الحاجة إلى ملف Dockerfile، فإنها تجعل عملية تعبئة تطبيقاتنا ونشرها أسرع من أي وقت مضى. بالإضافة إلى ذلك، نظرًا لأنها تبني صور الحاويات القياسية، فلا يوجد احتكار للبائعين.
تتوفر Cloud Native Buildpacks في مرحلة المعاينة على العديد من المنصات، مما يعني أن مجموعة الميزات خفيفة ولكنها سريعة النمو. كما تعمل Heroku، التي جعلت Cloud Native Buildpacks مفتوحة المصدر ، على جلبها إلى منصتها من الجيل التالي أيضًا. أتطلع إلى رؤية كيف تعمل Cloud Native Buildpacks على تمكين نشر التطبيقات بشكل آمن وسريع عبر مجتمع منصة السحابة.
