INIT

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

LOCAL

Локальные модели которые могут влезть в 24гб макбука довольно тупенькие.
Но, instruct модели могут легко обогощаться поисковым тулингом. И при правельном промте он будет на каждой итерации дозапрашивать данные из интернете и учитывать их при запросе. В целом это помогает, особенно когда делаешь сложный флоу с частым обращением к модели.
Сейчас просто играюсь с ИБ агентом, который работает на локальной модели и строит план сканирования учитывая инфу из интернета. Ну и итеративно вызвает shell мака для запуска разных команд.

MONO

Монореп с микросервисами это необычное удовольствие.
Обычно принято что один репозиторий это один микросервис, а общие либы выносятся в артифакты и тянутся при билде. Это классика.
Но можно сделать все иначе:
- Одна репа
- Каждая директория в репе это отдельный сервис
- Директории с общими либами которые включаются в билд
- На уровне CI/CD множество джоб для билда конкретного сервиса
Ну и на выбор - деплоить каждый сервис как отдельный чарт, или же делать общий чарт, кому как удобнее.
А зачем так делать? Ну это проще. Все в одном месте и нет необхожимости ходить по десяткам реп и настраивать все отдельно. Для небольших команд идеально.
Из минусов, более увесистый CI/CD и сложнее рулить доступами.

FLOW

За последние годы флоу разработки довольно поменялся.
Раньше было так:
feature branch - develop - test - preprod - master
То есть множество бранчей за каждым из которых закреплен стенд.

Ну и по моему все поняли что это не очень удобно. То что нужны более гибкие стратегии.
Сейчас чаще всего это выглядит так:
- feature branch - отсюда можно в дев
- потом сразу в мастер ветку - оттуда тест и препод
- выставляем тег и катим в прод

Эта стратегия куда проще и гибче, можно быстрее добавлять и убивать разные стенды)

INGRESS

По сути ингрес контролер это обычная прокся. Его задача это просто роутить трафик по сервисам, по доменам и урлам.
Что от него может требоваться?
- Работа с хедерами, например для проксирования только того что реально нужно
- Директивы работы с трафиком, например максимальный размер запроса
- Регексы, для более сложного роутинга
- Интеграция с cert менеджерами
Эти пункты покрывают почти все что нужно от контролера. Сейчас почти все типы контролеров закрывают это)

LB

Лоад балансер в кубе это такой тип сервиса который под капотом имеет node port и делает запрос в провайдера на сетевым балансером.
Nodeport по сути просто начинает биндить порт на нодах, и как раз на него вешается таргер балансера.
Это может быть нужно как раз для ингресов, что бы начать слушать 443 порт и принимать запросы из интернета.

UPTIME

Есть системы где важны каждые миллисекунды аптайма.
Но по факту таких меньшенство. Большому проценту проектов вполне допустимо полежать несколько секунд во время релиза.
Условно мы выкатываем какой то микросервис который обрабатывает запросы из очереди. И если мы погасим его и сразу же поднимем новый то может пройти пару секунд, за которые набежит несколько новых сообщений. Новый поднимется и быстро раскидает это. В большенсве случаев это будет максимально незаметно.

FLOW

Не устаю напоминать - ветка и стенд это не одно и тоже. После мержа в тест ветку мы не обязаны катить ее именно на тест стенд.
Наша главная задача это просто проверить код перед релизом в прод. А уж как мы это будем делать не так важно.
Фичи можно тестить на временных динамических стендах. А после слияния многих фичей в потенциально релизную ветку или тег нужно потестить ее на копии продовой инфры с продовыми данными.
На этом все, все остальные промежуточные стенды делают больше для удобства, и откуда в них деплоить решают сами команды.

PHP

Большая часть интернета написана на php. Но по ощущениям люди который поддерживают эти сайты и пишут новые живут где то в другом мире.
Там до сих пор можно подрубится к серверу по ftp, просто загрузить файлы и перезапустить nginx. Без докера и cicd процессов.
Но тут важно поднимать, большенство этих сайтов максимально простые лендосы и интернет магазины без особой нагрузки. А все эти процессы релизов, кластаризация и отказоустойыивость больше нужна для больших и сложных систем которые и будут писать на php. Отсюда этот разрыв в понимании процессов)

URL

Часто, когда очень много стендов, не удобно вшивать бекенд урл на фронт каждого стенда.
Удобнее сделать относительный путь, по типу:
- фронт на example.com
- бекенд урл указываем /api/
- при обращении на бекенд фронт ображется на свой же домен на урл /api/
- nginx стенда уже сам разруливает куда что отправлять
Это экономит много времени на настройку роутинга запросов)

CONFIG

Столкнулся с интересным кейсом - сеть ресторанов с большим количеством оборудования типа кисков, планшетов и телевизоров. На них стоит софт которые обрашается на сервер.
И вот как обновлять этот софт? Учитывая что ресторан это закрытй контур.
Выбрали pull модель. Есть контролер, это пини пк на каждой точке. Сделали сервис в нашем клауде который хранит актуальные вресии софта. И вот этот контроллер опрашивает этот сервис раз в какое то время и при наличии обновлений сам обновляет все железки.
Это удобная модель обновлений, так как не нужно обращаться на каждую железку, а можно просто опубликовать изменения и все железки сами придут к желаемому состоянию.