Комментарии 37
Вот я из ретроградствующих. Как из статьи, так из собственных ощущений вижу что "Это дикость". Какие проблемы мы решаем всей этой кучей инструментов? Быстрая выкладка кода? Но не создаем ли мы больше проблем, чем решаем? Или тут следует выключить мозг и смириться с тем, что "так надо"?
Следующая задача — упрощение развертывания и обновления. Не нужно растаскивать на все используемые серверы, достаточно обновить образ и перезапустить все копии контейнеров.
Можно задать этот же вопрос про объектно-ориентированное програмирование, и ответ кстати будет примерно такой же. Зачем нужно ООП?
Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
В 1990-е годы ожидалось что приложение будет выпускаться раз в несколько лет и монолитный ООП подходил, да и в целом — технологии не давали обновлять «части» приложения.
В 2010-е хочется обновлять приложение (оно теперь стоит на сервере) как можно быстрее. Если большая команда будет писать миллион фич в пределах одного приложения — это будет сложно, лучше приложение разделить. Поскольку люди имеют свойство делать глупости и ошибаться — лучше эти отдельные куски приложения сделать вообще отдельными приложениями, пусть каждый работает над своей частью. Эти приложения надо как-то менеджить — появился K8S. Для больших приложений (посмотрите на карту сервисов Netflix) это работает великолепно.
Почему так пишут даже маленькие приложения? Да фиг его поймет почему, можно по другому, но пишут. ООП тоже непонятно зачем для маленьких приложений было, но стало просто стандартом. Так и тут. Противно, в отличие от ООП (которое было до того как многие из нас стали айтишниками) произошло при нас, хочется брюзжать. На ООП, наверняка, также толпа справедливо брюзжала.
Зачем нужно ООП?
Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
Для этого нужно ABI, нужна система пакетов типа npm/maven/nuget, нужны библиотеки. ООП для этого не нужно.
Не беспокойтесь, такое уже было и благополучно сдохло. Вспоминаю J2EE, который весь из себя был заточен для распределённых систем. Там было все, что сегодня есть в k8s и даже больше. Сдохло оно протому, что появился spring framework, который выкинул всю распределенщину и позволил делать «просто». Затем уже spring’у досталось от Ruby On Rails, который сделал ещё проще и который до сих пор его можно считать стандартом простоты и лаконичности.
А до J2EE была CORBA и DCOM, там было все то же самое. J2EE приходил к ним на смену, вроде как пытался их упростить :)
Продвинутый App server был распределённым, мог запускаться на нескольких хостах. Был auto scaling, когда новые инстансы сервисов поднимались по требованию. Облаков тогда не было, поэтому масштабирование было внутри app server.
Мне кажется с докером и кубером сейчас происходит то же что и с {any_js_framework}, а именно докер+кубер пихают везде куда ни попадя.
Развертывание приложений — если вы производите сотни развертываний приложения в день может быть тут и будет полезен этот стек. Но черт побери — зачем столько развертываний? Ну хорошо, даже если нужно столько развертываний, то просто привези код на сервер и запусти. Для этого подойдут обычные CI/CD методики. При этом программисты будут делать свою работу, а админы свою.
Масштабирование: если вы разрабатываете приложение с возможным взрывным ростом, то наверняка делаете это сразу в облаках и, теоретически, неограниченными техническими возможностями. В таком случае кубер хорошее решение. В остальных случаях, имхо, проще добавить серверов классическим методом, и немного изменить скрипты CI/CD для доставки приложения на большее число серверов.
Локальная разработка — да, проще поднять свою копию приложения в докер контейнерах и разрабатывать локально используя их, но это касается весьма больших приложений с увесистым стеком технологий. В остальном же поднять вебсайтик локально можно и без докеров и куберов.
Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.
Потом смотришь — лендинг, а под ним OS — VM — k8s — docker — PM2 — Reakt(в котором jQuery и куча тяжелых библиотек) и все это лютейшим образом тормозит, жрет половину мощности хорошего сервака, и падает через каждые 20 минут от пережора памяти, весело прибиваемое OOM и так же весело рестартуя.
Мне кажется инструменты следует применять с умом и по необходимости.
Я согласен, это звучит дико, но мне кажется другого пути уже нет.
Exe-формат действительно не самый лучший формат на свете, я помню споры про него.
Но программистов проще учить «стандарту» и этот стандарт будет уже такой.
В остальном же поднять вебсайтик локально можно и без докеров и куберов.
Дело несколько усложняется, когда нужно поднять локально несколько вебсайтиков с разными версиями рантаймом и баз данных.
Смотря что считать "ваши". Мои личные — может быть свои личные ресурсы на это выделю, а вот моей компании — уже хуже с этим.
Но все это мои, ретроградные рассуждения, возможно я просто не умею все это готовить )))
А вы расскажите, пожалуйста, какие конкретно проблемы решает ООП, чего в нем такого? Вот богатая стандартная библиотека решает, GC решает, ABI позволяет иметь богатую экосистему, reflection тоже очень сильно помогает. А само ООП, чем нам помогает, кроме того, что мы пишем «obj.method()» вместо «method(obj)»? Наследование, полиморфизм тривиально реализуются в любом вменяемом языке. ОО языки дают удобный синтаксис, но это маргинальное улучшение, по сравнению с упомянутой богатой стандартной библиотекой и прочими вкусностями.
K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере. А теперь попробуем найти компании и проекты, которым это актуально. Такие есть, но их немного. У них очень много железа, не в облаке, а в собственном дата центре и они хотят максимально эффективно его использовать. А ещё у них штат админов, которые заколебались права доступа на это железо раздавать и которым проще дать людям «виртуальную» среду, куда они свои сервисы смогут закидывать. Это все стоит немалых денег, но так как железа много и админов много и времени на согласование с ними тоже тратиться много, то k8s имеет экономический смысл.
В остальном k8s нужен, в первую очередь, консультантам и продавцам девопсеров.
ООП может быть вообще бесполезно. ФП может быть в сто раз лучше. Но проблема в том, что мир в 90-е пошел в ООП. И человек из 80-х отрицающий ООП, потому что «это какой-то новомодный тренд», будет прав, но выпадет из тренда. Я не пропагандирую в статье, что это _правильный_ путь. Но я пропагандирую, что если вы хотите соответствовать текущим технологическим тенденциям — это надо знать.
>K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере.
В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
Давайте я скажу так, в порядке дружелюбной критики. Статья хорошая и полезная, информация по делу и изложена понятным образом. Я не считаю, что связывать полезность ООП с полезностью
k8s это верно, потому что полезность самого ООП это предмет неутихающих дебатов. В частности вот это фактически не верно.
Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт;
В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.
Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.
Или просто будете нанимать тех, кто уже умеет. Вот прямо сейчас в поисках работы сталкиваюсь, что нужны на проекты люди со знанием PHP и AWS и ответ "за неделю-другую, думаю, разберусь с основами, чтоб реализовать основные флоу, которые привык реализовывать на k8s" уже не устраивает.
имхо для новой компании эта проблема будет решена
я считаю что достаточно скоро написать helm/yaml деплоящий аппу в EKS/GKE будет неким базовым навыком разработчика
то есть я совсем не говорю что «технологии изменились, и то, на чем написан софт надо менять», я говорю «технологии изменились и их стоит учить», хотя бы по этим двум не-техническим причинам:
1. старым компаниям соврешенно резонно не менять стек, но — см. booking — рано или поздно на этот стэк станет сложно нанимать людей
2. рано или поздно людям со старым стэком станет сложно наниматься на новый стэк
Букинг очень давно переезжает на JVM, и новые сервисы на ней, и нанимают в основном джавистов. Перл иногда требуется, но Букингу не принципиально, знает разработчик перл или нет—если будет нужно, помогут подучить и разобраться.
Между прочим, я не считаю перл каким-то ископаемым динозавром: он развивается, им пользуются. Я сам предпочитаю перл пайтону, когда дело доходит до консольных скриптов.
В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
Вот сейчас залез в репу и вспомнил: минимально запустить сервис из образа — несколько yaml — файлов с манифестами (обычный набор: деплоймент, сервис, ингресс, конфиг, секреты), умножаем на количество окружений (локальное, дев, тест, препрод, прод) или добавляем какой-нибудь Helm, который позволит обойтись меньшим количеством файлов с манифестами, но добавляет файлы со разными значениями для разных окружений.
То есть если переложить на докер/кубернетес, то чётка видна эволюция. В конце всем охота чтобы сервис просто работал.
Я думаю уже можно начинать присматриваться к serverless, типа AWS Lambda или GCP Functions, есть также версии для кубернетеса, типа Kubeless, Serverless, итд.
Но следуя этой «эволюционной» парадигме, что будет дальше??
Что будет в совсем далёком будущем не совсем понятно, но «зватра» возмжно будут они.
А просто Serverless это уже «сегодня».
Я не программист, не сисадмин (в прошлом веке был, но давно уже другими делами занимаюсь). И в качестве хобби и саморазвития иногда поднимаю серверочки.
Возьмем, к примеру, ioBroker. Там какой-то Node.Js, с которым я раньше дела не имел. Попробовал на свой Centos установить — он, конечно, встал, не ioBroker не завелся. Нужна более новая версия Node.js, а она ставится уже не просто yum install.
Собственно, поскольку я уже давно хотел посмотреть, а что же такое Докер, я и решил это попробовать.
Встало мгновенно!
Чтобы переехать, к примеру, на Ubuntu, не надо копаться заново. Тот же самый контейнер запускается точно так же.
Естественно, хост не только этим занимается. У меня еще mosquitto на нем крутится.
Может он и встал бы «как есть», а может потребовал бы каких-то других библиотек. Решать конфликты и зависимости ни разу не интересно.
docker run mosquitto… выбрав нужный имидж на dockerhub — все! Пофиг, что он внутри вообще на другом ддистрибутиве собран. Все нужное в нем, за меня люди поработали.
Контейнер отъедает 1.78MB памяти. Может это «из пушки по воробям», но я могу себе это позволить ради собственного удобства.
Вышла новая версия софта. Как забэкапить, чтобы обновить? Как откатиться, если что?
Раньше у меня такие проблемы были с Wordpress, Drupal… Как там у ioBroker все устроено вообще понятия не имею.
На VPS снапшот не снимешь. Надо с каждым приложением индивидуально разбираться. И с кодом, и с данными.
С докером я останавливаю контейнер с текущей версией. Копирую директорию с его файлами (ну которая в контейнер подмонтировалась). И запускаю контейнер с новой версией.
Если что-то пойдет не так — остановить «новый», вернуть директорию и запустить старый контейнер — плевое дело.
А если саму OS обновить? Вот тупо yum/apt update/upgrade дать страшно. Какая-нибудь билиотека поменяется или еще что, и фиг разберешься, что не так.
Снапшотов, на помню, у меня на VPS нет.
С докером и простым бэкапом папок с данными я в любой момент создаю новый сервер или полностью переустанавливаю ОС (в т.ч. на новую версию вместо того, чтобы кучу апдейтов тащить), запускаю ansible (его я так же оценил — не интересно вручную ставить fail2ban и запрещать логин рутом через ssh), и через несколько минут опять все работает.
Есть еще ряд моментов, но эти оказались наиболее значимыми для меня.
В энтерпрайзах с хорошими админами вопросы бэкапов и апдейтов, безусловно, решены.
Однако же конфликты библиотек от приложений, написанных разными разработчиками, остаются.
Ну реально, один писал под Ubuntu, другой под Debian, третий на RedHat.
Не факт, что если все трое принесут свои наработки на сервер с CentOS, все заработает само.
Какие-нибудь npm будут нужны разных версий, еще что-то…
Гораздо проще принести свой контейнер. Он и маленький (не целая виртуальная машина), и содержит все, что нужно, ни с кем не конфликтует…
А если приложения макросервисные, так вообще пофиг, какая команда какой микросервис на каком фреймворке пилит. Все будет прекрасно жить и друг другу не мешать.
Всякая «побочка» типа A/B тестирования тоже элементарно реализуется. бегут 4 контейнера, запустил пятый с новой версией. 20% пользователй на нее направил, посомтрел, постепенно старые контейнеры остановил, новые запустил…
И опять же, все автоматически.
Разумеется, любую технологию надо с умом использовать, а не просто потому что модно.
Но да, этот тренд с контейнерами возник не искусственно. Он реально много проблем решает.
У меня в голове такая аргументация была, но я не мог ее сформулировать.
Смотря что понимать под готовыми.
Не у всех Bitnami с выверенными имиджами.
Очень многие берут условный Alpine м докерхаба, и на него уже свое накручивают.
И дальше уже CI/CD со встроенными проверками. И на исходники (вдруг разработчик библиотеку не сам с нуля написал, а с гитхаба уволок). И контейнеров (вдруг в той же Альпине уязвимость, и библиотеки а-ля openssl, дырявые).
Только вот какая разница, взять имидж Альпины или CentOS из репозитория имиджей или как ISO для VM?
И при обнаружении CVE-2019-14697, когда все в продуктиве, проще создать контейнер, основанный на новом образе, чем патчить живую VM.
Не вижу принципиального усложнения.
Вот если бы вы привели пример, что Docker привносит свои дополнительные уязвимости, это было бы бесспорно.
проще создать контейнер, основанный на новом образе, чем патчить живую VM.
Если у вас есть возможность создать новый контейнер — значит, и VM вполне допустимо перезагрузить либо пересоздать.
Конечно допустимо. Вопрос в удобстве.
Что обычно делают при обнаружении уязвимости в ОС или библиотеке или ещё чем-то таком, не в самом приложении?
Докер/Кубернетес:
Автоматически собирается новый контейнер, отправляется на тестирование, потом в продакшн.
VM:
Автоматическая установка патчей мне видится намного менее распространенной.
Но дело не в этом — железный и виртуальных хост по сути это одно и то же с точки зрения процессов эксплуатации, а админов одинаковый набор инструментов.
В случае с кубером и докером процесс другой, инструменты добавились еще или вообще не существуют, нужно самим писать. Архитектурно кубер не эквивалентен ВМ, хотя бы из за особенностей построения сетевой части те для ИБ нужно раскуривать NetworkPolicy и как то вовлекать их в процесс апрува. И еще нужно учитывать что часть компонентов экосистемы откровенно глючит и может вообще полностью менять свою функциональность от версии к версии. :)
Ну и практика показала что далеко не каждый админ сможет до конца разобраться с кубером и докером.
Так что патч менеджмент — это только верхушка айсберга.
И не только «уязвимости»
Достаточно на какой-нибудь CIS Benchmark Кубернетеса взглянуть, чтобы оценить, за сколькими настройками следить надо. Даже сетевая безопасность (трафик) не основной момент (хотя тоже новый подход, новые инструменты...)
Но о том, что Докер с Кубером предназначены для облегчения жизни безопасников никто и не говорил :)
Равно как и всяческие облака. Одно неверное движение, и на базе данных появился публичный IP (в отличие от традиционных ЦОД, где админам сложнее так напортачить).
Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое— выдача желаемого (?) за действительное.
В любом случае считаем TCO применительно к необходимому SLA и получаем основание для решения. Что-то выгодно в облаке, а что-то наоборот, будет лишней ничем не оправданной тратой денег.
Kubernetes, микросервисы, CI/CD и докер для ретроградов: советы по обучению