Привет, Хабр! Меня зовут Миняйлов Лев, я DevOps-инженер в ИТ‑холдинге Т1.
В этой статье предлагаю рассмотреть эволюцию методов развертывания в Helm от v2 к v4, и дополнительно уделить внимание порядку обновления ресурсов в кластере и возможностям влиять на него через хуки.
Мы избавились от «вечно живущих» EC2‑инстансов, настроили масштабируемые GitLab Runner’ы через Fleeting и Autoscaler и при этом сократили расходы на CI‑инфраструктуру. Делимся рабочими конфигами, подводными камнями и практическим гайдом по настройке.
Запуск WPF на Linux долгое время казался невозможным. Но благодаря связке Docker и Wine теперь это реальность. Рассказываю о своем практическом опыте, как заставить эксклюзивную технологию Microsoft работать вне Windows.
Хочешь быстро поднять несколько лёгких Linux-виртуалок из Windows, да так, чтобы процесс можно было легко повторить? Я, как любитель и самоучка, недавно решил с этим разобраться и всё получилось.
Я сделал это так, на Windows через WSL установил Alpine сборки minirootfs, затем при помощи Ansible развернул в Oracle VM VirtualBox 3 виртуальные машины на базе Alpine сборки standard. Никаких облаков, только локальный контроль и минимум зависимостей. Для чего всё это? Сейчас всё чаще говорят о минималистичных системах, об оптимизации железа под конкретные задачи, о работе на граничных устройствах, вот и захотелось попробовать всё своими руками.
Нагрузочное тестирование давно перестало быть «дополнительной проверкой перед релизом» и стало частью инженерной культуры: без него сложно говорить о предсказуемости систем, зрелости инфраструктуры и реальной готовности продукта к росту. Инструментов для нагрузки сегодня много, но каждый по-своему влияет на процесс: где-то важна гибкость сценариев, где-то — масштабирование, где-то — интеграция в CI/CD. В этой статье разбираем ключевые решения, их сильные и слабые стороны и то, как они помогают увидеть систему такой, какой она будет под реальной боевой нагрузкой.
Статья для тех, кто пытался поставить k3s на Arch Linux и столкнулся с зависающим установщиком, проблемами DNS и отсутствующими systemd юнитами. Полное руководство по ручной установке с реальными командами и решениями.
Привет, Хабр!
Бывало, открываешь десяток терминалов, чтобы мониторить систему: в одном htop, в другом делаешь tail логов, в третьем запускаешь отладку. Через пару минут такой работы голова идет кругом от мельтешащих окон. Для того, чтобы как-то разобраться с этим, помогут терминальные мультиплексоры, старый добрый GNU Screen и его более крутой товарищ tmux.
Funxy — гибридный язык программирования со статической типизацией, pattern matching и удобной работой с бинарными данными.
Для чего подходит
Скрипты и автоматизация. Один бинарник без зависимостей — скачал и работает. Встроенная работа с файлами, JSON, HTTP, SQL.
Небольшие приложения. CLI-утилиты, API-сервисы, обработка данных.
Работа с бинарными данными. Парсинг на уровне отдельных битов. Сетевые протоколы, форматы файлов, нестандартные структуры.
Обучение программированию. Простой синтаксис, но с важными концепциями: типы, pattern matching, иммутабельные структуры данных, рекурсия с TCO (можно писать рекурсивный код без страха переполнения стека).
У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод.
В статье разбираем, как с помощью отдельного проекта, GitLab CI и небольшого Python-скрипта автоматизировать групповую заморозку развёртываний: централизованно задавать расписание, распространять его на все нужные проекты и при этом не ломать привычный workflow команды.
Всякий в Рунете ищет себе жизни хорошей, да только одни сервисы живут вольготно и горя не знают, а другие попадаются в сети хитрые, уязвимостями прозванные.
Так и эксперты СайберОК весь ноябрь бродили по цифровым тропинкам и всё пытались понять: кому в Рунете жить хорошо, а кому достаётся участь тревожная. Прошлись по инстансам, сверили телеметрию, посмотрели, где есть PoC’ы, а где только шум, и составили ТОП / АНТИТОП уязвимостей ноября.
Привет, меня зовут Иван и я SDET‑специалист в SimbirSoft. Полагаю, каждый программист хотя бы раз слышал про инструмент Kafka, многие работали с ним. Наиболее простое его использование — это настройка взаимодействия между микросервисами. А если попробовать использовать его как инструмент для логирования — связать Kafka и Elasticsearch? И при чём тут вообще Elasticsearch? Все просто: это система, которая позволяет работать с большим объемом данных. В нашем случае также необходимо использовать Kibana, надстройку над эластиком, которая позволит визуализировать данные.
В этой статье мы рассмотрим процесс настройки потоковой передачи логов из Kafka в Elasticsearch:
— как настроить взаимодействие между Kafka и Elasticsearch
— как настроить Kibana для визуализации логов, хранящихся в Elasticsearch.
Эта статья будет полезна тестировщикам для настройки анализа логов в распределённых системах, а также разработчикам, желающим реализовать альтернативные сценарии использования Kafka для централизованного логирования.
Есть несколько очевидных проблем с LLM: утечка конфиденциальных данных и кода, компрометация токенов, зависимость от внешних провайдеров. О них знают все, но это никого не останавливает. Даже если руководитель решит перестраховаться и не выделит деньги на LLM, сотрудники купят подписку сами и продолжат ими пользоваться, потому что это удобно. Есть и менее очевидные сложности: например, одна команда может потратить все токены, и их придется докупать.
Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.
Сразу оговорюсь, что статья будет полезна, скорее всего, инженерам, архитекторам, да и просто человекам-оркестрам из средних и малых компаний, которым нужно относительно быстро и безопасно внедрить у себя LLM. А вот для крупного бизнеса или, например, КИИ явно нужно что-то другое — посерьезнее и понадежнее.
В данной статье я покажу, как на Windows развернуть кластер Kubernetes из одного узла с поддержкой GPU и time-slicing, используя WSL.
В итоге получится удобная домашняя Kubernetes-лаборатория.
Задача — не просто спарсить сообщения из Telegram-каналов. Задача — научиться вылавливать из потока обсуждений актуальные тренды, боли клиентов и рабочие лайфхаки. Это золотая жила для SEO-специалистов, продуктологов и маркетологов.
В этой статье (первой из двух) мы сфокусируемся на создании и деплое юзербота для сбора данных. Во второй части подключим нейросеть для анализа и получим готовые инсайты.
Проблема: почему Telegram — это и сокровищница, и хаос
С приходом Telegram-чатов и каналов живое общение и экспертиза ушли с форумов и блогов. Теперь вся актуальная информация — в тысячах чатов, но она тонет в потоке сообщений.
Для создателей контента (SEO): Сложно увидеть, о чем сейчас говорят и спрашивают люди в нише. Тренды рождаются в чатах, а не в поиске.
Для продуктологов и аналитиков: Открытые чаты конкурентов — кладезь обратной связи. Но нет структуры «вопрос-ответ». Ценные инсайты о фичах, проблемах и ожиданиях пользователей размазаны по диалогам.
На носу 2026 год, а я хочу поделиться своим путешествием по переводу приложения на инфраструктуру Kubernetes. Самой сложной и интересной частью была настройка автоскейлинга. Не слишком ли заезженная тема? Думаю нет, потому что я буду рассказывать именно с позиции разработчика приложения, а не девопса. Мне повезло, я без понятия как это всё настраивается. Я буду рассказывать как это всё работает. Конфигов кубера будет минимум, рассуждений и погружений в метрики максимум. В конце оставил TL;DR. Поехали?
В последние годы наметилась тенденция к применению в архитектурах информационных систем WEB-технологий с использованием на рабочих местах пользователей веб-браузеров в качестве тонких клиентов. Однако в некоторых отраслях по различным причинам продолжают использоваться архитектуры с толстыми клиентами. И если в сфере WEB-технологий уже выработаны и укоренились приёмы автоматизации обновления компонентов программных систем, которые большей частью находятся на серверах, то в архитектурах с толстыми клиентами обновление программного обеспечения на рабочих местах пользователей по-прежнему может требовать значительного внимания обслуживающего персонала.
Хостинг электронной почты — это одна из тех коварных статей расходов, которая часто застает врасплох. Вы покупаете домен, создаете несколько почтовых адресов, и все кажется отличным до тех пор, пока не приходит время продления.
Внезапно вы сталкиваетесь с заоблачными ценами, начисляемыми за каждого пользователя. Это заставило меня задуматься: если я уже самостоятельно хощу почти все основные сервисы, которыми пользуюсь, почему бы не поднять собственный почтовый сервер? 💭
Впрочем, в интернете существуют смешанные мнения о самостоятельном хостинге почтового сервера. Некоторые утверждают, что это не лучшая идея, ссылаясь на сложность и потенциальные проблемы с доставляемостью писем.
Другие, в основном любители вроде меня, настроили свои почтовые серверы и остались довольны результатом.
Логическая часть меня колебалась, но любопытный ребенок внутри хотел попробовать в любом случае. В конце концов, разве не лучший способ учиться — это совершать ошибки? Итак, вот как я развернул 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, то поймёте, почему без подобного инструмента жить уже не хочется.
