DevOps by REBRAIN

🎁 До -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 или освоить новые технологии 🤍

Теперь связка работает так: шаблон объявляет data stream nginx-logs и вешает на его бэкинг-индексы политику logs-policy. Как только первичный шард достигает 50 ГБ или индексу исполняется 7 дней, ILM выполняет rollover создаёт новый бэкинг-индекс и переключает запись на него. Отсчёт min_age в каждой фазе идёт от момента rollover: сразу после него старый индекс уходит в warm-фазу и сжимается в один сегмент, а через 90 дней удаляется. Первый бэкинг-индекс создаётся автоматически при первой записи в data stream, бутстрапить его вручную не нужно. 😎 Практический план внедрения 1. Развернуть Fluentd как DaemonSet (для K8s) или системный сервис (для VM). 2. Настроить парсинг и фильтрацию под форматы ваших приложений (JSON, Nginx, Multiline для Java/Python стектрейсов). 3. Включить обогащение метаданными, чтобы привязать логи к окружению. 4. Настроить кластер Elasticsearch и сразу применить ILM-политики для ротации. 5. Подключить Kibana и вывести ключевые метрики на дашборды (кол-во 5xx ошибок, топ падений по сервисам). 6. Настроить алертинг (через Elastic Alerting или ElastAlert) на критические маркеры вроде OutOfMemoryError. В результате разбор инцидента силами дежурного инженера сокращается с нескольких часов поиска по серверам до пары кликов в Kibana. Чтобы освоить централизованный сбор и анализ логов на практике, включая работу с мультилайн логами, обогащение метаданными и настройку производительности Elasticsearch - 🔥открывай демодоступы бесплатно🔥 и начинай погружаться в технологию: 🔹EFK - полный стек: Elasticsearch, Fluentd, Kibana, настройка, оптимизация 🔹Logs - работа с логами в Linux, syslog, journald, ротация 🔹Docker - логи контейнеров, драйверы логирования

Анализ логов в реальном времени: От 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
    }
  }
}

🟡 Анонс открытых практикумов на следующую неделю 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), прошедший путь от системного администратора до разработки.

❗ Открытый практикум Разбор задачи «Nginx Reverse Proxy Hardcore» идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/512 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Разбор задачи «Nginx Reverse Proxy Hardcore» уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/512 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум Разбор задачи «Nginx Reverse Proxy Hardcore» начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире. Урок называется «Основы coding-агентов: архитектура, запуск и первый ReAct-цикл». Разберём, чем автономный агент отличается от обычного автодополнения кода вроде Copilot, и почему это не одно и то же. На занятии пройдём: 🟢что такое агент и в чём разница между уровнями автономности 🟢анатомию агента и ReAct-цикл: как он рассуждает (Reason) и действует (Act) 🟢установку и первый запуск opencode на чистой машине 🟢управление контекстным окном: лимиты, счётчики токенов, что делать при деградации контекста После занятия ты будешь понимать архитектурные отличия автономных агентов от систем автодополнения кода, сможешь сам установить и запустить opencode в рабочем окружении и разберёшь логи tool calls в verbose-режиме, чтобы дебажить действия агента. Практика: разворачиваешь виртуальную машину, ставишь opencode, запускаешь агента в verbose-режиме и поручаешь ему написать Python-скрипт с тестами, а потом разбираешь вывод ReAct-цикла: что агент думал и какие инструменты вызывал. 📆 До понедельника остались считаные дни. Если ещё не занял место, самое время присоединиться. ↘️ Узнать подробности и занять место

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - Разбор задачи «Nginx Reverse Proxy Hardcore» 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

🔥Разбор задачи по траблшутингу "Nginx Reverse Proxy" Вы её решали — кто-то справился блестяще, кто-то упёрся в стену, а кто-то нашёл неочевидный костыль и задумался: «А правильно ли я сделал?» Сегодня, 17 июля в 19:00 МСК, мы разберем эту задачу вместе с экспертом, который покажет свой путь поиска проблемы: от первых логов до финального решения. 👨‍💻 Наш эксперт — Юрий Береговой Senior-разработчик, совмещающий бэкенд на Java/Spring с профессиональным управлением инфраструктурой (Kubernetes, Terraform, Ansible, Jenkins, AWS/GCP) и обожающий нестандартные задачи, где прокачка идёт через реальный опыт. На вебинаре он: - покажет 🔥свой собственный процесс диагностики🔥 — как он читает логи, проверяет гипотезы и принимает решения; - ответит на ваши вопросы в прямом эфире. 🎁 Бонус для участников траблшутинга Все, кто решал задачу с 9 июня (независимо от результата), получат специальный промокод на скидку. Просто напишите нашему менеджеру — и он отправит вам промокод. Успевайте! 🎲 И конечно, розыгрыш призов среди всех зарегистрировавшихся — участвуйте и забирайте подарки! 🗓 Когда: Сегодня = 17 июля 2026, 19:00 МСК 🔗 Регистрация обязательна Приходите — будет не просто полезно, а по-настоящему хардкорно. Увидимся! 👀

❗ Открытый практикум IPTables-2 идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/503 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума IPTables-2 уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/503 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум IPTables-2 начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

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

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - IPTables-2 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

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

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

❗ Открытый практикум RAID-массивы идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/497 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума RAID-массивы уже через 5 минут Встречаемся в 20:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/497 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум RAID-массивы начнётся сегодня в 20:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате