'Hello World' вам в облако

Хм, готовая бизнес модель: клепаем статьи про то как делать по хайпу, направляем таких клиентов к вам, деньги пополам!
Шутка, конечно же)
Пусть каждый сам для себя решает, как делать и не делать.

'Hello World' вам в облако

Да, утрирую, прошу прощения.
Но аналогия она примерно такая, да.
Мне k8s даёт удобный тул деплоя и скейлинга сервисов (а кубик работает с докером), и я его использую, и показал в статье как это можно делать в условиях работы с продуктом.
Делать так же в своём продукте вАм или не делать — дело исключительно ваше

'Hello World' вам в облако

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

Та не вопрос, только, как я выше написал, тулы меняются, эволюционируют и за эволюцией надо успевать. Если ты продолжишь писать на Коболе и доставлять софт на прод дискетами, то найти к себе в команду людей будет сложновато. Это не значит, что надо всё контейнеризовать и обязательно крутить ими в клауде.

Вы еще вот совсем оставляет в стороне контроль целостности. В случае с монолитом у вас есть РСУБД. В случае с микросервисами контроль целостности вы будете выполнять руками, а это крайне нетривиальная задача. Где окажется «скорость доставки», когда у вас, например, сервис оплат станет неконсистентным с сервисом заказов?

Да, это острый вопрос, и про него я написал в TODO'шечках, и в комментах чуть-чуть уже обсудили, и оставлять в стороне я его не собираюсь и не хочу :)

Есть методика написания кода таким образом, чтобы миграция логики сервиса делалась в несколько шагов, когда разные версии разных сервисов становятся совместимыми (пару if'ов в коде).
В любом случае, задача комплексная и решать её надо с умом.

'Hello World' вам в облако

Прекрасная показательная история о том, как не надо слепо надеяться на технологии :)
"Ребята, тут новый API подвезли — заживём!" Нет, не заживём, а потестим, возьмём то, что реально ускоряет процесс, и ещё раз потестим, а потом может быть в прод.

А ещё я троллю любителей u-сервисов тем, что в них прокси типа nginx едет через прокси. Ну, смотрите сами. WAF, LB, балансировщик кубера, потом Ingress, потом ещё мы захотим service mesh, потом мы ещё запихнем контейнер с nginx+php-fpm в кластер. И путь запроса станет весьма долгим. Да, это более масштабируемая история. Но не всем это надо

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

'Hello World' вам в облако

Скорость доставки — это про то, насколько быстро изменения в проде появятся или насколько быстро решатся проблемы юзеров без изменения в коде (поскейлим всё в x100).

У кого-то это хук в гите, у кото-то watcher на изменения в файловой системе разработчика или директории, куда релизные версии выкладываются и ftp'шкой сразу в прод.

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

'Hello World' вам в облако

Логика есть, если поправить и доставить изменение в прод занимает N секунд вместо N минут (а за оставшееся время попробуем проанализировать тупняк и понять, с фига ли мы так тормозим, может чего-нибудь пооптимизируем?).

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

Да, тормозящий сервис скорее всего тормозит по причине кривых рук разработчиков или админов, но сокорость доставки кусков логики для меня, например, решает много (kubectl apply -f… — ВСЁ)

'Hello World' вам в облако

Всё верно, размикросервились тут!

Но для меня микросервисность и клаудность продукта даёт ещё один плюс — удобство и скорость доставки в прод. Да, это даёт накладные расходы тоже и не малые (в том числе на дизайн и продумывание API), но конечный лояльный клиент для бизнеса, думаю, важнее. О чём это я?

А, вот пример:

1. Есть условный Василий, владелец крутого сетевого магазина спортивной экипировки. И у Васи есть интернет магазин монолит.
2. Есть условный Пётр, владелец крупного интернет-магазина, продающего ВСЁ, спортивную экипировку в том числе. И у него огромная инфраструктура, клауд, k8s и все все все.
3. Мне нравится магазин Васи, ибо там всегда есть то, что мне нужно и иногда по очень выгодным ценам. НО интернет-магазин Васи откликается на мои действия по 10-15 секунд!!! и местами очень не устраивает UI (конкретно в мобильной версии сайта)
4. У Пети я могу очень комфортно сёрфить по магазину и выбирать себе спорт-товары, даже те, что есть у Васи и иногда по ценам ниже, чем у Васи (Петя много не потеряет, если продаст последнюю пару лыж чуть дешевле, но клиент останется доволен)
5. Мы уже дошли до 5-го пункта, и где тут про удобство клауда и про скорость доставки?? Да нету здесь ничего про это. НО когда я пишу Пете, что у него воооот этот вот участок сайта некрасивый для юзера и он чуть тупит, то Петя идёт и решает эту проблему за условных N минут (похачив пару строк во фронтовом компоненте и одной командой задеплоив новую версию микросервиса, отвечающего за этот кусок UI и за этот кусок бизнес логики) — PROFIT. Но когда я Васю прошу о том же, то это может затянуться на несколько дней, недель, месяцев, — монолит не так просто обновлять на боевых серверах.

Вывод: клауд — недешёвое удовольствие как с точки зрения дизайна API, так и с точки зрения содержания инфраструтуры, НО это огромный плюс в пользу скорости решения пользовательских проблем (много пользователей утром пожаловались на медленную корзину в магазине, во время ланча они уже получили скоростное оформление заказов и маленький аддон в виде красивого виджета в корзине, а команде разработчиков это почти ничего не стоило) и доставки апдейтов в прод

'Hello World' вам в облако

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

'Hello World' вам в облако

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

Ну и не забываем про все практики хорошего тона и кода — кодстайл, чекстайл, код ревью и все прочие пляски с бубном, перед тем как код попадёт в прод, никто не отменяет (это к слову про быдлокодинг)

'Hello World' вам в облако

Принято. Но всё равно полезно было узнать.

'Hello World' вам в облако

Я тоже смеялся, чесслово) Но ещё раз скажу про пойнт данной статьи: она не про то как в реальности Привет Мир затолкать в облако (и не надо этого делать), а о том как можно построить процесс разработки и доставки любого вашего продукта до пользователя (а показано на примере Hello World)

'Hello World' вам в облако

Примерные цифры такие (очень примерные):

• CI: диск 200Gb, RAM 8-10Gb (по сути там три сервиса в докер-контейнерах: CI worker node, CI UI node, postgresql, — для более или менее серьёзных намерений надо ноды разносить на разные виртуалки)
• k8s master node: диск 100Gb, RAM 8Gb
• k8s worker node: диск 300Gb, RAM 12Gb
• nexus: диск 1Tb, память 8Gb

Объём файлов отдельно не считал.

'Hello World' вам в облако

Вы, видимо, хотели сказать «с хостером доменов»? В функции регистраторов не входит создание/удаление записей внутри зоны.

Да, именно это я имел ввиду :)

Насчёт интеграции godaddy и кубика — вооон там чуть выше gecube расписал совет, как сделать. А подключаемые библиотеки для certbot — не, не слышал) но тема интересная, надо попробовать. Спасибо!

'Hello World' вам в облако

Спасибо за советы и ссылочки)

'Hello World' вам в облако

Высоконагруженный? А фиг знает, сколько это, ибо нагрузки у всех разные и все считают своё высоконагруженным (так или иначе).
Статьёй я не хотел побуждать всех перезжать в облака и поднимать свой k8s-кластер, а всего лишь хотел показать, как это можно сделать и как построить примерный процесс доставки продукта в клауд.

Делать это или нет — вопрос вышего выбора :)
Про микросервисы:

За свою карьеру много всякого разного монолита видел и микросервисов тоже (не так много и не такого разного как монолита, но видел), и для меня иногда очень остро стоял вопрос скэйлинга того или иного участка бизнес-логики, но я не мог этого сделать легко, если имел дело с монолитом, отжирающим кучу памяти, диска и процессорного времени, а с микросервисом, который делает ровно одну задачу и делает её хорошо, я могу это сделать легко и быстро, условно указав большее количество реплик в деплойменте кубика

'Hello World' вам в облако

Еще идиотский вопрос — какие выгоды от запуска интеграционных тестов в Concourse-CI в dind? Почему их сразу в кубернетес не гонять на отдельном неймспейсе?

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

Когда я столкнулся с проблемой запуска контейнеров в контейнере, то в голову сразу пришла идея — а нет ли готовой реализации в tescontainers, которая бы позволяла тестовые контейнеры запускать сразу в кубике? Ответ: готовой реализации нет, но работы, похоже, ведутся

Еще не понял пляску с LE — не проще было кластерный cert-manager сразу настроить?

Кластерный cert-manager работает, если ты имеешь дело с регистратором доменов, реализация для работы с которым есть в кубике (проблема не в LE, а в том месте, где ты домен держишь)
Речь сейчас именно про LE-сертификат, чтобы дёшево можно было сделать сертификат на любой домент.
Мой домен (bihero.io) хостится в GoDaddy и k8s не смог мне автоматом создавать сертификаты для моих поддоменов. Я пробовал, честное слово, но кубик не смог из коробки это сделать, пришлось ручками ходить (там в DNS записи надо добавлять текст руками, который просит LE).

Чуть не забыл: проблема не возможности кубика автоматически создавать и рулить сертификатами была выявлена при работе с wildcard сертификатами LE

Ну, он просто по инструкции как в статье — можно подкинуть ЛЮБОЙ серт, хоть купленный у DigiCert/thawte/GoDaddy etc.

Да, подкинуть можно любой сертификат

'Hello World' вам в облако

Спасибо за замечания!

Например, squash не нужен. Во-первых, есть опция в последнем докере --squash

Про --squash в последнем докере почитаю.

не понял — зачем так. Если можно ENTRYPOINT переопределить

Почему CMD["./run.sh"]? Это скорее "исторически сложилось": сдедали сервис, запаковали так в докер, работает — не трогай :) будем рассматривать и другие true way способы.

Разумно. А еще круче — добавить в кластер https://github.com/fluxcd/flux-get-started

Относительно деплоя в куб была ещё идея в оператор это всё завернуть, но то уже тема отдельной статьи. А за ссылку спасибо!

очевидное решение — сделать «интеграционное» репо, которое будет знать о всех микросервисах и содержать информацию об их взаимосвязах и версиях. И деплоить именно из него. Через механизмы типа гит хука можно в это репо кидать информацию о новых версиях деплойментов из репозиториев каждого из «микросервисов». Еще на самом деле нет проблемы, если у вас в экосистеме будут деплойменты с версией API v1 и версией API v2. Здесь больше вопрос декомпозиции — готовы ли вы сказать, что API v2 — это не следующая версия приложения, а НОВОЕ приложение. Тогда как бы проблема рассасывается сама собой. Либо тащить в какой-то момент времени ОБЕ версии апи и каким-то внешним способом контролировать, что как только потребители v1 исчезли, то можно его выпилить из кодовой базы и деплоить новую версию только с v2, но это тогда не ТЕХНИЧЕСКАЯ, а ОРГАНИЗАЦИОННАЯ проблема

Согласен про "организационность" и "не техничность" проблемы рассинхронизации API. Тоже думал про отдельный репозиторий со всеми связями между сервисами и версиями API, но пока не начинаешь это делать, то всё кажется овер сложным и не решаемым. Главное начать. Про версии деплойментов — отлично подмечено, надо попробовать :)

'Hello World' вам в облако

Пример:
Высоконагруженный интернет-магазин
Грубый (очень примерный) список сервисов:

• сервис по работе с товарами: описания товаров, вендоров
• сервис по работе с ценами: несколько ценовых колонок для разных категорий покупателей и т.д. и т.п.
• корзина
• заказы
• статика: тонны картинок товаров в разных размерах — всё это надо хранить и отдавать
• склад: наличие, расписание поставок от вендоров и поставщиков, логистика в пределах складов и даже шкафов внутри одного склада

И все сервисы надо скэйлить и обеспечивать high availability (много сервисов в нескольких экземплярах за балансерами и в нескольких дата-центрах). А ещё надо конкуренцию держать и поставлять всё новое и новое на сервера как можно быстрее (десятки, сотни деплоев в день). По мне так для этого облака и придумывались, нет разве?

'Hello World' вам в облако

Именно с такой целью и писал, чтобы под рукой был шаблон. Рад, что понравилось :)

'Hello World' вам в облако

На Go к сожалению (или к счастью :) ) не пишу, но вот про фронт да — забыл добавить описание. Будет время — запилю статью подобную про фронт на React'е и мобилку на Kotlin'е.