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

Ну и как уж не закончить вечер на shortparis)
https://www.youtube.com/watch?v=IMRxAi8_xx0

DOCKER

Контейнеризацию можно воспринимать как ООП.
Где образ это класс, по сути набор методов которые можно исполнять, слепок.
А контейнер это объект класса, отдельная сущность на основе обьекта, с своими параметрами. Мы можем плодить множество объектов одного класса которые со старта будут отличатся аргументами.
Например - образ с постгресом, на его основе мы можем запустить множество контейнерв с разными настройками авторизации. Это будет множество разных объектов одного класса постгрес)

Погнали)

FEDORA

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

DOCKER

В контексте контейниризации нам больше важно ядро а не сам дистрибутив.
Ведь она использует миханимы ядра, cgroups и неймспейсы. Тут весь остальной дистрибутив играет роль, но больше в контексте стабильности, что бы система просто не падала.
Поэтому мы можем быстро мигрировать контейнеры между дистрибутивами линукса, и идеале использовать минималистичные. Есть например fedora coreos, в которой нет почти ничего, кроме вещей нужных для контейнеров)
Для меня тут оснавная красота в том, что мы можем собрать образ в котором есть только бинарник и запустить его на системе в которой нет почти ничего кроме ядра. Очень минималистично)

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

Если что вот
https://www.youtube.com/watch?v=Wkl-lqf6ZU8&t

INFRA

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