Коллеги, приветствую!👋

Прошёл вебинар «Модели ветвления и их влияние на CI/CD-пайплайн»⚡️

Кирилл из Фланта разобрал 4 модели ветвления, их плюсы/минусы и на примере показал их связь с CI/CD.

Запись:
➡️ ВК - https://vkvideo.ru/live-59405817_456240151

➡️ Ютуб - https://www.youtube.com/live/rAiE8mfRPEk?si=RbUYMj5GgT9p5k4I

Коллеги, приветствую👋

Решил порадовать подписчиков своего канала и разыграть фирменный мерч: 3 кепки с надписью Devops Bootcamp

Условия розыгрыша:
➡️ скидываете в комментарии свой лучший мем про devops — про боль CI/CD, про пятничный деплой, который все обещали не делать. В общем, всё, что действительно откликается тем, кто в теме.

➡️ Победителей я определю путем подсчета реакций под мемами. Три мема с наибольшим количеством реакций забирают кепки.

➡️ Мемы принимаю до 10 сентября, итоги 18 сентября.

Давайте посмотрим, у кого в нашем комьюнити самое классное чувство юмора 🙂

Коллеги, приветствую 👋

Сегодня подводим итоги розыгрыша фирменного мерча: разыгрывались 3 кепки с надписью Devops Bootcamp. Условие было простое — кепки достаются авторам трёх мемов, набравших больше всего реакций. Итак, рады объявить победителей:

1️⃣ @balahonovden
2️⃣ @monk_22
3️⃣ @v122474487139

В ближайшее время с вами свяжутся коллеги из Слёрма и расскажут, как получить свой приз 🙂

⚡️⚡️⚡️⚡️⚡️⚡️

Коллеги, приветствую👋

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

🔴Мои коллеги Senior ИТ-рекрутер Аниса Рогатова и практикующий DevOps-инженер Евгений Федосеев разбирали реальные вакансии с карьенрого агрегатора: что на самом деле стоит за каждым требованием и на что смотрят при отборе.

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

Смотреть полную запись вебинара ➡️ СМОТРЕТЬ

Вчера стартовал курс «Профессия DevOps-инженер»🔥

Из чего состоит курс:
Обучение проходит на базе приложения SlurmTalks - платформы, которую студенты пошагово собирают и разворачивают, применяя изученные инструменты на практике.

Курс включает 7 модулей:
🔴 Linux и Git - база: администрирование, ветвление, слияние, работа с командной строкой.
🔴Ansible - автоматизация конфигураций: плейбуки, роли, шифрование секретов.
🔴 Docker - контейнеризация: образы, Dockerfile, Docker Compose, Docker Swarm.
🔴Kubernetes - оркестрация: архитектура кластера, Helm, работа с хранилищами данных, безопасность.
🔴CI/CD - сборка пайплайнов в GitLab: тестирование, безопасность, деплой.
🔴Мониторинг и логирование - Prometheus, Grafana, ELK/EFK-стек, работа с инцидентами.
🔴Terraform - инфраструктура как код: провайдеры, модули, работа с AWS, Yandex Cloud и другими облаками.

⚡️Завершает обучение финальный проект - построение инфраструктуры для высоконагруженного приложения с настройкой CI/CD, мониторинга и безопасности.

Первые 5 дней обучения - бесплатно. Можно начать курс и оценить формат, прежде чем принимать решение ➡️ попробовать бесплатно

Коллеги, приветствую👋

Курс «Профессия DevOps-инженер» уже стартовал🔥

В закрытом чате уже активно идёт знакомство: участники из разных компаний, городов и даже стран общаются, делятся опытом, обсуждают CI/CD, кластеры и автоматизацию.

Это не только обучение, но и возможность найти единомышленников, коллег из разных уголков мира и даже друзей. Если хотите прокачаться в DevOps, получить обратную связь от экспертов и зарядиться комьюнити - присоединяйтесь.

Начать погружение в курс можно бесплатно)

➡️ ПРИСОЕДИНИТЬСЯ ПО ССЫЛКЕ

Существуют ли волшебные флаги?

Коллеги всех приветствую👋

Возникла задача копировать S3-бакеты. С небольшим количеством файлов всё нормально — справляется без проблем. Но когда файлов сотни миллионов, начинается боль.

🔴Исходные данные: несколько терабайт, средний размер файла 10–15 КБ, общее количество файлов 300–400+ миллионов. Доступной оперативной памяти 256–512 ГБ. Ожидаемая скорость хотя бы 50–100 МБ/с. Реальная скорость 1–2 МБ/с.

В чём проблема:
--fast-list — это флаг rclone, который загружает весь список объектов в память сразу, а потом начинает передачу.

🔴С --fast-list: память = N_объектов × 1 КБ. Для 400 млн файлов: 400 000 000 × 1 КБ = ~381 ГБ. Вывод: не укладывается в доступную память → rclone падает по OOM.

🔴Без --fast-list: rclone обрабатывает по одной папке (префиксу) за раз. Память = N_файловвкрупнейшей_папке × 1 КБ. Если крупнейшая папка = 5 млн файлов: 5 000 000 × 1 КБ = ~4.8 ГБ. НО: каждый файл = отдельный LIST + PUT запрос к S3.

Почему всё равно медленно:
Проблема не в нагруженности API, а в том, что запросов физически много. rclone упирается не в пропускную способность сети, а в количество операций, которые нужно выполнить. Каждый файл требует LIST (получить метаданные), HEAD (проверить mtime/size), PUT (загрузить файл), проверку destination. Итого ~4 API-вызова на файл × 400 млн = 1.6 млрд запросов.

Даже если S3-провайдер не режет rate limits и API не перегружен, просто физическое время на выполнение 1.6 млрд запросов при 1000–3000 запросов/сек даёт 6–18 дней только на запросы.

Как подобрать параметры transfers и checkers:
transfers и checkers — самые важные параметры копирования. Чтобы подобрать их правильно, нужно посчитать потребление памяти.
⏩transfers — сколько файлов копируется параллельно. Каждый transfer занимает buffer_size памяти (по умолчанию 16 МБ). Формула: transfers × buffer_size. Например, 256 × 16 МБ = ~4 ГБ.
⏩checkers — сколько файлов проверяется параллельно (сравнивает метаданные source и destination). Каждый checker держит в памяти ~1000 файлов по 1 МБ на файл. Формула: checkers × 1000 × 1 МБ. Например, 256 × 1000 × 1 МБ = ~250 ГБ.

🔴Парадокс с настройками transfers и checkers:
НО: это всё имеет смысл только с --fast-list. Без --fast-list rclone работает так медленно, что память вообще не утилизируется. Можно выставить transfers 256, checkers 256, но реальная скорость будет 1–2 МБ/с из-за количества S3-запросов.

🔴Получается замкнутый круг: с --fast-list нужно 381 ГБ памяти для 400 млн файлов (столько памяти может не быть), без --fast-list память не нужна, но скорость падает в 50–100 раз, потому что каждый файл = отдельный запрос.

➡️Выводы: --fast-list обязателен для миллионов файлов, но требует огромной памяти (~1 КБ на объект). Для 400 млн файлов это уже ~381 ГБ, что превышает типичные лимиты памяти. Без --fast-list rclone упирается в количество операций S3 — каждый файл = отдельный запрос. Оптимизация параметров (transfers, checkers, buffer-size) не даёт эффекта — бутылочное горлышко в количестве запросов, а не в rclone. Единственное решение: разбивать на префиксы и запускать параллельно несколько процессов

➡️Итог: сотни миллионов мелких файлов = ад для любого S3-клиента. rclone не виноват — это ограничение архитектуры S3 API, где каждый файл требует отдельного запроса.

P.S. Если кто сталкивался с такой же проблемой — поделитесь опытом, как решали? Может, есть волшебный флаг или сервис, который это умеет? Или скажите какую еще проблему я не учел, которая будет проблемой при такой большой переливке?

Жду ваши ответы в комментариях👇

«У вас что-то с кубером»

Коллеги всем привет👋🏻
Расскажу сегодня случай про обращение с проблемой:

Как обычно, вечер. У внешней команды установка релиза и он падает с ошибкой. Коллеги приходят с ошибкой и просят решить проблему. Релиз на их тестовых кластерах установился без проблем.

⏩В логах — отказ при создании роли из pre-upgrade hook. Примерно такой:

Error: UPGRADE FAILED: pre-upgrade hooks failed: warning: Hook pre-upgrade templates/reload-config.yml failed:roles.rbac.authorization.k8s.io "release-hook" is forbidden:
user "release-user" is attempting to grant RBAC permissions not currently held:

На первый взгляд всё очевидно: пользователю не хватает прав. Нужно поправить RBAC, выдать доступ и продолжить релиз.

Но сначала стоит спросить: а права на что именно мы собираемся выдавать?

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

- apiGroups: ["apps"]
resources: ["deployments/rollout", "deployments/status"]

⏩У стандартного Deployment нет подресурса rollout. Есть команда kubectl rollout, но это не одноимённый подресурс Kubernetes. В чарт попала правдоподобная, но несуществующая сущность — deployments/rollout.

Вероятно этот фрагмент написал ИИ. А результат не проверили.
А почему тогда на другом кластере работало?

⏩Потому что тестировали под администратором. Вот как выглядит проверка полномочий под cluster-admin — даже для выдуманных подресурсов:

$ kubectl auth can-i get deployments.apps --subresource=rollout -n production
yes

$ kubectl auth can-i get deployments.apps --subresource=shit -n production
yes

⏩Это иллюстративный вывод для учётной записи с cluster-admin, а не проверка существования этих подресурсов. Команда can-i отвечает на вопрос «разрешено ли мне такое действие?», а не «существует ли такой API?». Поэтому администратор получает yes даже для выдуманных названий

⏩При этом запись в RBAC не подтверждает существование указанного API-ресурса. Администратор может сохранить роль с deployments/rollout, но новый подресурс от этого не появится. В конфигурации просто останется бессмысленное правило.

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

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

⏩Выдать больше прав — значит заставить установку пройти, не исправив дефект.

ИИ удобно использовать в DevOps: он быстро собирает YAML, шаблоны и скрипты. Но правдоподобная конфигурация ещё не означает рабочую.

Коллеги, приветствую! 👋

Рекомендую обратить внимание на новый интенсив Слёрма «n8n для DevOps: AI-ассистент за 3 недели».

⏩Коротко: 3 недели по 2–3 часа в день, 8 воркфлоу в репозитории. Поднимаете self-hosted n8n в Docker, строите пайплайны с триггерами и ветвлением, вызываете LLM со структурированным выводом, готовите воркфлоу к продакшену: секреты, ретраи, лимиты.

Для старта опыт с n8n не требуется.

🔴Полезно DevOps/SRE и сисадминам - автоматизировать алерты, проверки деплоя и рутину через API и вебхуки.
🔴Разработчикам и тимлидам - понять, где нужен агент, а где достаточно обычного IF.

⏩УЗНАТЬ ПОДРОБНОСТИ