Я уже несколько лет познаю облака. Но до сих пор меня не покидает ощущение, что я что-то делаю сильно не так. Я начал со своей инсталляции кубернетеса на виртуалки у хостера. Сейчас переехал на managed кубернетес. Но меня поражает объём работы, который нужно делать для поддержания всей этой инфраструктуры. Это всё такое, как говорится, bare bones. Каждый нюанс нужно настраивать.
Вот приведу только один простой пример — логгирование. Имеется куча сервисов, которые пишут логи в stdout. Эти логи нужно собирать централизованно, класть в каком-то виде в S3 и давать к ним доступ для просмотра. Чтобы это работало, я потратил не один день, разбираясь со стеком loki + promtail + grafana. У меня кучка манифестов для запуска всех этих сервисов в кластере. У меня абсолютно не дефолтный конфиг для loki. promtail я тоже несколько дней настраивал, и там честно говоря ещё настраивать и настраивать. Вывод каждой программы нужно парсить в нужном формате. Настроил для spring boot 2, обновились, оказалось — формат лога поменялся. Настроил для spring boot 3. Сегодня вот запустил один сервис, который льёт логи как не в себя (ну по моим меркам), loki начал валиться с загадочными ошибками, тоже пару часов потратил на исследование и решение проблемы. Причём практически все проблемы приводят либо в исходники, либо в закрытые 3 года назад issues. Или вообще никуда не приводят. Такого, чтобы проблема случилась и ты просто нагуглил решение в документации — фиг вам.
И выше только один пример. Кроме него ещё множество задач, часть которых я вообще не успеваю делать. Мониторинг (его по-моему можно настраивать вечность), скалирование, безопасность, CI/CD пайплайн.
Я в целом уже во всём этом разбираюсь, каждую отдельную задачу решал, если мне надо с чистого листа всё настроить, то за пару месяцев, наверное, настрою, если не выгорю.
Но что меня поражает — это же всё абсолютно типовые задачи. Если мне надо настроить парсинг логов для кейклока, его надо настроить всем остальным. Всем нужен сбор логов, всем нужен сбор метрик, всем нужна сборка образа при пуше и выкладывание этого образа в свой реестр. Всем нужна автоматизация инфраструктуры из гит репозитория. И тд и тп.
Я вполне представляю теоретическое облако, где все эти вопросы решены. Где я вбиваю токен от гитхаба в админку и дальше он все вопросы сам решает. Настраивает CI/CD. Настраивает все нужные скалирования, всякие там ресурсы, cpu, memory. Собирает логи. Имеет готовые настройки для всех сервисов, которые мне могут понадобиться. Но на практике я это облако не вижу.
Если провести аналогию — я ставлю какой-нибудь centos на сервер и имею из коробки настроенный фаервол, а также удобные средства для его кастомизации. Я имею из коробки настроенное логгирование, мне не нужно разбираться с каким-то rsyslog или journald или чего там сейчас используют. У меня из коробки настроен ssh, для всех программ в дистрибутиве настроены профили selinux. То бишь от меня скрыта довольно немаленькая сложность. А то, что я делаю в кубе, мне напоминает компиляцию своего линукса из исходников в сравнение с этим.
Сейчас я пользуюсь облаком от селектела. Я также смотрел в яндекс и немного соприкасался с aws (с ним по-моему разобраться жизни не хватит). В общем я там ничего такого не увидел. Там всё только сложней и неудобней.
Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
Здравствуйте, vsb, Вы писали:
vsb> Но меня поражает объём работы, который нужно делать для поддержания всей этой инфраструктуры. Это всё такое, как говорится, bare bones. Каждый нюанс нужно настраивать.
Это официальная идеология линукс возведенная в религию.
"Здесь ты можешь настроить всё, и тебе, сукин сын, придётся настраивать всё!" (с)
«Смейся в лицо опасности!» Стоп, не так! «Сделай сам!». Вот. " (c) Linus Torvalds
Здравствуйте, vsb, Вы писали:
vsb>Я уже несколько лет познаю облака. Но до сих пор меня не покидает ощущение, что я что-то делаю сильно не так. Я начал со своей инсталляции кубернетеса на виртуалки у хостера. Сейчас переехал на managed кубернетес. Но меня поражает объём работы, который нужно делать для поддержания всей этой инфраструктуры. Это всё такое, как говорится, bare bones. Каждый нюанс нужно настраивать.
vsb>Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
а какие преимущества получаешь взамен? Более легкое масштабирование? Что еще?
Здравствуйте, opfor, Вы писали:
O>а какие преимущества получаешь взамен? Более легкое масштабирование? Что еще?
Ну самое главное это — да, масштабирование. Как масштабирование отдельного сервиса путём запуска его в нескольких копиях, так и масштабирование приложения путём запуска сервисов на нескольких серверах. Это даёт и возможность обрабатывать больше запросов, и возможность работать надёжней (если все сервисы запущены в двух копиях на разных серверах, то проблемы с одним сервером не отражаются на глобальной доступности приложения). Также в теории эластичность может позволять экономить. К примеру у меня сейчас один сервис использует много CPU и масштабируется в зависимости от нагрузки. Днём до 5-8 копий запускается, ночью и в выходные до минимума в 2 копии снижается. Для этого иногда приходится запускать дополнительный сервер, что происходит автоматически. С докером я бы держал его постоянно запущенным.
Кроме этого больше доступных возможностей, описываемых стандартным языком.
В кубере есть пространства имён, позволяющие группировать сервисы. В докере можно запускать множество докер-композов, множество сетей, настраивать между ними связность, но это будет адски сложно и запутанно, в этом никто кроме создателя не разберётся, я знаю, я так делал. В кубере это в сто раз проще, просто кладёшь сервис в неймспейс и стучишься к нему через myapp.mynsname из другого неймспейса.
В кубере есть ингрессы (для роутинга входящих запросов по хостам и путям). В докере для этого нужно будет настраивать что-то вроде нгинкса на хосте или в контейнере. И если в кубере ингрессы это стандартно (то бишь любой другой человек посмотрит и поймёт, если он с этим знаком), то в нгинксе конфиги городят каждый как хочет.
В кубере есть сетевые политики, что-то вроде виртуального фаервола между сервисами. В докере я аналога не знаю, ну разве что по отдельным сетям разводить, но это довольно сложно и не очень гибко.
В кубере есть кронджобы. В докере опять же я прямого аналога не знаю, я делал аналогичный функционал с помощью линуксового крона, но это не прозрачно (в кубере обычно все манифесты лежат в одном месте, а в линуксе конфигурация получается раскиданной по всему серверу).
В кубере есть потрясающая штука, позволяющая деплоить сервисы с нулевым даунтаймом. При обновлении манифеста у деплоймента он сначала запускает новый контейнер, ждёт, пока тот начнёт отвечать на ready checks, после этого перенаправляет трафик на новый контейнер, а старый останавливается. Если в приложении всё сделано правильно (правильные ready checks, правильный shutdown с обработкой оставшихся запросов, это в принципе всё несложно сделать), то такие обновления вполне безопасны и работают даже когда сервис запущен в одном экземпляре. Я это вообще очень ценю, т.к. это позволяет выкатывать большинство обновлений в рабочее время, а вечером отдыхать.
Кроме этого в кубере есть множество штук, нужных именно для работы сервиса, распределённого по нескольким серверам — балансировка нагрузки между сервисами, подключение сетевых томов к контейнерам, у докера прямого аналога этим возможностям нет, хотя про сворм я не в курсе, может там что-то есть.
Кроме этого для кубера есть множество дополнительных сервисов. К примеру cert-manager позволяет интегрироваться с ингресс-контроллером и решать вопрос с HTTPS через letsencrypt. В докере это надо самому настраивать.
Кроме этого для кубера есть набор инструментов для генерации манифестов из шаблонов. Я пользуюсь kustomize, также популярен helm, есть и другие инструменты. Про докер я не слышал. Там максимум гибкости — подставить разные значения env-ов. Это нужно для того, чтобы переиспользовать манифесты. К примеру написать описание сервисов для какой-то базы, и потом применить эти описания для продакшн окружения, стейджинг-окружения, тестового окружения и тд.
Я сходу всё могу не вспомнить, могу лишь сказать, что практически все потребности, которые бывают нужны, в кубере чаще всего в том или ином виде есть. Вот недавно кейклок нужно было запустить в кластере. Для этого ему надо дать DNS-имя, которое будет резолвиться в список IP-адресов, соответствующих контейнерам. В кубере это называется headless сервис и доступно из коробки. В докере я вообще хз, как такое делать.
Единственное, где докер лучше это в возможности собирать контейнеры. В кубере такой возможности нет и настроить это крайне нетривиально. В докере она из коробки есть. Т.е. в тот же docker compose можно положить рядом каталог с приложением, настроить его через директиву build и всё.
Ну и порог входа в докер, конечно, гораздо ниже.
А так я бы кубер и на одном сервере использовал, если не жалко 2-3 гигабайтов оперативной памяти на накладные расходы.
На самом деле сравнение тут не совсем тривиальное, т.к. это довольно разные сущности. Я попытался сравнить их с позиции "пользователя". А так — одно время кубернетес вообще поверх докера работал, т.е. был чем-то вроде надстройки, хотя сейчас уже по-другому сделано.
Здравствуйте, opfor, Вы писали:
vsb>>Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
O>а какие преимущества получаешь взамен? Более легкое масштабирование? Что еще?
Ну это как переход от rent-a-car к car sharing. Выигрываешь на маленьких поездках, поскольку можно аредовать машинку с поминутной оплатой и за парковку не платить, сильно проигрываешь, если машина нужна на долгий срок.
Здравствуйте, vsb, Вы писали:
vsb>Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
И это все намного быстрее, чем настраивать все самому на голом железе. Часть настройки облако берет на себя. При этом оставшаяся настройка все еще предоставляет возможность кастомизации.
Ну и в облаках есть еще более высокоуровневые сервисы. Например, AWS Lambda (Serverless Function) — почти ничего не надо настраивать — написал скрипт, и оно поехало крутиться. Никто не заставляет поднимать свой кубер.
неужели нет аналога aws lambda/google cloud run, которые, на первый взгляд, вообще не надо особо настраивать? все масштабирования, ингрессы, tls, мониторинг, логи и тп там есть автоматом. я потратил ноль времени на настройку, но у меня простой сетап.
Здравствуйте, Константин Л., Вы писали:
КЛ>неужели нет аналога aws lambda/google cloud run, которые, на первый взгляд, вообще не надо особо настраивать? все масштабирования, ингрессы, tls, мониторинг, логи и тп там есть автоматом. я потратил ноль времени на настройку, но у меня простой сетап.
Можешь вкратце описать путь от коммита в гит до сервера? Сначала тестового, потом боевого. Как выглядит автоматизация этого всего без настройки. Я когда с AWS разбирался, для простой виртуалки-билдера несколько дней потратил, разбираясь в их хитросплетениях разрешений, чтобы собирать образы и пушить их в ECS. И я вообще ничего не автоматизировал, тупо руками натыкивал. Через terraform в этом всём разобраться и поднять — наверное неделя понадобится, и это при том, что я его неплохо знаю. И это только пара простейших сервисов.
Вот взять какой-то минимальный джентльменский набор. Интеграция с git-сервером. Билд по коммиту. Пуш образа в свой реестр. Выкатывание образа куда-нибудь там, пусть в лямбду, я с ней не знаком, но там ведь тоже что-то вроде образа должно быть. Соединение всего этого с базой, чтобы там ежедневные бэкапы были. И всё это с каким-то минимальным уровнем безопасности, то бишь хотя бы без незашифрованных паролей в репозитории. Это действительно легко настраивается?
Ещё вопрос — эти aws lambda/google cloud run локально разработчик легко запускает? А то с кубером уже проблемы возникли, разработчики кубер не знают и даже запустить не могут, а поддерживать две конфигурации (одна для кубера, одна для докер композа, запускаемого локально) не очень-то удобно.
Кстати, настроил я это всё так, что этот билдер за пару месяцев выжрал весь бюджет вроде в 5 000 долларов, лол. Какой-то я не такой тип диска выбрал. Так что на этом моё знакомство с AWS закончилось. И это уже, кстати, второй раз, когда авс меня грабит, первый раз на glacier я попался, там тоже за какую-то тривиальную операцию типа скачать 100 ГБ с меня сняли 100 баксов. Такое ощущение, что они специально расставляют такие ловушки в прайсах.
vsb>В кубере есть ингрессы (для роутинга входящих запросов по хостам и путям). В докере для этого нужно будет настраивать что-то вроде нгинкса на хосте или в контейнере. И если в кубере ингрессы это стандартно (то бишь любой другой человек посмотрит и поймёт, если он с этим знаком), то в нгинксе конфиги городят каждый как хочет.
Traefik прикручивается к докер контейнерам очень несложно. Получается тот же ингресс. High Availability, как в Кубере, однако же это не даёт...
vsb>Я сходу всё могу не вспомнить, могу лишь сказать, что практически все потребности, которые бывают нужны, в кубере чаще всего в том или ином виде есть. Вот недавно кейклок нужно было запустить в кластере. Для этого ему надо дать DNS-имя, которое будет резолвиться в список IP-адресов, соответствующих контейнерам. В кубере это называется headless сервис и доступно из коробки. В докере я вообще хз, как такое делать.
Верно, в докере нет смысла запускать кластер. Это другой уровень абстракции.
vsb>А так я бы кубер и на одном сервере использовал, если не жалко 2-3 гигабайтов оперативной памяти на накладные расходы.
И процессор Кубер отжирает тоже...
vsb>Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
Я с кубером тоже начал работать не так давно — около года.
Кубер — довольно сложная система, но как мне кажется, сложность у Кубера — оправданная.
Без Кубера у "компании, которая хочет" или была бы система попроще, без high availability, и с ограниченным scaling,
или пили ли бы и то и другое, но тогда также самое нужно было то самое "человекоместо", потому что это реально непростые вещи.
Я кстати недавно наткнулся на SUSE Harvester. Классная ОС: в ней и baremetal hypervisor и Kubernetes, и через Rancher можно ставить любое количество изолированных Kube clusters (лишь бы ресурсов хватило).
Здравствуйте, vsb, Вы писали:
vsb>Кстати, настроил я это всё так, что этот билдер за пару месяцев выжрал весь бюджет вроде в 5 000 долларов, лол. Какой-то я не такой тип диска выбрал. Так что на этом моё знакомство с AWS закончилось. И это уже, кстати, второй раз, когда авс меня грабит, первый раз на glacier я попался, там тоже за какую-то тривиальную операцию типа скачать 100 ГБ с меня сняли 100 баксов. Такое ощущение, что они специально расставляют такие ловушки в прайсах.
Классика же
Dow Jones неправильно настроил сервер AWS и раскрыл данные 2,4 млн банковских клиентов, в том числе политиков
А с ледником вроде убрали уже эту фигню что если очень быстро скачивать — надо очень много заплатить.
Здравствуйте, sambl74, Вы писали:
S>А с ледником вроде убрали уже эту фигню что если очень быстро скачивать — надо очень много заплатить.
Да, убрали, ну там вообще полный бред был. Я сильно не в претензии, оба раза деньги были не мои, а типа кредиты или как там это называется, в общем авс дал, авс взял, как говорится. Но могли бы быть и мои.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Константин Л., Вы писали:
КЛ>>неужели нет аналога aws lambda/google cloud run, которые, на первый взгляд, вообще не надо особо настраивать? все масштабирования, ингрессы, tls, мониторинг, логи и тп там есть автоматом. я потратил ноль времени на настройку, но у меня простой сетап.
vsb>Можешь вкратце описать путь от коммита в гит до сервера? Сначала тестового, потом боевого. Как выглядит автоматизация этого всего без настройки. Я когда с AWS разбирался, для простой виртуалки-билдера несколько дней потратил, разбираясь в их хитросплетениях разрешений, чтобы собирать образы и пушить их в ECS. И я вообще ничего не автоматизировал, тупо руками натыкивал. Через terraform в этом всём разобраться и поднять — наверное неделя понадобится, и это при том, что я его неплохо знаю. И это только пара простейших сервисов.
1. tag в bitbucket
2. автоматом запускается bb pipeline
2a. в нем билдится docker image как артифакт
2b. docker login в https://gcr.io, docker load, docker push (image google/cloud-sdk:alpine)
2с. deploy тулой gcloud, три строки: gcloud auth activate-service-account -> gcloud config set project -> gcloud run deploy (тот же google/cloud-sdk:alpine)
test/prod лежат в разных проектах GCR, их ключ в env'ах deployment в bb
vsb>Вот взять какой-то минимальный джентльменский набор. Интеграция с git-сервером. Билд по коммиту. Пуш образа в свой реестр. Выкатывание образа куда-нибудь там, пусть в лямбду, я с ней не знаком, но там ведь тоже что-то вроде образа должно быть. Соединение всего этого с базой, чтобы там ежедневные бэкапы были. И всё это с каким-то минимальным уровнем безопасности, то бишь хотя бы без незашифрованных паролей в репозитории. Это действительно легко настраивается?
бекапы без проблем в cloud sql. все security через ключи в env deployment'а bb, поход в базу через Cloud AIM (тут пришлось чуть поресерчить и накатить пару строк sql для маппинга ролей/прав аккаунта postgre) — никаких паролей, все работает через акк под которым ранается сервис.
vsb>Ещё вопрос — эти aws lambda/google cloud run локально разработчик легко запускает? А то с кубером уже проблемы возникли, разработчики кубер не знают и даже запустить не могут, а поддерживать две конфигурации (одна для кубера, одна для докер композа, запускаемого локально) не очень-то удобно.
у меня простой сетап — 3 сервиса и 2 веб аппки. ну локально могу в докере запустить. оркестрации нет. конфиг частично через env variables которые прописываешь в GCR
vsb>Кстати, настроил я это всё так, что этот билдер за пару месяцев выжрал весь бюджет вроде в 5 000 долларов, лол. Какой-то я не такой тип диска выбрал. Так что на этом моё знакомство с AWS закончилось. И это уже, кстати, второй раз, когда авс меня грабит, первый раз на glacier я попался, там тоже за какую-то тривиальную операцию типа скачать 100 ГБ с меня сняли 100 баксов. Такое ощущение, что они специально расставляют такие ловушки в прайсах.
мм, чето невозможно дорого. мы платим меньше 150 за две лямбды и 200 за другой инстанс (24 на 7, монолит плюс 2 веб-аппки), который требует cloud sql.
Здравствуйте, vsb, Вы писали:
vsb>Я уже несколько лет познаю облака. Но до сих пор меня не покидает ощущение, что я что-то делаю сильно не так. Я начал со своей инсталляции кубернетеса на виртуалки у хостера. Сейчас переехал на managed кубернетес. Но меня поражает объё vsb>Вот приведу только один простой пример — логгирование. Имеется куча сервисов, которые пишут логи в stdout. Эти логи нужно собирать централизованно, класть в каком-то виде в S3 и давать к ним доступ для просмотра. Чтобы это работало, я
Для логгирования и APM понядобится один человек, по крайней мере. И еще SRE, плотно работающий с ними. Ибо тема неисчерпаемая и важная
Здравствуйте, vsb, Вы писали:
vsb>Я уже несколько лет познаю облака. Но до сих пор меня не покидает ощущение, что я что-то делаю сильно не так. Я начал со своей инсталляции кубернетеса на виртуалки у хостера. Сейчас переехал на managed кубернетес. Но меня поражает объём работы, который нужно делать для поддержания всей этой инфраструктуры. Это всё такое, как говорится, bare bones. Каждый нюанс нужно настраивать.
Такое надо когда вам действительно нужна масштабируемость, т.е. потоки данных имеют высокую парралелизацию. Условно пишем свой ютуб, нужно уметь ходить в хранилище, авторизовывать и выдавать контент. Точек синхронизации мало. А если взять биллинг или бухгалтерию, где точек синхронихации и атомарности на порядок выше, а реальная потребность в масштабировании на порядок ниже, то cloud-native подход вообще не нужен. Напилили группы сервисов, внутри группы сервисы ходят плюс минус напрямую, для общения извне, есть гейтвейные компоненты, о которых знает внешний мир.
Все такое делается на виртуалках/докерах в полу ручном режиме, без даунтаймов и дешевле.
native-cloud хороший и нужный подход, но надо точно знать, что вам нужна эта масштабируемость. При этом могут еще и наносервисов напилить, так что общее complexity вырастает геометрически.
Здравствуйте, vsb, Вы писали:
vsb>Но меня поражает объём работы, который нужно делать для поддержания всей этой инфраструктуры. Это всё такое, как говорится, bare bones. Каждый нюанс нужно настраивать.
Кубер, конечно, не отличается легким стартом, но, в целом, ничего космического для старта не требует. Тем более что хелмы для популярных сервисов обычно идут в комплекте, а свои хелмы на первых шагах будут совсем простенькие.
Дальше, конечно, метаданные кубера и го темплейтесы дают гремучий результат, но к тому моменту ты обычно уже многое знаешь и понимаешь.
Есть еще альтернативный вариант — CDK, там понятность деплоймента деградирует с ростом сложности не так быстро.
vsb>Вот приведу только один простой пример — логгирование. Имеется куча сервисов, которые пишут логи в stdout. Эти логи нужно собирать централизованно, класть в каком-то виде в S3 и давать к ним доступ для просмотра.
Это какой то совсем непростой пример. Простой это берешь либо уже настроенный образ ELK/EFK c хелмами в том числе и с хранением в S3, либо вообще ELK в виде SaaS и тогда тебя не парит где оно вообще хранит. Для своих сервисов просто подключаешь аппендер для эластика, он везде есть готовый. А для тех кто гадит в консоль сажаешь сайдкаром какой нибудь fluentbit или fluentd.
Причем в SaaS решениях (это далеко не один только ELK, там куча вариантов) у тебя в 99% случаев еще будет пошаговая инструкция как это все настраивать. Просто идешь по ней не включая моск.
vsb>Чтобы это работало, я потратил не один день, разбираясь со стеком loki + promtail + grafana.
Ну ты сам пошел по пути не самого популярного стека, что ж теперь жаловаться. Ну и доки у loki тоже специфические. Когда я последний раз в его сторону смотрел там все явно было заточено на тех кто прям таки вплотную знаком с ELK, но он его по каким то причинам не устраивает.
vsb>Вывод каждой программы нужно парсить в нужном формате.
Да, нужно. Но там же просто регекс. И для основных кейсов его можно нагуглить готовый.
vsb> Настроил для spring boot 2, обновились, оказалось — формат лога поменялся.
Формат лога в консоль задается в настройках логгера примерно везде. А для своих сервисов я вообще не понимаю зачем тебе форматы консольных или файловых логов и их парсинг. В 2024 году из своих сервисов обычно отдельный аппендер выдает логи в JSON. Structured logging, слышал про такое?
vsb>И выше только один пример.
Пример чего? Того что ты выбрал довольно странное решение вместо де-факто стандартного elk/opensearch стека? Ну и кто тебе ЗБ?
vsb>Мониторинг (его по-моему можно настраивать вечность),
Что такое "мониторинг"? Метрики? Ну, там тема сама посебе непростая, неважно в облаках или нет.
vsb> скалирование,
Ты имеешь в виду автоскейлинг? Ну берешь KEDA и вперед. Какого то космоса там вроде нет, все довольно просто. Сложности там с получением правильных метрик, но это, опять же, сама по себе задачка непростая, в предметной области непростая, а не в реализации.
vsb> безопасность,
Что с ней?
vsb> CI/CD пайплайн.
О да, вот тут, конечно, все непросто. Но, опять же, есть решения типа ArgoCD, сильно все упрощают.
vsb>Но что меня поражает — это же всё абсолютно типовые задачи. Если мне надо настроить парсинг логов для кейклока, его надо настроить всем остальным.
Ну да. Поэтому есть дока. Ах да, мы ж зачем то решили пойти путем loki.
vsb>Я вполне представляю теоретическое облако, где все эти вопросы решены. Где я вбиваю токен от гитхаба в админку и дальше он все вопросы сам решает. Настраивает CI/CD. Настраивает все нужные скалирования, всякие там ресурсы, cpu, memory. Собирает логи. Имеет готовые настройки для всех сервисов, которые мне могут понадобиться. Но на практике я это облако не вижу.
Это не теоретическое, это вполне доступно на практике. Смотри в сторону SaaS/PaaS решений. Как апофеоз их — что то типа Amazon Lambda. А уж если ты решил сам свой инстанс киклоака поднимать, т.е. даже SaaS IdP тебе не подходит, то странно удивляться что тебе приходится делать кучу низкоуровневой работы. Тут уж назвался груздем — полезай в кузов, и изображай из себя мегауниверсального спеца, решая в том числе и те задачи, что должна решать целая команда девопсов.
Тут надо понимать простую вещь. Кубер это микросервисы. А микросервисы это куча команд с узкой специализацией. А микросервисы, которые пишет, деплоит и обкладывает инфрой один человек это карго культ и ничего больше.
vsb>Правильно ли я понимаю, что на текущем этапе развития любая компания, которая хочет хоститься в облаке со сложностью большей, чем один докер-композ, обречена на трату практически одного человекоместа только на то, чтобы совладать со всем этим? Причём все компании делают примерно одно и то же.
Ответь мне на простой вопрос — зачем тебе кубер? Арендуй себе одиночную ВМку или AWS Auto Scaling и вперед, ставь свой CentOS туда с фаерволом. Если функционала хватит — кубер тебе и не нужен. А вот если не хватит и ты начнешь его руками докручивать, то результат, в лучшем случае, будет примерно аналогичен тому что мы имеем готовое. А в более вероятном худшем будет сложнее и хуже.
Здравствуйте, Константин Л., Вы писали:
КЛ>неужели нет аналога aws lambda/google cloud run, которые, на первый взгляд, вообще не надо особо настраивать?
Смеешься? Он там свой собственный idp поднять хочет, а ты ему лямбду советуешь.
Здравствуйте, vsb, Вы писали:
O>>а какие преимущества получаешь взамен? Более легкое масштабирование? Что еще? vsb>Ну самое главное это — да, масштабирование. Как масштабирование отдельного сервиса путём запуска его в нескольких копиях, так и масштабирование приложения путём запуска сервисов на нескольких серверах.
Для этого кубер необязателен. Решения типа Azure VMSS или AWS Auto Scaling все это умеют на существенно более низком и простом уровне.
vsb>Кроме этого больше доступных возможностей, описываемых стандартным языком.
Что за возможности такие?
vsb>В кубере есть пространства имён, позволяющие группировать сервисы.
неймспейсы не для группировки сервисов, а для того чтобы на каждый вариант не поднимать отдельный кластер, бо долго и дорого. Есть у теюя, к примеру, текущий мастер, текущая бета и текущий релиз. Можно три кластера поднять, а можно один и раскидать версии по неймспейсам, вынеся заодно инфру за скобки, чтобы не дублировать.
А на проде, как правило, неймспейс один.
vsb>В кубере есть ингрессы (для роутинга входящих запросов по хостам и путям). В докере для этого нужно будет настраивать что-то вроде нгинкса на хосте или в контейнере.
В кубере ингресс тоже надо настраивать.
vsb>то в нгинксе конфиги городят каждый как хочет.
Конфиги ингресса в кубере практически идентичны конфигам nginx, только с оберткой в виде куберовского ямла.
vsb> При обновлении манифеста у деплоймента он сначала запускает новый контейнер, ждёт, пока тот начнёт отвечать на ready checks, после этого перенаправляет трафик на новый контейнер, а старый останавливается.
Этой суперштуке в два раза больше лет, чем куберу.
vsb>Кроме этого в кубере есть множество штук, нужных именно для работы сервиса, распределённого по нескольким серверам — балансировка нагрузки между сервисами,
Load balancers тоже.
vsb>Кроме этого для кубера есть множество дополнительных сервисов. К примеру cert-manager позволяет интегрироваться с ингресс-контроллером и решать вопрос с HTTPS через letsencrypt. В докере это надо самому настраивать.
Да при чем тут вообще докер? Докер само по себе это вообще не аналог кубера. Если ты пишешь про compose, то это вообще не production решение.
vsb>Единственное, где докер лучше это в возможности собирать контейнеры. В кубере такой возможности нет и настроить это крайне нетривиально.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>Чтобы это работало, я потратил не один день, разбираясь со стеком loki + promtail + grafana.
НС>Ну ты сам пошел по пути не самого популярного стека, что ж теперь жаловаться. Ну и доки у loki тоже специфические. Когда я последний раз в его сторону смотрел там все явно было заточено на тех кто прям таки вплотную знаком с ELK, но он его по каким то причинам не устраивает.
ELK меня не устроил тем, что он громоздкий. У меня было ощущение, что этот ELK будет ресурсов жрать больше, чем все остальные приложения вместе взятые. Loki сейчас жрёт копейки. Поэтому в целом результатом я доволен.
vsb>> Настроил для spring boot 2, обновились, оказалось — формат лога поменялся.
НС>Формат лога в консоль задается в настройках логгера примерно везде. А для своих сервисов я вообще не понимаю зачем тебе форматы консольных или файловых логов и их парсинг. В 2024 году из своих сервисов обычно отдельный аппендер выдает логи в JSON. Structured logging, слышал про такое?
Не увидел в этом смысла. Мне проще настроить формат лога в одном месте (конфиг promtail) чем по каждому приложению ползать и искать как там его настроить.
vsb>>Мониторинг (его по-моему можно настраивать вечность),
НС>Что такое "мониторинг"? Метрики? Ну, там тема сама посебе непростая, неважно в облаках или нет.
Prometheus, кучка экспортеров к нему вроде node-exporter, kube-state-metrics, метрики с ингресс-контроллера и тп. Ну и по каждому сервису в общем случае свои метрики могут быть нужны.
Alertmanager, к нему alert rules в прометее по интересующим ситуациям. Ну и настройка уведомлений, куда слать, когда всё плохо.
Ещё по хорошему Grafana с нужными визуализациями, но у меня с ней как-то не срастается, пару дашбордов сделал и на этом пока закончил. Главная ценность метрик для меня в алертах.
vsb>> безопасность,
НС>Что с ней?
Настройка сетевых политик. Настройка доступа к кластеру.
vsb>>Но что меня поражает — это же всё абсолютно типовые задачи. Если мне надо настроить парсинг логов для кейклока, его надо настроить всем остальным.
НС>Ну да. Поэтому есть дока. Ах да, мы ж зачем то решили пойти путем loki.
Прямо по ссылке: "The support for GELF log handler is deprecated and will be removed in a future Keycloak release". Хороший пример.
Ну и отсылка логов из приложения это странно для меня звучит. А если логгирующий сервис упал, логи теряем? А если само приложение по OOM упало, последние логи (в которых самое интересное) останутся в каком-то буфере? Там же по-любому будет буфер, чтобы логгирующий код не тормозил.
Сейчас у меня логи пишутся в файлы (стандартными средствами kubernetes), promtail эти логи читает и пушит в loki. Любой компонент может лежать достаточно долго и ничего не потеряется, как встанет, так допушат. Только если прям совсем долго всё будет лежать и куб файлы отротирует.
НС>Ответь мне на простой вопрос — зачем тебе кубер? Арендуй себе одиночную ВМку или AWS Auto Scaling и вперед, ставь свой CentOS туда с фаерволом. Если функционала хватит — кубер тебе и не нужен. А вот если не хватит и ты начнешь его руками докручивать, то результат, в лучшем случае, будет примерно аналогичен тому что мы имеем готовое. А в более вероятном худшем будет сложнее и хуже.
На кубер я переезжаю с примерно десятка машин, физических и виртуальных, в которых крутится несколько десятков сервисов и баз разного размера. Руководство очень плодотворно генерирует идеи для самых разных проектов, поэтому сервисов получается много, даже без упарывания в микросервисы. Одиночной ВМки мне не хватит, даже большой. Если вопрос конкретно мне — у меня есть конкретное требование хранения и обработки данных в Казахстане, поэтому почти все известные мировые сервисы для меня недоступны, вот буквально в конце прошлого года появился относительно адекватный managed kubernetes от прослойки селектела, на который я и переехал со своего самодельного. Ну и компания у нас продуктовая, халявных бюджетных денег нет, а это выливается в то, что деньги пытаются экономить на всём, что тоже сказывается немного на выборе решений.
Но в целом меня интересует, как это работает и в других сервисах, так что в любом случае спасибо за ответ.
Здравствуйте, Ночной Смотрящий, Вы писали:
O>>>а какие преимущества получаешь взамен? Более легкое масштабирование? Что еще? vsb>>Ну самое главное это — да, масштабирование. Как масштабирование отдельного сервиса путём запуска его в нескольких копиях, так и масштабирование приложения путём запуска сервисов на нескольких серверах.
НС>Для этого кубер необязателен. Решения типа Azure VMSS или AWS Auto Scaling все это умеют на существенно более низком и простом уровне.
Я отвечал и сравнивал конкретно два решения — использование docker compose и использование kubernetes.
Причём именно из опыта того, как это было изначально сделано — куча docker compose-ов, раскиданных по разным серверам, написанных разными людьми, которые я постепенно перенёс в кластер, и была возможность сравнить "до" и "после".
vsb>>Кроме этого больше доступных возможностей, описываемых стандартным языком.
НС>Что за возможности такие?
Я ниже описал всё это, постаравшись выделить ключевое. Если вкратце — namespace, ingress, network policy, cronjob, deployment и аддоны вроде cert-manager. Также инструментарий вроде kustomize.
Тут суть именно в том, что это всё стандартное и однотипное. Опять же в моём опыте каждый настраивал роутинг между сервисами как бог на душу положит. Кто-то в отдельном caddy. Кто-то в отдельном nginx (как туда cerbot прикручен был, это отдельная история). Кто-то в коде приложения прямо реверс-проксирование делал. Кронджобы тоже делают по-разному. Где-то через линуксовый крон. Где-то отдельным приложением со своими таймерами.
В кубере это всё есть, и делать тот же роутинг не ингрессами — ну затея максимально странная, вряд ли кто-то это будет делать без серьёзной нужды. Хотя технически, конечно, можно.
vsb>> При обновлении манифеста у деплоймента он сначала запускает новый контейнер, ждёт, пока тот начнёт отвечать на ready checks, после этого перенаправляет трафик на новый контейнер, а старый останавливается.
НС>Этой суперштуке в два раза больше лет, чем куберу.
Не думаю, что это легко можно сделать в докере.
S через letsencrypt. В докере это надо самому настраивать.
НС>Да при чем тут вообще докер? Докер само по себе это вообще не аналог кубера.
В плане применения — вполне себе аналог.
НС>Если ты пишешь про compose, то это вообще не production решение.
И что в нём не продуктового? Я его встречал достаточно часто. Вполне себе удобный способ управления докер контейнерами на одном сервере.
Здравствуйте, vsb, Вы писали:
НС>>Для этого кубер необязателен. Решения типа Azure VMSS или AWS Auto Scaling все это умеют на существенно более низком и простом уровне. vsb>Я отвечал и сравнивал конкретно два решения — использование docker compose и использование kubernetes.
Композ это вообще не решение для прода.
vsb>Не думаю, что это легко можно сделать в докере.
Забудь уже про композ (и не называй его докером). Альтернатива куберу в облаках — ручные ВМки. И написать скрипт (или взять готовый), который перещелкнет тебе балансер с публичным IP на другой инстанс совсем нетрудно. Для ажура мне попадались даже варианты с полноценным rollout апдейтом, когда апдейт последовательно на вмки накатывается с переключением и визуализацией процесса.
Да, сейчас есть kubectl rollout, но только ради одной этой фичи тащить кубер не обязательно.
НС>>Да при чем тут вообще докер? Докер само по себе это вообще не аналог кубера. vsb>В плане применения — вполне себе аналог.
Нет.
НС>>Если ты пишешь про compose, то это вообще не production решение. vsb>И что в нём не продуктового?
Да практически все. Композ это просто способ попроще поднимать несколько контейнеров, более дешевая замена виртуалкам. Это не оркестратор. Использовать его на проде, конечно, можно, но ты все будешь делать руками. В композе даже совсем базовые вещи типа поднятия упавших контейнеров настолько убоги, что пользоваться ими можно только на локальной машине.
Оркестратор от авторов докера называется Swarm и он не взлетел.
