SSDLC

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

Заметка:
Разделять сервисы по пользакам в БД может помочь с дебагом, когда нужно найти сервис который ее кладет.

PRE COMMIT

Технология которая позваляет делать флоу перед попаданием кода в репозиторий.
Как пример, на локальной машине разработчика мы можем вызывать:
- Тесты
- Линтеры
- Сканирование на безу и сикреты
Это позволяет нам не допускать в репозторий код с явными проблемами.
Проблема в том что нельзя напрямую заставить всех разработчиков использовать его, максимум кастомить CI/CD джобы которые по косвеным признакам определит запуск. Но по большей части инструмент нужен самим разработчикам, что бы сделать проверку на дурака)

INTERVIEW

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

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

STACK

Как подбирать стек для проекта, в контексте инфры и DevOps практик:
1. Задачи. Определить что мы хотим от инструмента, какие задачи он должен закрывать?
2. Перспектива. Планируется ли в будущем какие то задачи которые не сможет закрыть конкретный инструмент?
3. Популярность. Есть ли на проекте или на рынке люди которые смогут работать с ним?
4. Надежность. Хватит ли нам той надежности которую предоставляет данный инсрумент?
5. Безопасность. Тут не надо пояснять)

Вот к примеру:
Gitlab CI/CD по всем пунктам плюс минус такой же как CircleCi, по сути делает тоже самое. Но в реалиях рынка РФ gitlab сильно популярнее и бОльшее количество людей умеют с ним работать, для меня выбор очевиден)

Что выгоднее?
1. Доставить на орбиту солнеыные панели и отправлять электричесвто на землю
2. Отправить в космос то что потребляет энергию

Смотрим тут)
https://www.youtube.com/watch?v=XYQ_NmzeD6c

ERLANG

Иногда читаю про язык erlang и его виртуальную машину. И каждый раз нравится все больше.
Основная идея состоит в надежных распределенных вычислениях. Как это добивается:
1. Виртуальная машина предоставляет простой способ поднять кластер на разных нодах
2. Она сама распределяет нагруку и создает процессы на нодах
3. Есть специальный фреймворк для вычислений на кластере
4. Hot reload, можно без поростоя обновить код
5. Миграции, позволяет настраивать переход состояния процессов при hot reload
6. Автоматический перенос процессов между нодами

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

MONO

Один из вариантов ведения разработки это монорепы.
Как пример - в репе несколько модулей одного проекта, плюс общие компоненты. Чаще всего все эти модули собираются в отдельные микросервисы, и при сборке сразу из репы тащаться общие компоненты.
Зачем так делать? Для кого то это проще. Если все модули имеют сильную связанность то куда легче вести все это вместе. Плюс, в какой то мере, это проще поддерживать и выкатывать.
Какой обычно флоу для CI/CD:
- При изменения файлов кокнретного модуля тригер на сборку этого модуля
- Тригер сборки модуля тригерит его деплой
- При изменения файлов общих компонентов пересобираются и деплоятся все компоненты

TOOLS

Про зоопарк инструментов.
Периодически втречаю проекты где есть какое то количество инструментов которые делают одно и тоже, но их схлопывают.
Например репозиторий в гитлабе, а пайпланы запускаются в jenkins. Казалось бы, почему не сделать сразу все в гитлабе? Ну или не переделать сейчас.
Чаще это бывает легаси которое сложно выпилить. Например когда то дженкинс закрывал что то чего нет в гитлабе. Но со временем база пайлпайнов сильно разрастается, и уже сложно просто взять и переписать все на гитлаб. Так и продолжается, все новые пайпланы по привычке заводятся на jenkins.
Что тут можно сделать? Ну если команду все устраивает то ничего делать не нужно.
А так, изначально не стоит заводить зоопарк инструментов, это сильно увеличивает сложность поддержки и необходимую экспертизу.
Если же это уже случилось то можно просто остановится и оставить этот кусок как легаси, все новое уже заводить как нужно. А легаси можно уже потихоньку разгребать)

Очень классное выступление манискин, как обычно Итальянцы делают очень жарко)
https://www.youtube.com/watch?v=_kOzW0HPLT0

TRIVY

Как сделать сканирование образов без доступа в интернет? Это важно в закрытых контурах.
Проблема в том что нам нужна база данных известных CVE, и в любом случае придется выкачивать их из интернета.
Но это можно сделать на этапе сборки самого трайви, а не при сканировании. Это даст нам гарантию что мы просканирую наши образы только у себя и это никуда не сольется.
Делается это так:
При сборке образа с трайвии делаем:
RUN trivy image --download-db-only
При сканировании добавляем два параметра:
--skip-db-update --offline-scan

Все. Мы сможем сканить оффлайн)
Главное это периодически пересобирать образ, что бы держать базу CVE актуальной.

CACHE

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

В офис красоту подвезли)

HARDWARE

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

CI/CD

Про разные CI/CD системы.
По своей логике они все одинаковые, просто предоставляют разные фичи.
Например сейчас смотрю один проект который работает на bitbucket. Я ни разу с ним не работал, но с опытом гитлаба тут все понятно, просто чуть другой синтаксис.
Тут, как по мне, нужно понимать логику и основные примитивы CI/CD процесса, а с синтаксисом могут помочь нейросети.
Из различий. По тому что я вижу в битбакете любят использовать шаблонные пайплайны которые предоставляет сам битбакет. Как я понял разные вендоры инфры типа aws и яндекс клауда могут предоставлять свои публичные пайплайны под их инфру. В гитлабе такого особо не встречал, все пишут шаблоны сами.
Ну и по ощущениям гитлаб куда более гибкий.

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

И последнее на сегодня)
"Колаба" бостонов и ролинг стонс)
https://www.youtube.com/watch?v=XnZH4izf_rI

PROXY

Как пробрасывать определенный трафик из контейнера через прокси? Разберем на примере апи openai.
Допустим наше приложение расологается в России, но нам нужно делать запросы к моделькам.
Для начала поднимаем иностранный сервер и ставим туда пакет nginx-full, он включает в себя модуль проксирования tcp трафика.
В nginx conf добавляем такой блок:

stream {

    upstream backend {
        server api.openai.com:443;
    }
        server {
        listen 443;
        proxy_pass backend;
        proxy_ssl_server_name on;
        ssl_preread on;
    }

}

Он будет слушать на 443 порту и весь трафик который пришел на него пробрасывать на api.openai.com.
Далее, при старте контейнера указываем ему переписывание hosts для этого домена:

--add-host=api.openai.com=$YOUR_PROXY_IP

Где $YOUR_PROXY_IP это адрес сервера с nginx.

Все, теперь если приложение в контейнере будет обращаться на api.openai.com то все запросы будут идти через прокси.

CLOUD

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

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

HELM

Есть шаблонные хельм чарты которые предоставляют сами вендоры софта.
Например bitnami предоставляет свой регистри с чартами, с свое реализацией софта. Сегодня ставил рабит и редис оттуда.
Когда использовать такие чарты? Когда это небольшой проект где не нужно что то кастомное.
Для таких проектов хватит готовых чартов, которые и так очень хорошо настроены, лучше чем сделают многие на коленке)
Как использовать такие чарты:
- Добавляем репу helm repo add bitnami
- Обновляем кеш helm repo update
- Скачиваем чарт helm pull bitnami/memcached --version 8.0.4
- Делаем install скачанного чарты
Чаще всего все заведется с первого раза, можно сразу начинать пользоваться)

QUESTION

Пара моих любимых вопросов которые задают на собесах.
1. При канареечном релизе мы постепенно переключаем трафик на новую версию. На что ориентироваться при повышение процента трафика? На какие метрики?
2. Есть релизы в которых мы держим новую и старую версию одновременно. Но новая версия может накатить миграцию в БД которуа сломает старую версию. Что делать?
3. Есть сервер с постгрей. В нормальном режиме диск потребляется на 30%. Но начались волны потребления, пару раз в день диск забивается до 100 процентов и возвращается к 30. В чем может быть проблема и что делать?

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