تکامل ابزارهای تحویل، یا افکار در مورد Docker، deb، jar و موارد دیگر

به نوعی در یک مقطع تصمیم گرفتم مقاله ای در مورد تحویل در قالب ظروف Docker و بسته های دب بنویسم، اما وقتی شروع کردم به دلایلی به زمان های دور اولین رایانه های شخصی و حتی ماشین حساب ها منتقل شدم. به طور کلی به جای مقایسه خشک docker و deb، این افکار را در مورد موضوع تکامل به دست آوردیم که برای بررسی شما ارائه می کنم.

هر محصولی، مهم نیست که چیست، باید به نحوی به سرورهای محصول برسد، باید پیکربندی و راه اندازی شود. این چیزی است که این مقاله در مورد آن خواهد بود.

من در یک زمینه تاریخی فکر خواهم کرد، «آنچه می بینم همان چیزی است که درباره آن می خوانم»، وقتی برای اولین بار شروع به نوشتن کد کردم چه چیزی دیدم و اکنون چه چیزی را مشاهده می کنم، خود ما در حال حاضر از چه چیزی استفاده می کنیم و چرا. مقاله وانمود نمی کند که یک مطالعه تمام عیار است، برخی از نکات مغفول مانده است، این دیدگاه شخصی من از آنچه بود و اکنون است است.

بنابراین، در روزهای خوب قدیم... اولین روش تحویلی که پیدا کردم، نوار کاست از ضبط صوت بود. من یک کامپیوتر BK-0010.01 داشتم...

عصر ماشین حساب ها

نه، حتی یک لحظه زودتر وجود داشت، یک ماشین حساب نیز وجود داشت MK-61 и MK-52.

پس وقتی داشتم MK-61، سپس راه انتقال برنامه یک کاغذ معمولی در جعبه ای بود که روی آن برنامه ای نوشته شده بود که در صورت لزوم برای اجرای دستی آن در ماشین حساب نوشته می شد. اگر می‌خواهید بازی کنید (بله، حتی این ماشین‌حساب ضدغرق بازی‌هایی داشت) - می‌نشینید و برنامه را وارد ماشین حساب می‌کنید. طبیعتاً وقتی ماشین حساب خاموش شد، برنامه به فراموشی سپرده شد. علاوه بر کدهای ماشین حساب که روی کاغذ به دست خودش نوشته شده بود، این برنامه ها در مجلات «رادیو» و «فناوری برای جوانان» منتشر می شد و در کتاب های آن زمان نیز منتشر می شد.

اصلاح بعدی یک ماشین حساب بود MK-52، قبلاً ظاهری از ذخیره سازی داده های غیر فرار دارد. حالا لازم نبود بازی یا برنامه به صورت دستی وارد شود، اما پس از انجام چند پاس جادویی با دکمه ها، خود را لود کرد.

اندازه بزرگترین برنامه در ماشین حساب 105 قدم و اندازه حافظه دائمی در MK-52 512 قدم بود.

به هر حال، اگر طرفداران این ماشین حساب ها هستند که این مقاله را می خوانند، در روند نوشتن مقاله، هم شبیه ساز ماشین حساب برای اندروید و هم برنامه هایی برای آن پیدا کردم. پیش به سوی گذشته!

• شبیه ساز MK-61 برای اندروید
• کاتالوگ برنامه برای MK-61

یک انحراف کوتاه در مورد MK-52 (از ویکی پدیا)

MK-52 با فضاپیمای سایوز TM-7 به فضا پرواز کرد. قرار بود از آن برای محاسبه مسیر فرود در صورت از کار افتادن رایانه روی برد استفاده شود.

از سال 52، MK-1988 با واحد توسعه حافظه Elektronika-Astro به عنوان بخشی از یک کیت محاسباتی ناوبری برای کشتی های نیروی دریایی عرضه شده است.

اولین کامپیوترهای شخصی

به روزگار برگردیم BC-0010. واضح است که حافظه بیشتری در آنجا وجود داشت، و تایپ کد از روی یک تکه کاغذ دیگر گزینه ای نبود (اگرچه در ابتدا این کار را انجام دادم، زیرا به سادگی هیچ وسیله دیگری وجود نداشت). کاست های صوتی برای ضبط صوت در حال تبدیل شدن به ابزار اصلی ذخیره و ارائه نرم افزار هستند.

ذخیره سازی روی نوار کاست معمولاً به شکل یک یا دو فایل باینری بود و هر چیز دیگری در داخل آن قرار داشت. قابلیت اطمینان خیلی کم بود، مجبور شدم 2-3 نسخه از برنامه را نگه دارم. زمان بارگذاری نیز ناامید کننده بود و علاقه مندان برای غلبه بر این کاستی ها، کدگذاری فرکانس های مختلف را آزمایش کردند. در آن زمان، من خودم هنوز درگیر توسعه نرم افزار حرفه ای نبودم (بدون احتساب برنامه های ساده در BASIC)، بنابراین، متأسفانه، من به شما نمی گویم که چگونه همه چیز در داخل چیده شده است. این واقعیت که رایانه در اکثر موارد فقط RAM داشت، سادگی طرح ذخیره سازی داده ها را تعیین کرد.

ظهور رسانه های ذخیره سازی قابل اعتماد و بزرگ

بعداً فلاپی دیسک ها ظاهر شدند، فرآیند کپی ساده شد و قابلیت اطمینان افزایش یافت.
اما وضعیت تنها زمانی به شدت تغییر می کند که حافظه های محلی به اندازه کافی بزرگ به شکل HDD ظاهر شوند.

نوع تحویل اساساً در حال تغییر است: برنامه های نصب کننده ظاهر می شوند که فرآیند پیکربندی سیستم و همچنین پاکسازی پس از حذف را مدیریت می کنند، زیرا برنامه ها نه تنها در حافظه خوانده می شوند، بلکه از قبل در حافظه محلی کپی می شوند، که از آن باید در صورت لزوم بتوانید موارد غیر ضروری را پاک کنید.

در عین حال، پیچیدگی نرم افزار ارائه شده در حال افزایش است.
تعداد فایل‌ها در تحویل از چند به صدها و هزاران افزایش می‌یابد، تضاد بین نسخه‌های کتابخانه و شادی‌های دیگر زمانی شروع می‌شود که برنامه‌های مختلف از داده‌های مشابهی استفاده می‌کنند.

در آن زمان، وجود لینوکس هنوز به روی من باز نشده بود؛ من در دنیای MS DOS و بعداً ویندوز زندگی می‌کردم و در Borland Pascal و Delphi می‌نوشتم و گاهی به C++ نگاه می‌کردم. بسیاری از مردم در آن زمان از InstallShield برای ارائه محصولات استفاده می کردند. ru.wikipedia.org/wiki/InstallShield، که با موفقیت تمام وظایف محول شده برای استقرار و پیکربندی نرم افزار را حل کرد.

عصر اینترنت

به تدریج، پیچیدگی سیستم‌های نرم‌افزاری پیچیده‌تر می‌شود؛ از برنامه‌های یکپارچه و رومیزی، انتقالی به سیستم‌های توزیع‌شده، تین کلاینت‌ها و میکروسرویس‌ها وجود دارد. اکنون باید نه تنها یک برنامه، بلکه مجموعه ای از آنها را پیکربندی کنید تا همه با هم کار کنند.

مفهوم کاملاً تغییر کرد، اینترنت آمد، عصر خدمات ابری فرا رسید. تا کنون، تنها در مرحله اولیه، در قالب وب سایت، هیچ کس به طور خاص رویای خدمات را نداشته است. اما این یک نقطه عطف در توسعه و ارائه برنامه های کاربردی بود.

برای خودم اشاره کردم که در آن لحظه تغییری در نسل توسعه دهندگان رخ داد (یا فقط در محیط من بود) و این احساس وجود داشت که همه روش های خوب تحویل قدیمی در یک لحظه فراموش شدند و همه چیز از همان ابتدا شروع شد. شروع: تمام تحویل ها با اسکریپت های زانو انجام می شد و با افتخار آن را «تحویل مستمر» نامیدند. در واقع، دوره ای از هرج و مرج آغاز شده است، زمانی که قدیمی فراموش می شود و استفاده نمی شود، و جدید به سادگی وجود ندارد.

زمان هایی را به یاد می آورم که در شرکت ما که در آن زمان کار می کردم (نامی نمی برم)، به جای ساختن از طریق مورچه (maven هنوز محبوب نبود یا اصلا وجود نداشت)، مردم به سادگی کوزه ها را در IDE جمع می کردند و متعهد بودند. آن را در SVN. بر این اساس، استقرار شامل بازیابی فایل از SVN و کپی کردن آن از طریق SSH در دستگاه مورد نظر بود. خیلی ساده و دست و پا چلفتی است.

در عین حال، تحویل سایت های ساده در PHP به روشی بسیار ابتدایی با کپی کردن فایل تصحیح شده از طریق FTP در ماشین مورد نظر انجام شد. گاهی اوقات اینطور نبود - کد به صورت زنده در سرور محصول ویرایش می شد و اگر پشتیبان گیری در جایی وجود داشت بسیار شیک بود.

بسته های RPM و DEB

از سوی دیگر، با توسعه اینترنت، سیستم‌های شبه یونیکس محبوبیت بیشتری پیدا کردند، به ویژه، در آن زمان بود که من RedHat Linux 6 را در حدود سال 2000 کشف کردم. طبیعتاً ابزارهای خاصی برای ارائه نرم افزار نیز وجود داشت؛ طبق ویکی پدیا، RPM به عنوان مدیر بسته اصلی قبلاً در سال 1995 در نسخه RedHat Linux 2.0 ظاهر شد. و از آن زمان تا به امروز این سیستم در قالب بسته های RPM تحویل داده شده و با موفقیت موجود و در حال توسعه بوده است.

توزیع‌های خانواده دبیان نیز مسیر مشابهی را طی کردند و تحویل را در قالب بسته‌های deb اجرا کردند که تا به امروز بدون تغییر باقی مانده است.

مدیران بسته به شما این امکان را می‌دهند که محصولات نرم‌افزاری را خودشان تحویل دهید، آنها را در طول فرآیند نصب پیکربندی کنید، وابستگی‌های بین بسته‌های مختلف را مدیریت کنید، محصولات را حذف کنید و موارد غیر ضروری را در طول فرآیند حذف نصب کنید. آن ها در بیشتر موارد، این تنها چیزی است که مورد نیاز است، به همین دلیل است که آنها چندین دهه عملاً بدون تغییر دوام آوردند.

رایانش ابری نه تنها از رسانه های فیزیکی، بلکه همچنین از مخازن ابری، نصب را به مدیران بسته اضافه کرده است، اما اساساً تغییر چندانی نکرده است.

شایان ذکر است که در حال حاضر اقداماتی برای دور شدن از deb و تغییر به بسته‌های اسنپ وجود دارد، اما در ادامه بیشتر در مورد آن صحبت خواهیم کرد.

بنابراین، این نسل جدید توسعه دهندگان ابری، که نه DEB و نه RPM را می‌دانستند، به آرامی رشد کردند، تجربه کسب کردند، محصولات پیچیده‌تر شدند و به روش‌های تحویل معقول‌تری نسبت به FTP، اسکریپت‌های bash و صنایع دستی دانشجویی مشابه نیاز بود.
و اینجاست که Docker به تصویر می‌آید، نوعی ترکیبی از مجازی‌سازی، تعیین حدود منابع و روش تحویل. اکنون مد و جوان است، اما آیا برای همه چیز لازم است؟ آیا این یک نوشدارویی است؟

بر اساس مشاهدات من، اغلب Docker به عنوان یک انتخاب معقول پیشنهاد نمی شود، بلکه صرفاً به این دلیل است که از یک طرف در مورد آن در جامعه صحبت می شود و کسانی که آن را پیشنهاد می کنند فقط آن را می دانند. از سوی دیگر، آنها در بیشتر موارد در مورد سیستم های بسته بندی خوب قدیمی سکوت می کنند - آنها وجود دارند و کار خود را بی سر و صدا و بدون توجه انجام می دهند. در چنین شرایطی واقعاً هیچ انتخاب دیگری وجود ندارد - انتخاب واضح است - Docker.

من سعی خواهم کرد تجربه خود را از نحوه اجرای Docker و آنچه در نتیجه اتفاق افتاد به اشتراک بگذارم.

فیلمنامه های خودنویس

در ابتدا، اسکریپت‌های bash وجود داشت که بایگانی‌های jar را در ماشین‌های مورد نیاز مستقر می‌کردند. این فرآیند توسط جنکینز مدیریت شد. این با موفقیت کار کرد، زیرا آرشیو jar در حال حاضر یک مجموعه شامل کلاس ها، منابع و حتی پیکربندی است. اگر همه چیز را در آن به حداکثر برسانید، پس گسترش آن به یک اسکریپت سخت ترین چیزی نیست که نیاز دارید

اما اسکریپت ها چندین معایب دارند:

• اسکریپت‌ها معمولاً با عجله نوشته می‌شوند و بنابراین به قدری ابتدایی هستند که تنها شامل یک بهترین سناریو هستند. این با این واقعیت تسهیل می شود که توسعه دهنده به تحویل سریع علاقه مند است و یک اسکریپت معمولی نیاز به سرمایه گذاری مقدار مناسبی از منابع دارد.
• در نتیجه نکته قبلی، اسکریپت ها حاوی مراحل حذف نصب نیستند
• هیچ روش ارتقای مشخصی وجود ندارد
• هنگامی که یک محصول جدید ظاهر می شود، باید یک اسکریپت جدید بنویسید
• بدون پشتیبانی وابستگی

البته، شما می توانید یک فیلمنامه پیچیده بنویسید، اما، همانطور که در بالا نوشتم، این زمان توسعه است، و نه کمترین، و، همانطور که می دانیم، همیشه زمان کافی وجود ندارد.

همه اینها بدیهی است که دامنه کاربرد این روش استقرار را فقط به ساده ترین سیستم ها محدود می کند. زمان تغییر این امر فرا رسیده است.

کارگر بارانداز

در یک نقطه، وسط های تازه ضرب شده به سمت ما آمدند، غرق در ایده ها و هیاهوی بارانداز. خوب، پرچم در دست - بیایید آن را انجام دهیم! دو تلاش وجود داشت. هر دو ناموفق بودند - فرض کنید به دلیل جاه طلبی های بزرگ، اما عدم تجربه واقعی. آیا لازم بود آن را به زور و به هر طریقی تمام کرد؟ بعید است - تیم قبل از اینکه بتواند از ابزار مناسب استفاده کند باید به سطح مورد نیاز تکامل یابد. علاوه بر این، هنگام استفاده از تصاویر آماده داکر، اغلب با این واقعیت مواجه می شدیم که شبکه به درستی کار نمی کند (که ممکن است به دلیل رطوبت خود داکر باشد) یا گسترش کانتینرهای افراد دیگر دشوار است.

با چه ناراحتی هایی مواجه شدیم؟

• مشکلات شبکه در حالت پل
• مشاهده سیاههها در یک ظرف ناخوشایند است (اگر آنها به طور جداگانه در سیستم فایل دستگاه میزبان ذخیره نشده باشند)
• ElasticSearch گهگاه به طرز عجیبی در داخل ظرف یخ می زند، دلیل آن مشخص نشده است، ظرف رسمی است
• استفاده از یک پوسته در داخل ظرف ضروری است - همه چیز بسیار کنده شده است، هیچ ابزار معمولی وجود ندارد
• اندازه بزرگ ظروف جمع آوری شده - گران قیمت برای نگهداری
• به دلیل اندازه بزرگ کانتینرها، پشتیبانی از چندین نسخه دشوار است
• زمان ساخت طولانی تر، بر خلاف روش های دیگر (اسکریپت ها یا بسته های deb)

از طرف دیگر، چرا بدتر است که یک سرویس Spring را در قالب یک آرشیو jar از طریق همان deb مستقر کنیم؟ آیا جداسازی منابع واقعا ضروری است؟ آیا ارزش از دست دادن ابزارهای راحت سیستم عامل را با قرار دادن یک سرویس در یک ظرف بسیار کاهش یافته دارد؟

همانطور که تمرین نشان داده است، در واقعیت این ضروری نیست، بسته deb در 90٪ موارد کافی است.

چه زمانی deb خوب قدیمی از کار می افتد و چه زمانی واقعاً به داکر نیاز داریم؟

برای ما، این استقرار خدمات در پایتون بود. تعداد زیادی کتابخانه مورد نیاز برای یادگیری ماشینی و در توزیع استاندارد سیستم عامل گنجانده نشده است (و نسخه های اشتباه وجود دارد)، هک با تنظیمات، نیاز به نسخه های مختلف برای سرویس های مختلف زندگی بر روی یک سیستم میزبان منجر به این، که تنها راه معقول برای تحویل این مخلوط هسته ای، داکر بود. شدت کار مونتاژ یک کانتینر داکر کمتر از ایده بسته‌بندی همه آن در بسته‌های deb جداگانه با وابستگی‌ها بود، و در واقع هیچ کس عاقل این کار را انجام نمی‌دهد.

دومین نکته ای که قصد داریم از Docker استفاده کنیم، استقرار خدمات با استفاده از طرح استقرار سبز-آبی است. اما در اینجا می خواهم به تدریج پیچیدگی را افزایش دهم: ابتدا بسته های deb ساخته می شوند و سپس یک کانتینر داکر از آنها ساخته می شود.

بسته های اسنپ

بیایید به بسته های اسنپ برگردیم. آنها برای اولین بار به طور رسمی در اوبونتو 16.04 ظاهر شدند. برخلاف بسته‌های معمول deb و بسته‌های rpm، snap همه وابستگی‌ها را حمل می‌کند. از یک طرف، این به شما امکان می دهد از تضادهای کتابخانه جلوگیری کنید، از طرف دیگر، بسته به دست آمده از نظر اندازه بزرگتر است. علاوه بر این، این می تواند بر امنیت سیستم نیز تأثیر بگذارد: در مورد تحویل فوری، همه تغییرات در کتابخانه های موجود باید توسط توسعه دهنده ای که بسته را ایجاد می کند نظارت شود. به طور کلی، همه چیز به این سادگی نیست و شادی جهانی از استفاده از آنها حاصل نمی شود. اما، با این وجود، اگر از همان Docker فقط به عنوان یک ابزار بسته بندی استفاده شود و نه برای مجازی سازی، این یک جایگزین کاملا منطقی است.

در نتیجه، ما اکنون هم از بسته‌های deb و هم از کانتینرهای docker در یک ترکیب معقول استفاده می‌کنیم، که شاید در برخی موارد آن‌ها را با بسته‌های اسنپ جایگزین کنیم.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

برای تحویل از چه چیزی استفاده می کنید؟

• فیلمنامه های خودنویس

• به صورت دستی در FTP کپی کنید

• بسته های deb

• بسته های دور در دقیقه

• بسته های اسنپ

• Docker-تصاویر

• تصاویر ماشین مجازی

• کل هارد را کلون کنید

• عروسک خیمه شب بازی

• ansible

• دیگر

109 کاربر رای دادند. 32 کاربر رای ممتنع دادند.

منبع: www.habr.com