بطريقة ما، قررت في مرحلة ما أن أكتب مقالًا عن التسليم في شكل حاويات Docker وحزم deb، ولكن عندما بدأت، لسبب ما، عدت إلى العصور البعيدة لأجهزة الكمبيوتر الشخصية الأولى وحتى الآلات الحاسبة. بشكل عام، بدلاً من المقارنات الجافة بين عامل الإرساء وديب، حصلنا على هذه الأفكار حول موضوع التطور، والتي أقدمها للنظر فيها.
أي منتج، بغض النظر عن ماهيته، يجب أن يصل بطريقة أو بأخرى إلى خوادم المنتج، ويجب تكوينه وإطلاقه. وهذا ما ستكون هذه المقالة عنه.
سأفكر في سياق تاريخي، "ما أراه هو ما أغني عنه"، وما رأيته عندما بدأت كتابة التعليمات البرمجية لأول مرة وما ألاحظه الآن، وما نستخدمه بأنفسنا في الوقت الحالي ولماذا. المقال لا يدعي أنه دراسة كاملة، فقد أغفل بعض النقاط، هذه وجهة نظري الشخصية لما كان وما هو الآن.
لذلك، في الأيام الخوالي... أقدم طريقة للتسليم وجدتها كانت أشرطة الكاسيت من أجهزة التسجيل. كان عندي جهاز كمبيوتر BK-0010.01...
عصر الآلات الحاسبة
لا، كانت هناك لحظة سابقة، وكانت هناك أيضًا آلة حاسبة и .
لذلك عندما كان لي ، ثم كانت طريقة نقل البرنامج عبارة عن قطعة ورق عادية في صندوق مكتوب عليه برنامج، والذي، إذا لزم الأمر، لتشغيله يدويًا، يتم كتابته في الآلة الحاسبة. إذا كنت تريد اللعب (نعم، حتى هذه الآلة الحاسبة التي تعود إلى ما قبل الطوفان كانت تحتوي على ألعاب) - فاجلس وأدخل البرنامج في الآلة الحاسبة. وبطبيعة الحال، عندما تم إيقاف تشغيل الآلة الحاسبة، اختفى البرنامج في غياهب النسيان. بالإضافة إلى رموز الآلة الحاسبة المكتوبة شخصيًا على الورق، تم نشر البرامج في مجلتي "الراديو" و"التكنولوجيا للشباب"، وتم نشرها أيضًا في كتب ذلك الوقت.
وكان التعديل التالي آلة حاسبة ، فهو يحتوي بالفعل على بعض مظاهر تخزين البيانات غير المتطايرة. الآن لم يعد من الضروري إدخال اللعبة أو البرنامج يدويًا، ولكن بعد إجراء بعض التمريرات السحرية باستخدام الأزرار، تم تحميل نفسه.
وكان حجم أكبر برنامج في الآلة الحاسبة 105 خطوة، وحجم الذاكرة الدائمة في MK-52 كان 512 خطوة.
بالمناسبة، إذا كان هناك معجبين بهذه الآلات الحاسبة الذين يقرؤون هذه المقالة، أثناء كتابة المقالة، فقد وجدت محاكيًا للآلة الحاسبة لنظام Android وبرامج خاصة به. إلى الأمام إلى الماضي!
استطراد قصير حول MK-52 (من ويكيبيديا)
طار MK-52 إلى الفضاء على متن المركبة الفضائية Soyuz TM-7. كان من المفترض أن يتم استخدامه لحساب مسار الهبوط في حالة فشل الكمبيوتر الموجود على متن الطائرة.
منذ عام 52، تم توفير MK-1988 مع وحدة توسيع الذاكرة Elektronika-Astro للسفن البحرية كجزء من مجموعة الحوسبة الملاحية.
أول أجهزة الكمبيوتر الشخصية
دعونا نعود إلى العصر . من الواضح أن هناك المزيد من الذاكرة، ولم تعد كتابة التعليمات البرمجية من قطعة من الورق خيارًا (على الرغم من أنني فعلت ذلك في البداية، لأنه ببساطة لم تكن هناك وسيلة أخرى). أصبحت أشرطة الصوت الخاصة بالمسجلات هي الوسيلة الرئيسية لتخزين البرامج وتسليمها.
كان التخزين على الكاسيت عادةً على شكل ملف ثنائي أو ملفين ثنائيين، وكل شيء آخر كان موجودًا بداخله. كانت الموثوقية منخفضة للغاية، واضطررت إلى الاحتفاظ بنسختين أو ثلاث نسخ من البرنامج. كانت أوقات التحميل أيضًا مخيبة للآمال، وقام المتحمسون بتجربة ترميزات تردد مختلفة للتغلب على هذه العيوب. في ذلك الوقت، لم أشارك بعد في تطوير البرامج المهنية (باستثناء البرامج البسيطة في BASIC)، لذلك، لسوء الحظ، لن أخبرك بالتفصيل كيف تم ترتيب كل شيء في الداخل. إن حقيقة أن الكمبيوتر يحتوي على ذاكرة الوصول العشوائي (RAM) فقط في معظمها تحدد مدى بساطة نظام تخزين البيانات.
ظهور وسائط تخزين موثوقة وكبيرة الحجم
في وقت لاحق، ظهرت الأقراص المرنة، وتم تبسيط عملية النسخ، وزيادة الموثوقية.
لكن الوضع يتغير بشكل كبير فقط عندما تظهر وحدات تخزين محلية كبيرة بما فيه الكفاية على شكل محركات أقراص ثابتة.
يتغير نوع التسليم بشكل أساسي: تظهر برامج التثبيت التي تدير عملية تكوين النظام، بالإضافة إلى التنظيف بعد الإزالة، حيث لا تتم قراءة البرامج في الذاكرة فحسب، بل يتم نسخها بالفعل إلى وحدة التخزين المحلية، والتي تحتاج منها إلى تكون قادرًا على مسح الأشياء غير الضرورية إذا لزم الأمر.
وفي الوقت نفسه، يتزايد تعقيد البرامج المتوفرة.
ويزداد عدد الملفات في التسليم من بضعة إلى مئات وآلاف، ويبدأ التعارض بين إصدارات المكتبة والأفراح الأخرى عندما تستخدم برامج مختلفة نفس البيانات.
في ذلك الوقت، لم يكن وجود Linux متاحًا لي بعد؛ عشت في عالم MS DOS، ولاحقًا، Windows، وكتبت بلغة بورلاند باسكال ودلفي، وأتطلع أحيانًا إلى لغة C++. استخدم العديد من الأشخاص InstallShield لتسليم المنتجات في ذلك الوقت. ، والذي نجح في حل جميع المهام المعينة لنشر البرنامج وتكوينه.
عصر الانترنت
تدريجيا، أصبح تعقيد أنظمة البرمجيات أكثر تعقيدا، من تطبيقات Monolith وسطح المكتب، هناك انتقال إلى الأنظمة الموزعة والعملاء الرفيعين والخدمات الصغيرة. الآن لا تحتاج إلى تكوين برنامج واحد فقط، بل مجموعة منها، بحيث تعمل جميعها معًا.
لقد تغير المفهوم تمامًا، وجاء الإنترنت، ووصل عصر الخدمات السحابية. حتى الآن، فقط في المرحلة الأولية، في شكل مواقع الويب، لم يحلم أحد بالخدمات بشكل خاص. لكنها كانت نقطة تحول في كل من تطوير التطبيقات وتقديمها.
لقد لاحظت بنفسي أنه في تلك اللحظة كان هناك تغيير في أجيال المطورين (أو كان ذلك في بيئتي فقط)، وكان هناك شعور بأن جميع طرق التسليم القديمة الجيدة قد نُسيت في لحظة واحدة وبدأ كل شيء من البداية البداية: بدأ تنفيذ جميع عمليات التسليم بنصوص الركبة وأطلق عليها بكل فخر "التسليم المستمر". في الواقع، بدأت فترة من الفوضى، عندما يتم نسيان القديم وعدم استخدامه، والجديد ببساطة غير موجود.
أتذكر الأوقات التي كنت أعمل فيها في شركتنا (لن أسميها)، بدلاً من البناء عبر النمل (لم يكن المخضرم مشهورًا بعد أو لم يكن موجودًا على الإطلاق)، قام الناس ببساطة بجمع الجرار في IDE والتزموا بهدوء في SVN. وبناء على ذلك، يتألف النشر من استرداد الملف من SVN ونسخه عبر SSH إلى الجهاز المطلوب. انها بسيطة جدا وأخرق.
وفي الوقت نفسه، تم تسليم المواقع البسيطة بلغة PHP بطريقة بدائية للغاية عن طريق نسخ الملف المصحح عبر FTP إلى الجهاز المستهدف. في بعض الأحيان لم يكن هذا هو الحال - فقد تم تحرير الكود مباشرة على خادم المنتج، وكان الأمر أنيقًا بشكل خاص إذا كانت هناك نسخ احتياطية في مكان ما.
حزم RPM وDEB
من ناحية أخرى، مع تطور الإنترنت، بدأت الأنظمة المشابهة لـ UNIX تكتسب المزيد والمزيد من الشعبية، على وجه الخصوص، في ذلك الوقت اكتشفت RedHat Linux 6، حوالي عام 2000. وبطبيعة الحال، كانت هناك أيضًا وسائل معينة لتوصيل البرامج؛ وفقًا لويكيبيديا، ظهر RPM كمدير الحزم الرئيسي بالفعل في عام 1995، في إصدار RedHat Linux 2.0. ومنذ ذلك الحين وحتى يومنا هذا، تم تسليم النظام في شكل حزم RPM وكان موجودًا ومتطورًا بنجاح كبير.
اتبعت توزيعات عائلة دبيان مسارًا مشابهًا ونفذت التسليم على شكل حزم debian، والتي ظلت دون تغيير حتى يومنا هذا.
يسمح لك مديرو الحزم بتسليم منتجات البرامج بأنفسهم، وتكوينها أثناء عملية التثبيت، وإدارة التبعيات بين الحزم المختلفة، وإزالة المنتجات وتنظيف العناصر غير الضرورية أثناء عملية إلغاء التثبيت. أولئك. في أغلب الأحيان، هذا هو كل ما هو مطلوب، ولهذا السبب استمرت لعدة عقود دون تغيير تقريبًا.
أضافت الحوسبة السحابية التثبيت إلى مديري الحزم ليس فقط من الوسائط المادية، ولكن أيضًا من المستودعات السحابية، ولكن لم يتغير سوى القليل بشكل أساسي.
تجدر الإشارة إلى أنه توجد حاليًا بعض التحركات نحو الابتعاد عن deb والتحول إلى الحزم المفاجئة، ولكن المزيد عن ذلك لاحقًا.
لذلك، فإن هذا الجيل الجديد من مطوري السحابة، الذين لم يعرفوا DEB ولا RPM، نما أيضًا ببطء، واكتسبوا الخبرة، وأصبحت المنتجات أكثر تعقيدًا، وكانت هناك حاجة إلى بعض طرق التسليم الأكثر معقولية من FTP، ونصوص bash والحرف الطلابية المماثلة.
وهنا يأتي دور Docker في الصورة، وهو مزيج من المحاكاة الافتراضية وتحديد الموارد وطريقة التسليم. إنها عصرية وشبابية الآن، ولكن هل هناك حاجة إليها في كل شيء؟ هل هذا هو الدواء الشافي؟
من ملاحظاتي، في كثير من الأحيان يتم اقتراح Docker ليس كخيار معقول، ولكن ببساطة لأنه، من ناحية، يتم الحديث عنه في المجتمع، وأولئك الذين يقترحونه يعرفون ذلك فقط. من ناحية أخرى، فإنهم في الغالب صامتون بشأن أنظمة التغليف القديمة الجيدة - فهي موجودة وتقوم بعملها بهدوء ودون أن يلاحظها أحد. في مثل هذه الحالة، لا يوجد حقًا خيار آخر - الخيار واضح - Docker.
سأحاول مشاركة تجربتي حول كيفية تنفيذ Docker وما حدث نتيجة لذلك.
نصوص مكتوبة ذاتيا
في البداية، كانت هناك نصوص باش تنشر أرشيفات الجرة على الأجهزة المطلوبة. تمت إدارة هذه العملية بواسطة جينكينز. لقد نجح هذا الأمر، نظرًا لأن أرشيف الجرة نفسه عبارة عن مجموعة تحتوي بالفعل على فئات وموارد وحتى تكوينات. إذا وضعت كل شيء فيه إلى الحد الأقصى، فإن توسيعه إلى برنامج نصي ليس هو الشيء الأكثر صعوبة الذي تحتاجه
لكن البرامج النصية لها عيوب عديدة:
- عادة ما تتم كتابة النصوص على عجل، وبالتالي فهي بدائية للغاية بحيث تحتوي على سيناريو واحد فقط لأفضل الحالات. يتم تسهيل ذلك من خلال حقيقة أن المطور مهتم بالتسليم السريع، ويتطلب البرنامج النصي العادي استثمار كمية مناسبة من الموارد
- ونتيجة للنقطة السابقة، لا تحتوي البرامج النصية على إجراءات إلغاء التثبيت
- لا يوجد إجراء ترقية ثابت
- عندما يظهر منتج جديد، تحتاج إلى كتابة نص جديد
- لا يوجد دعم التبعية
بالطبع، يمكنك كتابة نص متطور، ولكن، كما كتبت أعلاه، هذا هو وقت التطوير، وليس آخرا، وكما نعلم، لا يوجد دائما ما يكفي من الوقت.
من الواضح أن كل هذا يحد من نطاق تطبيق طريقة النشر هذه على أبسط الأنظمة فقط. لقد حان الوقت لتغيير هذا.
عامل في حوض السفن
في مرحلة ما، بدأ الوسطاء الجدد في القدوم إلينا، وهم يغليون بالأفكار ويهتفون بعامل الرصيف. حسنًا، العلم في متناول اليد - فلنفعل ذلك! كانت هناك محاولتان. كلاهما لم ينجح - دعنا نقول، بسبب الطموحات الكبيرة، ولكن الافتقار إلى الخبرة الحقيقية. هل كان من الضروري إجبارها وإنهائها بأي وسيلة ضرورية؟ هذا غير محتمل - يجب أن يتطور الفريق إلى المستوى المطلوب قبل أن يتمكن من استخدام الأدوات المناسبة. بالإضافة إلى ذلك، عند استخدام صور Docker الجاهزة، غالبًا ما نواجه حقيقة أن الشبكة لا تعمل بشكل صحيح (والتي قد تكون بسبب رطوبة Docker نفسها) أو كان من الصعب توسيع حاويات الأشخاص الآخرين.
ما هي المضايقات التي واجهناها؟
- مشاكل في الشبكة في وضع الجسر
- من غير المناسب عرض السجلات في حاوية (إذا لم يتم تخزينها بشكل منفصل في نظام الملفات الخاص بالجهاز المضيف)
- يتجمد ElasticSearch أحيانًا بشكل غريب داخل الحاوية، ولم يتم تحديد السبب، والحاوية رسمية
- من الضروري استخدام غلاف داخل الحاوية - كل شيء بسيط جدًا، ولا توجد أدوات عادية
- حجم كبير من الحاويات المجمعة - تخزينها مكلف
- نظرًا للحجم الكبير للحاويات، فمن الصعب دعم إصدارات متعددة
- وقت إنشاء أطول، على عكس الطرق الأخرى (البرامج النصية أو حزم deb)
من ناحية أخرى، لماذا يكون من الأسوأ نشر خدمة Spring في شكل أرشيف جرة من خلال نفس deb؟ هل عزل الموارد ضروري حقًا؟ هل يستحق فقدان أدوات نظام التشغيل الملائمة عن طريق حشو الخدمة في حاوية صغيرة جدًا؟
كما أظهرت الممارسة، فإن هذا ليس ضروريًا في الواقع، فحزمة deb كافية في 90٪ من الحالات.
متى يفشل deb القديم الجيد ومتى نحتاج حقًا إلى عامل إرساء؟
بالنسبة لنا، كان هذا بمثابة نشر الخدمات في لغة بايثون. هناك الكثير من المكتبات اللازمة للتعلم الآلي وغير المدرجة في التوزيع القياسي لنظام التشغيل (وما هي الإصدارات الخاطئة)، والاختراقات مع الإعدادات، والحاجة إلى إصدارات مختلفة لخدمات مختلفة تعيش على نفس النظام المضيف أدت إلى هذا، وأن الطريقة الوحيدة المعقولة لتوصيل هذا الخليط النووي هي الرصيف. تبين أن كثافة العمالة في تجميع حاوية الإرساء أقل من فكرة تجميعها كلها في حزم deb منفصلة مع التبعيات، وفي الواقع لن يقوم أي شخص بكامل قواه العقلية بذلك.
النقطة الثانية التي نخطط فيها لاستخدام Docker هي نشر الخدمات باستخدام نظام النشر الأزرق والأخضر. ولكن هنا أريد الحصول على زيادة تدريجية في التعقيد: أولاً، يتم إنشاء حزم deb، ثم يتم إنشاء حاوية عامل إرساء منها.
حزم المفاجئة
دعنا نعود إلى الحزم المفاجئة. ظهرت لأول مرة رسميًا في Ubuntu 16.04. على عكس حزم deb وحزم rpm المعتادة، يحمل snap جميع التبعيات. من ناحية، يسمح لك هذا بتجنب تعارضات المكتبة، ومن ناحية أخرى، تكون الحزمة الناتجة أكبر حجمًا. بالإضافة إلى ذلك، يمكن أن يؤثر هذا أيضًا على أمان النظام: في حالة التسليم السريع، يجب مراقبة جميع التغييرات التي يتم إجراؤها على المكتبات المضمنة بواسطة المطور الذي يقوم بإنشاء الحزمة. بشكل عام، ليس كل شيء بهذه البساطة والسعادة العالمية لا تأتي من استخدامها. ولكن، مع ذلك، يعد هذا بديلاً معقولاً تمامًا إذا تم استخدام نفس Docker فقط كأداة تعبئة وليس للمحاكاة الافتراضية.
نتيجة لذلك، نستخدم الآن كلاً من حزم deb وحاويات الإرساء في مجموعة معقولة، والتي ربما سنستبدلها في بعض الحالات بحزم مبكرة.
يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. ، من فضلك.
ماذا تستخدم للتسليم؟
-
نصوص مكتوبة ذاتيا
-
انسخ يدويًا إلى FTP
-
حزم ديب
-
حزم دورة في الدقيقة
-
الحزم المفاجئة
-
صور عامل الميناء
-
صور الآلة الافتراضية
-
استنساخ القرص الصلب بأكمله
-
دمية
-
ansible
-
آخر
صوت 109 مستخدمًا. امتنع 32 مستخدما عن التصويت.
المصدر: www.habr.com