Docker объявил об открытом бета-тестировании Docker VMM
Собственного, полностью переписанного слоя виртуализации, который отныне лежит в основе Docker Desktop. Новый движок уже доступен в паблик-бете на macOS и Windows начиная с Docker Desktop v4.86. Разберёмся, что именно поменялось, почему это важно даже тем, кто никогда не задумывался о VMM, и как всё это протестировать самостоятельно.
Опция “С сервера imap.yandex.ru по протоколу IMAP” живёт в личных настройках сотрудника: справка Яндекса адресует все четыре шага владельцу ящика. Документация Яндекс 360 API описывает при этом обратное действие - enable_imap: false ограничивает работу через почтовые программы, причём до тех, кто уже включил доступ себе, этот параметр не достаёт. Разбираю, что эта асимметрия означает для инструментов, которые забирают почту по IMAP, и как за вечер проверить свой на тестовой учётной записи.
Не потому, что контейнерному миру срочно нужен ещё один init. Есть Tini, есть docker run --init, и для большинства production-сценариев я бы по-прежнему начал именно с них.
Мне скорее хотелось разобрать задачу до самого нижнего уровня: без libc, без runtime, напрямую через Linux syscalls. Заодно проверить, насколько сильно будет отличаться одна и та же реализация на x86-64 и ARM64.
В итоге из небольшого эксперимента получился mini-init-asm: PID 1, который запускает приложение в отдельной process group, передаёт сигналы всей группе, собирает zombie-процессы и умеет корректно завершать контейнер с exit code приложения.
Позже туда добавились subreaper mode и простой restart-on-crash. А сам проект в итоге доехал сначала до Debian unstable, а затем и до testing.
Но началось всё с вопроса: что вообще должен уметь нормальный PID 1 внутри контейнера?
Let’s Encrypt всегда проверял только доменные имена. Однако с развитием микросервисных архитектур, API-взаимодействий и IoT-устройств возникла необходимость защищать трафик серверов, у которых нет домена. 15 января 2026 года стал общедоступным профиль shortlived с 6-дневными сертификатами для «чистых» IP-адресов. Теперь не нужно тратить деньги и время на покупку и регистрацию бесполезных доменных имен.
На Хабре уже есть подробные статьи и руководства на тему настройки HTTPS, выпуска сертификатов и конфигурации веб-серверов, но в большинстве случаев они объясняют, как защитить сайт с доменом. Мы же разберём, как обойтись без него и выпустить официальный доверенный TLS-сертификат прямо на «голый» IPv4-адрес.
Привет, Хабр!
Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.
Сегодня для многих организаций импортозамещения СУБД - уже практическая задача, которую необходимо решать без остановки бизнес-процессов и без многомесячной переработки прикладных систем. Одним из ключевых требований при выборе новой платформы становится возможность сохранить существующую прикладную логику и минимизировать объем изменений в коде приложений.
В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.
Kubernetes называют инструментом автоматизации. Ирония в том, что первые годы его эксплуатации в облаке — это история ручного труда: сертификаты, которые никто не обновлял, кластеры, которые деградировали молча, клиенты, которые ждали поддержки там, где мы предполагали самообслуживание. Мы начали делать managed Kubernetes в 2018 году, когда на российском рынке этого сервиса почти не существовало. Эта статья о том, что значит слово «managed» на самом деле — и какую архитектуру оно в итоге требует.
Привет, Хабр. Десять лет назад я был обычным сетевым инженером, которому надоело править tac_plus.conf руками, и я написал вокруг него веб-морду — TACACSGUI. Она неожиданно разошлась: тысячи инсталляций, форум, письма из мест, о которых я и не думал. Документации там практически не было — интерфейс был устроен так, что люди разбирались сами. Это был главный урок, который я оттуда вынес.
Второй урок был в почте. Самая частая просьба за все годы, с огромным отрывом: «добавьте RADIUS». Прикрутить RADIUS сбоку к обёртке над TACACS-демоном невозможно так, чтобы это не было уродством: получились бы две несвязанные правды, два места настройки, два набора пользователей. И я решил не прикручивать, а переделать.
Так появился Taranac — TACACS+, RADIUS, NAC. Полтора года проектирования и разработки (не считая времени, которое я просто носил архитектуру в голове). Сегодня это работающая платформа: TACACS+, RADIUS, 802.1X, MFA со своим push-сервисом и мобильным приложением, PKI, captive portal, кластеризация. Free, self-hosted, без лимитов на устройства и пользователей.
Я пришёл сюда не продавать (продавать нечего — оно бесплатное), а за обратной связью. Ниже — что я строил, какие решения принимал и почему. И отдельным разделом — честно про то, чего в проекте нет и что в нём можно не любить.
Планировщик процессов — одна из важнейших подсистем ядра Linux. Именно он определяет, какой поток получит процессорное время в каждый конкретный момент. Несмотря на многоядерность современных компьютеров, количество одновременно выполняемых задач практически всегда значительно превышает доступные вычислительные ресурсы. Поэтому ядру необходимо постоянно принимать решения о распределении процессорного времени между задачами.
Привет! Я Никита, разработчик системного ПО в Selectel. В этой статье рассмотрим эволюцию трех наиболее известных планировщиков Linux: O(1), CFS (Completely Fair Scheduler) и EEVDF (Earliest Eligible Virtual Deadline First).
Я много лет занимался инфраструктурой. Потом перестал и ушёл в продукт — но привычка заглядывать: «А как у вас тут всё устроено?» осталась. И вот теперь я хожу к клиентам по совсем другим вопросам, а глаза всё равно выпадают.
NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции.
Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.
Полночь, деплой горит, а ты вручную поднимаешь десятый сервер за неделю: копируешь ISO, тыкаешь Enter в консоли анаконды, правишь fstab, чинишь grub — и на утро выясняешь, что забыл gpg-ключ репозитория на трех машинах из десяти. Признавайтесь, бывало? Эта статья для тех, кто устал платить временем и нервными клетками за ручную сборку образов.
В этой статье расскажу, как построил полностью автоматизированный пайплайн для сборки образов закрытого дистрибутива Linux на базе RedHat — без единого ручного клика после старта. Ansible управляет хостом-билдером, Packer с shell-провижионерами собирает сам образ, и в итоге мы получаем готовый RAW, оптимизированный для OpenStack. Подход не привязан к конкретной ОС: если у вас другой дистрибутив, достаточно заменить ks.cfg на preseed.cfg или любой другой автоустановщик — остальная логика пайплайна должна работать без изменений. На десерт расскажу, как оформил часть решения в модуль для Ansible и отправил его в официальную коллекцию community.general.
Привет, Хабр! Это снова Денис — тимлид инфраструктурной Core-команды в Timeweb Cloud.
В прошлой статье я разбирал живые миграции: NBD, RDMA, switchover за сотни миллисекунд и прочий внутренний хардкор платформы. Там было вкусно инженерам. Сегодня — про другое удовольствие.
Вот у нас снова есть клиент. У него есть сервер. На сервере — жизнь бизнеса: сайт, база, файлы, пара скриптов «временно, но уже третий год». И где-то в голове тихо живёт мысль:
> «Бэкапы? Конечно. Сделаем. После релиза. И отпуска. И вот этого срочного.»
Знакомо до боли. Я как раз собрал сценарий для тех, кто уже устал откладывать и хочет нормальный бэкап без полугодового проекта внедрения. Открываете один файл настроек, запускаете Terraform — и получаете готовую систему резервного копирования в облаке.
Если ждали 40 экранов про внутренности Bareos — выдохните. Сегодня я буду продавать спокойный сон. Он, между прочим, тоже продукт.
Импортозамещение сервера приложений — это не только перенос Java‑систем в новую среду. Нужно сохранить привычные сценарии эксплуатации, централизовать управление и встроить решение в существующий технологический ландшафт заказчика.
Я Сергей Рощупкин, занимаюсь развитием платформы управления серверами приложений Digital Q.AppServer в «Диасофт». В статье разберу реальный кейс миграции с Oracle WebLogic в крупном банке, покажу, как устроена платформа и где в ней работают ИИ‑агенты, а в конце — практические советы инженерам, которые мы сформулировали по итогам проектов.
Кстати, хочу поблагодарить сообщество за обратную связь по EvertyDesk. Я увидел огромное количество замечаний, идей и реальных проверок. Много ребят запускали проект у себя, ковыряли его, находили проблемы, и вместе мы дотащили всё до версии 2.0.1. Да, я перепрыгнул с 0.0.1 почти сразу. Иногда нумерация версий тоже хочет жить быстрее разработчика.
Нейросети очень помогают добивать мелкие и очевидные баги. Это невозможно сравнить с тем, как я работал раньше, и с тем, как работаю сейчас.
Некоторые спрашивали про Contributor в виде cloud. Ребят, было бы стыдно этого не указать. Значительная часть работы действительно идёт в диалоге с нейросетями. Я фанат технологий, и иногда меня в хорошем смысле удивляет, насколько круто они умеют делать рутинную работу.
В целом я считаю, что мы живём в удивительное время.
Меня можно за это хейтить. Можно не хейтить. Я просто качусь по общей технологической волне и не особенно жду признания. Сегодня я могу делать вещи, которые раньше даже в виде заказной разработки выглядели безумными идеями.
Поэтому я решил начать параллельную серию статей. Помимо своего VST3-плагина для сведения я хочу наконец сделать то, о чём мечтал годами, пока работал ведущим инженером у частного интернет-провайдера.
Когда трафик измеряется миллионами пакетов в секунду, даже небольшие накладные расходы сетевого стека начинают иметь значение. XDP позволяет подключиться к обработке значительно раньше, но работать приходится почти напрямую с данными пакета. На практическом примере разберём, как подключить XDP-программу к интерфейсу, читать сетевые заголовки и понять, для каких задач такого уровня обработки достаточно, а где стоит подняться выше по стеку.
Повторяющиеся операции в облачной инфраструктуре — по отдельности совсем не сложные. Проверить доступные мощности, сверить параметры нового объекта, собрать данные об инциденте или рассчитать лимит IOPS — все это можно сделать вручную. Но когда количество кластеров, площадок, клиентов и запросов растет, а количество рук — не увеличивается, это становится проблемой.
Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. В этой статье я рассказываю про личный опыт автоматизации мониторинга облака. Под катом разберу четыре задачи, которые мы последовательно автоматизировали — заглядывайте, если интересно.
Доброго времени суток, читатели!
Хочу представить вам unissh – современный, простой опенсорсный SSH клиент с selfhosted zero-knowledge сервером для синхронизации данных.
Однажды, морозным ноябрьским утром 2024 года, я, как новоиспечённый тимлид не такой уж и маленькой команды, поверил в себя и в то, что спустя полгода изучения проекта и передачи дел от предшественника я полностью понимаю, как там всё устроено. Судьба обычно наказывает за самоуверенность. Не стал исключением и мой случай.
Для понимания контекста добавлю, что я НЕ девопс - мне пришлось этим заниматься, и всё пишу через призму своего понимания проблемы. Возможно, сейчас придёт корифей AWS/CDK и скажет, что всё можно было сделать проще. Другими словами, не является индивидуальной инвестиционной рекомендацией.
Хабр, и снова здравствуй ) На связи Алексей Боровиков, архитектор Astra Cloud. Тут такое дело, мы выкатили мажорный релиз нашей облачной платформы. Работа была проделана колоссальная, я не буду писать все изменения, иначе это будет не статья, а книга. Поэтому решил сфокусироваться на одном компоненте и рассказать, как мы его сделали и почему. Речь идет про IAM — Identity and Access Management. Он отвечает на главные вопросы облачной безопасности: кто, что сделал и имел ли на это право. Итаааак…
Когда речь заходит об оптимизации запросов в PostgreSQL, разработчики, как правило, сосредотачиваются на времени выполнения: индексы, планы запросов, настройки памяти и так далее. Время планирования остаётся в тени. А зря! Планировщик работает перед каждым выполнением запроса. Для OLTP‑нагрузки с короткими транзакциями накладные расходы на планирование могут составлять значительную долю от общего времени ответа. Для запросов с большими IN‑списками и высоким statistics_target планирование может занимать сотни миллисекунд, тогда как само выполнение укладывается в миллисекунды. Поэтому ускорение планировщика не менее важно, чем ускорение выполнения.