DevOps by REBRAIN

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

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

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

🏁 ДЕНЬ СТАРТА: ПОГНАЛИ РЕШАТЬ! БЕСПЛАТНО! Сегодня 10 декабря! Пора закатать рукава и погрузиться в детали сломанного Systemd. Переходите на страницу траблшутинга → регистрируйтесь, если не успели → и начинайте решать! Ваша задача уже ждёт: 1. Нужно разобраться, почему Go-приложение отказывается работать как служба, хотя вручную — всё запускается. 2. Где та самая коварная строчка в конфиге? Где прячется проблема с правами или изоляцией? ❗️❗️❗️ Что делать прямо сейчас: ❗️❗️❗️ ↘Внимательно изучите условие задачи - вот прямая ссылка на задачу, если уже зарегистрировались. Все детали и подсказки уже там. ↘Приступайте к диагностике. Проверяйте логи, анализируйте юнит, тестируйте гипотезы. ↘У вас есть 5 дней — до 15 декабря включительно — чтобы найти решение и отправить его. 🔥 А 15 декабря Василий Озеров проведёт подробный разбор задачи: ✅ Покажем правильное решение и все шаги диагностики. ✅ Объясним ключевые ошибки и как их избежать. ✅ Ответим на ваши вопросы по решению. Не откладывайте! Самые интересные инсайты часто приходят в процессе глубокого копания.

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

👀 С этими 5 ошибками в GitLab CI сталкиваются все 👀 🔥Разбираем, почему они возникают и как их решать раз и навсегда Если работаешь с GitLab CI, ты точно знаешь эти боли. Вместо того чтобы гуглить каждый раз, давай разберемся, почему они случаются и как исправить их системно. 1️⃣ «Runner зарегистрирован, но джобы висят в stuck» Что происходит: Создал раннер, а пайплайн не стартует. В интерфейсе This job is stuck. Почему так: GitLab отправляет джоб только на раннеры с подходящими тегами. Если в джобе tags:[docker], а у раннера тег linux, они не встретятся. 💡Как решить: ↘ Проверь теги раннера: gitlab-runner list ↘ В .gitlab-ci.yml укажи те же теги в джобе ↘ Убедись, что раннер в статусе active (не paused) 🧠 Системный подход: Пойми механику tags как систему маршрутизации и сможешь проектировать инфраструктуру под разные типы задач. 2️⃣ Docker-in-Diner: connection refused Что происходит: Пытаешься собрать Docker-образ внутри CI, но получаешь Cannot connect to the Docker daemon. Почему так: Докер внутри контейнера (DinD) требует особых прав и переменных окружения. 💡Как решить:

services:
  - name: docker:dind
    alias: docker
    command: ["--tls=false"]
variables:
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""

↘ Плюс не забудь добавить privileged: true в конфиг раннера при регистрации. 🧠 Системный подход: Пойми разницу между изолированными окружениями и научишься выбирать подход (DinD, Kaniko, Socket) под задачу. 3️⃣«Кеш не работает, зависимости качаются каждый раз» Что происходит: Вроде настроил кеширование, но npm install или go mod download выполняются каждый раз с нуля. Почему так: Ключ кеша меняется при каждом коммите (например, $CI_COMMIT_SHA), поэтому GitLab не находит старый кеш. 💡 Как решить:

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

Для кеширования зависимостей лучше использовать хэш lock-файла:

cache:
  key: $CI_COMMIT_REF_SLUG-$CI_PROJECT_DIR/package-lock.json

🧠 Системный подход: Научись проектировать стратегии кеширования, понимать lifecycle кеша и экономить часы времени сборок. 4️⃣ Секрет случайно попал в логи Что происходит: В логах пайплайна видишь свой $DEPLOY_TOKEN или другой секрет. Почему так: GitLab не может автоматически маскировать секреты, если они попадают в stdout. 💡 Как решить: ↘ Создай переменную в Settings → CI/CD → Variables с флагами Masked и Protected ↘ Никогда не делай echo $TOKEN — вместо этого проверяй наличие: if [ -n "$TOKEN" ]; then echo "Token is set"; fi ↘Используй set -euo pipefail для отладки, но затем убирай 🧠 Системный подход: Разберись с практиками безопасной работы с секретами, поймешь, как GitLab обрабатывает переменные под капотом. 5️⃣ «У меня локально работает, а в CI падает» Что происходит: Тесты проходят на локальной машине, но в пайплайне валятся с ошибками подключения. Почему так: В CI сервисы доступны не по localhost, а по своим сетевым алиасам. 💡 Как решить:

services:
  - postgres:14
  
test:
  script:
    - PGHOST=postgres psql -U postgres -c "SELECT 1"  # не localhost!

🧠 Системный подход: Научись проектировать воспроизводимые окружения и поймешь принципы контейнерной сети в CI. ------------------------------ Эти 5 проблем — симптомы. Корень — в непонимании как GitLab CI работает изнутри. На курсе GitLab CI мы учим не просто «как исправить», а: 🔹 Предсказывать проблемы до их появления 🔹 Строить ментальную модель работы пайплайнов 🔹 Принимать инженерные решения — какой подход выбрать под задачу 🔹 Отлаживать системно — от чтения логов до анализа архитектуры Стартуем 22 декабря. Подойдет, если уже работаешь с веб-проектами и хочешь прокачать автоматизацию. До 10 декабря включительно цена 22 000 рублей потом 25 000. По ссылке можешь купить программу.

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

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

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

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

Знакомо ощущение, когда открываешь Burp Suite и теряешься в сотне вкладок? Интерфейс выглядит как кабина пилота, а времени на полноценный пентест нет. В таких случаях не пытайтесь изучить всё. Фокус на трёх ключевых функциях, которые решат большинство задач по безопасности веба — от быстрой проверки до поиска критических уязвимостей. 🎯 1. Intercept — видеть всё, что уходит в сеть Зачем: понимать, что на самом деле отправляет ваше приложение. Что делать: 1. Включите перехват (Intercept is on) 2. Выполните действие в браузере (логин, поиск) 3. Смотрите "сырой" запрос: куки, заголовки, параметры ⭐️Фишка: меняйте любые параметры на лету. Хотите проверить, что будет если передать user_id=1 вместо user_id=2? Просто отредактируйте и нажмите Forward. 🔁 2. Repeater — тестировать одну точку снова и снова Зачем: глубоко проанализировать конкретный эндпоинт. Что делать: 1. Перетащите перехваченный запрос из Intercept во вкладку Repeater 2. Меняйте параметры, заголовки, тело запроса 3. Нажимайте Send и сравнивайте ответы 💡Практический кейс: Проверка на SQL-инъекцию. Добавляете ' или " в параметры и смотрите — не вернулась ли ошибка базы данных в ответе? ⚡ 3. Active Scan — автоматический поиск уязвимостей Зачем: пусть Burp поработает за вас, пока вы занимаетесь другими задачами. Что делать: 1. Кликните правой кнопкой по запросу в Proxy → Send to Scanner 2. Выберите Active Scan 3. Через 10-15 минут проверьте вкладку Dashboard → Issue activity 🔥 Что найдёт: XSS, SQLi, уязвимые заголовки, проблемы с CORS, пути к файлам — всё, что можно обнаружить автоматически. 📌 Краткий алгоритм на 10 минут: 1️⃣ Настройте прокси в браузере на 127.0.0.1:8080 2️⃣ Включите Intercept, сделайте действие в приложении 3️⃣ Изучите запрос — нет ли в нём чувствительных данных 4️⃣ Отправьте в Repeater подозрительные эндпоинты 5️⃣ Запустите Active Scan на самый интересный запрос Этих трёх инструментов достаточно, чтобы провести базовую проверку безопасности за чашку кофе☕️. Burp Suite — это не только для хакеров, это практичный Swiss Army Knife для инженера, который хочет быть уверен в своём коде. P.S. Хотите не просто пользоваться инструментами, а понимать, как искать уязвимости системно? Наш курс по безопасности веб-приложений — это не про запоминание кнопок в Burp, а про мышление пентестера. Старт: 22 декабря А какими функциями Burp Suite пользуетесь вы чаще всего?

❗️ВАЖНО ДЛЯ СТУДЕНТОВ КУРСА WHITE HACKING❗️ Если ты уже покупал наш практикум "White Hacking", то модуль "Безопасность веб приложений OWASP10" будет для тебя бесплатным. Чтобы получить доступ: 🔰 просто напиши в поддержку на info@rebrainme.com с темой «Доступ к OWASP10, студент White Hacking» 🔰 в письме укажи email, на который зарегистрирован твой ЛК 🔰 мы откроем модуль в твоём кабинете

Хей, ребята! 🖖 Часто вижу в проектах JWT как стандарт для аутентификации. Токен есть, но мало кто смотрит, насколько он действительно защищён. 😳 А зря 😳 Потому что типовые ошибки в JWT — это прямая дорога к компрометации аккаунтов. Не верите? Давайте проверим ваш токен прямо сейчас. 📌 Шаг 1: Смотрим, что внутри JWT состоит из трёх частей: header.payload.signature. Просто вставьте свой токен на сайт jwt.io или в расширение DevTools — и сразу увидите: 1️⃣ Алгоритм подписи (alg) 2️⃣ Данные пользователя (payload) 3️⃣ Срок действия (exp) 📌 Шаг 2: Ищем опасные признаки 1️⃣ Алгоритм "none" — самая грубая ошибка. Если в header видите "alg": "none", токен можно подделать, просто удалив подпись. 2️⃣ Слабый секрет — если ключ подписи простой (типа "secret123"), его можно подобрать брутфорсом. Проверить можно через hashcat или онлайн-инструменты. 3️⃣ Отсутствие проверки alg — сервер может принимать любой алгоритм. Попробуйте сменить RS256 на HS256 в header — иногда это срабатывает. 📌 Шаг 3: Практика в Burp Suite 1️⃣ Перехватите запрос с токеном в Burp 2️⃣ Отправьте токен в Decoder 3️⃣ Модифицируйте payload (например, поменяйте "user": "user" на "user": "admin") 4️⃣ Если подпись не проверяется — вы только что нашли уязвимость Что делать, если нашли проблему? ↘ Никогда 🚫 не используйте алгоритм "none" в продакшене ↘ Генерируйте сложные секреты длиной от 32 символов ↘ Всегда проверяйте алгоритм подписи на сервере ↘ Используйте короткое время жизни токенов (exp) ⚠️P.S. Эта проверка — только верхушка айсберга⚠️ Если хотите не просто находить уязвимости, а понимать их природу и думать как атакующий — смотрите наш практический курс по безопасности веб-приложений. На курсе разберём: 🔹 Полный цикл пентеста — от разведки до отчёта 🔹 Все уязвимости OWASP Top 10 на реальном стенде OWASP Juice Shop 🔹 Работу с Burp Suite на продвинутом уровне 🔹 Методы защиты на уровне архитектуры, а не просто "заплатки" 🗓Старт: 22 декабря Подробная программа Проверили свой токен? 🔍

GitOps и пароли: как хранить секреты в репозитории и не скомпрометировать кластер? 🔐 Знакомо: хотите хранить конфигурацию в Git, но пароли от БД, API-ключи и TLS-сертификаты держать там страшно. Ручное создание kubectl create secret ломает принцип GitOps. Решение — Sealed Secrets от Bitnami. Суть: вы шифруете секрет локально специальным ключом, а в Git кладёте уже зашифрованный манифест. Расшифровать его может только ваш кластер. 3 шага к безопасности: 1️⃣ Установка оператора в кластер

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.1/controller.yaml

2️⃣ Шифрование секрета локально Устанавливаем утилиту kubeseal, создаём обычный Secret и шифруем его:

echo -n "mysecretpassword" | kubectl create secret generic db-pass --dry-run=client --from-file=password=/dev/stdin -o yaml > secret.yaml
kubeseal --scope cluster-wide -f secret.yaml -o sealedsecret.yaml

3️⃣ Применение в GitOps Полученный sealedsecret.yaml безопасно пушим в репозиторий. Argo CD или Flux применяют его, и контроллер в кластере автоматически расшифровывает его в обычный Kubernetes Secret. Что внутри sealedsecret.yaml :

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-pass
spec:
  encryptedData:
    password: AgBv2n4H1LiV+8O7X...
# Расшифровать можно только вашим кластером

Почему это безопасно? 🔑 Приватный ключ для расшифровки никогда не покидает кластер 🔒 В Git летит только шифр — даже при утечке репозитория данные защищены 🔄 Полная совместимость с GitOps: Secret создаётся автоматически при деплое Когда выбрать Sealed Secrets: 🔹 Нужен простой и самодостаточный инструмент 🔹 Нет доступа к Vault или AWS Secrets Manager 🔹 Хотите минимальную инфраструктуру для управления секретами Когда смотреть в сторону External Secrets Operator: 🔸 Уже используете HashiCorp Vault / AWS Secrets Manager 🔸 Требуется ротация секретов без передеплоя приложений 🔸 Нужна централизованная аудитория доступа Итог: Sealed Secrets — элегантный мост между безопасностью и GitOps-практиками. Позволяет хранить всё в Git, не оставляя секреты в plain text. На курсе Argo CD разбираем не только Sealed Secrets, но и интеграцию с Vault через AVP, работу с External Secrets Operator и паттерны разделения доступа. Учим не просто инструменты, а стратегии безопасности для production. 💡 Полезно? Если да, то ставь 🔥

Привет! 👋 Знакомо: делаешь новую фичу в отдельной ветке, а проджект или тестировщик просит: «А можно 👀глянуть👀 вживую?». И начинается ад: 🔹«Подними на тестовом» → нужно мержить, конфликты, ждать 🔹«Дай доступ к локальному» → настраивать окружение, порты, зависимости 🔹«Скинь скриншоты» → не показывает реальное поведение 🔥 Есть способ лучше 🔥 Review Apps в GitLab — это временные окружения, которые создаются автоматически для каждой ветки и умирают после мержа. Как облачный стенд, который живет ровно столько, сколько нужно. Вот как это настроить. Без магии, просто копируй:

review:
  stage: deploy
  script:
    - echo "Деплоим ветку $CI_COMMIT_REF_SLUG на временный сервер"
    # Твои команды деплоя (kubectl, docker-compose, ansible)
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.your-app.com
    on_stop: stop_review  # что запустить при удалении
  rules:
    - if: $CI_MERGE_REQUEST_ID  # Только для MR

stop_review:
  stage: cleanup
  script:
    - echo "Удаляем окружение review/$CI_COMMIT_REF_SLUG"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual  # или automatic для автоудаления

💡Что происходит: 1️⃣ Создаешь Merge Request → пайплайн сам поднимает окружение 2️⃣В MR появляется кнопка с ссылкой на твое живое приложение 3️⃣ После мержа (или вручную) окружение автоматически чистится Зачем это тебе: • Показываешь работу клиенту/ПМ/тестировщику без лишних телодвижений • Тестируешь в реалистичных условиях, а не «на локалке» • Экономишь ресурсы — окружения живут только когда нужны • Автоматизируешь рутину — не нужно руками что-то поднимать и чистить Это не сложно. Если уже умеешь деплоить приложение (хоть в Docker, хоть на сервер), то добавить Review Apps — дело 15 минут ⏰ конфигурации. А если хочешь научиться не просто копировать конфиги, а понимать как проектировать такие пайплайны — приходи на курс по GitLab CI. Научим делать не только Review Apps, но и полноценные staging/prod окружения с безопасностью и мониторингом. Если было полезно, то ставь 🔥

Ищем двух смелых DevOps-инженеров, которые готовы показать свой скилл на реальном техническом интервью — в открытом формате. 👀 Что это значит? 🔹 Вы проходите собеседование на вакансию Middle/Senior DevOps в проект Магнит Tech 🔹 Всё происходит в на закрытом вебинаре в zoom с аудиторией 🔹 Зрители — наше комьюнити 🔹 Вы получаете обратную связь после собеседования 🏆Для кого это крутая возможность: 🔸Хотите попасть в сильную команду Магнит Tech 🔸Не боитесь сложных технических вопросов 🔸Готовы показать экспертизу вживую 🔸Хотите получить максимум фидбека за одно собеседование 📝 Что ждёт на собеседовании: Разбор реальных кейсов Архитектурные задачи по построению отказоустойчивых кластеров Практические вопросы по мониторингу и автоматизации Обсуждение подходов к документации и взаимодействию с заказчиками Что вы получаете: ✅ Прозрачный процесс собеседования ✅ Профессиональную обратную связь ✅ Новые контакты в индустрии ✅ Уважение комьюнити за смелость 📌 Как участвовать? Напишите в tg @fleurkaraman краткое intro: - Почему хотите именно открытый формат - Ссылку на ваше резюме Прием заявок открыт до 10 декабря включительно. Чтобы вебинар был максимально полезным для всех, мы проведём два живых собеседования: с инженером уровня Middle и уровня Senior. Самым подходящим кандидатам вышлем приглашение и детали 12 декабря! Это шанс не просто пройти собеседование 💪 P.S. Поставьте 🔥 - если интересен такой формат и будете ждать этот веб 🙁 - совсем не интересны открытые собесы

Привет! 👋 Тот момент, когда делаешь коммит и идешь пить кофе☕️, потому что пайплайн будет идти 15 минут ⌛ — знакомо? 🚴‍♂️Скорость CI — это не просто цифры. Это твое время, фокус и нервные клетки. Медленный пайплайн убивает поток, заставляет контекстно переключаться и просто бесит. В 90% случаев тормоза — из-за неправильного кеширования. Не тех зависимостей, не там и не так. 💡 Вот как это исправить за 5 минут: 1️⃣ Раздели кеш для зависимостей и сборки

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/  # или .m2/, vendor/ и т.д.
  policy: pull-push  # загружаем И обновляем

2️⃣ Используй разные ключи для разных веток

variables:
  CACHE_KEY: $CI_COMMIT_REF_SLUG

cache:
  key: ${CACHE_KEY}
  paths:
    - .gradle/caches/

3️⃣ Настрой политику pull для тестов

test:
  stage: test
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
    policy: pull  # только загружаем, не обновляем!
  script:
    - npm test

Почему это работает: • Зависимости скачиваются один раз, а не на каждом запуске • pull-push на этапе сборки обновляет кеш при изменении зависимостей • pull на этапе тестов экономит время на запись кеша Простой чек-лист для твоего пайплайна: ✅ Зависимости кешируются отдельно от артефактов ✅ Используешь policy: pull где можно ✅ Ключ кеша учитывает версии зависимостей (например, хэш package-lock.json) А если хочешь по-настоящему глубоко разобраться в кешировании, артефактах и оптимизации пайплайнов — приходи практиковаться наш курс по GitLab CI. Там разбираем не только лайфхаки, но и как проектировать пайплайны, которые не тормозят с самого начала. Оставим ссылку на покупку со скидкой 3000 рублей. Она действует до 9 ноября. Твой пайплайн все еще идет 15 минут?

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

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