Docker играчка ли е или не? Или все още е?

Здравейте на всички!

Много искам да премина направо към темата, но би било по-правилно да разкажа малко за моята история:

Влизане

Аз съм програмист с опит в разработването на предни приложения с една страница, scala/java и nodejs на сървъра.

Доста дълго време (определено няколко-три години) бях на мнение, че Docker е манна небесна и като цяло много готин инструмент и абсолютно всеки разработчик трябва да може да го използва. И от това следва, че всеки разработчик трябва да има инсталиран Docker на локалната си машина. Какво ще кажете за моето мнение, прегледайте свободните работни места, които са публикувани на същия hh. Всеки втори съдържа споменаване на docker и ако го притежавате, това ще бъде вашето конкурентно предимство 😉

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

Причини за употреба

Защо използвах докер? Вероятно поради следните причини:

• стартиране на база данни, 99% от приложенията ги използват
• стартиране на nginx за фронтенд разпространение и прокси към бекенд
• можете да пакетирате приложението в докер изображение, по този начин моето приложение ще работи навсякъде, където съществува докер, проблемът с разпространението се решава незабавно
• откриване на услуги извън кутията, можете да създавате микроуслуги, всеки контейнер (свързан към обща мрежа) може лесно да достигне до друг чрез псевдоним, много удобно
• Забавно е да създадете контейнер и да „играете“ в него.

Какво винаги НЕ харесвам в докера:

• За да работи моето приложение, имам нужда от самия Docker на сървъра. Защо ми трябва това, ако приложенията ми работят на jre или nodejs и средата за тях вече е на сървъра?
• ако искам да стартирам моето (частно) локално изградено изображение на отдалечен сървър, тогава имам нужда от собствено хранилище на докери, имам нужда регистърът да работи някъде и също трябва да конфигурирам https, защото docker cli работи само през https. О, по дяволите... има опции, разбира се, за локално запазване на изображението чрез docker save и просто изпратете изображението чрез scp... Но това са много движения на тялото. И освен това изглежда като решение „патерица“, докато не се появи вашето собствено хранилище
• docker-compose. Необходим е само за стартиране на контейнери. Това е всичко. Той не може да прави нищо друго. Docker-compose има куп версии на своите файлове, собствен синтаксис. Колкото и декларативно да е, не искам да им чета документацията. Няма да ми трябва никъде другаде.
• когато работят в екип, повечето хора пишат Dockerfile много криво, не разбират как се кешира, добавят всичко необходимо и ненужно към изображението, наследяват изображения, които не са в Dockerhub или частно хранилище, създават някои docker-compose файлове с бази данни и нищо не продължава. В същото време разработчиците гордо заявяват, че Docker е готин, всичко работи локално за тях, а HR важно пише в свободното място: „Ние използваме Docker и имаме нужда от кандидат с такъв трудов опит.“
• Постоянно ме преследват мисли за повдигане на всичко в Docker: postgresql, kafka, redis. Жалко е, че не всичко работи в контейнери, не всичко е лесно за конфигуриране и стартиране. Това се поддържа от разработчици на трети страни, а не от самите доставчици. И между другото, веднага възниква въпросът: доставчиците не се притесняват да поддържат продуктите си в Docker, защо е това, може би знаят нещо?
• Винаги възниква въпросът за устойчивостта на данните от контейнера. и тогава си мислите, трябва ли просто да монтирам хост директорията или да създам докер том или да направя контейнер за данни, който сега е deprecated? Ако монтирам директория, тогава трябва да се уверя, че uid и gid на потребителя в контейнера съвпадат с идентификатора на потребителя, който е стартирал контейнера, в противен случай файловете, създадени от контейнера, ще бъдат създадени с права на root. Ако използвам volume тогава данните просто ще бъдат създадени в някои /usr/* и ще има същата история с uid и gid като в първия случай. Ако стартирате компонент на трета страна, трябва да прочетете документацията и да потърсите отговора на въпроса: „в кои контейнерни директории компонентът записва файлове?“

Винаги не ми харесваше фактът, че трябваше да се занимавам с Docker твърде дълго в началния етап: Разбрах как да стартирам контейнери, от какви изображения да стартирам, направих Makefiles, които съдържат псевдоними на дълги Docker команди. Мразех docker-compose, защото не исках да науча друг инструмент в докер екосистемата. И docker-compose up Това ме притесняваше, особено ако все пак се срещнаха там build конструкции, а не вече сглобени изображения. Всичко, което наистина исках, беше просто да направя продукт ефективно и бързо. Но не можах да разбера как да използвам докер.

Представяме ви Ansible

Наскоро (преди три месеца) работих с екип на DevOps, почти всеки член на който имаше негативно отношение към Docker. По причини:

• докер правила iptables (въпреки че можете да го деактивирате в daemon.json)
• docker е с грешки и няма да го стартираме в производствена среда
• ако docker daemon се срине, всички контейнери с инфраструктура се сриват съответно
• няма нужда от докер
• защо докер, ако има Ansible и виртуални машини

На същата работа се запознах с друг инструмент - Ansible. Веднъж чух за това, но не се опитах да напиша собствени книги-игри. И сега започнах да си пиша задачите и тогава визията ми се промени напълно! Защото разбрах: Ansible има модули за стартиране на едни и същи докер контейнери, компилации на изображения, мрежи и т.н., а контейнерите могат да се изпълняват не само локално, но и на отдалечени сървъри! Радостта ми нямаше граници - намерих НОРМАЛЕН инструмент и изхвърлих Makefile и docker-compose файловете, те бяха заменени с yaml задачи. Кодът беше намален чрез използване на конструкции като loop, whenИ др

Docker за стартиране на компоненти на трети страни, като бази данни

Наскоро се запознах с ssh тунелите. Оказа се, че е много лесно да „препратите“ порта на отдалечен сървър към локален порт. Отдалеченият сървър може да бъде или машина в облака, или виртуална машина, работеща във VirtualBox. Ако моят колега или аз се нуждаем от база данни (или друг компонент на трета страна), можем просто да стартираме сървъра с този компонент и да го изключим, когато сървърът не е необходим. Пренасочването на порт дава същия ефект като база данни, работеща в докер контейнер.

Тази команда препраща моя локален порт към отдалечен сървър, изпълняващ postgresql:

ssh -L 9000:localhost:5432 [имейл защитен]

Използването на отдалечен сървър решава проблема с развитието на екипа. Такъв сървър може да се използва от няколко разработчици наведнъж, не е необходимо да могат да конфигурират postgresql, да разбират Docker и други тънкости. На отдалечен сървър можете да инсталирате същата база данни в самия Docker, ако е трудно да инсталирате конкретна версия. Всичко, от което се нуждаят разработчиците, е да предоставят ssh достъп!

Наскоро прочетох, че SSH тунелите са ограничена функционалност на обикновен VPN! Можете просто да инсталирате OpenVPN или други VPN реализации, да настроите инфраструктурата и да я дадете на разработчиците за използване. Това е толкова готино!

За щастие, AWS, GoogleCloud и други ви дават една година безплатно използване, така че ги използвайте! Те са евтини, ако ги изключите, когато не се използват. Винаги съм се чудел защо ще ми трябва отдалечен сървър като gcloud, изглежда, че ги намерих.

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

В крайна сметка: можете и трябва да стартирате бази данни и други инфраструктурни екстри на отдалечени сървъри или във виртуална кутия. Не ми трябва докер за тези цели.

Малко за докер изображенията и разпространението

Вече писах Статия в което исках да предам, че използването на докер изображения не предоставя никаква гаранция. Докер изображенията са необходими само за създаване на докер контейнер. Ако надграждате до докер изображение, тогава надграждате, за да използвате докер контейнери и ще използвате само тях.

Виждали ли сте някъде, където разработчиците на софтуер пренасят своите продукти само в докер изображение?
Резултатът от повечето продукти са двоични файлове за конкретна платформа; те просто се добавят към докер изображението, което е наследено от желаната платформа. Чудили ли сте се защо има толкова много подобни изображения в dockerhub? Въведете например nginx, ще видите 100500 XNUMX изображения от различни хора. Тези хора не са разработили самия nginx, те просто са добавили официален nginx към своя докер образ и са го подправили със собствени конфигурации за удобство при стартиране на контейнери.

Като цяло можете просто да го съхранявате в tgz, ако някой трябва да го стартира в docker, тогава го оставете да добави tgz към Dockerfile, да наследи от желаната среда и да създаде допълнителни кифли, които не променят самото приложение в tgz. Всеки, който ще създаде докер изображение, ще знае какво е tgz и какво трябва да работи. Ето как използвам докер тук

В крайна сметка: нямам нужда от докер регистър, ще използвам някакъв S3 или просто хранилище за файлове като google drive/dropbox

Докер в CI

Всички компании, в които съм работил, са подобни. Обикновено са хранителни стоки. Тоест, те имат едно приложение, един технологичен стек (е, може би няколко или три езика за програмиране).

Тези компании използват докер на своите сървъри, където се изпълнява CI процесът. Въпрос: Защо трябва да създавате проекти в докер контейнер на вашите сървъри? Защо просто не подготвите среда за изграждането, например, напишете Ansible playbook, който ще инсталира необходимите версии на nodejs, php, jdk, ще копира ssh ключове и т.н. на сървъра, в който ще се извърши изграждането?

Сега разбирам, че това е прострелване в крака, защото докерът не носи печалба с изолацията си. Проблеми, които срещнах с CI в докер:

• отново се нуждаете от докер изображение за изграждане. трябва да потърсите изображение или да напишете свой собствен докер файл.
• 90%, че трябва да препратите някои ssh ключове, секретни данни, които не искате да записвате в докер изображението.
• контейнерът се създава и умира, всички кешове се губят заедно с него. следващата компилация ще изтегли отново всички зависимости на проекта, което отнема време и е неефективно, а времето е пари.

Разработчиците не изграждат проекти в докер контейнери (някога бях такъв фен, наистина, съжалявам себе си в миналото xD). В java е възможно да имате няколко версии и да ги промените с една команда на тази, от която се нуждаете сега. В nodejs е същото, има nvm.

Продукция

Вярвам, че docker е много мощен и гъвкав инструмент, това е неговият недостатък (звучи странно, да). С негова помощ компаниите могат лесно да се пристрастят към него и да го използват където трябва и не трябва. Разработчиците пускат своите контейнери, някои от своите среди, след което всичко плавно се влива в CI и производството. Екипът на DevOps пише някакъв вид код за стартиране на тези контейнери.

Използвайте докер само на най-новото етап от вашия работен процес, не го влачете в проекта в началото. Това няма да реши бизнес проблемите ви. Той само ще премести проблемите на ДРУГО ниво и ще предложи свои решения, вие ще свършите двойна работа.

Когато е необходим докер: Стигнах до извода, че докерът е много добър в оптимизирането на даден процес, но не и в изграждането на основна функционалност

Ако все пак решите да използвате докер, тогава:

• бъдете изключително внимателни
• не принуждавайте разработчиците да използват докер
• локализирайте използването му на едно място, не го разпространявайте във всички хранилища на Dockefile и docker-compose

PS:

• Наскоро попаднах опаковчик и те казват, че работи много добре с Ansible и ви позволява да обедините процеса на изграждане на изображения (включително докер изображение)
• също за докер, интересна статия

Благодаря ви за четенето, желая ви прозрачни решения във вашите дела и продуктивни работни дни!

Източник: www.habr.com