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 и кучу других. Но в идеале структура диреторий проекта должна быть схожей. Тогда один небольшой шаблон пайплайна заработает вообще везде)

STORAGE

Какие основные функции файлового хранилища я хочу видеть.
Так как чаще всего я использую их для бекапов то нужно:
1. Гибкие настройки доступа
2. Cli интерфейс для клиента
3. Ротация, что бы не забивать стор старыми файлами
4. Лимиты, возможность настроить типа хранилища и ограничения на место/запросы
5. Мониторинг, по используемому месту и запросам

По опыту, вообще не все предоставляют это. Только несколько провайдеров которые делают S3 хранилки.

BUFER

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

SAAS

Есть настоящий и псевдо saas.
Настоящий - под каждого клиента поднимаем изолированный инстанас приложения. Со своей база данных, всей инфрой и контейнерами приложения.
Псевдно - у нас одна система и разделяем клиентов по схемам в одной бд. Ничего отдельного ему не поднимаем.

Оба варианта рабочие.

Настоящий.
Плюсы:
- Реальная изоляция
- Меньше логики разделения на приложении
- Безопасность
Минусы:
- Дороже по инфре
- Больше времени перед отдачей клиенту
- Сложно релизить новые версии

Псевдо.
Плюсы:
- Быстрее поднимаем
- Дешевле по инфре
- Легче вносить изменения
Минусы:
- Менее безопасно
- Сложная логика разделения на приложении
- Не так безопасно

LLM

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

BASH

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

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

UPDATE

Сегодня обновлял одну систему развернутую в контейнерах. На одну мажорную версию.
Какая случилисаь проблема - нужно было обновить mongo с версии 6.0 до 8.3. Плюс к этому вендор системы выбрал для этого новый образ монги и добавил дополнительные скрипты при старте.
Что пришлось делать:
- Берем обновленный образ и поднимаем его с версией седьмой версией монги
- Снимаем дамп с актуальной монги
- Заливаем ее в 7 версию
- Поднимаем целевую 8.3 версию
- Снимаем дамп с 7 версии
- Заливаем его в 8.3
- Поднимаем версию приложения

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

DATA

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

DISK

Как я обычно подбираю тип и размер диска:
1. Сервер приложения.
Например обычная виртуалка с контейнерами или нода в кубе где будет крутится приложение. Тут хватит минимального hdd диска. Так как в таких случаях сервер баз данных и файловое хранилище вынесены наружу, то взаимодействие диском минимальное. Чаще приложенеи выгружается в ram при старте и работает уже там.
2. Небольшой сервер хранения.
Например s3 или база данных. При небольших нагрузках тут хватит обычного ssd диска, обьем выбираем по необходимости. Тут пока не надо сильно запариваться, при небольших нагрузках все будет хорошо.
3. Нагруженный сервер хранения.
Тут уже лучше сразу думать про nvme. Так же в клаудах, да и в целом в любых системах, IOPS и скорость чтения/записи зависит от размера диска - чем больше тем выше. Поэтому тут имеет смысл перезакладывать размер диска и подбирает с максималными характеристиками. Ну и конфигурировать размеры блоков, подбирать файловую систему и больше мониторить его состояние.

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