في أحد الأيام ، قررت أن أكتب مقالًا عن تسليم حزم الإرساء والحزم في شكل حاويات ، لكنني عندما بدأت ، عانيت في الأيام البعيدة من أول أجهزة الكمبيوتر الشخصية وحتى الآلات الحاسبة. بشكل عام ، بدلاً من مقارنات جافة بين عامل الإرساء و deb ، هذه هي الأفكار حول التطور ، والتي أقدمها إلى ملعبك.
أي منتج ، أيا كان ، يجب أن يصل إلى خوادم المنتج بطريقة ما ، يجب تكوينه وإطلاقه. هذه المقالة ستكون حول هذا الموضوع.
سوف أفكر في السياق التاريخي ، "ما أراه - أن أغني" ، وما رأيته عندما بدأت في كتابة الشفرة وما أشاهده الآن ، وما نستخدمه نحن في الوقت الحالي ولماذا. لا يتظاهر المقال بأنه دراسة كاملة ، بعض النقاط مفقودة ، هذه هي وجهة نظري الشخصية لما كان وما هو الآن.
لذلك ، في الأيام الخوالي ... كانت طريقة التسليم الأولى التي عثرت عليها هي أشرطة التسجيل. كان لدي جهاز كمبيوتر BK-0010.01 ...
عصر الآلات الحاسبة
لا ، كانت هناك نقطة سابقة ، كان هناك أيضًا آلة حاسبة
MK-61 و
MK-52 .
لذلك ، عندما كان لدي
MK-61 ، كانت طريقة نقل البرنامج هي استخدام قطعة ورق عادية في صندوق تم تسجيل البرنامج عليه ، والتي ، إذا لزم الأمر ، تمت كتابتها يدويًا إلى الآلة الحاسبة. إذا كنت تريد اللعب (نعم ، حتى لو كانت هناك ألعاب على هذه الآلة الحاسبة القديمة) ، فأنت تجلس وتدخل البرنامج في الآلة الحاسبة. بطبيعة الحال ، عندما تم إيقاف تشغيل الآلة الحاسبة ، أصبح البرنامج في غياهب النسيان. بالإضافة إلى رموز الآلة الحاسبة المكتوبة على الورق شخصيًا ، تم نشر البرامج في مجلات راديو وتقنيات الشباب ، وكذلك في كتب ذلك الوقت.
كان التعديل التالي هو آلة حاسبة
MK-52 ، فقد ظهر بالفعل نوع من تخزين البيانات غير المتطاير. الآن ، لم يكن من الضروري توجيه اللعبة أو البرنامج يدويًا ، ولكن بعد القيام ببعض التمريرات السحرية باستخدام الأزرار ، فقد تم تحميلها بنفسها.
بلغ حجم أكبر برنامج في الحاسبة 105 خطوات ، وكان حجم الذاكرة الدائمة في MK-52 512 خطوة.
بالمناسبة ، إذا كان هناك معجبون بهذه الآلات الحاسبة الذين يقرؤون هذه المقالة - أثناء عملية كتابة المقال ، وجدت كل من محاكي الآلة الحاسبة لنظام Android والبرامج الخاصة به. إلى الأمام إلى الماضي!
استطرادا صغيرا عن MK-52 (من ويكيبيديا)
طار MK-52 إلى الفضاء على متن مركبة الفضاء Soyuz TM-7. كان من المفترض أن تستخدم لحساب مسار الهبوط في حالة فشل الكمبيوتر على متن الطائرة.
تم تزويد MK-52 مع وحدة توسيع الذاكرة "Electronics-Astro" منذ عام 1988 لسفن البحرية كجزء من مجموعة الحوسبة الملاحية.
أول أجهزة الكمبيوتر الشخصية
دعنا نعود إلى أوقات
BK-0010 . من الواضح أن هناك ذاكرة أكبر ، ولم يعد هناك خيار لإخراج الشفرة من قطعة من الورق (على الرغم من أنني فعلت ذلك في البداية ، لأنه ببساطة لم يكن هناك وسيط آخر). الوسيلة الرئيسية لتخزين وتسليم البرامج هي أشرطة الصوت لأجهزة التسجيل.
كان التخزين على شريط كاسيت عادةً في شكل ملف ثنائي أو اثنين ، وكان كل شيء آخر موجودًا بالداخل. كانت الموثوقية منخفضة للغاية ، واضطررت إلى الاحتفاظ 2-3 نسخ من البرنامج. وقت التحميل لم يكن سعيدًا أيضًا ، فقد جرب المتحمسون ترميز تردد مختلف للتغلب على أوجه القصور هذه. في ذلك الوقت ، لم أكن قد اشتركت في تطوير البرامج الاحترافية (بصرف النظر عن البرامج الأساسية البسيطة) ، وبالتالي ، للأسف ، لم أخبرك بالتفصيل كيف تم ترتيب كل شيء بالداخل. حقيقة وجود ذاكرة الوصول العشوائي فقط على جهاز الكمبيوتر بالنسبة للجزء الأكبر تحدد بساطة نظام تخزين البيانات.
ظهور وسائط تخزين موثوقة وكبيرة
في وقت لاحق ، تظهر الأقراص المرنة ، عملية النسخ مبسطة ، والموثوقية في تزايد.
لكن الموقف لا يتغير بشكل كبير إلا عندما تظهر مخازن محلية كبيرة بما فيه الكفاية في شكل محرك أقراص صلبة.
يتغير نوع التسليم بشكل أساسي: تظهر أدوات التثبيت التي تتحكم في عملية تكوين النظام ، وكذلك التنظيف بعد الحذف ، نظرًا لأن البرامج لا يتم قراءتها فقط في الذاكرة ، ولكن يتم نسخها بالفعل إلى وحدة التخزين المحلية ، والتي تحتاج إلى أن تكون قادرًا على مسحها وغير ضرورية إذا لزم الأمر.
في الوقت نفسه ، يزداد تعقيد البرنامج المقدم.
يزداد عدد الملفات في التسليم من الوحدات إلى المئات والآلاف ، وتبدأ تعارضات إصدارات المكتبات والأفراح الأخرى عندما تستخدم برامج مختلفة نفس البيانات.
في تلك الأيام ، لم يكن وجود نظام Linux مفتوحًا بالنسبة لي ، فقد عشت في عالم MS DOS ، وفي وقت لاحق Windows ، وكتبت في Borland Pascal و Delphi ، وأحيانًا ألقي نظرة على C ++. لتزويد المنتجات في تلك الأيام ، استخدم الكثير منها InstallShield
ru.wikipedia.org/wiki/InstallShield ، والتي نجحت في حل جميع مهام نشر البرامج وتهيئتها بنجاح.
عصر الإنترنت
تدريجيا ، يصبح تعقيد أنظمة البرمجيات أكثر تعقيدًا ، فمن انتقالًا إلى تطبيقات متراصة وسطح المكتب ، هناك انتقال إلى الأنظمة الموزعة ، والعملاء الرقيقين ، والخدمات الصغيرة. أنت الآن بحاجة إلى تكوين ليس فقط برنامج واحد ، ولكن أيضًا إعدادهم ، وحتى يصبحوا أصدقاء جميعهم معًا.
لقد تغير المفهوم بالكامل ، لقد حان الإنترنت ، لقد حان عصر الخدمات السحابية. حتى الآن ، يتم تفسيرها فقط في المرحلة الأولية ، في شكل مواقع ، لا أحد يحلم خاصة بالخدمات. ولكن هذه كانت نقطة تحول في صناعة كل من التنمية والتسليم الفعلي للتطبيقات.
بنفسي ، لاحظت أنه في هذه اللحظة كان هناك تغيير في أجيال المطورين (أو كان فقط في بيئتي) ، وكان لدي شعور بأن جميع طرق التسليم القديمة الجيدة قد تم نسيانها في لحظة واحدة وبدأ كل شيء من البداية: لقد بدأوا في إجراء التسليم بالكامل مع نصوص عالية في الركبة وتسمى بفخر "التسليم المستمر". في الواقع ، بدأت فترة من الفوضى ، عندما ينسى القديم ولا يستخدم ، ولكن ببساطة لا يوجد جديد.
أتذكر الأوقات التي قضيتها في شركتنا ، حيث عملت في ذلك الوقت (لن أتصل) ، بدلاً من البناء من خلال نملة (لم يكن المافن مشهورًا بعد أم لا على الإطلاق) ، قام الأشخاص بتجميع جرة في IDE والتزامهم له في SVN. وفقًا لذلك ، كان النشر للحصول على الملف من SVN ونسخه عبر SSH إلى الجهاز المطلوب. بهذه البساطة والخرقاء.
في الوقت نفسه ، تم تسليم المواقع البسيطة إلى PHP بدائية تمامًا عن طريق نسخ الملف الذي تم تصحيحه عبر FTP إلى الجهاز الهدف. في بعض الأحيان ، لم يكن هناك شيء من هذا القبيل - تم تعديل الشفرة مباشرة على خادم المنتج ، وكانت أنيقة خاصة إذا كانت هناك نسخ احتياطية في مكان ما.
حزم RPM و DEB
من ناحية أخرى ، مع تطور الإنترنت ، بدأت الأنظمة المشابهة لـ UNIX تكتسب شعبية أكثر وأكثر ، على وجه الخصوص ، لقد اكتشفت في ذلك الوقت RedHat Linux 6 بنفسي ، حوالي عام 2000. بطبيعة الحال ، كانت هناك أدوات معينة لتسليم البرامج هناك ، وفقًا لـ Wikipedia ، RPM حيث ظهر مدير الحزمة الرئيسي بالفعل في عام 1995 ، في إصدار RedHat Linux 2.0. ومنذ ذلك الحين وحتى الآن ، تم تسليم النظام في شكل حزم RPM وبنجاح كبير وتطور.
توصلت توزيعات عائلة دبيان بطريقة مماثلة ونفذت عملية التسليم في شكل حزم دبي ، والتي لم تتغير أيضًا إلى يومنا هذا.
يسمح لك مديرو الحزم بتزويد منتجات البرنامج بأنفسهم ، وتهيئتها أثناء عملية التثبيت ، وإدارة التبعيات بين الحزم المختلفة ، وإزالة المنتجات وتنظيف الفائض أثناء إلغاء التثبيت. أي بالنسبة للجزء الأكبر ، هذا هو كل ما هو مطلوب ، وهذا هو السبب في أنها استمرت عدة عقود دون تغيير يذكر أو معدومة.
تمت إضافة السحب إلى تثبيت مديري الحزم ، ليس فقط من الوسائط الفعلية ، ولكن أيضًا من المستودعات السحابية ، ولكن لم يتغير كثيرًا في الأساس.
تجدر الإشارة إلى أن هناك بعض الزحف في الوقت الحالي نحو تجنب deb والتحول إلى حزم snap ، ولكن المزيد عن ذلك لاحقًا.
لذلك ، فإن هذا الجيل الجديد من مطوري السحابة ، الذين لا يعرفون DEB أو RPM ، نما أيضًا ببطء ، واكتسبوا الخبرة ، وأصبحت المنتجات أكثر تعقيدًا ، وكانت هناك حاجة إلى بعض طرق التسليم المعقولة أكثر من FTP ، والبرامج النصية للباش والحرف اليدوية المماثلة للطلاب.
وهنا Docker يدخل المشهد ، وهو نوع من مزيج من الافتراضية ، وتخصيص الموارد وطرق التسليم. هو الآن شباب عصري ، لكن هل هو ضروري لكل شيء؟ هل هو الدواء الشافي؟
وفقًا لملاحظاتي ، غالبًا ما يتم تقديم Docker ليس كخيار معقول ، ولكن ببساطة لأنه يتم التحدث عنه من ناحية في المجتمع ، والذين يعرفونه لا يعرفون ذلك إلا من ناحية. من ناحية أخرى ، فإنهم في الغالب صامتون بشأن أنظمة التغليف القديمة الجيدة - إنهم يفعلون وما زالوا يقومون بعملهم بهدوء وبشكل غير محسوس. في مثل هذه الحالة ، لا يوجد خيار آخر - الخيار واضح - عامل الميناء.
سأحاول مشاركة تجربتي في كيفية تطبيق Docker ، وما حدث كنتيجة لذلك.
مخطوطات مكتوبة ذاتيا
في البداية ، كانت هناك نصوص باش التي نشرت محفوظات الجرة على الأجهزة اللازمة. أدار هذه العملية من قبل جنكينز. نجح هذا الأمر ، نظرًا لأن أرشيف الجرة نفسه عبارة عن تجميع يحتوي على فئات وموارد وحتى تكوين. إذا وضعت كل شيء فيه إلى الحد الأقصى - ثم قم بتوسيعه باستخدام برنامج نصي - فهذا ليس أصعب شيء تحتاجه
لكن البرامج النصية لها عدة عيوب:
- عادةً ما يتم كتابة البرامج النصية على عجل وبالتالي فهي بدائية بحيث تحتوي على واحد فقط من البرامج النصية الأكثر نجاحًا. يتم تسهيل ذلك من خلال حقيقة أن المطور مهتم بالتسليم السريع ، ويتطلب البرنامج النصي العادي قدرًا لا بأس به من الموارد.
- نتيجة للفقرة السابقة ، لا تحتوي البرامج النصية على إجراء إزالة التثبيت
- لا يوجد إجراء الترقية المعمول بها
- عندما يظهر منتج جديد ، تحتاج إلى كتابة برنامج نصي جديد
- لا يوجد دعم التبعية
بالطبع ، يمكنك كتابة سيناريو فاخر ، ولكن ، كما كتبت أعلاه ، هذا وقت التطوير ، وليس أصغر وقت ، ولكن ، كما تعلمون ، لا يوجد دائمًا وقت كافٍ.
من الواضح أن كل هذا يحد من نطاق طريقة النشر هذه إلى أبسط الأنظمة. لقد حان الوقت لتغيير هذا.
عامل الميناء
في مرحلة ما ، بدأت تحضر لنا أتباع طازجة مخبوزة بالأفكار وتهتز مع عامل ميناء. حسنا ، العلم في متناول اليد - تفعل ذلك! كانت هناك محاولتان. كلاهما غير ناجح - دعنا نقول ذلك ، بسبب الطموحات الكبيرة ، ولكن عدم وجود تجربة حقيقية. هل كان من الضروري القوة والانتهاء بأي وسيلة؟ من غير المحتمل أن يتطور الفريق تطويريًا إلى المستوى المطلوب قبل أن يتمكن من استخدام الأدوات المناسبة. علاوة على ذلك ، باستخدام صور جاهزة لرسو السفن ، غالبًا ما صادفنا حقيقة أن الشبكة عملت بشكل غير صحيح هناك (والذي ربما كان مرتبطًا أيضًا برطوبة عامل الميناء نفسه) أو كان من الصعب توسيع حاويات الأشخاص الآخرين.
ما الازعاج الذي واجهناه؟
- مشاكل الشبكة في وضع الجسر
- من غير المريح النظر إلى السجلات الموجودة في الحاوية (إذا لم يتم نقلها في أي مكان بشكل منفصل إلى نظام ملفات الجهاز المضيف)
- تعليق مطاطي غريب بشكل دوري معلق داخل الحاوية ، لم يتم إنشاء السبب ، الحاوية رسمية
- من المحرج استخدام القشرة داخل الحاوية - كل شيء مشذب إلى حد كبير ، لا توجد أدوات مألوفة
- حاويات كبيرة لجمع - مكلفة لتخزين
- بسبب الحجم الكبير للحاويات ، من الصعب دعم إصدارات متعددة
- بناء أطول ، على عكس الأساليب الأخرى (البرامج النصية أو حزم deb)
من ناحية أخرى ، هل من الأسوأ نشر خدمة Spring في شكل أرشيف جرة من خلال deb نفسه؟ هل هناك حاجة لعزل الموارد؟ هل يستحق فقدان أدوات ملائمة لنظام التشغيل ، حشو الخدمة في حاوية قلصت بشدة؟
كما أوضحت الممارسة ، في الواقع هذا ليس ضروريًا ، حزمة Deb كافية في 90٪ من الحالات.
متى لا تزال deb القديمة جيدة تفشل ومتى كنا بحاجة حقًا إلى عامل ميناء؟
بالنسبة لنا ، كان هذا نشر الخدمات في بيثون. الكثير من المكتبات اللازمة للتعلم الآلي وغير متوفرة في التسليم القياسي لنظام التشغيل (وما كان هناك من الإصدارات الخاطئة) ، الاختراقات مع الإعدادات ، والحاجة إلى إصدارات مختلفة للخدمات المختلفة التي تعيش على نفس نظام المضيف أدى إلى أن الطريقة الوحيدة المعقولة لتزويد هذا الخليط النووي هي عامل الميناء. اتضح أن تعقيد تجميع حاوية الإرساء أقل من فكرة تعبئتها كلها في عبوات منفصلة للديون مع تبعية ، ولم يكن أي شخص في ذهنه الصحيح قد أخذها.
النقطة الثانية حيث كنت تخطط لاستخدام عامل ميناء هي لنشر الخدمات باستخدام نظام النشر الأزرق والأخضر. لكن هنا أريد الحصول على زيادة تدريجية في التعقيد: أولاً ، يتم تجميع حزم deb ، ثم يتم تجميع حاوية عامل ميناء منها.
حزم المفاجئة
العودة إلى حزم المفاجئة. ظهرت لأول مرة رسميًا في Ubuntu 16.04. على عكس حزم deb المعتادة وحزم rpm ، تحمل الأداة snap جميع التبعيات. من ناحية ، يتجنب هذا تعارض المكتبات ، من ناحية أخرى ، فهذا يعني أحجامًا أكثر أهمية من الحزمة الناتجة. بالإضافة إلى ذلك ، يمكن أن يؤثر ذلك على أمان النظام: في حالة الخاطف ، يجب مراقبة جميع التغييرات التي تم إجراؤها على المكتبات المضمنة بواسطة المطور الذي ينشئ الحزمة. بشكل عام ، ليس كل شيء بسيطًا جدًا ولا تأتي السعادة العامة لاستخدامه. لكن ، مع ذلك ، يعد هذا بديلاً معقولًا ، إذا تم استخدام نفس عامل الإرساء فقط كوسيلة للتعبئة ، وليس الافتراضية.
نتيجةً لذلك ، نستخدم الآن كل من حزم deb وحاويات الإرساء في تركيبة معقولة ، والتي ربما نستبدلها في بعض الحالات بحزم إضافية.