DevOps *

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

Внезапно вы сталкиваетесь с заоблачными ценами, начисляемыми за каждого пользователя. Это заставило меня задуматься: если я уже самостоятельно хощу почти все основные сервисы, которыми пользуюсь, почему бы не поднять собственный почтовый сервер? 💭

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

Другие, в основном любители вроде меня, настроили свои почтовые серверы и остались довольны результатом.

Логическая часть меня колебалась, но любопытный ребенок внутри хотел попробовать в любом случае. В конце концов, разве не лучший способ учиться — это совершать ошибки? Итак, вот как я развернул email-сервер с Mailcow, со своей долей проб и ошибок.

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

На одном из последних запросов я получил оффер — Установить Hestia, Roundcube, настроить почту. Казалось бы нет ничего проще — пишем промт в ИИ (chatGPT моя супруга ласково его называет по свойски «спроси у гопоты») и получай ответы. Но не тут то было...

Последние пару лет я активно работаю с автоматизацией и AI‑агентами. Проекты разные — от чат‑ботов для Telegram до сложных RAG‑систем с векторными базами. И знаете, что меня всегда бесило? Каждый раз при развертывании нового проекта уходило несколько часов, а то и целый день на настройку окружения.

Сначала настраиваешь Docker Compose для n8n, потом прикручиваешь Postgres, потом вспоминаешь про Redis (потому что без него n8n в queue mode не заведешь), потом Supabase для векторов, потом Qdrant, потому что Supabase для векторов медленноват... А еще же HTTPS нужно настроить, Caddy или Nginx сконфигурировать, сертификаты получить. И так каждый раз.

После очередного развертывания я подумал: «Хватит, надо это автоматизировать раз и навсегда». Так родился n8n‑install — репозиторий, который превращает чистый Ubuntu VPS в полноценный AI‑стек одной командой.

Привет Хабр! Если вам тоже доводилось разбирать незнакомый проект, сопровождать прод или помогать QA, вы знаете, как быстро начинаешь ненавидеть однообразные команды etcdctl: копировать ключ, вбивать get, ловить в терминале многострочные значения, скроллить историю… Особенно если ключей сотни, а половина из них — конфиги или JSON’ы на несколько экранов.

Мне хотелось чего-то попроще: запустил один бинарь в терминале и спокойно ходишь по дереву ключей etcd, как по файловой системе, подобно mc.

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

Под катом расскажу, как он устроен, почему в etcd v2 внезапно пропадают ключи, которые начинаются с подчеркивания, как их всё-таки увидеть, зачем понадобилась “инъекция” узлов, и как решить боль с большими многострочными ключами, например JSON или yaml. А также покажу, как этот инструмент помогает разбираться с локами, которые создает python библиотека для работы c etcd.

Если вы хоть раз пробовали разгрести чужое хранилище в etcd, то поймёте, почему без подобного инструмента жить уже не хочется.

В какой момент логично перейти на выделенный сервер и что вы получите взамен? Рассказываем о реальных цифрах, архитектуре и плюсах перехода.

Привет, Хабр! Меня зовут Николай, я – старший инженер по внедрению в Т2. На определенном этапе эксплуатации системы, когда настроены все мониторинги, и подключены все алерты, появляется необходимость оформить работоспособность всего, что есть, в одной метрике. Такую метрику, знаете, и отделу бизнес-мониторинга можно продемонстрировать, и коллегам из смежных команд – и при этом сделать все максимально прозрачным и понятным. Чтобы, как я иногда говорю, моя бабушка посмотрела и все поняла. В этой статье я расскажу, что у меня получилось из идеи создать доходчивую и простую для восприятия метрику индекса здоровья системы!

Хочу понять, есть ли потребность в решении которое я проектирую.

Деплой через AI — есть ли в этом смысл?

Привет.

Я студент, изучаю Ansible на Raspberry Pi через Tailscale. Делюсь полным путем от первой ошибки до работающих веб-серверов. Код + выводы + уроки. Репозиторий на GitHub.

Self-hosted AI-платформа на Docker: N8N, Ollama, Open WebUI, Qdrant, Whisper. Автоустановка, 152-ФЗ. Разбор архитектуры, benchmark топовых моделей декабря 2025 (DeepSeek-R1, Llama 3.3, Qwen 2.5), метрики на CPU/GPU, расчёт TCO.

За последний год из компании Alfabit.org было уволено большое количество сотрудников. Договор в компании составлен так, что тебя могут уволить "одним днем" и ты еще останешься должен (и зарплата уйдет на погашение "не выполненных задач"). Обо всем по порядку:

Статья объясняет, как StarRocks 4.0 делает запросы к JSON почти столь же быстрыми, как к нативным столбцам. FlatJSON на этапе загрузки «колоннизирует» частые поля и задействует индексы (включая ZoneMap), словарное кодирование и Global Dictionary, а также Late Materialization. В результате логовая, e‑commerce и IoT‑аналитика работает в реальном времени без тяжёлого ETL.

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

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

StarRocks 4.0: Real‑Time Intelligence on Lakehouse. Сквозная оптимизация конвейера в реальном времени, 3–15× ускорение JSON, SQL Plan Manager, Decimal256 и поддержка Apache Iceberg для нативной Lakehouse‑аналитики.

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?

Привет, Хабр! Сегодня хочу поделиться опытом того, как я отказался от стандартной утилиты мониторинга SSSD в пользу прямого общения с демоном через D-Bus и создал полнофункциональный Ansible-модуль.

Привет, Хабр! У платформы VK Cloud есть продукт, который позволяет компаниям частично или полностью перенести свою инфраструктуру не в публичное, а в частное облако. То есть хранить все в своем ЦОД и под личным контролем — но пользоваться при этом интерфейсом и инструментами, разработанными VK Tech.

В этой статье расскажем, как работает платформа VK Private Cloud и чем на самом деле она отличается от публичного облака. Будет много технических примеров, деталей и конфигураций и минимум общих описаний — только для уточнения нюансов. А также подробности о новой версии 4.3.

Zabbix — отличный универсальный инструмент. Но как только виртуалок становится не 20, а 200, всё превращается в бесконечный тюнинг: поднял лимит PHP, подкинул кэш, вырубил логирование — и надеешься, что доживёт до утра. Мы проверили, где эта грань на самом деле проходит и как себя ведёт альтернатива — zVirt Metrics. В статье — архитектура, производительность и честные цифры из тестов. Материал будет полезен инженерам, которые держат на себе мониторинг виртуализации и хотят, чтобы всё работало из коробки и без плясок с бубном при росте числа инсталляций zVirt.

Я работаю DevOps-инженером в команде разработки продукта Колибри-АРМ, аналога Microsoft SCCM, покрывающего потребности в импортозамещении ПО для управления парком АРМ. В данной статье будет описан кейс решения задачи по обеспечению высокой доступности продукта – она будет по большей части описывать перенос непосредственно функциональности, и тут не будут рассматриваться такие аспекты как безопасность кластера и приложения внутри.

Тема семи (именно семи) ошибок при внедрении процессов DevOps довольно популярна на просторах сети. Начиная с 2018 года периодически публиковались статьи на эту тему. При этом, с годами сами ошибки менялись. В этой статье мы рассмотрим версию семи ошибок образца 2025 года. Начнём с первой ошибки, связанной с принятием DevOps как культуры.

Привет, Хабр! Меня зовут Макарий, и как Senior SRE в Yandex Cloud я не только участвовал в разработке Managed Service for Kubernetes, но и всегда любил в свободное время посмотреть, что интересного понавыпускали для «кубика». Kubernetes, как де‑факто стандарт оркестрации контейнеров, предлагает базовые механизмы для управления вычислительными ресурсами. Однако стандартный планировщик Kubernetes (kube‑scheduler) разрабатывался с учётом общих принципов балансировки нагрузки и не специализирован для уникальных особенностей рабочих GPU‑нагрузок.

Предлагаю рассмотреть весь спектр возможностей — от встроенных механизмов шедулинга K8s до специализированных планировщиков, таких как Volcano, Apache YuniKorn и KAI‑Scheduler. Проанализирую конкретные сценарии, в которых каждый из этих инструментов демонстрирует свои преимущества, и предложу рекомендации по выбору оптимального решения для ваших рабочих GPU‑нагрузок.