GITLAB

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

А было бы удобно, в группе было бы несколько переменок типа:

K8S_URL **** env dev
K8S_URL **** env preprod
K8S_URL **** env prof

И в пайпланах указывать просто env.

TAG

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

VIBE

Сегодня в полу ручном режиме сканил проекты в sonarqube.
Локально поднял его, через docker-compose и навайбкодил скрипт который проходит по всем локальным проектам и сканируют их.
Хороший вариант для быстрого анализа инструмента. Контейниризация и вайбкод хорошо подходят для "приключения на 15 минут", где нужно просто собрать прототип системы и получить быстрые результаты.
Из минусов - нет полного погружения и раскрытия всех возможностей инструмента. Но как способ "быстро понять" идеально)

DAST

В контексте динамического анализа безопасности тоже есть черный, серый и белый ящик.
Черный ящик - просто даем адрес системы для атаки.
Серый ящик - даем, например, просто пользака.
Белый ящик - даем максимального пользака и схему апи.

Все эти варианты важны и покрывают разные сценарии.
Черный ящик - как мы защищены от сторонних злоумышленников.
Серый ящик - может ли обычный пользователь системы что то сделать.
Белый ящик - что может администратор системы.

Поэтому важно покрывать все сценарии)

SWAGGER

Сейчас прогоняю на одном проекте DAST. И как же больно что для каждого микросервиса свой отдельный сваггер.
То есть есть гетвей через который мы можем обращаться на микрач, и что бы найти его апи схему нужно открывать его свагер и выкачивать схему.
Понятно почему это сделано - разработчики конкретного микрача актуализирует свою схему и раскатывают сервис, и не нужно делать обновлений на гейте. Но иногда это очень не удобно.
Есть подходы когда гейт сам похватывает изменения схемы на микрачах и добавляет их в свой свагер. Это позволяет просмотреть все нужные эндпоинты из одного места.
Ну и автогенерацию схему никто не отменял)

TBD

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

VIBE

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

ROLLING

В контексте линукса есть такая схема обновлений rolling release.
Это когда нет обновления между версиями, только постоянные апдейты. Например это fedora.
Да, там могут быть версии, но по сути это просто фиксация текущего состояния. Нет такого как например в убунте - обновления в рамках одной версии, и обновление до новой как отдельная сущность.
В федоре мы просто постоянно ставим обычные апдейты и таким образом получаем самую новую версию системы.
Чаще это куда удобнее, особенно на серверах. Ведь в классическом случае для обновления до новой версии часто нужен даунтайм сервера, и не выйдет сделать это без простоя.

SHIFT LEFT

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

TBD

Как внедрить appsec подходы в транк как можно левее?
Обычно там все начинается с коммита в фича ветку, начинаем тут. Прогоняем все статические проверки кода. Можно инкрементальные, для скорости.
Так же, очень часто, фича ветки в транке катятся на динамические стенды. Тут можно и динамический анализ погонять.
Дальше создается МР в мастер, и тут уже можно блокировать их если не прошли проверки. Тут в идеале делать не инкремент а полную проверку и статически и динамически на отдельном стенде.
Ну и перед релизом в прод проверять всю мастер ветку, так как туда может быть смержено много разных фича веток.

WAIT

Есть синхронные и асинхронные задачи.
Например когда мы в пайплане хотим запустить полное сканирование проекта, которое может занимать хоть пол часа. И если для релизной ветки важно дождаться отчета и стопнуть релиз в случае чего, то для фича ветки не нужно заставлять ждать.
Часто можно запустить инструмент с флагом —no-wait. И тогда джоба за секунды просто запустит проект и пойдет дальше. А если разработчик спустя время не проверит есть ли криты, то ему просто не даст смержить. Либо же просто на этапе тестовой ветки стопнет раскатку и ему все равно придется чинить)

ARM

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

SCALE

На одном из проектов продолжаю эксперементировать с скейлом нод кластера.
Пока что лучший подход который для себя выделил - автоскел.
Когда мы катим приложения в выставляем необходимые ему ресурсы. Например 0,5 cpu и 512 ram на одну реплику. И куб в современных клаудах уже давно умеет "заказать" новые ноды если пейлоуду не хватает ресурсов.
Главное тут - высатвлять минимальное количество ресурсов. Которое будет необходимо под среднюю нагрузку. Иначе куб может сильно сократить количество нод и при приходе трафика не успеть отскейлить.
Из важных плюсов такого подхода - платим только за то что используем. Куб не будет выделять лишних ресурсов при правильной конфигурации шаблонных нод. И соотвественно платим только за тот пейлоад который есть.

CLOUD

Сейчас появляется разделение облаков на гиперскейлеры и неоклауды.
Пока это не четкие термины, больше наминальное разделение.
Как я это понимаю.
Гиперскейлеры - огромные облака с десятками датацентров. В них огромное количество сервисов, от барметала и виртаулизации, до менедж куба и лямбда вычислений. Например AWS и GCP.
Неоклауды - несколько датацентров и фокус на определенные сервисы. Тот же самый nebius, которые делает клауд для AI вычислений и делает это очень хорошо.

Понятно, гиперскейлеры могут делать сервисы для AI а неоклауды кучу сервисов. Но тут вопрос качества и фокуса)

LAMBDA

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

GHZ

Про частоты процессора.
Если мы проектируем кластер то что делать с частотами процессора. Больше частоты и меньше ядер? Или же больше ядер и меньше частоты?
Допустим у нас есть два процесса которым для расчета нужно по 250 миллионов операций. Где одна операция это один такт процессора.
И допустим у нас есть два варианта:
1. Одно ядро на 3 Ггц
2. Два ядра по 2 Ггц

Тут 1ггц это миллиард операций в секунду.
По итогу - нам надо выполнить на обоих вариантах 500 операций для двух равных процессов.
В первом случае мы займем 1/6 времени процессора.
Во втором разделим два процесса по ядрам и выполним за 1/8 времени процессора.

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

SYNC

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

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

MEM

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

DIST

Радует тенденция. Вендоры софта который ставится на сервер все чаще предоставляют его в виде докер образов и композа.
Выдает креды до своего регистри и манифест разворачивания, плюс лиценцию.
Очень удобно, можно развернуть весь софт буквально за 5 минут и сразу начать пользоваться)

Рад что мы уходим от нативных пакетов линукса, деб и рпм. Это было всегда очень больно в контекст установки и обновления.

TBD

Транк может потребовать больше вычеслительных ресурсов для разработки.
Если мы посмотрим на классический гитфлоу то там чаще есть 3 стенда которыы проходит код до прода: дев - тест - препрод.
В транке нет классических дев стендов, чаще есть динамические стенды под фича ветки. И при большой команде их может быть очень много, в моменте видел десятки фича стендов.
Ну и после этого фича проходит через тест и препрод.
Поэтому транк может потребовать длинный кластер под разработку, иногда даже больше чем прод. Особенно по памяти.

Пару лет назад уже кидал сюда, но снова залип на концерты в Берлинской филармонии)

https://www.youtube.com/watch?v=GnyAgOWhMnk