Devops Bootcamp с Федосеевым

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🎉 Розыгрыш завершен!

🏆 Победители:
1. @WolkStt

🔍 Проверить результаты

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

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

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

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

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

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

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

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

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

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

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

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

Слёрм разыгрывает бесплатную консультацию - 30 минут с Анисой Рогатовой, Senior ИТ-рекрутером в финтехе (опыт в OZON, Банке Точка, SkillFactory, спикер HR API и INDEX)

На консультации:
🔴Разберёте ваше резюме по косточкам — что убрать, что усилить
🔴Получите конкретные правки под вашу цель, а не общие советы
🔴Получите ответы на карьерные вопросы: от интервью до дальнейшего роста

Условия просты:
➡️Нужно подписаться на канал - @devopsupgrade
➡️Нажать кнопку «УЧАСТВОВАТЬ»

8 сентября бот случайным образом определит победителей

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

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

Приглашаю вас на вебинар на тему: «Разбор реальных вакансий Junior DevOps»⚡️

Спикеры:
🔴Аниса Рогатова — Senior ИТ-рекрутер в финтехе (OZON, Банк Точка, SkillFactory)
🔴Евгений Федосеев — DevOps-инженер в «Пульс АЙТИМ», 5+ лет в DevOps, выпускник курса «Профессия DevOps-инженер»

Что будет на вебинаре:
⏩Живой разбор реальных вакансий Junior DevOps — что стоит за каждым требованием
⏩Что на самом деле означает «знание K8s» для джуна (сложное — простыми словами)
⏩Зарплатную вилку:
как конкретные навыки конвертируются в цифры оффера.
⏩Как презентовать себя на собеседовании, чтобы вас увидели как готового специалиста
⏩Как пройти техническое собеседование с тех лидом — рабочие советы и лайфхаки

🔴Когда: 1 сентября, 19:00 по мск
🔴Запись на вебинар ➡️ по этой ссылке

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

Сегодня поговорим о том, как быстро перенести индекс Elasticsearch между кластерами без S3.
Недавно при переезде на новый кластер Elasticsearch понадобилось перенести только несколько индексов. Казалось бы, задача простая: перенести документы — и готово. Но индекс в Elasticsearch - это не только документы. Есть ещё mapping, settings, aliases и другие метаданные.

Самый правильный вариант - Snapshot/Restore
Для полноценного переноса Elasticsearch предоставляет механизм Snapshot/Restore. Snapshot можно хранить во внешнем repository, например в S3, а затем восстановить на другом кластере.

Документация:
Snapshot and Restore
S3 repository
Это хороший вариант, когда инфраструктура уже готова. Но что делать, если доступ к S3 нужно ещё получить, а индексы нужны буквально «вчера»?

Reindex — быстрый перенос документов
В Elasticsearch есть API _reindex, который позволяет скопировать документы из одного индекса в другой. Он также поддерживает перенос из удалённого Elasticsearch-кластера.

Простейший вариант:

POST /_reindex
{
  "source": {
    "index": "old-index"
  },
  "dest": {
    "index": "new-index"
  }
}

Документация: Reindex API
Но здесь есть важный нюанс.
_reindex переносит документы, но не переносит mapping и settings исходного индекса.

Поэтому целевой индекс нужно подготовить до запуска reindex.
Сначала mapping, потом документы
Получить mapping исходного индекса можно так:

GET /old-index/_mapping

Документация: Get mapping
После этого создаём индекс на новом кластере с нужным mapping:

PUT /new-index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "keyword"
      },
      "age": {
        "type": "integer"
      }
    }
  }
}

Это важно, потому что если создать пустой индекс без нужного mapping, Elasticsearch может применить dynamic mapping при первой индексации документов. В результате типы полей могут отличаться от исходного индекса.
При создании индекса можно сразу задать settings, mappings и aliases: Create index API.

И не забываем про aliases
Ещё одна частая ошибка — перенести документы и забыть про aliases.

Например, приложение работает с:

users

а на самом деле это alias, указывающий на:

users-2026-08

Получить aliases можно через:

GET /old-index/_alias

После переноса их необходимо создать на новом индексе.

Например:

PUT /new-index/_alias/users

Или использовать _aliases, если нужно одновременно удалить alias со старого индекса и добавить его на новый:

POST /_aliases
{
  "actions": [
    {
      "remove": {
        "index": "old-index",
        "alias": "users"
      }
    },
    {
      "add": {
        "index": "new-index",
        "alias": "users"
      }
    }
  ]
}

Это удобно при production-миграции: приложение продолжает обращаться к тому же alias, а мы просто переключаем его на новый индекс.

Документация: Aliases API
Можно автоматизировать
Если индексов много или не хочется писать всё вручную, можно использовать elasticsearch-dump.
Инструмент позволяет отдельно переносить data, mapping, alias, settings, analyzer и другие сущности.
elasticsearch-dump на GitHub

Например:

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=mapping

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=data

Это уже можно завернуть в обычный Bash-скрипт и автоматизировать миграцию.

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

Делюсь фрагментом нашего эфира про путь DevOps-инженера. Говорили о наболевшем: почему компетенции, наработанные на российском рынке, постепенно теряют ликвидность за его пределами, и что с этим делать.

Разобрали, как выстраивать свою квалификацию с учётом этого фактора, и какой стек выбирать — если ориентируетесь на РФ, а если смотрите в сторону зарубежных проектов.

Думаю, будет полезно всем, кто задумывается о своём развитии в DevOps.

Смотрите запись эфира полностью здесь ➡️ смотреть

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

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

Вместе с Кириллом старшим инженером по практикам DevOps в Фланте, разобрали 4 базовые модели ветвления, обсудили их плюсы и минусы, а на практическом примере показали, как выбор модели определяет требования к CI/CD-пайплайну.

⏩Отдельное спасибо всем участникам — вопросов было много, обсуждение получилось живым и по делу

Если пропустили эфир или хотите пересмотреть — запись уже доступна:
➡️ ВК - https://vkvideo.ru/live-59405817_456240151
➡️ Ютуб - https://www.youtube.com/live/rAiE8mfRPEk?si=RbUYMj5GgT9p5k4I

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

Проверка работ на грант по курсу «Профессия DevOps-инженер» завершена — результаты уже готовы!

Более 400 человек подали заявки на грант, и выбор победителей дался нам совсем не просто. В итоге определили троих:
⚡️Скидка 100%
Назипов Даниил daniil.nazipov2001@yandex.ru

⚡️Скидка 50%
Романенко Дмитрий mr.komorka@gmail.com

⚡️Скидка 30%
Корнилов Александр kornilov.it@gmail.com

Поздравляем! Скоро с вами свяжется менеджер и расскажет о дальнейших шагах.

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

Не пропустите, с вами свяжутся в ближайшее время🔥

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

Сегодня настроение порассуждать о достаточно общих вещах. Насколько вы в жизни и работе позволяете себе делать что-то не по плану, а действовать по ситуации?

🔴Мне кажется, работа инженера подразумевает, что необходимо опираться на чёткие планы работ. Например, план резервного копирования тут надо вставить шутку про тех, кто делает бекапы, но ещё не проверяет или даже в целом план восстановления инфраструктуры. Я, например, не очень люблю на каждое действие писать отдельный план, но без чётких планов, кажется, нельзя. Сразу возникает идея составлять целое руководство администратора системы, но качественно получается так не всегда. Описывать как код — хороший приём, и это тоже добавляет прозрачности. Но это всё про работу.

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

А может, на самом деле всё в любом случае запланировано❓

Коллеги, мы в эфире!

Ждем вас по ссылкам:
➡️ВК - https://vkvideo.ru/live-59405817_456240151

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

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

Напоминаю, сегодня в 19:00 мск пройдет вебинар на тему: «Модели ветвления и их влияние на CI/CD-пайплайн»⚡️

Со мной в эфире:
🔴Кирилл Юденок — старший инженер по практикам DevOps, Флант

Расскажем:
⏩Что такое модель ветвления и почему это не «просто про git»
⏩Зачем нужны модели ветвления (и почему без них плохо)
⏩Историю одного проекта — от "push" в main до выстроенного процесса
⏩4 базовые модели: схемы, плюсы, минусы — без воды
⏩Как выбранная модель ветвления определяет требования к CI/CD-пайплайну — на примере из практики

Успейте зарегистрироваться до старта ➡️ в боте

Встретимся в эфире!

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

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

Как мы разбирали уже ранее - есть условия переменных и при выборе окружения будет возможность выбрать стенды только внутри этого окружения, но теперь добавим еще разные типы, проверяем поля и так мы убедимся, что запуск пайплайна не упадет из-за некорректных данных указанных при запуске

  inputs:
    environment:
      description: "Target environment"
      options: ["test", "stage", "prod"]
      default: "test"

    landscape:
      description: "Target stand"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["my-prod01", "my-prod02"]
          default: "my-prod01"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["my-stage01", "my-stage02"]
          default: "my-stage01"
        - options: ["my-test01", "my-test02", "sandbox01"]
          default: "my-test01"

    playbook:
      description: "Playbook to run"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["deploy", "check", "rollback"]
          default: "check"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["deploy", "check", "rollback", "smoke", "migrate"]
          default: "deploy"
        - options: ["first_playbook", "deploy", "check", "smoke", "migrate", "debug"]
          default: "first_playbook"

    mode:
      description: "Execution mode"
      options: ["apply", "check", "diff"]
      default: "apply"

    limit_hosts:
      description: "Optional ansible --limit"
      default: ""
      regex: '^$|^[A-Za-z0-9_.:,-]+$'

    forks:
      description: "Ansible forks"
      type: number
      default: 10

    gather_facts:
      description: "Enable gather_facts"
      type: boolean
      default: true

    verbose:
      description: "Enable -vvv"
      type: boolean
      default: false

    confirmation:
      description: "Type APPROVE for production apply"
      default: ""

Для числовых знаний поставим type: number и boolean когда просто выбираем true/false что-бы не писать это текстом - можно и ошибиться.

Получаем основные поля - выбираются из предложенных вариантов. Число в специальном поле и переключатели там где это уместно. Остается пару полей с строкой - в данном случае это для гибкости.