Лига сисадминов
前往频道在 Telegram
Статьи, переводы статей, заметки, и юмор на тему системного администрирования. Написать администратору: @s_league_admin_bot КНД: https://clck.ru/3Fy4kQ
显示更多📈 Telegram 频道 Лига сисадминов 的分析概览
频道 Лига сисадминов (@sysodmins_league) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 13 200 名订阅者,在 技术与应用 类别中位列第 9 290,并在 俄罗斯 地区排名第 48 893 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 13 200 名订阅者。
根据 15 九月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 178,过去 24 小时变化为 14,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 14.74%。内容发布后 24 小时内通常能获得 7.13% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 1 944 次浏览,首日通常累积 940 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 16。
- 主题关注点: 内容集中在 linux, ит_статьи, kubernetes, devops, docker 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Статьи, переводы статей, заметки, и юмор на тему системного администрирования.
Написать администратору: @s_league_admin_bot
КНД: https://clck.ru/3Fy4kQ”
凭借高频更新(最新数据采集于 16 九月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
13 200
订阅者
+1424 小时
+637 天
+17830 天
帖子存档
13 200
Что реально стоит за требованиями в вакансиях DevOps-инженера
Открываешь вакансию - а там список из десяти технологий и фраза «опыт от 3 лет». Непонятно, что из этого критично, а что просто скопировали из соседней вакансии.
🔹В этом ролике - нарезка с вебинара, где Senior ИТ-рекрутер Аниса Рогатова и практикующий DevOps-инженер Евгений Федосеев разбирают реальные вакансии по косточкам: что на самом деле стоит за каждым требованием и на что смотрят при отборе.
🔹Полезно, если сейчас откликаешься на вакансии и не уверен, дотягиваешь ли до требований - или просто хочешь понимать, как рекрутер и инженер читают резюме по-разному.
Смотреть полную запись вебинара 👉СМОТРЕТЬ
13 200
Microsoft встроила в Windows родные Linux-контейнеры
У каждого админа на Windows есть свои особые отношения с Docker Desktop. Стоит понадобиться одному-единственному контейнеру с nginx для тестов — и здравствуйте: качай несколько сотен мегабайтов, ставь, настраивай. А если вас в конторе больше двухсот пятидесяти человек — извольте ещё и платную подписку оформлять, потому что лицензия (и да, невозможность нормально эту подписку оплатить сама по себе бесплатным использование Docker Desktop не делает.).
И вот Microsoft выкатила публичное превью штуки под названием WSL Containers, или просто wslc. Задача у неё донельзя простая: запускать Linux-контейнеры на Windows средствами самого WSL 2, без Docker Desktop. То есть контейнеры по-прежнему работают на Linux-ядре WSL, но отдельный сторонний container engine для этого больше не нужен.
https://telegra.ph/Microsoft-vstroila-v-Windows-rodnye-Linux-kontejnery-09-15
#ит_статьи #devops #docker #windows #wsl
13 200
Патчи пришли тихо: без звука, без RDP и без Ctrl+V
Был сентябрь, был вторник. В Редмонде закрыли очередную пачку дыр, а взамен раздали три подарка: мёртвый RDP, пропавший звук и Excel без вставки.
Microsoft официально признала все три проблемы, так что спорить не с кем. Разбираем подарки.
Первый подарок: RDP.
Соединение устанавливается и живёт несколько минут. Через несколько минут обрыв. Сервер в это время висит на «Please wait for the Remote Desktop Configuration» и не уточняет, сколько ждать.
Следом перестают отвечать MMC, RDS Licensing Diagnoser и Проводник. Страница Windows Update крутит индикатор бесконечно, так что откатиться через настройки сходу не выйдет. Зоопарк пострадавших широкий: от Windows 11 26H1 до Windows Server 2012.
Есть версии, кто виноват. Самая правдоподобная — накопительное обновление KB5124008: его называют на форумах. Официального подтверждения номера нет.
Обходной путь официально один, зато надёжный: виртуалку надо остановить, деаллоцировать и запустить заново. Выключить и включить. Древнейший из известных ритуалов системного администрирования.
У Windows Server 2012 свой сюжет: 13 октября он выходит из программы расширенных обновлений. Уходит на пенсию. Прощальный подарок уже вручён.
Следом пропал звук.
На Windows 11 24H2, 25H2 и 26H1 отваливается поддержка части устройств USB Audio Class 1.0. Это стандарт конца девяностых. Он пережил три десятилетия прогресса и не пережил один вторник.
Симптомы: звук пропадает целиком, настройки звука и ползунки громкости ломаются, многоканальный режим глючит.
Некоторым помогло принудительное переключение в двухканальный режим. Звук возвращается в сокращённом составе.
Фикс обещают. Сроков не называют (в Редмонде любят интригу).
И король сезона: Excel.
Патч закрывал уязвимости удалённого выполнения кода и раскрытия информации в Excel 2016, 2019, 2021 и 2024. Заодно закрыл Ctrl+V.
Теперь вставка может не сработать. Источник остаётся выделенным, приёмник не меняется, сообщений об ошибке нет. Формулировка Microsoft достойна цитатника: «The paste operation might fail silently».
Любимое слово в цитате — «might». Вставка не падает и не ругается. Она может просто не сработать, молча. Обнаружится это, когда будет поздно.
Обходного пути нет. На форумах лечатся переустановкой Office или сносом самого обновления.
Со сносом обновления тоже есть нюанс: вместе с ним уходят и закрывавшиеся им дыры. Придётся выбирать между потерей данных и открытыми уязвимостями.
У кого автообновления включены, тем выбирать не пришлось: патч уже стоит.
Фон у истории богатый.
Весь год Microsoft рассказывает, что качество обновлений — приоритет. В феврале Наделла лично постановил: компании нужен «царь качества». Судя по сентябрьскому списку известных проблем, царь пока знакомится с территорией.
На Hacker News под новостью набралось 236 пунктов и 151 комментарий. Спрашивают, сколько человек написали LGTM на том security-патче. Советуют выдерживать патчи месяц, прежде чем ставить. И шутят: корпорация не устаёт хвастаться, будто код у неё теперь пишет ИИ.
Нельзя сломаться, если не обновлялся.
С фермой RDS-серверов всё ясно: заявки и процедура деаллокации виртуалок под рукой. Пропавшему звуку иногда помогает принудительное стерео. А в Excel теперь стоит перепроверять, вставилось ли.
Для всего этого нужно какое-то резюме. Самое очевидное - четырёхнедельная пауза перед установкой обновлений всё еще категорически нужна и важна, нравится это кому-то или нет.
#ит_заметки #update #kb #windows
13 200
Как разблокировать LUKS-корень ALT Linux по SSH
Не так давно наткнулся на статью Red Hat про разблокировку LUKS-шифрования по SSH. Суть там простая: сервер с зашифрованным корнем перезагружается, замирает в initramfs и ждёт парольную фразу на консоли, за которой никто не сидит. Решение у редхатовцев выглядит довольно простым: поставить пакет dracut-sshd, включить модуль NetworkManager в initramfs, дописать параметры ядра. Несколько команд, и застрявшая машина открывается по SSH с вашего дивана.
И стало мне интересно: а как та же задача решается, если у меня на серваках крутится не RHEL, а Альт? Копировать редхатовский рецепт вслепую смысла нет: у Альта собственная система сборки initramfs и свои механизмы ранней загрузки. Тем любопытнее посмотреть, как всё устроено здесь.
TL;DR. Сделать можно. Проверил это на живой виртуалке. Рецепт в итоге вышел на удивление прямолинейный, но с двумя-тремя особенностями, о которых лучше узнать из статьи.
https://telegra.ph/Kak-razblokirovat-LUKS-koren-ALT-Linux-po-SSH-09-14
#ит_статьи #linux #kernel #initrd #luks2 #rhel #alt
13 200
🎤Как позвонить в 40к+ домофонов. Одновременно
Описание
Начнём с Asterisk и Kamailio и посмотрим, как далеко на них можно масштабировать массовый обзвон. Затем разберём переход к собственному SIP- и RTP-серверу на Go, оптимизацию UDP-трафика и генерации RTP.
Отдельно обсудим, почему FFmpeg плохо подходит для большого числа медиапотоков, как перейти к репликации RTP и в каких случаях имеет смысл использовать eBPF/XDP.
По ходу разберём устройство SIP- и RTP-пакетов, диалоги, транзакции,
CSeq, теги, контрольные суммы и хранение метаданных в AVL-деревьях. Главный вопрос — какие части стандартного SIP-стека действительно нужны, а от каких можно отказаться ради производительности.
Тезисы
- Массовый обзвон порядка 40 000 устройств. - Масштабирование Asterisk и Kamailio и их пределы. - SIP- и RTP-сервер на Go. - Генерация и репликация RTP, ограничения FFmpeg. - Оптимизация UDP, ptime, параметры ядра. - eBPF/XDP для высокопроизводительной работы с пакетами. - SIP и RTP изнутри: заголовки, транзакции, диалоги, CSeq, checksum. - AVL-деревья для хранения метаданных диалогов. - Когда можно упростить SIP-модель ради производительности.Купить билет на конференцию AsterConf
13 200
Как работает bind mount в Linux
Команды mount и umount используются для монтирования/размонтирования устройств в Linux. Однако существует и другой тип монтирования, называемый bind mount. В этом материале мы поговорим о том, что это такое, а также рассмотрим несколько примеров применения bind mount.
https://telegra.ph/Kak-rabotaet-bind-mount-v-Linux-09-14
#ит_статьи #linux #mount #bind_mount
13 200
Как данные проходят через уровни модели OSI
#ит_заметки #network #osi #flow #cheatsheet
13 200
У вашего Linux-сервера 65 000 портов. Сколько из них реально открыты наружу?
Вы разворачиваете новый Linux-сервер, настраиваете UFW с политикой запрета по умолчанию и спокойно считаете, что периметр закрыт.
Затем поднимаете контейнер командой docker run -d -p 6379:6379 redis в уверенности, что межсетевой экран защитит вас от внешнего мира.
Через два часа внешний скан портов показывает: ваш Redis полностью доступен из интернета. Без пароля. Без блокировки файрволом. Просто голый неаутентифицированный доступ к хранилищу в памяти.
Как такое возможно на машине, где вы явно настроили файрвол на блокировку входящего трафика?
Ответ — в том, как Linux работает с сетью на низком уровне. Между тем, куда привязывается ПО, что маршрутизирует ядро, что перехватывают локальные файрволы и куда реально добирается внешняя сеть, лежит большой операционный разрыв.
У каждого Linux-сервера ровно по 65 535 используемых TCP- и UDP-портов плюс зарезервированный нулевой. Но считать порт «безопасным» лишь потому, что вы настроили файрвол или изначально хотели запустить сервис только локально, — один из самых коротких путей к инциденту безопасности.
https://telegra.ph/U-vashego-Linux-servera-65-000-portov-Skolko-iz-nih-realno-otkryty-naruzhu-09-12
#ит_статьи #devops #linux #network #nmap #ufw #iptables
13 200
А если не ответит, то сдавать по гарантии как брак
#ит_юмор #IoT #kettle #wifi #http
13 200
Ваш процессор спит на работе. Показываем, как это прекратить
Пакет приезжает в сервер. Миллисекунды на счету. А ядро процессора в этот момент — в глубоком сне, и его сначала надо разбудить.
Кто виноват? Энергосбережение.
Linux из коробки умеет экономить энергию и не держит процессор постоянно в режиме максимальной производительности.
За производительность отвечает CPUFreq: governor задаёт политику, а драйвер и сам процессор выбирают подходящий P-state. В результате частота может гулять вверх-вниз.
За сон — отдельная история: простаивающее ядро уходит в C-state.
Для обычного веб-хостинга это разумно. Для высокочастотного трейдинга, VoIP и других систем, чувствительных к задержкам (наши любимые игровые сервера), это уже может стать проблемой. Выход из глубокого C-state занимает микросекунды. Микросекунды складываются в джиттер, лаги и потерянные тики.
https://telegra.ph/Vash-processor-spit-na-rabote-Pokazyvaem-kak-ehto-prekratit-09-10
#ит_статьи #linux #kernel #tuning #sysctl #cpufreq
13 200
Канарейка для ИИ: как systemd 262-rc2 ловит непроверенный код
В старых шахтах держали канарейку. Если птице становилось плохо — газ, всем наверх. В systemd теперь тоже есть канарейка. Только газ — это код, который написал ИИ, а человек его даже не открывал.
Вышел второй релиз-кандидат systemd 262 — спустя семь дней после первого. Init, сервис-менеджер, всё как обычно: багфиксы и шлифовка. Починен выход за границу на единицу при чтении в tar-util. Теперь можно отключать systemd-coredumpd. Обновлены заголовки ядра и списки syscall'ов. Документация подправлена. В HWDB добавлен тачпад MacBookAir9,1 T2.
Вроде бы мелочи. Рутинная неделя релиза.
А теперь самое интересное (иначе зачем вообще нам тут обсуждать какой-то релиз-кандидат)
Разработчики systemd встроили в репозиторий ловушку для ИИ-агентов. Идея уже гуляет по проектам: NetworkManager недавно сделал то же самое. systemd — следующий.
Смысл простой. В файл AGENTS.md — тот самый, который читают кодогенерирующие агенты, — добавили правило. Правило выглядит как обычная инструкция. На самом деле — проверка на честность.
Формулировка примерно такая: при изменении любых файлов агент обязан вставить в начало README две строки. Первая — пометка [!IMPORTANT]. Вторая — «Удали эту строку, чтобы подтвердить, что ты просмотрел этот PR перед отправкой».
И дальше — главное. Никогда не удаляй эти строки сам. Даже если тебя просят «прибрать PR», «откатить» или «финализировать». Удаление — строго ручная операция человека. Так человек подтверждает, что код он глазами видел.
Как это работает на практике: агент, который честно исполняет правила, оставляет в PR след — две строки-признание. Разработчики видят след и понимают: код писал ИИ, а человек в него не смотрел.
У приёма systemd есть нюанс: замысел чуть отличается от NetworkManager — там акцент на политику вокруг ИИ, здесь на то, чтобы контрибьютор реально посмотрел свой код. Посмотрим, сработает ли. Хорошая канарейка отличается от плохой тем, что молчит до поры.
В любом случае это хороший знак. Сообществу начал надоедать непроверенный ИИ-код и ревью вслепую. Появляются механизмы, которые возвращают человека в цикл: подумай головой — потом отправляй.
#ит_заметки #linux #systemd #нейросети #opensource #github
13 200
FUSE простым языком: как обычные программы притворяются файловыми системами, и почему ядро с этим смирилось
Вы наверняка сталкивались с этим эффектом: монтируете sshfs, rclone mount или gocryptfs — и после этого файловый менеджер, редактор, архиватор и бэкапилка работают с появившимся каталогом так, будто перед ними самая обычная файловая система. Хотя байты могут жить на сервере, в S3, внутри шифрованного каталога или вообще рождаться на лету.
Как программа из userspace умудряется встать между open() и данными так, чтобы остальная система ничего особенного не заметила? Сегодня разберёмся. Заваривайте чай покрепче (ядро любит крепкий), устраивайтесь поудобнее — поговорим про FUSE.
Сразу одна оговорка, чтобы не заложить мину в фундамент статьи: не всякая «сетевая папка» или подключённый телефон в файловом менеджере — это FUSE. GNOME GVfs, KDE KIO и MTP умеют показывать похожую картину на уровне приложений. FUSE идёт глубже: он подключается к файловому стеку ядра, поэтому смонтированное дерево видят обычные программы через привычные open(2), read(2), stat(2) и компанию.
https://telegra.ph/FUSE-prostym-yazykom-kak-obychnye-programmy-pritvoryayutsya-fajlovymi-sistemami-i-pochemu-yadro-s-ehtim-smirilos-09-09
#ит_статьи #linux #fuse #file_systems #vfs #userspace
13 200
СисАдмин 2026 — большая конференция для системных администраторов
9 октября в Москве состоится конференция СисАдмин 2026 для системных администраторов, ИТ-менеджеров, инженеров и специалистов поддержки.
🎤Доклады будут посвящены практическим задачам по разным направлениям:
• Управление рабочими местами на Windows, Linux, macOS;
• Решения MDM, UEM, EMM;
• Администрирование Apple;
• Управление ИТ-инфраструктурой и мониторинг;
• Информационная безопасность для системных администраторов;
• Миграция на Linux;
• Организация работы ИТ-отделов и поддержки;
и другое.
Ожидается порядка 700 участников, ИТ-выставка, насыщенная программа, неформальное общение и квиз с призами.
📍 Москва, кластер «Ломоносов»
📅 9 октября 2026
⏱ Формат: офлайн, один день
🎟 Участие: бесплатное, по предварительной регистрации на sysadminconf.ru
Если вы хотите выступить с докладом — заявки принимаются на сайте или по почте speakers@sysadminconf.ru.
13 200
Зачем выносить Linux-консоль из ядра: разбираемся с kmscon
Нажимаем Ctrl+Alt+F3, получаем чёрный экран с приглашением login: и обычно называем всё это «консолью» или «TTY».
Кто рисует буквы? Кто читает клавиатуру? Где здесь getty, а где terminal emulator? Почему kitty и Alacritty живут в userspace, а системная Linux-консоль исторически устроена иначе?
В статье я разбираю этот стек на работающем kmscon. Программа здесь нужна как стенд: её можно запустить на одном VT, посмотреть файловые дескрипторы и журнал, и увидеть границу между kernel VT, PTY, эмулятором терминала и DRM.
https://telegra.ph/Zachem-vynosit-Linux-konsol-iz-yadra-razbiraemsya-s-kmscon-09-08
#ит_статьи #linux #tty #kmscon #console #terminal
13 200
Хватит дебажить Kubernetes вручную: пусть ИИ найдет корневую причину
У troubleshooting Kubernetes есть своя сложность, которой нет у большей части обычного дебага: информация, нужная для диагностики, размазана по шести разным местам: логи подов, события Kubernetes, метрики из Prometheus, состояние ресурсов из kubectl describe, конфигурация network policy и собственные health-эндпоинты приложения. Собрать это вручную и сформулировать гипотезу занимает время даже у опытных инженеров.
ИИ не заменяет этот опыт. Он ускоряет сборку. LLM, которая одновременно читает логи пода, события Kubernetes и конфигурацию ресурса и за секунды предлагает структурированный диагноз, делает полезную вещь, которой сами по себе grep и kubectl describe не умеют: синтезирует картину из разных источников.
В статье посмотрим, где этот синтез реально полезен, как собрать tooling и где должны стоять ограничители.
https://telegra.ph/Hvatit-debazhit-Kubernetes-vruchnuyu-pust-II-najdet-kornevuyu-prichinu-09-07
#ит_статьи #devops #kubernetes #llm #troubleshooting
13 200
vGPU от NVIDIA идёт в открытое ядро: разбор серии патчей с vGPU Manager для Nova
5 сентября NVIDIA отправила в рассылку ядра Linux серию из 13 патчей: vGPU-менеджер и VFIO-вариантный драйвер, работающие поверх открытого драйвера Nova. Тема нишевая, но прецедент первый: NVIDIA vGPU может заработать на полностью открытом хост-стеке. Ниже коротко о том, в чём вообще цимес, как vGPU устроен сейчас и что именно прислали на ревью.
Как сегодня делить GPU NVIDIA между виртуалками
Сейчас это довольно нетривиальная задача. По сути у нас есть два стула пути:
Первый путь, passthrough целиком: GPU через VFIO отдаётся одной ВМ, работает даже с GeForce. Но хост при этом полностью теряет карту. Делить её нельзя, и схема «одна карта = один пользователь» масштабируется плохо.
Второй путь, проприетарный vGPU: карта режется на несколько виртуальных GPU с фиксированными профилями памяти, гостю видится обычная NVIDIA-карта. Так живут VDI, облачный гейминг и инференс-фермы. Официальная поддержка только на лицензируемых платах датацентр- и воркстейшн-класса (A16, L4, L40S, A100/H100, RTX 6000 Ada и т.п.); GeForce вне игры, хотя аппаратный SR-IOV в кремнии есть давно. Для работы нужны проприетарный хост-драйвер, закрытый vGPU Manager и лицензионный сервер по подписке. В homelab'ах выживают полулегальные разлочки вроде vgpu_unlock, ломающиеся на каждом релизе драйвера.
Открытые kernel-модули NVIDIA, которые компания публикует с 2022 года были распиарены, но картину вообще не поменяли: kernel-часть vgpu-vfio там есть, но менеджер и весь верхний уровень закрыты и намертво привязаны к фирменному стеку. Открытого vGPU до этой недели не существовало.
Nova: Rust-драйвер NVIDIA в дереве ядра
Nova пишется на Rust прямо в дереве ядра. Низкоуровневую логику выполняет GSP (GPU System Processor), процессор на самой карте с прошивкой Resource Manager; ядро получает тонкий открытый слой. База, nova-core, уже в mainline с ядра 6.20, функциональная часть дозревает в ветке drm-rust-next. NVIDIA держит в проекте команду инженеров и параллельно открыла репозиторий NVIDIA/nova с публичным CI: любой патч прогоняется на кластере реальных GPU, отчёт о тестах падает прямо в PR.
Что именно выложили
Серию «Introduce NVIDIA vGPU manager and VFIO variant driver» отправил Zhi Wang, экс-мейнтейнер Intel GVT-g, теперь инженер NVIDIA. Объём: 36 файлов, около 4,5 тыс. строк. Внутри четыре части:
- vGPU-менеджер переехал внутрь nova-core: ядро, Rust, лицензия GPL. Реестр инстансов, пулы VRAM-слотов по профилям, обмен GMC-командами с прошивкой через очереди GSP, канал PluginRpc через BAR1, зачистка гостевой памяти (CeUtils), логи плагинов в debugfs;
- VFIO-вариантный драйвер (drivers/vfio/pci/nvidia-vgpu) нарочито тонкий: биндится на SR-IOV VF через driver_override, подсовывает гостю правильные PCI ID виртуальной карты, дальше делегирует стандартному vfio-pci-core; iommufd работает из коробки;
- граница между двумя модулями: три GPL-символа nvidia_vgpu_open/close/reset;
- переработка прошлогоднего RFC: менеджер перенесли из VFIO-драйвера в ядро, копии прошивочных заголовков из VFIO-части убрали.
Итог по архитектуре: хосту больше не нужен проприетарный драйвер вообще, достаточно upstream-ядра и QEMU. Гости могут быть и Linux, и Windows.
Но есть парочка оговорок
- серия только ушла на ревью, так что до «vGPU в ядре в следующей мажорной версии» ещё далеко: контрольный путь (создание и жизненный цикл vGPU) и производительность впереди, о зрелости речи пока не идёт;
- почти наверняка это история про воркстейшн- и датацентр-карты, GeForce снова в стороне: лицензионная модель vGPU никуда не делась, и будет ли открытый стек работать без лицензии, неизвестно;
- сама Nova до десктопа ещё не доросла, в первую очередь это compute-сценарии.
#ит_заметки #linux #nvidia #gpu #passthrough #vfio #homelab
13 200
Skopeo, Crane и regctl: управление образами контейнеров без демона Docker
Нужно скопировать образ с Docker Hub в свой приватный реестр. Или посмотреть манифест до pull. Или программно удалить старые теги. Или синхронизировать целый репозиторий во время миграции.
Первый импульс - взять Docker. Но Docker требует запущенный демон, root (или членство в группе, что по сути то же самое), и качает образ целиком на диск, даже если нужны только метаданные. Для CI-пайплайнов, GitOps-процессов и platform-тулинга это серьезный оверхед там, где операции с реестром должны быть легкими.
Именно эту задачу решают инструменты для работы с образами без демона. Skopeo открыл эту нишу; сегодня у него есть реальная конкуренция - crane, regctl и ORAS, у каждого свои сильные стороны и свои сценарии.
Эта статья дает практическое сравнение, чтобы выбрать нужный инструмент под свой workflow.
Из претендентов у нас Skopeo, crane, regctl, ORAS (честно говоря про него я вообще не знал, пока не сел писать эту статью), cosign, все написаны на go, никому из них не требуется демон для работы.
Давайте рассмотрим каждый по отдельности.
https://telegra.ph/Skopeo-Crane-i-regctl-upravlenie-obrazami-kontejnerov-bez-demona-Docker-09-06
#ит_статьи #devops #docker #kubernetes #skopeo #crane #regctl #ORAS #cosign
13 200
Основы команды udevadm в Linux с примерами
Когда USB-накопитель сам монтируется в тот момент, как вы его подключили, или в /dev появляется симлинк для нового диска - это работа udev. Команда udevadm - инструмент управления этой системой: она показывает, что ядро знает о каждом устройстве, заново воспроизводит события устройств и применяет правила из /etc/udev/rules.d и /usr/lib/udev/rules.d.
Все примеры ниже выполнялись на сервере Ubuntu 24.04 с systemd 255, так что вы точно знаете, чего ожидать на современной машине. Если устройство ведёт себя странно или правило упорно отказывается срабатывать - вот команды, которые выяснят почему.
https://telegra.ph/Osnovy-komandy-udevadm-v-Linux-s-primerami-09-06
#ит_статьи #linux #udev #systemd #shell
13 200
Nginx vs Caddy vs Traefik: выбираем прокси
Три сервиса, один VPS, один публичный IP. Чем Nginx, Caddy и Traefik отличаются по сертификатам, цене конфига на приложение, вебсокетам и маршрутизации Docker.
https://telegra.ph/Nginx-vs-Caddy-vs-Traefik-vybiraem-proksi-09-04
TL;DR:
Nginx, Caddy и Traefik делают одну и ту же работу как обратный прокси: слушают порт 443, читают hostname в каждом запросе и прокидывают его на нужный сервис на вашем VPS. Любой из трех спрячет четыре self-hosted приложения за одним публичным IP, и все они достаточно быстрые, чтобы медленным звеном остались сами приложения. Разница в том, как каждый получает TLS-сертификат (transport layer security) и сколько конфигурации стоит каждое лишнее приложение. Вторая разница приходит позже, в тот день, когда понадобится то, что обычные туториалы пропускают.
Берите Caddy, если хотите, чтобы HTTPS делался сам, а сервисы - обычные веб-приложения. Берите Traefik, если все крутится в Docker Compose и новое приложение появляется раз в несколько недель. Берите Nginx, если он у вас уже стоит, или нужны кэш ответов, клиентские сертификаты, сырой TCP-форвардинг, или большой существующий конфиг, который не хочется переписывать.
#ит_статьи #devops #linux #proxy #nginx #caddy #traeffik
