CLOUD INIT

По сути система конфигурации. В облаках, когда мы выбираем ось, то ее образ не собирается под нас а просто подтягивается шаблонный. Но когда мы конфижим машину в интерфейсе (или где то еще) то мы выбираем разные параметры типа:
- Имя машины
- Пользователи
- Добавляем ключи
- Делаем какие то настройки сети
Cloud init дает нам возможность при первом запуске получить такую машину которую мы сконфижили. По сути это простой yaml манифест с описанием настроек машины и интерпритатор написанный на питоне, который парсит и применяет этот манифест. И по итогу мы получаем такую машину как мы хотим из шаблонного образа операционки.
Большенство задач которые описаны в этом манифесте выполняются только при первом запуске. Но некоторые могут запускаться и после ребута, по сути мы можем добавлять их в манифест уже после создания машины.

По логике это очень похоже на ansible, просто специализированный именно под первоначальную настройку в клауде и сильно проще)

FLOW

Думаю важно понимать - нет какого то определенного правильного гит флоу в разработке.
Наверно можно сказать что есть самые поулярные вариант типа:
feature-N -> dev -> test -> main -> tag
Но это не прибито гвоздями. Каждая команда может сама решать как удобно. Например у меня на одном из проектов все фичи сливаются в main ветку, откуда катится на дев стенд, и уже с main создается продный тег, и всем удобно)
Сложные флоу нужны там где есть много разработчиков и множество стендов, но и там можно сделать попроще.
Гибкие методологии разработки на то и гибкие, что позволяют нам делать удобно конкретно для нас)

INTERPRETATION

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

SYSTEMD

После загрузки ядра линукса нам нужно поднят всю остальную систему, которая может состоять из множества компонентов.
Для этого сейчас, чаще всего, используется systemd. По сути это набор манифестов и рантайм который позволяет поднять все так как нам нужно. Там описывается:
- Путь до компонента
- Политика старта/рестарта
- Пользователь
- Рабочая директория
И множество других полезных директив.
После загрузки ядро передает управление в systemd и он уже поднимает все в нужном порядке.
Раньше в большенстве дистрибутивов использовался init. Но его основной минус в том что он запускает все поочередно и имеет менее гибкую настройку. В то время как systemd может запускать все паралельно и имеет большой уровень кастомизации

ASISTENT

Яндекс клауд выкатил превью версию AI асистента.
Пока это бесплатная версия которая не так много умеет, но уже дает прикольные возможности. Например сегодня я описал ему что мне нужна группа безопасности с определенными правилами, он спроектировал ее и спросил можно ли ее создать, я апрувнул и он ее сделал. И еще сейчас с его помощью провожу ревизию клауда, что бы вытащить все ресурсы которые не используются либо используются не на полную.
Пока что он ограничен, например он не может снять метрики с managed постгри. Но уже может по mcp цепляться к кубу.
Думаю за этим определенное будущее, и в какой то мере замена саппорта клауда)

LAMBDA

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

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

SSH

Как сделать второй фактор при аутификации по ссш?
Самый простой способ это использовать гугл аутенфикатор. После настройки при аутенфикации нужно будет ввести и пароль и второй фактор из приложения (но с ключами полноценно пока не работает, все равно придется вводить пароль).
Как реализовать:
1. Ставим пакет

apt install libpam-google-authenticator 

2. Для нужно пользака, под которым будем ходить, генерим код командой

google-authenticator

дальше добавляем этот код в приложение гугл аутификатора

3. В файле /etc/pam.d/sshd добляем строку

auth required pam_google_authenticator.so

4. В /etc/ssh/sshd_config добавим

ChallengeResponseAuthentication yes

5. Рестарутем ssh

service ssh restart

На этом все, при следующем логине система попросит нас ввести пароль и код)

K8S

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

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

Заметка:
Когда обновляешь версию убунты на сервере гитлаба то нужно обновить гитлабовские deb репозитории до актуальной версии)

IDENPODENT

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

INCLIDE

Сейчас пишим общие пйплайны для микросервисов. Флоу такой:
- На МР запускаются линтер и юнит тесты
- С develop ветки катится дев стенд, с main ветки тест стенд
- С тегов в прод
На дев и тест пайлпанй выглядит так:
1. Билд jar файла
2. Оборачивание в докер образ
3. Sca сканирование образа
4. Деплой на дев/тест
Для прода плинируем тегировать тест образ продовым тегом и катить уже.

Архитектурно это выглядит так:
Отдельная ci/cd репа, каждый шаг описан в отдельном файле, для того что бы в конкретную репу мы могли инклюдить только то что нужно. В самом репозитории сервиса делаем правки для деплоя, что бы можно было кастомизировать переменки, просто через extend общего шага из ci/cd репы.

TEAM

Иногда нужно отдавать часть задач на откуп самим разработчикам. Потому что если зацикливать все на себе то ты и сам все не успеешь и сама команда будет страдать.
Что бы можно разрешить им делать:
- Обновлять переменки
- Создавать базы данных на дев/тест стендах
- Смотреть отчеты сканов
- Пушить артифакты (например либы в нексус)

Если весь DevOps процесс выстроен хорошо то это будет очень просто делать, каждый разработчик сможет делать то что ему нужно и не ждать девопса)

Что бы я не давал:
- Все что касается изменения на прод инфре
- Сетевые политики
- Докручивать правила квалити гейтов
- Добавление/расширение ресурсов

Если кратко то все что касается разработки и не заафектит безопасность и не сломает прод можно давать разрабам, что бы не блочит их и не заваливать себя)

FAIL

Бывает случаи когда у нас падают тест и линтеры, тогда нам надо посмотреть отчет который сформировался. Как это сделать в гитлабе?
Допустим при падении артифакт с отчетом клаедтся в файл:

tests/result.html

Тогда в гитлабе в джобе с тестом нам надо указать:

  artifacts:
    when: on_failure
    paths:
      - "tests/result.html"
    expire_in: 1 week

Тогда этот артифакт сохранится при падении джобы и мы сможем скачать и посмотреть его)

REVIEW

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

SHIFT LEFT

И снова в тему AppSec. Иногда стоит напоминать, в первую очередь себе, очевидные истины по типу:
Чем раньше мы узнаем о проблеме тем лучше.
Если мы берем весь SDLC в контексте безопасности то "раньше" тут это этап аналитики, до этого этапа очень сложно оценить безопасность. На этапе аналитики скорее поможет кросс ревью и консультации с инженерами, тут сложно придумать что то бОльшее.
Если на этапе аналитики все ок то уже на этапе разработки мы можем смотреть реализацию. Если совсем упарываться то можно поставить сканеры как плагин в IDE разработчиков, и не разрешать пушить пока код не пройдет по всем правилам. Но это долго и дорого. Поэтому лучшим выбором будет это сканирование в CI пайплане сразу после пуша, которое может блокировать дальнейшие мержи на стенды.

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

N8N

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

LLM

Про использование языковых моделей для анализа кода.
Как по мне основной кейс использования это анализ дифференца в МР, так как что бы на каждый чих анализировал весь код нужно много токенов.
Что стоит ожидать в этом случае?
1. Анализ синтаксиса
2. Явные баги
3. Опечатки
4. Код стайл
5. Потенциальные проблемы

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

Не мог не поделится)

SUPPORT

Когда вся инфра и сам проект уже развернуты то для девопса настоет период поддержки.
Что обычно сюда входит:
1. Реакция на алерты
2. Реагирование на запросы разработки (чаще мелочи)
3. Зависит от проекта, но еще могут быть доступы
4. Мастшабирование
5. Иногда затаскивание новых сервисов и релизы старых

Чаще все это занимает не более часа в день, так как после первых релизов команда разработки может почти все сделать сама)

Уже кидал этот клип года 2 назад, но пожалуй повторюсь)
https://www.youtube.com/watch?v=lPlkGFDZn4I

VM

Сегодня столкнулся с кейсом: полетели настройки ссш ключей на виртуалке в яндексе.
Какое тут решение:
1. Делаем снимок диска нужно машины
2. Стопаем или удаляем машину
3. Конфигурим новую машину из снимка
4. Указыаем там нужный ключ и ip
5. Поднимаем машину

Все, после того как машина поднимется то там снова будут актуальные ключи, яндекс добавит их через cloud-init)