DevOps by REBRAIN
29K subscribers
493 photos
12 videos
4 files
1.03K links
Открытые практикумы по DevOps, Linux, Golang, Networks, Security

Мы на связи:
info@rebrainme.com
+7 (499) 116-34-68

https://rebrainme.com/

Зарегистрированы в РКН: https://knd.gov.ru/license?id=674db558d793bc0b0b8845ff&registryType=bloggersPermission
Download Telegram
🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat
Регистрация

Время проведения:
14 июля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢Агент Winlogbeat: основные теоретические сведения
🟢Установка и базовая конфигурация ELK
🟢Настройка сбора событий безопасности c MS Windows

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ RAID массивы
Регистрация

Время проведения:
15 июля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Некоторые уровни RAID массивов
🟢Виды RAID массивов
🟢Создание RAID массива и работа с ним

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------

3️⃣ IPTables-2
Регистрация

Время проведения:
16 июля 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Перенаправление пакетов
🟢Работа с NAT
🟢Маркировка трафика
🟢Логирование пакетов
🟢Ограничения (rate limiting)
🟢Изменение свойств пакета (mangle)
🟢Работа со списками (IPSet)
🟢Создание собственных цепочек

Кто ведёт?
Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Делимся записью открытого практикума "Что такое ИИ-агенты и почему они сделали LLM полезным", где с Артуром Сапрыкиным разобрали, почему современные языковые модели — это больше, чем просто чат, как устроены ИИ-агенты и как они меняют подход к автоматизации.

20 июля у Артура стартует интенсив «ИИ-агенты для инженеров». Подробности тут: https://clck.ru/3UTeAG

Краткий конспект видео 👇🏼

🟢 Модель и агенты — важно разделять мыслительные функции и практическое исполнение. Большая языковая модель выступает в роли координатора, который планирует шаги, а агент является непосредственным исполнителем задач.

🟢Ограничения базовых систем — стандартные текстовые генераторы без специальных надстроек не могут зайти в интернет, отправить электронное письмо или самостоятельно выполнить запрос к базе данных.

🟢 Вспомогательные инструменты — это программные модули, которые система вызывает для работы: код для построения графиков, доступ к корпоративным системам или почтовым серверам.

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

🟢Долговременная память — помимо текущего контекста диалога, программы используют внешние хранилища и базы данных. Это позволяет им помнить предпочтения человека и специфику компании в течение длительного времени.

🟢Совместная работа систем — несколько цифровых помощников могут объединяться для решения одной задачи, где один ищет данные, другой их анализирует, а третий составляет итоговый отчет.

🟢Безопасность и мониторинг — чтобы предотвратить нежелательные действия, необходимо жестко ограничивать права доступа и использовать специальные инструменты для фиксации каждого шага программы. Для ответственных задач лучше применять заранее прописанные сценарии.

↘️ Смотреть в ВК
↘️ Смотреть в Youtube

Если тебе интересна тема ИИ-агентов и ты хочешь разобраться, как внедрить искусственный интеллект в разработку и автоматизацию инфраструктуры, то ждем тебя на живом интенсиве «ИИ-агенты для инженеров», где за 9 занятий ты пройдешь весь путь.

↘️ Узнать подробнее об интенсиве и записаться
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥92👍1
Когда Argo CD не синхронизирует состояние

Развернул приложение через Argo CD, всё зелёное, синхронизация прошла успешно. Через час заходишь - висит статус OutOfSync. Непонятно, кто и что изменил. Вроде бы репозиторий не трогали, но кластер думает иначе.

Или другая ситуация: разработчик запушил изменения, Argo CD их подхватил, но деплой завис, потому что какой-то ресурс уже существует и его нельзя обновить. А на следующий день выясняется, что кто-то из коллег выполнил kubectl apply вручную, и теперь состояние кластера расходится с Git-репозиторием.

🤔 Главная проблема - непонимание источника истины. В GitOps источник истины - это Git-репозиторий. Любое изменение в кластере, сделанное в обход Git, создаёт рассинхрон. Argo CD это видит, но не знает, что с этим делать, если политики не настроены правильно.

🛠Решение - корректная настройка политик синхронизации

Для каждого приложения в Argo CD можно определить, как именно оно должно синхронизироваться с репозиторием. Вот пример конфигурации с тремя ключевыми параметрами:


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: false # Не удалять ресурсы, которых нет в Git
selfHeal: true # Автоматически возвращать состояние из Git при дрифте
syncOptions:
- CreateNamespace=true



🔹 `selfHeal: true` - самый важный параметр для борьбы с «ручными» правками. Он автоматически возвращает кластер к состоянию, описанному в Git, если кто-то изменил ресурс через kubectl edit или apply. Без этого параметра любое ручное вмешательство оставит приложение в статусе OutOfSync.
🔹 `prune: false` - осторожная настройка на этапе миграции. Мы запрещаем Argo CD удалять из кластера ресурсы, которые не описаны в Git. Это защита от случайной потери данных. Включать prune: true (что является стандартом для честного GitOps) стоит тогда, когда вы полностью уверены в чистоте своих манифестов.
🔹 `- CreateNamespace=true` - опция в syncOptions, которая указывает Argo CD автоматически создать целевой namespace в кластере, если его еще не существует. Избавляет от лишних ручных шагов.

😎Масштабируем подход: паттерн App-of-Apps
Для больших проектов используется паттерн App-of-Apps (приложение приложений). Это подход, при котором одно главное («рутовое») приложение Argo CD управляет набором других дочерних приложений.

Важно: Корневое приложение должно разворачивать дочерние манифесты строго в тот namespace, где работает сам контроллер Argo CD (обычно `argocd`), иначе система их не распознает.


apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-of-apps
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/infra.git
targetRevision: HEAD
path: apps/
destination:
server: https://kubernetes.default.svc
namespace: argocd # Обязательно указываем namespace Argo CD
syncPolicy:
automated:
prune: true
selfHeal: true



Каждое дочернее приложение в директории apps/ описывается собственным YAML-файлом и может иметь свои уникальные политики. Например, для баз данных можно оставить prune: false, а для легковесного фронтенда - prune: true.

Дополнительно внутри дочерних ресурсов можно использовать Sync Waves (волны синхронизации), чтобы управлять очередью развертывания. Например, сначала гарантированно поднять базу данных, а только потом - зависимый бэкенд:


metadata:
annotations:
argocd.argoproj.io/sync-wave: "1"



Ресурсы с меньшим значением волны (включая отрицательные числа) запускаются и проверяются на готовность раньше остальных.
👍31
Практический план внедрения
1. Соберите манифесты: определите все ресурсы, которые должны управляться через Argo CD, и перенесите их в Git.
2. Настройте политики безопасности: начните с selfHeal: true и prune: false для продакшена, чтобы защитить данные. На стейдже сразу включайте prune: true.
3. Подключите уведомления: настройте Argo CD Notifications в Slack или Telegram, чтобы мгновенно узнавать о сбоях синхронизации.
4. Внедрите App-of-Apps: централизуйте управление всеми сервисами кластера через один корневой репозиторий.
5. Оптимизируйте Webhooks: настройте webhook от GitHub/GitLab к Argo CD, чтобы синхронизация начиналась мгновенно при пуше, не дожидаясь стандартного 3-минутного опроса (polling).
6. Договоритесь на берегу: обучите команду главному правилу GitOps — никогда не менять ресурсы в кластере напрямую. Только через git commit и git push.

Если нарушить этот принцип, Argo CD либо молча перезапишет ваши изменения (при `selfHeal`), либо оставит кластер в перманентном рассинхроне. Единственный правильный подход: commit в Git, а не apply в консоли.

Чтобы освоить GitOps на практике, включая работу с Helm-чартами, настройку мультикластерного деплоя и управление конфигурациями, 🔥открывай демодоступы бесплатно🔥 и начинай погружаться в технологию:

* Argo CD - установка, настройка, App-of-Apps, интеграция с Helm
* Git - продвинутая работа с репозиториями, ветвление, стратегии слияния
* Helm - создание чартов, управление зависимостями, шаблонизация
🔥10
Что будет, если объединить FreeIPA + Bash + Ansible?

Обычно управление инфраструктурой держится на трёх разрозненных инструментах. Пользователей заводят вручную на каждой машине, единого каталога доступа нет, а рутинные задачи закрывают Bash-скриптами вместо того, чтобы оформить их в Ansible-роль и использовать на всех серверах.

Мы собрали FreeIPA, Bash и Ansible в один практикум: управление инфраструктурой и рабочими станциями, чтобы инженер мог настроить централизованный доступ, автоматизировать рутину через скрипты и роли и держать всю инфраструктуру под контролем из одной точки.

Тебя ждёт:

🟢Развертывание отказоустойчивых кластеров FreeIPA и управление политиками доступа.
🟢Интеграция Linux-инфраструктуры с Active Directory через trust-отношения.
🟢Написание безопасных и отказоустойчивых Bash-скриптов для автоматизации задач.
🟢Профессиональный парсинг и обработка сложных логов с помощью sed и awk.
🟢Разработка, структурирование и тестирование Ansible-ролей с помощью Molecule.
🟢Обеспечение качества IaC-кода через статический анализ и безопасное управление секретами.

↘️ Подробная о программа

Финальный проект
Собираешь все три навыка вместе: разворачиваешь отказоустойчивый домен FreeIPA, пишешь Bash-скрипты для сбора логов и автоматизируешь рабочие станции через Ansible.

🎁 До 19 июля действует скидка 7 500 рублей для новых участников

↘️ Купить практикум со скидкой

Если ты системный администратор, DevOps-инженер или инженер инфраструктуры и хочешь навести порядок в доступах и автоматизации — этот практикум для тебя 🤍
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32
Завтра последний день — траблшутинг Nginx Reverse Proxy закрывается 15 июля.

📖 Открыли теорию: разобрали, как nginx находит upstream и откуда берётся классический 502, почему сервис не стартует с виду правильным конфигом, и как ловить OOM Killer раньше, чем это сделает продакшен.

Ещё есть время подключиться к живому серверу и починить прокси, который перестал пускать клиентов дальше себя.

🏆 Инженер, который быстрее всех решит задачу, получит любой модуль стоимостью до 30 000 рублей
🟢Среди остальных участников разыграем две годовые подписки на вебинары

↘️ Решить задачу

Эфир с разбором задачи проведем 17 июля, регистрация уже открыта: https://clck.ru/3Umgcp
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥1
Настройка kube-prometheus-stack

Развернул kube-prometheus-stack, дашборды в Grafana зелёные. Проходит неделя - и выясняется, что прод упал ещё вчера в 3 часа ночи. Метрики есть, графики зафиксировали момент, но никто не получил уведомление. Или наоборот: каждые пять минут приходит алерт о том, что под перезапустился. Команда перестаёт реагировать на оповещения, а когда случается реальная проблема - её замечают пользователи, а не инженеры.

Стандартная установка kube-prometheus-stack поставляется с сотнями предустановленных правил. Многие команды либо отключают их все из-за шума, либо оставляют как есть и тонут в бесконечном потоке уведомлений. В результате мониторинг перестаёт быть инструментом и становится источником раздражения.

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

Шаг 1️⃣ Кастомизируем правила и убираем шум

Решение начинается с осознания: мониторинг - это про то, чтобы узнать о проблеме до того, как её заметит пользователь. И для этого нужны три вещи: правильные правила, умная маршрутизация и контроль над шумом.

Начнём с правил. Оставляем пять-десять действительно важных. Каждый алерт должен иметь чёткое действие. Если на оповещение нельзя ответить действием - это не алерт, это шум.

Создаём PrometheusRule с базовым набором. Обратите внимание на алерт PodCrashLooping: вместо капризной функции rate, которая сбрасывает таймер, как только под затих, мы используем точечный фильтр по статусу CrashLoopBackOff.


apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: kubernetes-essential
namespace: monitoring
spec:
groups:
- name: kubernetes.essential
rules:
- alert: PodCrashLooping
expr: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1
for: 10m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"

- alert: NodeNotReady
expr: kube_node_status_condition{condition="Ready",status="true"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "Node {{ $labels.node }} is not ready"

- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service) /
sum(rate(http_requests_total[5m])) by (service) > 0.05
for: 10m
labels:
severity: critical
annotations:
summary: "{{ $labels.service }} has {{ $value | humanizePercentage }} error rate"



Это минимальный базовый набор. PodCrashLooping, NodeNotReady и HighErrorRate покрывают большинство критических сценариев, когда в кластере что-то ломается.

Тяжёлые запросы и Recording Rules
Если вы часто используете сложные вычисления в дашбордах, они создают высокую нагрузку на Prometheus. Используем recording rules - они вычисляют выражение один раз по расписанию и сохраняют результат как новую готовую метрику:


- name: recording.rules
rules:
- record: namespace:pod_cpu:rate5m
expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace, pod)



Теперь вместо того чтобы каждый раз нагружать CPU вычислением этого агрегата при открытии Grafana, Prometheus моментально отдаёт уже записанное значение.

Шаг 2️⃣ Настраиваем Alertmanager

Даже самые правильные алерты бесполезны, если они приходят не тем людям или в неподходящее время. Настроим Alertmanager.

Настраиваем маршрутизацию по уровню критичности (`severity`) в нативном формате Alertmanager. Критические алерты отправляем в PagerDuty, предупреждения - в Slack, а для непредвиденных ситуаций оставляем дефолтный маршрут:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
route:
group_by: ['alertname', 'namespace']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: default
routes:
- matchers:
- severity = critical
receiver: pagerduty
- matchers:
- severity = warning
receiver: slack

receivers:
- name: default
- name: pagerduty
pagerduty_configs:
- routing_key: <your-routing-key>
- name: slack
slack_configs:
- channel: '#alerts'
api_url: <webhook-url>



Важный момент - группировка. Параметр group_by: ['alertname', 'namespace'] объединяет похожие алерты в одно компактное уведомление. Вместо десяти отдельных сообщений в Slack о том, что разные поды упали в одном сис-окружении, вы получите всего одно емкое оповещение.

Также не забывайте про Inhibition rules (правила взаимоподавления). Если узел (`NodeNotReady`) стал недоступен, все алерты о падении конкретных подов на этом узле должны подавляться автоматически. Нет никакого смысла читать спам о смерти пяти контейнеров, если упал весь сервер, на котором они были запущены.

Практический план внедрения
1️⃣ Установить kube-prometheus-stack через Helm с кастомным values-файлом.
2️⃣ Отключить или переопределить избыточные стандартные правила, оставив только критический минимум. Добавить свои правила через additionalPrometheusRulesMap.
3️⃣ Настроить recording rules для тяжёлых графиков, которые выводятся на главные экраны.
4️⃣ Сконфигурировать Alertmanager: задать маршрутизацию по severity, настроить группировку и правила подавления (inhibition).
5️⃣ Подключить каналы уведомлений (`receivers`): Slack/Telegram для предупреждений, PagerDuty или Opsgenie — для ночных критических звонков.
6️⃣ Включить нотификации в тестовом режиме на пару дней и откалибровать пороги срабатывания.
7️⃣ Постепенно добавлять новые алерты, но только тогда, когда старые перестали давать ложные срабатывания.

Правильно настроенный мониторинг - это когда вы узнаёте о проблеме до того, как она повлияла на бизнес, и получаете ровно столько уведомлений, сколько ваша команда способна обработать без выгорания.

🔥Открывай демодоступы бесплатно и начинай разбираться:
🔹 Kube Prometheus Stack - полный стек мониторинга на практике: Prometheus, Alertmanager, Grafana, ServiceMonitor, PrometheusRule.
🔹 Grafana - визуализация, продвинутые дашборды, алертинг и интеграции.
🔥11
Интенсив «ИИ-агенты для инженеров» с Артуром Сапрыкиным стартует уже на следующей неделе — собрали ответы на частые вопросы и коротко рассказали, как всё будет

За 9 живых эфиров с Артуром ты разберёшь, как работают автономные coding-агенты — opencode, Aider и Cline, научишься писать собственные MCP-серверы и подключать их к внутренней инфраструктуре, настраивать связку Architect/Editor для экономии на LLM API и генерировать Helm-чарты и Kubernetes-манифесты силами агента. Отдельно разберёте изоляцию AI-процессов в Docker и защиту от Prompt Injection.

Отвечаем на вопросы 👇🏼

🟢 Какой компьютер нужен для интенсива?

Минимум: 8 GB RAM, 20 GB на диске, 4 ядра CPU (x86-64 или Apple Silicon), GPU не обязательна — большинство заданий работают на CPU-инференсе. Из ОС подойдёт macOS 12+, Windows 10/11 с WSL2 или Linux, плюс стабильный интернет для загрузки моделей и работы с облачным агентом.

Комфортный уровень: 32 GB RAM, 40+ GB на диске, 8 ядер или Apple M-series, а для локальных моделей — видеокарта NVIDIA от 8 GB VRAM или Apple M1 и новее.

🟢Нужно ли платить за подписки на нейросети отдельно?

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

🟢 Будет ли разбор безопасности?

Да, целый блок посвящён изоляции в Docker, аудиту вызовов и защите от prompt injection.

🟢 Нужен ли опыт работы с AI-агентами до старта?

Нет, интенсив рассчитан на инженеров без опыта именно с агентами. А вот базовые вещи пригодятся: Git на уровне веток и PR, Docker и контейнеризация, понимание CI/CD и Python на уровне простых скриптов.

🟢 Что если пропущу эфир?

Все эфиры записываются, записи остаются у тебя вместе с доступом к чату интенсива — можно посмотреть в своём темпе и задать вопросы Артуру и другим участникам после.

🔥По многочисленным просьбам продлили скидку 10 000 руб. На этой неделе как раз многие решили, что готовы пойти на интенсив. Чтобы дать больше времени на решение, скидка остаётся в силе до 19 июля.

📆Начало занятий — 20 июля
🎁 Скидка 10 000 руб теперь действует до 19 июля. А для участников практикума «LLM для инженеров» дополнительная скидка 3 000 руб.

↘️ Узнать подробности и занять место

✉️ Чтобы получить дополнительную скидку, напиши нашим менеджерам в телеграм, они подробно расскажут о программе и помогут с оплатой.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥52
GitLab CI + Helm: Управление микросервисами

В репозитории 30 микросервисов. Для каждого свой .gitlab-ci.yml. В каждом — по 200 строк повторяющегося кода. Обновление Helm-чарта для нового сервиса — это копирование папки, замена названий и надежда, что ничего не сломается. Деплой в dev, staging и prod — это ручное изменение values.yaml или передача параметров через --set, которые легко забыть.

Знакомая архитектура? Когда микросервисов становится больше десяти, поддержка пайплайнов превращается в отдельную работу. Разработчики начинают копировать конфиги из соседних сервисов, не вникая в детали. В результате в разных сервисах пайплайны ведут себя по-разному, а единого стандарта нет.

Helm добавляет свой слой сложности. Чарты обычно лежат в отдельном репозитории, и обновление версии чарта — это отдельный коммит, который нужно синхронизировать с изменениями кода. Без автоматизации этот процесс ручной и подвержен ошибкам.

🛠Решение - централизация через include

Мы можем вынести всю логику во внешний репозиторий с шаблонами GitLab CI и автоматически управлять версиями чартов. Создаём универсальные шаблоны для всех этапов пайплайна и переиспользуем их во всех сервисах.

Структура центрального репозитория с шаблонами (infrastructure/ci-templates):

.gitlab/
├── templates/
│ ├── build.yml
│ ├── test.yml
│ ├── deploy.yml
│ └── helm.yml
└── jobs/
├── build-job.yml
└── deploy-job.yml


1️⃣ Шаблон для сборки образа (templates/build.yml)

Используем современные правила rules:if вместо устаревших конструкций.

.build_template:
stage: build
image: docker:24.0.7
services:
- docker:24.0.7-dind
variables:
DOCKER_HOST: tcp://docker:2376
DOCKER_TLS_CERTDIR: "/certs"
DOCKER_TLS_VERIFY: "1"
# на self-managed раннере в config.toml должен быть volumes = ["/certs/client", "/cache"], иначе клиент не увидит сертификаты и джоба упадёт на TLS. На shared-раннерах GitLab.com это уже настроено.
DOCKER_CERT_PATH: "/certs/client"
script:
- echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
- docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
- docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: always


2️⃣ Шаблон для деплоя с Helm (templates/deploy.yml)

.deploy_template:
stage: deploy
image: alpine/helm:3.12.0
script:
- helm upgrade --install "$CI_PROJECT_NAME" ./chart/ \
--set image.repository=$CI_REGISTRY_IMAGE \
--set image.tag=$CI_COMMIT_SHORT_SHA \
--set environment=$DEPLOY_ENV \
--namespace $DEPLOY_ENV \
--create-namespace \
--wait \
--timeout 5m
environment:
name: $DEPLOY_ENV
url: https://$CI_PROJECT_NAME.$DEPLOY_ENV.example.com
rules:
- if: '$DEPLOY_ENV == "prod" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
when: manual
- if: '$DEPLOY_ENV == "staging" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
when: on_success


3️⃣ Как теперь выглядит .gitlab-ci.yml внутри микросервиса

Каждый сервис определяет только свои переменные и расширяет (extends) готовые джобы. Обратите внимание на обязательное объявление стадий (stages), включая стадию предварительной подготовки.

include:
- project: 'infrastructure/ci-templates'
ref: main
file: '/templates/build.yml'
- project: 'infrastructure/ci-templates'
ref: main
file: '/templates/deploy.yml'

variables:
SERVICE_NAME: $CI_PROJECT_NAME

stages:
- prepare
- build
- test
- deploy

build:
extends: .build_template

deploy_staging:
extends: .deploy_template
variables:
DEPLOY_ENV: staging

deploy_prod:
extends: .deploy_template
variables:
DEPLOY_ENV: prod
Please open Telegram to view this post
VIEW IN TELEGRAM
👍74
💡Автоматизируем работу с Helm-чартами

Вместо ручного изменения Chart.yaml используем GitLab CI для динамического вычисления версии на основе коммита.

Вариант 🔤: Если чарт лежит внутри репозитория сервиса

Добавляем джобу автоматического обновления версии перед деплоем. Для изменения YAML используем современный синтаксис утилиты yq (v4+).


update_chart_version:
stage: prepare
image: alpine:3.18
variables:
GIT_DEPTH: 0 # без этого в клоне не будет тегов для git describe
script:
- apk add --no-cache yq git
- |
RAW=$(git describe --tags --always --dirty 2>/dev/null || true)
VERSION=${RAW#v} # убираем префикс v: v1.2.3 -> 1.2.3
# если тега SemVer-вида нет (только хэш) — берём базовую версию
if ! echo "$VERSION" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+'; then
VERSION="0.0.0-${CI_COMMIT_SHORT_SHA}"
fi
echo "Chart version: $VERSION"
yq -i ".version = \"${VERSION}\"" chart/Chart.yaml
- cat chart/Chart.yaml
artifacts:
paths:
- chart/Chart.yaml



Вариант 🔤: Если чарты хранятся в отдельном общем репозитории

Настраиваем автоматический пуш обновлений в репозиторий чартов. Вместо устаревшего gitlab-ci-token для авторизации в GitLab безопаснее и актуальнее использовать oauth2.


update_helm_repo:
stage: deploy
image: alpine/git:2.40.1
script:
# HELM_CHARTS_TOKEN — Project/Group Access Token репозитория helm-charts
# со scope write_repository. Задать в Settings -> CI/CD -> Variables
# (Masked + Protected). Имя пользователя для такого токена — oauth2.
- git clone https://oauth2:${HELM_CHARTS_TOKEN}@gitlab.com/infrastructure/helm-charts.git
- cd helm-charts
- mkdir -p $SERVICE_NAME
- cp -r ../chart/* ./$SERVICE_NAME/
- git config user.email "ci@example.com"
- git config user.name "GitLab CI"
- git add .
# коммитим только при наличии изменений, чтобы не ломать пайплайн пустым коммитом
- git diff-index --quiet HEAD || git commit -m "Update $SERVICE_NAME to $CI_COMMIT_SHORT_SHA"
# -o ci.skip, чтобы пуш не запускал бесконечный пайплайн в репозитории чартов
- git push -o ci.skip origin HEAD:main
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH



📌Важно: для кросс-репозиторного пуша CI_JOB_TOKEN не подходит — он даёт клонирование и доступ к API, но не право git push в чужой репозиторий (частичная поддержка появилась только в GitLab 19.1 и требует отдельной настройки allowlist на стороне целевого репозитория). Штатное решение — Project Access Token (или Group/Deploy Token) со scope write_repository, созданный в репозитории helm-charts с ролью не ниже Developer. Токен кладётся в CI/CD-переменную HELM_CHARTS_TOKEN (Masked + Protected). Имя пользователя в URL для access-токена — oauth2 (именно gitlab-ci-token используется только с CI_JOB_TOKEN).

😎 Практический план внедрения

1. Создать отдельный репозиторий для CI-шаблонов. Вынести в него общие этапы сборки, тестирования и деплоя.
2. В каждом сервисе заменить локальный громоздкий .gitlab-ci.yml на подключение шаблонов через include.
3. Унифицировать структуру Helm-чартов во всех сервисах. Использовать общую базу для values.
4. Настроить автоматическое вычисление версии чарта на основе git-тега или хэша коммита.
5. Разделять окружения через переменные: staging деплоится автоматически, а prod — строго вручную через when: manual.

Результат: в каждом сервисе всего 20–30 строк конфигурации вместо 200. Новый сервис добавляется за 5 минут: копируется лаконичный шаблон, меняется название, запускается пайплайн. Изменения в логике деплоя теперь раскатываются на все сотни сервисов одновременно — простым обновлением центрального шаблона.

Хочешь освоить GitLab CI и Helm на практике? 🔥Открывай демодоступы бесплатно🔥:

🔹GitlabCI & Helm & Kubernetes - полный кейс: CI/CD, Helm-чарты, деплой в Kubernetes.
🔹Gitlab CI -пайплайны, артефакты, кэширование, оптимизация и интеграции.
🔹Helm - создание чартов, управление зависимостями, сложная шаблонизация.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥31
Blue Team vs Red Team. Почему защищаться сложнее, чем атаковать

Red Team эффектно закрывает отчёт: нашли SQL-инъекцию, обошли WAF, забрали Domain Admin за два часа. У Blue Team задача менее зрелищная — закрыть 47 критических уязвимостей, 12 из них в проде, и успеть до дедлайна на исправление.

Правило здесь неравное. Атакующему достаточно одной дыры, а защите нужно закрыть все. Практикум BlueTeam учит находить слабые места в инфраструктуре раньше атакующих и защищать то, что уже развёрнуто — контейнеры, Kubernetes, веб-приложения, Active Directory.

В программе:

🟢Настройка безопасного окружения Docker и runtime-мониторинга в Kubernetes с помощью Falco
🟢Автоматизация процессов Vulnerability Management и сканирования инфраструктуры с Nessus/GreenBone
🟢Анализ исходного кода и контейнеров на наличие уязвимостей в CI/CD конвейере
🟢Выявление и эксплуатация уязвимостей веб-приложений из списка OWASP Top 10
🟢Проведение аудита безопасности Active Directory, выявление векторов атак и повышение привилегий
🟢Защита инфраструктуры Active Directory

↘️ Подробнее о программе

Финальный проект

Аудит безопасности гибридной инфраструктуры целиком. Нужно просканировать уязвимости веб-приложения, настроить защиту контейнеров в K8s, найти слабые места в Active Directory и собрать отчёт с планом устранения критических угроз.

Практикум уровня Middle, 65 уроков, 240 часов практики. Понадобятся базовые навыки администрирования Linux и Windows, понимание TCP/IP, DNS и основ Docker.

🎁 До 19 июля действует скидка 10 000 рублей для новых участников

↘️ Купить практикум со скидкой

Если ты сисадмин, DevOps-инженер или начинающий специалист по ИБ и хочешь закрывать дыры быстрее, чем их находят — этот практикум для тебя 🤍
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥61
🔥Разбор задачи по траблшутингу "Nginx Reverse Proxy"

Вы её решали — кто-то справился блестяще, кто-то упёрся в стену, а кто-то нашёл неочевидный костыль и задумался: «А правильно ли я сделал?»

Сегодня, 17 июля в 19:00 МСК, мы разберем эту задачу вместе с экспертом, который покажет свой путь поиска проблемы: от первых логов до финального решения.

👨‍💻 Наш эксперт — Юрий Береговой
Senior-разработчик, совмещающий бэкенд на Java/Spring с профессиональным управлением инфраструктурой (Kubernetes, Terraform, Ansible, Jenkins, AWS/GCP) и обожающий нестандартные задачи, где прокачка идёт через реальный опыт.

На вебинаре он:
- покажет 🔥свой собственный процесс диагностики🔥 — как он читает логи, проверяет гипотезы и принимает решения;
- ответит на ваши вопросы в прямом эфире.

🎁 Бонус для участников траблшутинга
Все, кто решал задачу с 9 июня (независимо от результата), получат специальный промокод на скидку.
Просто напишите нашему менеджеру — и он отправит вам промокод. Успевайте!

🎲 И конечно, розыгрыш призов среди всех зарегистрировавшихся — участвуйте и забирайте подарки!

🗓 Когда: Сегодня = 17 июля 2026, 19:00 МСК
🔗 Регистрация обязательна

Приходите — будет не просто полезно, а по-настоящему хардкорно. Увидимся! 👀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире.

Урок называется «Основы coding-агентов: архитектура, запуск и первый ReAct-цикл». Разберём, чем автономный агент отличается от обычного автодополнения кода вроде Copilot, и почему это не одно и то же.

На занятии пройдём:

🟢что такое агент и в чём разница между уровнями автономности
🟢анатомию агента и ReAct-цикл: как он рассуждает (Reason) и действует (Act)
🟢установку и первый запуск opencode на чистой машине
🟢управление контекстным окном: лимиты, счётчики токенов, что делать при деградации контекста

После занятия ты будешь понимать архитектурные отличия автономных агентов от систем автодополнения кода, сможешь сам установить и запустить opencode в рабочем окружении и разберёшь логи tool calls в verbose-режиме, чтобы дебажить действия агента.

Практика: разворачиваешь виртуальную машину, ставишь opencode, запускаешь агента в verbose-режиме и поручаешь ему написать Python-скрипт с тестами, а потом разбираешь вывод ReAct-цикла: что агент думал и какие инструменты вызывал.

📆 До понедельника остались считаные дни. Если ещё не занял место, самое время присоединиться.

↘️ Узнать подробности и занять место
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Введение в протокол IPv6
Регистрация

Время проведения:
21 июля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢IPv6: основные теоретические сведения
🟢Виды IPv6-адресов
🟢Базовая настройка IPv6 на маршрутизаторах Cisco и Eltex

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ Для чего усложнять работу с дисками? Знакомство в LVM
Регистрация

Время проведения:
22 июля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Что такое LVM
🟢Плюсы LVM
🟢Базовая работа с LVM

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------

3️⃣ DockerCustom Image
Регистрация

Время проведения:
23 июля 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Кейсы, где свой образ реально помогает: зависимости, утилиты, сертификаты, агенты, базовые настройки
🟢Что класть в образ, а что оставить в env, secrets или runtime-конфигурации
🟢Практика: собираем свой образ, уменьшаем размер через multi-stage build и пушим в registry

Кто ведёт?
Кирилл Ряховский — практикующий DevOps-инженер с 8-летним опытом в инфраструктуре и автоматизации (Linux, K8s, CI/CD, IaC), прошедший путь от системного администратора до разработки.
Please open Telegram to view this post
VIEW IN TELEGRAM
1