Администрирование

Установка Arch Linux на ZFS всегда была не очень тривиальным делом: нужно знать много тонкостей, прочитать кучу статей и различные вики, разобраться с флагами создания датасетов и пула, с конфигурацией initramfs и с тем, какие systemd сервисы стоит включать, с параметрами командной строки ядра и правильными конфигами. Если ставить вручную, то установка занимает целый вечер, с вдумчивым раскуриванием мануалов перед черной консолью.

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

Очередная «революционная» облачная платформа? Да ладно! Похоже, в этом году нас ждет парад похожих историй — все как один «независимые», «инновационные» и «готовые заменить AWS». 

В чем дело? В июне этого года MWS (входит в облачный бизнес МТС) официально заявила о запуске новой облачной платформы собственной разработки MWS Cloud Platform — без зависимостей от вендоров и сторонних технологий, Серьёзно — совсем без зависимостей? Захотелось разобраться, что действительно скрывается за такими заявлениями.

В этой статье последовательно проанализируем все аспекты платформы — от процесса регистрации до конкретных сервисов, сравним с решениями конкурентов и дадим объективную оценку. Особое внимание уделим тем моментам, где слова расходятся с реальным положением дел, а также проанализируем, насколько платформа готова к использованию в production-среде.

P.S. Информация актуальна на момент публикации статьи.

Недавно впервые занялся деплоем своих проектов и столкнулся с привычной для новичка проблемой: как аккуратно подгружать секреты для бэкенда и фронтенда. На словах всё просто: подключи .env. На деле — копипаст, дублирование, отсутствие истории и точного контроля доступа.

Решение — Bitwarden Secrets Manager + CLI. Централизованно храним ключи, раздаём доступ выборочно и автоматически подтягиваем их при деплое. В статье покажу, как настроить всё с Docker, NestJS, Vite и Coolify, чтобы деплой стал безопасным и удобным.

Всем привет!

В этой статье мы разберём, как развернуть кластер ClickHouse с использованием ZooKeeper для обеспечения репликации и отказоустойчивости. Я покажу пошаговую настройку сервисов, объясню, зачем ZooKeeper нужен ClickHouse, какие порты и конфигурации используются, а также поделюсь практическими советами по работе в Kubernetes.

Привет, Хабр! Статья не входила в планы, пишу с чувством лёгкой сюрреалистичности. В воскресенье утром наш основной API-гейтвей пережил маленькую апокалиптическую битву с памятью и выиграл без моего участия. Делюсь с Вами, как небольшой скрипт, на который я не полагал абсолютно никаких надежд, отработал аварию.

Влагозащищенный и пыленепроницаемый DECT-телефон Gigaset R700H PRO со степенью защиты IP65 — это надежное и многофункциональное устройство, которое стабильно работает под прямым потоком воды (под дождем), в условиях повышенной влажности или в пыльных производственных помещениях.

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

Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. Триггером масштабирования кластера может быть не утилизация, а события от внешних систем — например, очереди сообщений Kafka, системы мониторинга Prometheus или от платформы CI/CD.

Всем привет! Меня зовут Илья Смирнов, я архитектор решений в Cloud.ru. Расскажу, как лучше справляться с пиковыми нагрузками, если вы развернули свое приложение в кластере Kubernetes. Вместе запустим такое демо-приложение и посмотрим, как с ним работают классические подходы автомасштабирования — в этой части, а затем попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler) — в следующей. Не пропустите!

VDS/VPS берут в том случае, когда нужен контроль над сервером и гарантированные ресурсы. Но сценарии использования всегда различаются — кому-то нужен интернет-магазин, кому-то почтовый или игровой сервер, а кто-то вовсе хранит там архив с фото своего кота. Под катом я собрал типичные кейсы и советы о том, на что смотреть при выборе VDS под конкретные задачи. Приглашаю. 

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

Протокол SNMP, что нужно знать для начала.

Как системные администраторы узнают, что какой-то сервер не отвечает? или на нем зависла отдельная служба? греется процессор от неисправной системы отвода тепла? либо он уже второй день обрабатывает запросы от жителей целых ЖК, будучи доступным только по одному провайдеру сети интернет, так как на резервном перегорел SFP трансивер. Они не обновляют страницы состояния инфраструктуры, не читают каждые 10 минут логи и не сидят круглосуточно перед десятками консолей. За них это делает верный и чуткий помощник, мимо которого не проскочит не замеченной ни одна проблема в инфраструктуре. Вашему вниманию протокол SNMP (Simple Network Management Protocol) разработанный еще в 1988 году этот парень остается крутым в своем деле. Если вы только начинаете с ним знакомиться, то в этой статье я постараюсь расписать все, что о нем знаю (в рамках объяснения) сделаем пару практических примеров и составим хороший фундамент, для дальнейшего продвижения в этой большой сфере Мониторинга, обнаружения ошибок в инфраструктуре.

Первое, с чего хочется начать, это структура протокола, он состоит из двух частей:

Менеджер - это система запроса, обработки, хранения и отображения информации, полученной от проверяемых хостов, что и как спрашивать он узнает из специально подготовленной и бесплатно нам предоставленной базы MIB (Management Information Base) мы не будем его открывать и читать, потому что во первых испугаемся, во вторых нам это не нужно, оно само работает без нашего участия;

Агент: - знает все, о хосте и готов ответить на любые "вопросы" заданные менеджером (как в реальной жизни да? отправил агента - получаешь информацию по запросу) вопросы, он получает на особом "языке" OID (Object Identifier) читать их тоже не надо, за нас это сделает агент, они уже готовые и заранее записанные в MIB.

Наверно, вы сейчас подумаете "ну ничего себе симпл, что ты еще там предложишь? объекты да интерфейсы писать и соединять их в систему мониторинга?" нет, со сложностями мы закончили, дальше будем все вышеописанное, обсуждать на понятном языке. Менеджер, уже рассмотренный нами, работает в составе решений мониторинга, самые известные из них: Zabbix, Nagios и даже новомодный Prometheus через свой прокси, но чтобы не нагружать вас сразу всеми существующими технологиями, обойдемся обычными запросами с самого сервера, где и будем смотреть полученную информацию, то есть да, будем отправлять запросы из менеджера вручную, чтобы было понимание как оно работает "под капотом".

Но, как бы хорошо мы не знали ту или иную технологию, нам не удастся объяснить ее на пальцах и наш случай не исключение, поэтому нам понадобится полигон для наших тестов, им будет машина с установленным самым обычным Linux Debian. Давайте установим саму систему мониторинга, а также саму базу MIB, обновим список доступных для установки пакетов: apt update и выполним саму установку apt install snmp snmp-mibs-downloader

Как часто в своей работе вы задумываетесь о необходимости обеспечения удаленного доступа для пользователей? Как на счет 100% бесплатных решений?
Да, такое мы все любим, но уж очень невелик выбор подобных решений под Linux...

Когда я только начинал работать, 100% аптайма казались мне священным граалем. Казалось: если сервис никогда не падает — пользователи счастливы, бизнес доволен, инженеры спят спокойно. Но реальность быстро показала: каждая дополнительная «девятка» стоит всё дороже, а выгоды становятся всё менее заметными. В статье делюсь опытом: почему гонка за идеальной надёжностью — тупик, как помогает концепция Error Budget и почему лучше найти баланс между стабильностью и развитием.

Делимся опытом трансформации нашей инфраструктуры: от децентрализованных экземпляров Foreman с публичными IP до защищённой, изолированной архитектуры с централизованным управлением через GitLab, повышенной безопасностью и легкой масштабируемостью.

Представьте типичное утро понедельника в ИТ-отделе: вы открываете систему тикетов и видите десять одинаковых заявок: «После вчерашнего обновления macOS перестал работать [важный корпоративный софт]». 

Если это звучит знакомо, не паникуйте, вы не одиноки. Apple постоянно выпускает обновления безопасности и новые версии ОС, о чём она напоминает даже в документации: «поддержка актуального ПО – одна из самых важных задач для поддержки безопасности Mac». Однако в корпоративной среде эта же надёжность может обернуться головной болью для админа. С одной стороны, пропуск обновления может оставить дыры в безопасности; с другой – каждое обновление сопряжено с рисками несовместимости с бизнес-приложениями, скриптами и оборудованием.

И наконец привет! Меня зовут Эрик, я инженер технической поддержки в Ринго. В этом руководстве мы разберёмся со всеми основными инструментами и техниками по  управлению обновлениями macOS. Материал построен по принципу от простого к сложному: начнём с базовых компонентов системы обновлений, затем — разбор softwareupdate и defaults, рассмотрим MDM-профили, а также методы блокировки и оптимизацию доставки обновлений. 

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.

Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?

Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике.

Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS:

почему одинаковые запросы дают разные IP

как реально контролируется разрешение имен: что вызывает кого и зачем

как проводить диагностику: strace, resolvectl, tcpdump

Даже самые надёжные и отказоустойчивые системы иногда могут преподносить неприятные сюрпризы. Что уж говорить про обычные VPS-сервера и запущенные на них проекты. Рано или поздно может случиться ситуация, когда сайт или какой-то сервис «упал». Причины бывают разные: от внешних (например, сбой у провайдера или проблемы на стороне хостинга) до внутренних — ошибка в коде, нехватка ресурсов или некорректные настройки.

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

Один из удобных инструментов для этого — Uptime Kuma. Это относительно молодой (по сравнению с «тяжеловесами» вроде Zabbix) проект, который активно развивается, прост в установке и отлично подходит для новичков.

В этой статье мы разберёмся:

Впасть в зависимость от облачных сервисов в корпоративном сегменте довольно просто. Сначала ты просто переносишь пару приложений для тестов, потом соглашаешься на расширенный план, и вот уже через год IT-директор хватается за голову от счетов, которые выросли в несколько раз. Хуже всего, что с течением времени сервисов становится только больше, команды разворачивают новые проекты, а контроля за тратами как не было, так и нет. Кто запустил эти 50 инстансов? За что платим 200 тысяч в месяц? Почему расходы на машинное обучение выросли втрое?

В таких условиях FinOps перестает быть просто модным термином, становясь, по сути, единственным рабочим способом вернуть контроль над IT-бюджетом. Остается самая малость – доказать руководству, что эти инвестиции окупятся. А тут без конкретных метрик и четкого расчета ROI не обойтись.

Сегодня официально выпустили новую версию Kubernetes — 1.34. Собрали обзор со всеми изменениями. Среди главных нововведений — отслеживание здоровья устройств при DRA, тонкая настройка рестарта контейнеров в подах, асинхронная обработка API-вызовов, нативная доставка сертификатов X.509 в поды и новая разновидность YAML для описания конфигураций.