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

INFRA

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

AI

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

FEDORA

Сегодня у меня небольшой челендж - просидеть весь день на федоре,
Пока успешно, поделал задачи и сейчас занимаюсь своими делами. Самое главное для меня - при грамотной настройке федора под гномом может быть максимально удобной для перехода с макоси. Очень близкий дизайн и флоу работы.
С прошлых моих эксперементов с федорой, пару лет назад, особо ничего не изменилось но стало просто чуть удобнее.
Из плюсов:
- Удобнее работать с файлами
- Реальный контроль над системой
- Один основной способ установки софта
- НАТИВНЫЙ ДОКЕР
Из минусов - сама железка. Все же макбук для меня это эталон как сама железяка)

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

BOOT

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

WINDOWS

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

TRIAGE

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

FILE TRANSFER

Для загрузки больших файлов в хранилища лучше использовать специализированные протоколы.
Напримре, если у нас есть бекап бд на 100-200гб то не стоит грузить его по http апи через curl. Он не предназначен для этого и будет падать чаще чем специализированный софт.
Тут можно использовать утилиты для работы с ftp и s3. Это все специально написанные протоколы для работы с файлами которые обеспечивают стабильную загрузку и отказоустойчивость.
Я сам сейчас, чаще всего, использую самописные скрипты которые грузят по s3 через boto3. Стабильно и довольно быстро)

DOCKER

Сегодня который раз убедился что не стоит использовать alpine.
Мы собираем образы на раннерах в кубере, и у него есть такое поведение что он маунтит в рантайм джобы свои ресурсы, типа сервисных акков.
И вот при сборке образов приложений мы обновляем его базовые зависимости (appsec, все тако) . В alpine пакетный менеджер при обновлении выполняет свои скрипты, и в ряде зависимостей эти скрипты пытаются обратится по пути ресурсов к которым примаунчены кубовые ресурсы. Тут и встает проблема, что они маунтятся как ридонли и не дают возможность делать что либо в директорияъ даже на уровень ниже.
Как я не воевал с этим, ничего не вышло. Пришлось переходить на базовые образы основанные на deb.
По итоге, эти новые образы нормально встали со всеми обновлениями и итоговый образ аналогичен по размеру)

TEST

Почему нет процесса тестирования задач девопсов обычными тестерами?
Оно есть, но косвенно.
Где могут возникнуть ошибки и как это отслеживается:
1. Не верный билд и деплой. Это будет заметно при тестировании функционала.
2. Открытые ресурсы которые должны быть закрыты. Сетевики и команда ИБ.
3. Отказоустойчивость и производительность. Нагрузочное тестирование.
4. Бекапы. Тут да, девопсы должны сами настраивать проверку.
5. Опасные изменения в релизном процессе. Для этого по процессу все проходит через дев/тест стенды.

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

APPSEC

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

Ну и продолжаю отправлять сюда клипы моей любимой Российской группы)

https://www.youtube.com/watch?v=8nXo65cd9Ck

FEDORA

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

Пост немного сумбурный и без какой то одной мысли, просто передача того что в голове)

ANSIBLE

Декларативное описание состояние сервера не гаранирует две на 100% идентичные инсталяции.
Ведь если мы описываем там установку пакетов и прогоняем два сервера с разницей в день то на них могут установится разные версии зависимостей. Даже если мы выставляем версии нужных нам пакетов то нет гарантии что транзитивные зависимости этих пакетов будут зафиксированны. А вложенность этих зависимостей может быть многоуровневой.
Да, можно максимально приблизится к 100 процентной идентичности, для этого нужно ставить прокси репозитории и возится с правилами кеширования пакетов и их обновлением. Но даже тут нет гарантии.
По факту, единсвенное что можно обеспечить это идентичность настроек ОС, например пользаки и тд. Но даже тут, нужно обеспечить идентичность изначальной системы.

Но на практике это так не важно, условно если мы хотим настраивать на серверах авторизацию для деплоя контейнеров то нам не важны версии зависисмостей 3 уровня, важно что бы была нужная версия докера и пользаки)

Ну чтож)

GITLAB

Допустим у нас есть множество паралельных сборок в одном пайплайне.
Как обеспечить паралельность но не разорится на раннерах? Использовать автоскейл кубер.
Поднимаем раннер в кубе на отдельной ноде и создаем группу узлов с 0 нод и возможностью скейла. В джобах билда указываем запрос CPU, например так:

variables:
    KUBERNETES_CPU_REQUEST: "4" 

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

SHARED

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

SEC

Когда я начинал работать девопсом, в 2019 году, основной диалог в сообществе шел по поводу высоких нагрузок. Мы это прошли и сейчас обеспечивать высокую нагрузку стало легче, почти все к этому готовы.
Сейчас основной диалог про безопасность. О том как правильно делать безопасность, с акцентом на безопасность приложений. Ведь инфра тоже стала довольно безопасной, почти по дефолту.
Как по мне, сейчас конценсус состоит в shift left. То есть как можно раньше найти уязвимость и сразу ее исправить. Ну и появились разные подходы к поиску, начиная от статических линтеров до команд пентестеров.
Может я просто нахожусь в таком пузыре, но вижу реальный интерес проектов к этому. Все хотят сделать безопасно и не прям дорого, поэтому внедряют безопасность на ранних стадиях процесса разработки. Это не может не радовать)

DOCKER

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

RUN useradd -u 10001 -r appuser
USER appuser

Таким образом мы создадим пользака с минимальными правами и процессы в контейнере будут запускаться под ним)

CICD

Пайпланы, особенно в гитлабе, хорошо поддаются шаблонизации.
Если на проекте куча однотипных микросервисов то нет смысла для каждого писать отдельный пайплайн. Это займет много времени и появятся расхождения, плюс больше вероятности ошибок.
Гитлаб поддерживает include пайплайнов из других репозиториев. В котором можно описать несколько манифестов с пайплайнами в разных файлах, или один общий, и по необходимости инклудить их в проекта.
Описать пайплайн который будет работать везде не так уж и сложно. Можно опираться на предефайн переменные гитлаба, типа CI_PROJECT_NAME и кучу других. Но в идеале структура диреторий проекта должна быть схожей. Тогда один небольшой шаблон пайплайна заработает вообще везде)