Най-накрая разбрах, че в сравнение с Docker виртуалните машини вече са без значение

Виртуалните машини се настройват, използват и репликират изключително лесно. През годините винаги съм имал под ръка виртуална машина по различни ключови причини и тя никога не ме е подвеждала. Дотолкова, че в продължение на години дори не обмислях използването на Docker.

Въпреки това виртуалните машини не са перфектни и това ме накара да опитам Docker отново. Накрая се получи и разбирането на Docker промени гледната ми точка за средите за разработка.

Капанът на виртуалната машина

Мислех, че виртуалните машини са единственият начин за изолиране на приложенията.

Както вече споменахме, с виртуалните машини е удобно да се работи. Те са решение за всичко – от тестване на различна операционна система до необходимост от изолиране на тестов проект. Всеки път, когато имах нужда от чиста или позната среда, включвах виртуална машина и започвах работа.

По своята същност обаче виртуалните машини са свързани с огромни режийни разходи. Всеки път, когато стартирате виртуална машина, използвате напълно различна операционна система върху съществуващата. На моя 16-гигабайтов лаптоп можех да стартирам само около две виртуални машини едновременно, преди да започна да изчерпвам паметта.

Това би било добре, ако тествах операционна система – задача, която изисква зареждане на цялата операционна система. За отделни приложения и модули обаче всъщност не е необходимо да се зарежда цялата операционна система. Стига да имате необходимите зависимости, можете да стартирате почти всичко, което искате, с много по-малък размер на пакета.

След това идва въпросът за скоростта. Зареждането на една виртуална машина може да отнеме няколко минути всеки път. Това не е твърде голям проблем за някой, който периодично стартира виртуална машина, за да тества нещо. Когато обаче сте в активна среда за разработка, където машините трябва да се рестартират често, за да се тестват приложенията, стабилността или просто да се отстранят грешките, тези минути започват да се натрупват.

Не на последно място, виртуалните машини могат лесно да заемат няколко GB на диска за съхранение, дори ако на него не е инсталирана операционна система. Повечето виртуални машини, които създадох, имаха динамично разпределени дискове за съхранение, което означаваше, че в крайна сметка имах стотици GB за съхранение, заключени за виртуални машини, които дори не използвах толкова много.

Ето как Docker най-накрая ми допадна

Контейнерите като леки моментни снимки вместо цели системи.

Най-голямата разлика между Docker и виртуалните машини е, че контейнерите на Docker не са мини виртуални машини – те са по-скоро интелигентни опаковки за вашите приложения. Важно е да се разбере разликата между виртуалните машини и контейнерите.

Контейнерите споделят ядрото си с хост операционната система. Това означава, че те не се нуждаят от собствена операционна система, а само от приложението и неговите специфични зависимости. Въпреки това, ако имате нужда, можете лесно да стартирате пълна операционна система от типа на Ubuntu като Docker контейнер.

Всичко това е събрано в спретнат пакет, който се състои от няколко MB вместо GB. Това прави Docker контейнерите изключително леки и ресурсоефективни.

В сравнение с минутите, които са необходими на една виртуална машина, за да стартира, Docker контейнерите стартират почти мигновено. Когато разработвам и трябва да рестартирам нещо, за да тествам промените, вече не ми се налага да седя и да стискам палци, докато средата ми за разработчици се зареди. Контейнерите се рестартират почти мигновено и са готови за работа в рамките на секунди.

Друго предимство на използването на Docker е, че когато контейнеризирате дадено приложение, пакетирате всичко, от което то се нуждае, за да работи, включително точните версии на библиотеките, зависимостите, променливите на средата и дори конкретните слоеве на операционната система, които то очаква. Когато някой друг стартира вашия контейнер, той получава същата среда, в която сте разработвали.

Това спестява много време, което в противен случай би било загубено за справяне с конфликти на версии, липсващи зависимости или фини разлики в средите за разработка и за производство. Docker превръща оправданието „това работи само на моята машина“ в отживелица и аз съм изцяло за тази идея. Въпреки това има няколко най-добри практики на Docker, които е добре да се спазват за постигане на най-добри резултати.

Всички тези предимства водят и до много по-малки режийни разходи при работа с контейнерите. Можете да стартирате стотици Docker контейнери на машина, която би се справила само с няколко виртуални машини. Независимо дали стартирате контейнерите си локално или в облака, това директно ви спестява ствсем немалко пари по отношение на хардуера.

Има причина Docker да се превръща във все по-търсено умение за бекенд софтуерните специалисти. За щастие с него може да се започне достатъчно лесно, особено ако усвоите основните команди на Docker за начинаещи. Съществуват и някои основни теми за Docker за начинаещи, с които е добре да се запознаете, ако тепърва започвате. (На това ще се спрем в някоя от следващите статии)

Микроуслугите вече имат смисъл

Docker превърна тази модна фраза в нещо практично.

Преди да разбера концепцията на Docker, архитектурата на микроуслугите звучеше като кошмар. Не съм привърженик на разделянето на кода си на множество файлове или услуги. Също така обаче никога не ми се е налагало да мащабирам приложение, за да поддържам огромен брой потребители, така че обикновените виртуални машини и сървъри отговарят отлично на нуждите ми.

Разделянето на едно прекрасно и просто монолитно приложение на по-малки услуги все пак може да се окаже кошмар за администриране, ако става въпрос за личен проект, при който не ви е грижа за ефективността. Въпреки това, тъй като всяка микроуслуга се превръща в самостоятелна единица в Docker, можете да запазите приложението си работещо, дори ако някоя услуга се срине.

Това означава, че ако разработвате приложение за масовия потребител, няма да се сблъскате със сривове на приложението в момента, в който нещо в кода ви се повреди. Освен това мащабирането на отделните части на вашето приложение става изключително лесно и евтино.

Така например, ако очаквате голям поток от трафик за уеб сайт за електронна търговия поради продажбите на Черния петък, можете да увеличите мащаба на услугата си за обработка на плащания. Това спестява време и пари, като мащабирате само услугата, която ще бъде подложена на най-голямата тежест на трафика, запазвайки останалата част от инфраструктурата си оптимизирана и работеща. Дори ако дадена услуга се срине, приложението ви все още ще е достъпно.

Редица големи технологични продукти управляват хиляди микроуслуги по този начин. Да, това е сложно, но не е сложност заради самата сложност. Управлението става по-лесно, когато всяка част е правилно контейнеризирана.

Виртуалните машини все още не са остарели

Те все още са чудесни за определени работни натоварвания.

Docker контейнерите все още не могат да изхвърлят виртуалните машини от бизнеса. Има много начини, по които бихте предпочели виртуална машина пред контейнер, особено ако се нуждаете от пълна изолация на операционната система по причини, свързани със сигурността или тестването. Освен това, ако трябва да използвате стари приложения, които изискват специфични версии или конфигурации на операционната система, виртуалните машини са по-добрият начин.

Въпреки това, за разработката на съвременни приложения Docker може да се окаже инструмент, който променя правилата на играта. Инсталирането на Docker в операционната система Windows 11 е доста лесно и трябва да го изпробвате, ако още не сте го направили.

Той е по-бърз, по-ефективен, по-преносим и най-важното – по-евтин за работа в сравнение с виртуалните машини. Бъдещето очевидно е контейнерно и най-накрая разбирам защо всички бяха толкова развълнувани от него през всичкото това време.