company_banner

Kubernetes, микросервисы, CI/CD и докер для ретроградов: советы по обучению

    Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».

    Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

    Почему я считаю важным уметь менять парадигму технологического мышления?

    Самая сложная вещь для тех, кто давно работает в технологиях, — принять, что новый тренд стал постоянным. За 20 лет работы я видел, как приходили и уходили разные технологии, причем некоторые из них были «суперактуальны» целых несколько месяцев.

    Я читал Джоэля Спольски про то, как Microsoft систематически придумывает новый стек для разработчиков для того, чтобы в целом не дать им возможность посмотреть на что-то иное. Как SRE, я вдвойне опасался каждой новой технологии: всё новое — сырое, всё сырое — нестабильное. Ну, а всё нестабильное приведёт к проблемам в продакшне, а стабильность продакшна — это главное.

    Как программист и предприниматель, я хотел создавать продукт быстрее — всё новое надо изучать, изменять привычные подходы, а это значит — медленнее выкатывать фичи. Если какие-то новые технологии принимались быстро, то все связанное с микросервисно-ориентированной разработкой (давайте так назовем весь современный стек) нужно было учить. И с каждым годом учить все дольше; гораздо проще писать старым привычным методом и доставлять продукт быстрее.

    Но факт остается фактом: иногда новые технологии остаются и меняют всю парадигму целиком. И тут возникает выбор: оставаться в старой парадигме или переходить в новую. Cobol-программисты до сих пор могут устроиться на работу, perl-разработчики помнят про booking, но альтернативных путей для этих людей становится всё меньше и меньше. И тогда «ретроградство» во имя стабильности становится ограничением. Со всем современным стеком, если вы не хотите себя ограничивать, время уже не то, что пришло, а мы уже отстаем. И, если мы не хотим застрять в «perl»-е, надо учиться. Это занимает продолжительное время. Попробую рассказать свой пошаговый опыт в обучении.

    Направления глубокого погружения


    Поймите, как запускать приложения в докере. Прежде всего, ветеранам стоит понять, что способ «хранения» и «запуска» приложений изменился навсегда. Скорее всего, разработчик, который научился разработке в последние годы, вообще не представляет себе, как запускать приложение в продакшне без докера. В голове такого разработчика, вероятно, нет концепции «хранить файлы локально», кроме редких кейсов общего хранилища, но главное, что нужно понять «ветерану»: докер — это новый exe. У exe-формата, может быть, есть свои минусы, но никто уже об этом особо не думает.

    Да, микросервисный подход стал стандартом. Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт; теперь таким же стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). Это разумно: при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое. Зачем и маленькие приложения писать микросервисно, можно поспорить, но и их в какой-то момент все стали писать в ООП-стиле— просто так привычно (см. выше про exe). Можно много рассуждать о том, что у межпроцессной коммуникации (особенно, построенной на TCP-стеке) существует миллион недостатков с точки зрения производительности (один сервис пойдет к другому по TCP вместо того, чтобы просто выполнить ассемблерный-call — вы представляете какая это разница в производительности?), но факт остается фактом — у микросервисов есть достоинства скорости разработки средних и больших проектов и они также стали стандартом. Поймите, как микросервисы между собой взаимодействуют (HTTP API, grpc, асинхронное взаимодействие через очередь — миллион способов), бонусом — поймите, что такое service mesh. (Минута гневного юмора: боже, ребята, они придумали разделить приложение, и оказалось, что коммуникация между разделенными приложениями — сложная шутка, поэтому они добавили еще один слой, чтобы облегчить межпроцессный ужас, за что это нам?)

    Поймите, как управлять пачкой запущенных в докерах микросервисов. Итак, мы смирились, что приложения мы теперь запускаем в докере и что приложение мы разделяем на микросервисы. Теперь надо как-то управлять запущенными докерами. Можно делать это самому на выделенных серверах (и рулить, например Docker Swarm-ом, ну или собрать Kubernetes), а можно использовать сервисы, которые дают облака — контейнер-сервисы от AWS или Kubernetes. В использовании облаков есть одно очень большое преимущество. Вы, фактически, перестаете думать про слой, запущенный ниже менеджера контейнеров (SRE сейчас посмеются, но давайте признаемся — когда все стабильно, мы не лазим на ноды GKE руками в большинстве случаев). Таким образом, фактически, менеджер контейнеров, стандартом которого стал Kubernetes, превращается в операционную систему. В нём есть пакет-менеджеры, в него можно «ставить софт», в нём можно запускать «exe-шники» — докеры, в нём есть кронджобы. Kubernetes — это новая ОС.

    Разберитесь, как докер-контейнеры надо будет доставлять. Выкладка простого сайта теперь занимает 5 минут, и люди считают это нормой. Надо собрать докер, протестировать, положить в registry и поместить в менеджер докеров (давайте будем говорить дальше Kubernetes). Это дикость (?), к которой все привыкли, это оптимизируется и это стандарт. CI/CD системы стали стандартом выкладки, и с ними надо разобраться. Также как и с GitOps.

    Поймите, что on-premise хостинг для большинства приложений уйдет (на Западе — уже ушел) в прошлое. Когда-то давно нормой было купить серверы, собрать их, привезти в ДЦ, поставить в колокейшн и скоммутировать. Даже для небольшого проекта. Потом на смену пришли Dedicated-серверы. Какому количеству людей приходит сейчас в голову на небольших и средних проектах мучаться, покупать и собирать железо? На смену Dedicated — на Западе уже сейчас, а в РФ скоро — придут облака. Об этом говорят сто лет, я использую AWS с 2008 года, и у него есть проблемы, но когда мы говорим о сервисе, который берёт на себя менеджмент Kubernetes (EKS, GKE, Kubernetes от Яндекса или Селектела), мне становится непонятно, зачем менеджить сам Kubernetes и дедики, если это делают другие ребята? Я же не меняю кулеры в дедиках больше… Вопрос распространенности on-premise дистрибуций Kubernetes в РФ — это вопрос курса доллара, закона о персданных и «молодости» российского клауд-хостинга. Рано или поздно это решится и on-premise станет дикостью, которую хотят энтерпрайзы и большие нагруженные проекты. С базами то же самое. Если мы говорим о большинстве приложений, которым не требуется супервысокая нагрузка или супермощный тюнинг, то облачный PostreSQL/MongoDB/MySQL дает огромное количество преимуществ. Не надо думать про тюнинг, не надо думать про бэкапы. Создать дев-сервер из продакшн-сервера — пара команд в облачной консоли. Я понимаю, что вся эта идея может вызывать гнев у админа: ребята, я и сам админ, но для большинства нехайлоад задач менеджмент баз, правда, не нужен. Возможно, AWS и GKE стоят дорого и недоступны нам из-за закона о персданных, но это лишь дополнительное время для отставания: рано или поздно те же фичи будут у Яндекса или Селектела, и парадигма сменится.

    Поймите, что инфраструктуру теперь пишут. Я не любил IaaC, когда он был Chef-ом и Puppet-ом, но на смену им, слава богу, пришли более адекватные Terraform и Pulumi для описания того, что вы хотите поднять в кластере, и Ansible для работы внутри. Зайти и что-то поставить в шелл — теперь абсолютная дикость. Да, это быстрее и удобнее, но в новой парадигме — это дикость: вспомните про exe.

    Курс глубокого погружения


    Каким я вижу конкретный технический путь для того, чтобы понять, как работать с современным стеком?

    1) Сделать триальный аккаунт на клауд-хостинге. Их предоставляют все хостинги. Я начинал с GKE, но можно, например, взять аккаунт на российских хостингах, если вы ожидаете, что работать будете, скорее всего, на этой территории.
    Если Terraform/Pulumi поддерживают ваш клауд — описать инфраструктуру, которую вы хотите создать в них. Если у вас есть навыки программирования, я рекомендую Pulumi: вместо собственного SDL Terraform-а вы сможете писать на привычных языках и конструкциях.

    2) Найти приложение и упаковать его в докер. Что тут упаковывать — выбор за вами. Я внезапно обнаружил для себя, насколько стал распространен NodeJS, и решил заняться глубоким изучением его эксплуатации, поэтому дальнейшую работу веду с нодой. Вот, например, бложик на NodeJS, который можно поднять, но вообще все на ваше усмотрение.

    3) Разобраться с базовыми конструктами (под, деплоймент, сервис) K8S и задеплоить приложение руками в кластер K8S.

    4) Разобраться с Helm-ом, написать Helm-чарт, задеплоить приложение Helm-ом.
    Взять бесплатный план на CircleCI как CI-ке, которую не надо ставить, и конфигурировать: конфиги будут похожи на остальные системы.

    5) Задеплоить приложение через CI-ку.
    Разделить CI (то, что собирает приложение) и CD. Сделать CD по GitOps (см, например ArgoCD).

    Что дальше


    Где-то с этого момента вы, в принципе, будете в курсе основных базисов современного стэка.
    Куда можно пойти копаться дальше?

    • Если вы ищете работу/хотите работать на Западе, можно пойти в углубление знаний по клаудам: сдайте на Cloud Architect сертификат Google-а или аналогичный от AWS (мы в ITSumma недавно получили 3 таких сертификата). Это даст представление о фичах, которые дают клауды, и поможет в них ориентироваться. Хороший курс на linuxacademy.
    • Сдайте на CKA: это уже сложная тема, но стоит того. Подготовка к экзамену даст огромный пакет знаний.
    • Научитесь программировать, если не умеете. Я сейчас пошел изучать фронт и поражен тем, как всё изменилось. Мои знания закончились где-то в 2012-м или даже раньше, еще на JQuery, люди смеются. Фронт сейчас стал сложнее, чем бэкэнд, там огромное количество application-логики и при этом совершенно непривычные для меня парадигмы. Очень интересно!

    А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
    ITSumma
    Собираем безумных людей и вместе спасаем интернет

    Комментарии 35

      +14

      Вот я из ретроградствующих. Как из статьи, так из собственных ощущений вижу что "Это дикость". Какие проблемы мы решаем всей этой кучей инструментов? Быстрая выкладка кода? Но не создаем ли мы больше проблем, чем решаем? Или тут следует выключить мозг и смириться с тем, что "так надо"?

        +1
        Думаю в первую очередь это масштабируемость. Если вдруг понадобится больше ресурсов — такое решение позволит его получать «по запросу».
        Следующая задача — упрощение развертывания и обновления. Не нужно растаскивать на все используемые серверы, достаточно обновить образ и перезапустить все копии контейнеров.
          +5
          Тут хитрый вопрос.
          Можно задать этот же вопрос про объектно-ориентированное програмирование, и ответ кстати будет примерно такой же. Зачем нужно ООП?
          Чтобы большие команды могли проще создавать сложные многофункциональные приложения.
          В 1990-е годы ожидалось что приложение будет выпускаться раз в несколько лет и монолитный ООП подходил, да и в целом — технологии не давали обновлять «части» приложения.
          В 2010-е хочется обновлять приложение (оно теперь стоит на сервере) как можно быстрее. Если большая команда будет писать миллион фич в пределах одного приложения — это будет сложно, лучше приложение разделить. Поскольку люди имеют свойство делать глупости и ошибаться — лучше эти отдельные куски приложения сделать вообще отдельными приложениями, пусть каждый работает над своей частью. Эти приложения надо как-то менеджить — появился K8S. Для больших приложений (посмотрите на карту сервисов Netflix) это работает великолепно.
          Почему так пишут даже маленькие приложения? Да фиг его поймет почему, можно по другому, но пишут. ООП тоже непонятно зачем для маленьких приложений было, но стало просто стандартом. Так и тут. Противно, в отличие от ООП (которое было до того как многие из нас стали айтишниками) произошло при нас, хочется брюзжать. На ООП, наверняка, также толпа справедливо брюзжала.
            +3
            Отличие 90х и 200х есть еще в одном моменте — это развитие глобальной сети, а вместе с ней и способов доставки приложений. В 90х монолитные приложения обновлялись копированием с носителей на компьютеры оффлайн, и это было нормально. Затем с развитием сетей появилось онлайн обновление, что потребовало разбивать приложение на модули для снижения трафика. Ну а в настоящий момент эта «естественная» идея вышла на новый уровень.
              +1
              Зачем нужно ООП?
              Чтобы большие команды могли проще создавать сложные многофункциональные приложения.

              Для этого нужно ABI, нужна система пакетов типа npm/maven/nuget, нужны библиотеки. ООП для этого не нужно.

              +4

              Не беспокойтесь, такое уже было и благополучно сдохло. Вспоминаю J2EE, который весь из себя был заточен для распределённых систем. Там было все, что сегодня есть в k8s и даже больше. Сдохло оно протому, что появился spring framework, который выкинул всю распределенщину и позволил делать «просто». Затем уже spring’у досталось от Ruby On Rails, который сделал ещё проще и который до сих пор его можно считать стандартом простоты и лаконичности.


              А до J2EE была CORBA и DCOM, там было все то же самое. J2EE приходил к ним на смену, вроде как пытался их упростить :)


              Продвинутый App server был распределённым, мог запускаться на нескольких хостах. Был auto scaling, когда новые инстансы сервисов поднимались по требованию. Облаков тогда не было, поэтому масштабирование было внутри app server.

                0
                Один раз помучаться: сделать правильный контейнер, настроить GitLab CI/CD, а потом пушишь в нужную ветку и у тебя через пять минут все обновилось на рабочих серверах.

                Второй проект — чуть меняются скрипты и все.

                Потом вот пример: есть небольшой проект, надо добавить одну мелочь в дороге, ноута с собой нет. Зашел через веб-интерфейс в гитлаб с телефона, поправил, сохранил… а дальше само все обновилось.
                +5
                disclaimer: Я ретроград
                Мне кажется с докером и кубером сейчас происходит то же что и с {any_js_framework}, а именно докер+кубер пихают везде куда ни попадя.

                Развертывание приложений — если вы производите сотни развертываний приложения в день может быть тут и будет полезен этот стек. Но черт побери — зачем столько развертываний? Ну хорошо, даже если нужно столько развертываний, то просто привези код на сервер и запусти. Для этого подойдут обычные CI/CD методики. При этом программисты будут делать свою работу, а админы свою.

                Масштабирование: если вы разрабатываете приложение с возможным взрывным ростом, то наверняка делаете это сразу в облаках и, теоретически, неограниченными техническими возможностями. В таком случае кубер хорошее решение. В остальных случаях, имхо, проще добавить серверов классическим методом, и немного изменить скрипты CI/CD для доставки приложения на большее число серверов.

                Локальная разработка — да, проще поднять свою копию приложения в докер контейнерах и разрабатывать локально используя их, но это касается весьма больших приложений с увесистым стеком технологий. В остальном же поднять вебсайтик локально можно и без докеров и куберов.

                Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.

                Потом смотришь — лендинг, а под ним OS — VM — k8s — docker — PM2 — Reakt(в котором jQuery и куча тяжелых библиотек) и все это лютейшим образом тормозит, жрет половину мощности хорошего сервака, и падает через каждые 20 минут от пережора памяти, весело прибиваемое OOM и так же весело рестартуя.

                Мне кажется инструменты следует применять с умом и по необходимости.
                  +1
                  >Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.

                  Я согласен, это звучит дико, но мне кажется другого пути уже нет.
                  Exe-формат действительно не самый лучший формат на свете, я помню споры про него.
                  Но программистов проще учить «стандарту» и этот стандарт будет уже такой.
                    +1
                    В остальном же поднять вебсайтик локально можно и без докеров и куберов.

                    Дело несколько усложняется, когда нужно поднять локально несколько вебсайтиков с разными версиями рантаймом и баз данных.

                      0
                      Вот тут докер как раз будет уместен, я так считаю. Хотя если все сайты ваши, а не клиентские, то выровнять версии ПО на серверах и у себя проблем не составит.
                        0

                        Смотря что считать "ваши". Мои личные — может быть свои личные ресурсы на это выделю, а вот моей компании — уже хуже с этим.

                          0
                          Да, конечно, в большой компании могут быть сервисы с разными версиями баз и т.п. При этом, сугубо на мой взгляд, докер только увеличит энтропии в системе. Один сервис на том, другой на этом, пятый вообще через опу запускается. Да, можно с легкостью описать это все в конфигах и работать с тем что досталось, но мне кажется неправильным. Получается инструмент для управления хаосом, хоть и весьма удобный, а задача уменьшить этот хаос отодвигается все дальше и дальше.

                          Но все это мои, ретроградные рассуждения, возможно я просто не умею все это готовить )))
                            +1

                            Управляемый хаос уже имеет меньшую энтропию. :) И, да, в каком-то смысле докер инструмент по управлению хаосом, позволяющий разбить большой хаос на изолированные кирпички с единообразными входами и выходами.

                      0
                      как минимум докер для го чтобы работал скейлинг, автоподнимание, плавный деплой и тд. образ можно взять альпайн и будет бинарник +15мб.
                      +3

                      А вы расскажите, пожалуйста, какие конкретно проблемы решает ООП, чего в нем такого? Вот богатая стандартная библиотека решает, GC решает, ABI позволяет иметь богатую экосистему, reflection тоже очень сильно помогает. А само ООП, чем нам помогает, кроме того, что мы пишем «obj.method()» вместо «method(obj)»? Наследование, полиморфизм тривиально реализуются в любом вменяемом языке. ОО языки дают удобный синтаксис, но это маргинальное улучшение, по сравнению с упомянутой богатой стандартной библиотекой и прочими вкусностями.


                      K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере. А теперь попробуем найти компании и проекты, которым это актуально. Такие есть, но их немного. У них очень много железа, не в облаке, а в собственном дата центре и они хотят максимально эффективно его использовать. А ещё у них штат админов, которые заколебались права доступа на это железо раздавать и которым проще дать людям «виртуальную» среду, куда они свои сервисы смогут закидывать. Это все стоит немалых денег, но так как железа много и админов много и времени на согласование с ними тоже тратиться много, то k8s имеет экономический смысл.


                      В остальном k8s нужен, в первую очередь, консультантам и продавцам девопсеров.

                        +1
                        >А вы расскажите, пожалуйста, какие конкретно проблемы решает ООП, чего в нем такого? Вот богатая стандартная библиотека решает, GC решает, ABI позволяет иметь богатую экосистему, reflection тоже очень сильно помогает. А само ООП, чем нам помогает, кроме того, что мы пишем «obj.method()» вместо «method(obj)»? Наследование, полиморфизм тривиально реализуются в любом вменяемом языке. ОО языки дают удобный синтаксис, но это маргинальное улучшение, по сравнению с упомянутой богатой стандартной библиотекой и прочими вкусностями.

                        ООП может быть вообще бесполезно. ФП может быть в сто раз лучше. Но проблема в том, что мир в 90-е пошел в ООП. И человек из 80-х отрицающий ООП, потому что «это какой-то новомодный тренд», будет прав, но выпадет из тренда. Я не пропагандирую в статье, что это _правильный_ путь. Но я пропагандирую, что если вы хотите соответствовать текущим технологическим тенденциям — это надо знать.

                        >K8s это «шедулер» и все, что в нем есть, сделано ради одной задачи — запустить сервис на подходящем свободном сервере.

                        В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?
                          +2

                          Давайте я скажу так, в порядке дружелюбной критики. Статья хорошая и полезная, информация по делу и изложена понятным образом. Я не считаю, что связывать полезность ООП с полезностью
                          k8s это верно, потому что полезность самого ООП это предмет неутихающих дебатов. В частности вот это фактически не верно.


                          Как когда-то ООП появилось для того, чтобы большим командам стало проще писать большой софт;

                          В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?

                          Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.

                            0
                            Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.

                            Или просто будете нанимать тех, кто уже умеет. Вот прямо сейчас в поисках работы сталкиваюсь, что нужны на проекты люди со знанием PHP и AWS и ответ "за неделю-другую, думаю, разберусь с основами, чтоб реализовать основные флоу, которые привык реализовывать на k8s" уже не устраивает.

                              +1
                              >Тяжесть в деньгах работодателя, который будет платить за обучение людей делать то же самое, но по новому.
                              имхо для новой компании эта проблема будет решена
                              я считаю что достаточно скоро написать helm/yaml деплоящий аппу в EKS/GKE будет неким базовым навыком разработчика

                              то есть я совсем не говорю что «технологии изменились, и то, на чем написан софт надо менять», я говорю «технологии изменились и их стоит учить», хотя бы по этим двум не-техническим причинам:

                              1. старым компаниям соврешенно резонно не менять стек, но — см. booking — рано или поздно на этот стэк станет сложно нанимать людей
                              2. рано или поздно людям со старым стэком станет сложно наниматься на новый стэк
                              0
                              В случае если мы запускаем приложения в клауде — в чем «тяжесть» K8S?

                              Вот сейчас залез в репу и вспомнил: минимально запустить сервис из образа — несколько yaml — файлов с манифестами (обычный набор: деплоймент, сервис, ингресс, конфиг, секреты), умножаем на количество окружений (локальное, дев, тест, препрод, прод) или добавляем какой-нибудь Helm, который позволит обойтись меньшим количеством файлов с манифестами, но добавляет файлы со разными значениями для разных окружений.

                            0
                            Гораздо интересней, что придёт на смену докеру/кубенетесу. Автор правильно сказал, что всё убыстряется и становится проще. Тут хорошо подходит, по моему мнению, высказывание из ТРИЗ по поводу эволюции устройств. Конец эволюции это функция без устройства.
                            То есть если переложить на докер/кубернетес, то чётка видна эволюция. В конце всем охота чтобы сервис просто работал.
                            Я думаю уже можно начинать присматриваться к serverless, типа AWS Lambda или GCP Functions, есть также версии для кубернетеса, типа Kubeless, Serverless, итд.
                            Но следуя этой «эволюционной» парадигме, что будет дальше??
                              0
                              тоже смотрю на Serverless
                                0
                                На мой взгляд, один шажок вперёд от Lambda или Functions это Fargate и Cloud Run.
                                Что будет в совсем далёком будущем не совсем понятно, но «зватра» возмжно будут они.
                                А просто Serverless это уже «сегодня».
                                  0
                                  Про CloudRun я не очень знаю, а Fargate, это тот-же кластер и контейнеры, под капотом только может быть не EC2, а VM на Firecracker
                                    0

                                    Всё так.
                                    Fargate использует Firecracker. Так же как и AWS Lambda.
                                    А Cloud Run использует Knative поверх kubernetes.
                                    Только не совсем понятно к чему вы это?
                                    Serverless же тоже под капотом использует кластера из VM, light VM, либо контейнеров.

                                +2
                                Попробую сформулировать, как _я_ оценил Докер для своих личных целей. Думаю, что для Энтерпрайза это еще актуальнее.

                                Я не программист, не сисадмин (в прошлом веке был, но давно уже другими делами занимаюсь). И в качестве хобби и саморазвития иногда поднимаю серверочки.
                                Возьмем, к примеру, ioBroker. Там какой-то Node.Js, с которым я раньше дела не имел. Попробовал на свой Centos установить — он, конечно, встал, не ioBroker не завелся. Нужна более новая версия Node.js, а она ставится уже не просто yum install.
                                Собственно, поскольку я уже давно хотел посмотреть, а что же такое Докер, я и решил это попробовать.
                                Встало мгновенно!
                                Чтобы переехать, к примеру, на Ubuntu, не надо копаться заново. Тот же самый контейнер запускается точно так же.

                                Естественно, хост не только этим занимается. У меня еще mosquitto на нем крутится.
                                Может он и встал бы «как есть», а может потребовал бы каких-то других библиотек. Решать конфликты и зависимости ни разу не интересно.
                                docker run mosquitto… выбрав нужный имидж на dockerhub — все! Пофиг, что он внутри вообще на другом ддистрибутиве собран. Все нужное в нем, за меня люди поработали.

                                Оверхед?
                                image

                                Контейнер отъедает 1.78MB памяти. Может это «из пушки по воробям», но я могу себе это позволить ради собственного удобства.

                                Вышла новая версия софта. Как забэкапить, чтобы обновить? Как откатиться, если что?
                                Раньше у меня такие проблемы были с Wordpress, Drupal… Как там у ioBroker все устроено вообще понятия не имею.
                                На VPS снапшот не снимешь. Надо с каждым приложением индивидуально разбираться. И с кодом, и с данными.
                                С докером я останавливаю контейнер с текущей версией. Копирую директорию с его файлами (ну которая в контейнер подмонтировалась). И запускаю контейнер с новой версией.
                                Если что-то пойдет не так — остановить «новый», вернуть директорию и запустить старый контейнер — плевое дело.

                                А если саму OS обновить? Вот тупо yum/apt update/upgrade дать страшно. Какая-нибудь билиотека поменяется или еще что, и фиг разберешься, что не так.
                                Снапшотов, на помню, у меня на VPS нет.
                                С докером и простым бэкапом папок с данными я в любой момент создаю новый сервер или полностью переустанавливаю ОС (в т.ч. на новую версию вместо того, чтобы кучу апдейтов тащить), запускаю ansible (его я так же оценил — не интересно вручную ставить fail2ban и запрещать логин рутом через ssh), и через несколько минут опять все работает.

                                Есть еще ряд моментов, но эти оказались наиболее значимыми для меня.

                                В энтерпрайзах с хорошими админами вопросы бэкапов и апдейтов, безусловно, решены.
                                Однако же конфликты библиотек от приложений, написанных разными разработчиками, остаются.
                                Ну реально, один писал под Ubuntu, другой под Debian, третий на RedHat.
                                Не факт, что если все трое принесут свои наработки на сервер с CentOS, все заработает само.
                                Какие-нибудь npm будут нужны разных версий, еще что-то…
                                Гораздо проще принести свой контейнер. Он и маленький (не целая виртуальная машина), и содержит все, что нужно, ни с кем не конфликтует…
                                А если приложения макросервисные, так вообще пофиг, какая команда какой микросервис на каком фреймворке пилит. Все будет прекрасно жить и друг другу не мешать.

                                Всякая «побочка» типа A/B тестирования тоже элементарно реализуется. бегут 4 контейнера, запустил пятый с новой версией. 20% пользователй на нее направил, посомтрел, постепенно старые контейнеры остановил, новые запустил…
                                И опять же, все автоматически.

                                Разумеется, любую технологию надо с умом использовать, а не просто потому что модно.
                                Но да, этот тренд с контейнерами возник не искусственно. Он реально много проблем решает.
                                  0
                                  Крутой практический коммент, спасибо!
                                  У меня в голове такая аргументация была, но я не мог ее сформулировать.
                                    0
                                    на самом деле добавил еще один уровень абстракции, которым нужно заниматься. Контейнер — неполноценная ОС, в которую нужно уметь правильно собирать и обслуживать. Никто не даст вам в крупной компании запускать готовые контейнеры с докерхаба, тк там полно дыр и даже закладок. И вам придется обновлять базовый образ для контейнера по требованиям ИБ, даже если само приложение вы не обновляйте.
                                      0

                                      Смотря что понимать под готовыми.
                                      Не у всех Bitnami с выверенными имиджами.
                                      Очень многие берут условный Alpine м докерхаба, и на него уже свое накручивают.


                                      И дальше уже CI/CD со встроенными проверками. И на исходники (вдруг разработчик библиотеку не сам с нуля написал, а с гитхаба уволок). И контейнеров (вдруг в той же Альпине уязвимость, и библиотеки а-ля openssl, дырявые).


                                      Только вот какая разница, взять имидж Альпины или CentOS из репозитория имиджей или как ISO для VM?


                                      И при обнаружении CVE-2019-14697, когда все в продуктиве, проще создать контейнер, основанный на новом образе, чем патчить живую VM.
                                      Не вижу принципиального усложнения.


                                      Вот если бы вы привели пример, что Docker привносит свои дополнительные уязвимости, это было бы бесспорно.

                                        0
                                        проще создать контейнер, основанный на новом образе, чем патчить живую VM.

                                        Если у вас есть возможность создать новый контейнер — значит, и VM вполне допустимо перезагрузить либо пересоздать.

                                          +1

                                          Конечно допустимо. Вопрос в удобстве.


                                          Что обычно делают при обнаружении уязвимости в ОС или библиотеке или ещё чем-то таком, не в самом приложении?


                                          Докер/Кубернетес:
                                          Автоматически собирается новый контейнер, отправляется на тестирование, потом в продакшн.


                                          VM:
                                          Автоматическая установка патчей мне видится намного менее распространенной.

                                          0
                                          Ну докер и кубер и есть софт сам по себе, и у него есть уязвимости. Мне даже вроде ноты от ИБ приходили по этому поводу как то раз.
                                          Но дело не в этом — железный и виртуальных хост по сути это одно и то же с точки зрения процессов эксплуатации, а админов одинаковый набор инструментов.
                                          В случае с кубером и докером процесс другой, инструменты добавились еще или вообще не существуют, нужно самим писать. Архитектурно кубер не эквивалентен ВМ, хотя бы из за особенностей построения сетевой части те для ИБ нужно раскуривать NetworkPolicy и как то вовлекать их в процесс апрува. И еще нужно учитывать что часть компонентов экосистемы откровенно глючит и может вообще полностью менять свою функциональность от версии к версии. :)
                                          Ну и практика показала что далеко не каждый админ сможет до конца разобраться с кубером и докером.
                                          Так что патч менеджмент — это только верхушка айсберга.
                                            0
                                            То, что Докер и Кубер — это «новая вселенная» совершенно согласен.
                                            И не только «уязвимости»
                                            Достаточно на какой-нибудь CIS Benchmark Кубернетеса взглянуть, чтобы оценить, за сколькими настройками следить надо. Даже сетевая безопасность (трафик) не основной момент (хотя тоже новый подход, новые инструменты...)

                                            Но о том, что Докер с Кубером предназначены для облегчения жизни безопасников никто и не говорил :)

                                            Равно как и всяческие облака. Одно неверное движение, и на базе данных появился публичный IP (в отличие от традиционных ЦОД, где админам сложнее так напортачить).
                                              0
                                              Но о том, что Докер с Кубером предназначены для облегчения жизни безопасников никто и не говорил :)

                                              неважно, это все равно ЗО развития инфраструктуры, ты должен придумать решение которое устроит ИБ, аудиторов и остальные контролирующие органы компании.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое