Первая часть серии статей по Docker. Базовая теория по Docker для новичков и практиков — контейнеры, образы, Dockerfile, слои, HEALTHCHECK, multi-stage builds и шпаргалка по командам.
Типовая ситуация: Terraform-конфигурация выглядит привычно, а ИИ-агент экономит время на рутинных операциях. Но потерянный state-файл и один terraform destroy способны за минуты снести прод вместе с базой данных и снапшотами.
В этой статье разберем реальный инцидент, восстановление через AWS Support и защитные механизмы, которые появились в инфраструктуре после аварии.
Виртуализация — неотъемлемая часть IT-инфраструктуры. Она лежит в основе всех облачных систем, обеспечивает изоляцию ресурсов и гибкость управления. Такие возможности, конечно, появились не сразу. Технология прошла долгий путь: начавшись с одного системного вызова в 1980‑х, она переросла в большие инженерные решения.
В этой статье я расскажу про развитие гипервизоров: от появления системного вызова chroot(2) до возникновения идеи о виртуализации в браузере…
Большинство материалов по Cisco, Linux и GNS3 до сих пор ориентированы на VMware Workstation.
В последнее время возникли две проблемы.
Во-первых, официальный сайт GNS3 недоступен напрямую с территории РФ, из-за чего скачивание необходимых компонентов превращается в отдельную задачу.
Во-вторых, GNS3 рекомендует использовать VMware Workstation, который также недоступен с территории России.
В этой статье покажу, как собрать полноценный стенд на компьютере под управлением Windows 11. Мы установим GNS3 и создадим виртуальные машины GNS3 VM и Ubuntu 26.04 LTS в гипервизоре Hyper-V.
В результате получим готовую площадку для изучения компьютерных сетей и Linux.
Привет, Хабр! Импортозамещение инфраструктурного стека Microsoft — задача, с которой периодически сталкиваются большие российские компании и субъекты критической инфраструктуры (КИИ). Служба каталога, менеджер конфигураций, корпоративный центр сертификации — всё это годами держалось на решениях одного вендора. Но все знают, что за последние 5 лет всё кардинально поменялось, и нужны решения, способные реально заменить существующий 30 лет стек.
На Хабре уже выходили материалы про аналоги Active Directory. Настал черед поговорить про коробочные решения, уже заменяющие стек Windows + AD + SCCM + CA. Речь идёт об Astra Server Core, совместной платформе «Группы Астра» и компании «Аладдин». Решение представляет собой Astra Linux Server с корпоративным центром сертификации Aladdin Enterprise CA (eCA), службой каталога ALD Pro и менеджером конфигураций ACM.
Я поговорил об этом стеке с директором серверного ПО «Группы Астра» Алексеем Фоменко и генеральным директором компании «Аладдин» Сергеем Груздевым. Мы обсудили, из чего состоит платформа, как организована миграция с Windows-инфраструктуры без остановки сервисов, какие специалисты нужны для внедрения и как обстоит дело с совместимостью с другими российскими ОС.
Приятного чтения!
Портал есть, каталог на 200 услуг есть, база знаний есть. А сотрудник всё равно звонит на первую линию. Разбираем, почему так — и что реально меняет ИИ, честно, со слабыми местами.
В какой‑то момент у меня накопилось несколько VPS у разных провайдеров. Не десятки, но уже достаточно, чтобы каждый месяц ловить себя на одной и той же мысли: «А этот сервер когда оплачивать?»
Ссылка на биллинг — где‑то в закладках. Дата продления — в Telegram. Пароль от кабинета — в другом месте. Таблицы, заметки, все разбросано. Пока серверов немного, это ещё работает. Когда их перевалило за 15, начинаешь постоянно все терять. Кто хостер, а что там крутится, вкладки, вкладки, вкладки!
Так появилась идея: сделать личный кабинет для своих серверов.
Сколько существует ПО, столько админы и программисты спорят о свободном и несвободном ПО. Тема эта древняя и, казалось бы, все участвующие в споре стороны давно определились с лагерем, за который они “топят».
И так бы все и продолжалось, если бы в 2022 году картинка радикально не поменялась. Такие привычные и понятные продукты ушли из России, оставив многих перед необходимостью искать альтернативы. На встречах с заказчиками я начал снова все чаще слышать старые вопросы: «А объясните мне, что такого плохого в OpenSource?» и «Почему вы мне рекомендуете платное, если есть прекрасная бесплатная альтернатива?». Если на этом месте сразу захотелось прекратить читать и нажать на крестик, я дам быстрые ответы: между Open Source и проприетарным ПО гораздо больше общего, чем принято считать, а выбор по принципу «платное ПО или нет» – абсолютно неверная стратегия.
Если вы еще читаете, то давайте разбираться.
Привет, постоянные и не очень читатели!
Недавно на Хабре вышел лонгрид «Поймай меня, если сможешь [часть 1]: облако на Huawei Cloud Stack — что это, как используют и лицензирование», в котором я рассказал про платформу Huawei Cloud Stack (HCS) — как она устроена и почему крупные компании вообще смотрят в её сторону, там же про архитектуру, лицензирование и многое другое.
Но платформа HCS больше, чем сумма её частей: первый лонгрид (при всех моих стараниях) всё равно получился лишь аннотацией к Сильмариллиону. Той теории достаточно для поверхностного знакомства, теперь же обсудим подготовку к миграции: аудит инфраструктуры, разберёмся с RPO и RTO, посмотрим на совместимость виртуальных машин и образов, а самое главное — обсудим стратегии миграции по методологии AWS, которые можно применить не только к HCS, но и к любому другому облаку.
Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы честно попробовали воспользоваться опенсорс-провайдером Terraform для oVirt и получили неоднозначные результаты (на самом деле вполне однозначные).
Эта статья посвящена анализу провала проекта terraform-provider-ovirt. Посмотрим на принятые решения, поищем первопричину, оценим, как надо и как не надо делать, и выработаем основные концептуальные решения перед реализацией своего провайдера.
Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему — все это погубило terraform-provider-ovirt и всего этого следует опасаться любому разработчику подобного решения.
Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).
Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.
Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.
Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.
В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?
Штатная ситуация оказалась задачей со звёздочкой: кластер кинул алерт о том, что заканчивается сеть подов, но ни одно решение «из методички» не подходило, а вытаскивать кластер из прода было нельзя.
В статье расскажу, как мы не просто расширили подсеть подов, но сделали это на работающем кластере и не потеряли при этом данные. Что важно — трюк сработает на любом дистрибутиве Kubernetes и CNI.
Если у вас приватные репозитории на GitHub и команда, которая регулярно упирается в лимит времени GitHub Actions, эта статья сэкономит вам пару недель экспериментов. Рассказываем, как мы подняли self-hosted раннеры в Docker, настроили их репликацию через Docker Compose и почему в итоге пришли к Docker-in-Docker. Разобрали по шагам эволюцию решения от Bare Metal раннеров до докеризованной конфигурации. Репозиторий с настройкой находится в открытом доступе.
У вас есть сервер. Он числится на балансе. За ним закреплён Иванов. Иванов уволился год назад. Где сервер – никто не знает.
Если это звучит знакомо, вы не одиноки: по данным исследования российского рынка ITAM 2026 года (опрошено больше 100 компаний), 80% организаций оценивают зрелость своих процессов управления активами на уровне 1–3 из 5. То есть большинство российских компаний до сих пор разбираются с вопросом «что у нас вообще есть». До «где это стоит» и «сколько стоит» добрались единицы.
Эта статья про инструментарий: полный стек, от низкого уровня до дашборда для финансового директора, с плюсами и минусами по каждому слою.
Когда-то давно, конвертеры среды (медиаконвертеры) были довольно простыми устройствами, и если вам нужно было подключить два медных гигабитных коммутатора по оптоволокну, нужно было купить два гигабитных медиаконвертера.
Если же нужно было подключить что-то имеющее только 100 мегабитный порт, то нужно было купить 100 мегабитные медиаконвертеры.
Потом появились медиаконвертеры с преобразованием скорости. Можно было бы порадоваться-стало удобно, но тут есть одно фундаментальное различие между ними, и оно очень важное.
Изначально медиаконвертер — это конвертер среды передачи, то есть он преобразует электрический сигнал в оптический и наоборот. Разумеется, там не все так просто, но главное, это уровень L1 в модели OSI.
Но так работает только если у вас и медный и оптический порты, работают с одинаковой скоростью.
Как только вам нужно иметь разные скорости, вам понадобится как минимум буфер.
Так вот если заглянуть в современный медиаконвертер, изучить на чем он сделан, то внезапно окажется что это, по сути, двухпортовый коммутатор, с буферами, MAC таблицами, и прочими атрибутами современного коммутатора.
Чем это плохо спросите вы? да в общем для медиаконвертера плохо по целому ряду причин.
По сути, если вы соединяете через такие медиаконвертеры, например два хороших, дорогих коммутатора (скажем Huawei), вы между ними ставите два неуправляемых коммутатора.
Мало того, что это добавляет задержки на перекладку кадров из порта в порт через буферы, так это еще и осложняет диагностику, ведь ошибки на портах скорее всего вы посмотреть не сможете, как не сможете посмотреть и MAC таблицы, очереди и все то, что помогает при диагностике сетевых проблем.
Привет! Я Владимир Карагиоз, работаю техническим лидером по развитию гибридных облачных решений в Cloud.ru и увлекаюсь популярными в 90-х годах рабочими станциями Sun SPARCstation 5. У меня есть 30-летняя машина, которую я пытаюсь привести в чувство. Я уже вылечил детскую болезнь, связанную с севшей батарейкой модуля памяти, и подготовил машину к установке операционной системы — об этом рассказал в первой части истории. В этой статье поставим на машину Solaris 2.6 и начнем завозить уют для пользователя, привыкшего к комфорту современного Linux.
Виртуальные мобильные операторы (MVNO) стали привычной частью телеком-рынка. Их запускают банки, ретейлеры и операторы фиксированной связи, превращая мобильные услуги в элемент экосистемы и инструмент удержания клиентов. Однако изначально MVNO создавали для других целей — борьбы с монополией крупных операторов связи. Разберем, как развивалось это направление, и что происходит на рынке сегодня.
Привет! Я — Саша Басун, инженер направления пользовательских ИТ-сервисов в «Петрович-Тех». Сегодня я пришёл к вам с историей о том, как вывод значения ключа из реестра Windows может упростить обработку заявок в отделе технической поддержки.
Если коротко: помощь со стороны нашей техподдержки нередко начиналась с мема «Давайте поможем Даше найти Internet-ID на рабочем столе». Тут нет-нет, да все стадии от гнева до принятия пройти придётся. В итоге после заявки, которая пришла уже мне, родилось маленькое, но изящное решение на C#.
Если у вас российский номер, my.telegram.org с VPN выдаёт ERROR при создании приложения, а без VPN вообще не открывается. Антифрод сверяет страну номера и страну IP - и они не сходятся. Разбираю, почему обход через VPN - тупик, при чём тут DNS, и как получить api_id и api_hash одной строкой в файле hosts за 5 минут, без покупки номеров телефона других стран.
Виртуализация должна была упростить пользовательский опыт в больших и гео‑распределенных компаниях и снять нагрузку с ИТ‑служб. Но на практике оказалось, что перенос рабочего места в дата‑центр решает одни проблемы и одновременно создаёт другие.
Это особенно проявилось на фоне «бума» российского VDI в 2022 году. VDI отлично справляется с офисными приложениями, неплохо живёт с web‑сценариями и требует особого подхода к CAD‑ и мультимедийным нагрузкам. Но самый парадоксальный эффект проявляется в организации видеоконференцсвязи (ВКС).
Разберёмся, почему видеосвязь требует особых подходов к оптимизации, без которых цифровое рабочее место остаётся только наполовину виртуальным, какие есть российские ВКС и что делать их поставщикам, чтобы не ломался UX.