💡Автоматизируем работу с 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 - создание чартов, управление зависимостями, сложная шаблонизация.

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-инженер или начинающий специалист по ИБ и хочешь закрывать дыры быстрее, чем их находят — этот практикум для тебя 🤍

🔥Разбор задачи по траблшутингу "Nginx Reverse Proxy"

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

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

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

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

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

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

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

Приходите — будет не просто полезно, а по-настоящему хардкорно. Увидимся! 👀

В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире.

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

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

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

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

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

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

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

🟡 Анонс открытых практикумов на следующую неделю

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), прошедший путь от системного администратора до разработки.

Анализ логов в реальном времени: От syslog до EFK с фильтрацией

Приложение упало в 2 часа ночи. Разработчик пишет в чат: «Смотри логи». Ты заходишь на сервер, выполняешь kubectl logs — но под уже перезапустился, и логи пропали. В классической инфраструктуре мы привыкли полагаться на локальный syslog или journald, но когда логи разбросаны по десяти разным хостам или сотне эфемерных контейнеров, поиск ошибки превращается в лотерею. Открывать каждую машину по SSH и на ощупь перебирать файлы ротируемых логов с помощью grep и awk — тупиковый путь. Найти баг, который произошел строго между 23:00 и 23:05 на конкретном эндпоинте, в таких условиях практически невозможно.

Централизованный сбор логов решает эти проблемы раз и навсегда. В классическом стеке EFK (Elasticsearch, Fluentd, Kibana) обязанности разделены максимально эффективно:

🔹 Fluentd — собирает, парсит и фильтрует данные;
🔹 Elasticsearch — хранит и индексирует их;
🔹 Kibana — дает удобный UI для поиска и аналитики.

Шаг 1️⃣ Настройка Fluentd и фильтрация

Fluentd запускается как DaemonSet в Kubernetes или как агент на хостах. Он собирает стандартный вывод контейнеров или читает системные файлы.

Вот базовый конфиг, который собирает логи Nginx, парсит их «на лету» и фильтрует, отсекая лишние успешные запросы (200 OK), чтобы не забивать хранилище:

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/nginx/access.log.pos
  tag nginx.access
  <parse>
    @type nginx
  </parse>
</source>

# Фильтруем: исключаем из отправки логи со статус-кодом 200
<filter nginx.access>
  @type grep
  <exclude>
    key code
    pattern /^200$/
  </exclude>
</filter>

<match nginx.access>
  @type elasticsearch_data_stream
  host elasticsearch-service
  port 9200
  # пишем в data stream, а не в датовый индекс. только так работает ILM-rollover
  data_stream_name nginx-logs
  data_stream_template_name nginx-logs
  data_stream_ilm_name logs-policy
  <buffer>
    flush_interval 5s
  </buffer>
</match>

Если приложение сыплет многострочными ошибками (стектрейсами), обычный tail разобьет их на отдельные строки. Чтобы этого не произошло, настраиваем мультилайн-парсер:

<parse>
  @type multiline
  format_firstline /^\d{4}-\d{2}-\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3}) (?<level>[A-Z]+) (?<message>.+)/
</parse>

Для контейнеров обязательно включаем обогащение метаданными Kubernetes. Это добавит в каждый лог контекст: namespace, имя пода и лейблы.

<filter kubernetes.**>
  @type kubernetes_metadata
</filter>

Шаг 2️⃣ Оптимизация Elasticsearch (ILM)

Без управления индексами Elasticsearch быстро съест весь диск, а поиск станет невыносимо медленным. Настраиваем Index Lifecycle Management (ILM) политику, чтобы вовремя перемещать старые данные на дешевые диски и удалять их:

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "0ms",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

PUT _index_template/nginx-logs
{
  "index_patterns": ["nginx-logs*"],
  "data_stream": {},
  "priority": 200,
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-policy",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

🎁 До -30% на ВСЕ практикумы в честь грядущего дня сисадмина

У нас в Rebrain это уже традиция на день сисадмина устраивать распродажи. В этот раз скидка до 30% будет действовать до 28 июля, 23:59 мск. Если давно поглядываешь на практикум и ждёшь повод — вот он.

Самые популярные практикумы сейчас:

🟢 DevOps-инженер [ экономия 48 000 ₽ ]
🟢 Системный администратор [ экономия 40 200 ₽ ]
🟢 Linux Basics [ экономия 22 500 ₽ ]
🟢 Kubernetes (Base + Admin) [ экономия 34 500 ₽ ]
🟢 Linux Advanced [ экономия 27 000 ₽ ]
🟢 Прикладной LLM для инженеров [ экономия 19 500 ₽ ]
🟢 Linux: Анализ производительности и тюнинг [ экономия 9 000 ₽ ]
🟢 Повышение привилегий в Linux [ экономия 7 500 ₽ ]
🟢 Zabbix [ экономия 9 000 ₽ ]
🟢 Container Security [ экономия 9 000 ₽ ]
🟢 Proxmox [ экономия 9 000 ₽ ]
🟢 Patroni [ экономия 9 000 ₽ ]

Скидки действуют и на остальные программы, полный список доступен на платформе или на нашем сайте🤍

К большинству практикумов есть демодоступ: можно попробовать бесплатно и понять, подходит ли программа.

↘️ Смотреть все практикумы со скидкой

⌚Распродажа будет проходить до 28 июля. Сейчас отличный момент, чтобы разобраться в Kubernetes, подтянуть Linux или освоить новые технологии 🤍

🎁 А при полной оплате скидка увеличивается до 35% - это самый выгодный вариант. Промокод на дополнительную скидку можно запросить у нашего менеджера в телеграм.

Показываем фрагмент первого эфира интенсива «ИИ-агенты для инженеров» с Артуром Сапрыкиным 👀

На видео база, без которой дальше никуда: как LLM вызывает инструменты read, search, shell, edit и git, и что модель получает на каждом шаге: задачу, файлы, историю, результаты вызовов. Отдельно разобрали permissions и compaction: они защищают проект от опасных действий и не дают контексту разрастись до бесконечности.

Дальше больше 🔥

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

↘️ Присоединиться к интенсиву

Настройка Network Policies в Kubernetes для изоляции сервисов

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

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

Network Policies решают эту проблему. Это механизм, который позволяет определить, какие поды могут общаться друг с другом, а какие - нет. NetworkPolicy работает на уровне L3/L4 (IP/порты) и фильтрует входящий (`ingress`) и исходящий (`egress`) трафик.

Важный нюанс: NetworkPolicy - это API-объект, спецификацию которого должен принудительно исполнять ваш CNI-плагин. Cilium и Calico - поддерживают политики из коробки. Популярный Flannel - нет. Если CNI не поддерживает NetworkPolicy, вы можете создать сколько угодно таких объектов, но они просто будут игнорироваться.

Первым делом проверяем, какой CNI управляет сетью:

kubectl get pods -n kube-system -l k8s-app=calico-node
# или проверяем наличие Cilium
kubectl get pods -n kube-system -l app.kubernetes.io/name=cilium-agent

1️⃣Главный принцип: Deny by Default
Основной подход при работе с Network Policies - deny by default, allow explicitly (запрещено по умолчанию, разрешено только явно). Вместо того чтобы пытаться точечно блокировать опасные направления, мы сначала закрываем вообще всё, а затем аккуратно открываем нужные доступы.

Создаём политику, которая полностью блокирует весь входящий и исходящий трафик для всех подов в неймспейсе production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # Пустой селектор выбирает ВСЕ поды в данном неймспейсе
  policyTypes:
  - Ingress
  - Egress

podSelector: {} указывает, что правило применяется ко всем без исключения подам в неймспейсе production. А пустые блоки ingress и egress (так как мы их не описали ниже) означают полный запрет.

После применения этой политики поды в production оказываются в полной изоляции. У них перестают работать даже DNS-запросы, потому что это тоже исходящий (`egress`) трафик. Исправляем это.

Шаг 2️⃣: разрешаем DNS-резолв
Добавляем политику, которая позволит подам отправлять DNS-запросы к CoreDNS. Без этого приложения не смогут разрешить имена соседних сервисов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {} # Применяется ко всем подам в production
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
         matchLabels:
           k8s-app: kube-dns

    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Здесь мы используем встроенный системный лейбл kubernetes.io/metadata.name: kube-system. Он автоматически присваивается неймспейсам в Kubernetes, что избавляет нас от необходимости маркировать kube-system вручную. PodSelector позволяет задать конкретный поды с dns и открыть трафик только к ним.


Шаг3️⃣: точечный доступ (Связываем Frontend и Backend)
Теперь разрешаем нашему фронтенду обращаться к бэкенду. Нам нужно настроить Ingress-правило для бэкенда:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080