DevOps *

Привет, Хабр! Когда релизы выходят раз в две недели, это кажется нормой. Пока не замечаешь, что задачи копятся, а срочные правки превращаются в борьбу с бюрократией. Разработчики привыкают к долгому циклу ожидания, и низкий TTM становится фоном, на который уже никто не обращает внимания.

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

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

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

Итак вам надо клонировать репозиторий с компанейского репозитория и git просит какие-то непонятные пароли.
Знакома ситуация?

В этой заметке я написал как настроить ssh ключи.

Автор статьи — мобильный разработчик, который сам поднял инфраструктуру для стартапа на одной небольшой виртуалке. Вы узнаете, как он выбрал и внедрил werf, какие проблемы решал с помощью SOPS, как организовал хранение и шифрование секретов, и почему GitOps стал для него спасением.

Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков.

Привет, друзья!

В этой серии статей я делюсь с вами своим опытом решения различных задач из области веб-разработки и не только.

В этой статье мы научимся разворачивать Angular+Java веб-приложение на виртуальном сервере Ubuntu Linux с помощью Ansible.

Интересно? Тогда прошу под кат.

Привет! Меня зовут Алексей Федулаев, я руковожу направлением Cloud Native Security в MWS Cloud Platform. Вместе с Андреем Моисеевым мы в этой статье подробно разбираем, как устроены атаки на CI/CD, и почему автоматизация без должной защиты может обернуться серьёзными инцидентами.

Мы покажем, как злоумышленник может получить секреты из пайплайна, обойти security-джобы через конфигурации, скомпрометировать Docker Registry и внедрить вредоносный образ в продакшн. Также разберём, почему даже подпись артефактов не всегда спасает, если есть доступ к раннерам и окружению сборки.

Предупреждён — значит вооружён.

Данная статья открывает серию из трёх материалов, каждый из которых представляет отдельный уровень изучения Kafka.

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

Всем привет!

В этой статье, я вам расскажу про свой личный опыт работы с виртуальными сетевыми лабораториями. Хочу начать своё повествование с небольшой предыстории — как я пришёл к теме.

У себя в блоге мы регулярно делимся полезными ресурсами для специалистов: например, запустили бесплатный курс по DevOps. А сегодня дополнительно рассказываем про ещё четыре открытых материала по DevOps.

Здравствуйте, дорогие читатели Хабра! Я давно хотел поделиться своими знаниями о работе с реестрами под ключ, так как нигде нет четкой и последовательной информации по этой теме. Сегодня мы разберем, как управлять зависимостями через реестры vcpkg и как кэшировать их на сервере.

В своей предыдущей статье я рассказал читателям Хабра о пути, который привёл меня к разработке автоматизированного AI-радио с новостными блоками, подкастами и музыкальным контентом. Я получил много ценных отзывов — спасибо за это! Работа над AI-вещанием продолжается, но за последние месяцы всё выросло в нечто большее: в полноценную платформу.

Привет, Хабр!

В этой статье — история запуска Telegram Mini App, куда за трое суток пришло 100.000 реальных пользователей.

Покажу, как мы масштабировали Node.js приложения на многоядерных серверах, увеличивали RPS в 10 раз, боролись с N+1 проблемой в MongoDB и снижали нагрузку на CPU. А ещё расскажу как мы быстро настроили мониторинг через Grafana, подключили Cloudflare и интегрировали Sentry. Поделюсь практическими инсайтами о том, на что стоит обращать внимание в первую очередь, и как эти инструменты помогли нам оперативно находить узкие места и устранять сбои в реальном времени. Всё, о чём будет в этой статье, основано на том, что действительно сработало. Кроме того, расскажу, какие моменты мы упустили до запуска.

Это разбор с цифрами, графиками и практическими выводами. Он может сэкономить вам время, нервы и деньги, если вы готовитесь к запуску Telegram Mini App или просто работаете с Node.js-приложениями, которые могут оказаться под серьёзной нагрузкой.

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

Первая часть про подготовку к запуску доступна здесь.

Разберёмся, как грамотно (хотелось бы так) настраивать пользовательские правила в Positive Technologies Application Firewall, чтобы при виде атаки ваша защита не превратилась в уязвимую "истеричку". Расскажем про ключевые директивы, покажем примеры из реальной практики и обоснуем каждый шаг.

Облако долгое время воспринималось как безальтернативная основа современной инфраструктуры: гибко, удобно, масштабируемо. Но по мере роста нагрузки и счетов всё больше компаний начинают пересматривать это допущение. От стартапов до крупных игроков — растёт интерес к on-premises, где выше вход, но больше контроля и предсказуемости. В статье — разбор экономических и операционных причин, почему облачный энтузиазм пошёл на спад, примеры репатриации, реальные цифры и аргументы, которые заставляют смотреть в сторону серверной комнаты.

Приветствую.

Цифровая независимость — это не только вектор, по которому двигается страна, но и тенденция, которую я замечаю среди малых бизнесов независимо от направления деятельности. Крупный бизнес может позволить себе использовать облака условного «Сбера» или «Яндекса», что малому бизнесу может быть не по карману. Тогда они задумываются: «Может, дешевле выйдет собрать свою серверную инфраструктуру?»

Именно с таким вопросом в начале года к нам пришла одна небольшая Московская компания. Одним из элементов инфраструктуры было поднятие собственного почтового сервера на базе Mailcow.

Почему для малого бизнеса удобен свой почтовый сервер:

DevOps-инженер: разбор роли и специализаций
В статье рассматриваются роль и специализации DevOps-инженера в современной IT-индустрии. Разбираем ключевые факторы, влияющие на формирование роли DevOps-инженера в разных компаниях.

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

В новом материале DevOps-инженер Максим Кульвинский делится подробным обзором RBAC Wizard — свежего Open Source-инструмента для визуализации и анализа системы доступов в кластере. Разберёмся, как быстро развернуть утилиту с помощью Helm, посмотрим на её возможности и ограничения, а также выясним, кому и в каких случаях она может реально облегчить жизнь.

*Все технические решения описаны в обезличенном виде и адаптированы под публичное изложение. Проект находится под НДА, поэтому часть информации и детали реализации были изменены или обобщены.

Изначальный расчет был на то, что данное решение позволит существенно сократить обслуживание «железной» инфраструктуры. А вместе с ним 一 и расходы на IT-отдел в принципе. Дополнительно планировались привести в порядок текущий парк, который в тот момент насчитывал большое количество неуправляемых раннеров. Часть из них была просто забыта и заброшена, другая часть 一 в один прекрасный момент зависла и так и не пришла в себя. И, разумеется, никому не хотелось с этим разбираться, ведь гораздо проще было просто создать новый раннер. 

Все это выливалось в то, что длительность сборок проектов составляла по несколько часов 一 долго, нудно, тяжело и нерационально. 

Итого, наша мотивация для перехода в облако включала в себя: