Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787 Заявка: 8137718351
显示更多📈 Telegram 频道 Библиотека девопса | DevOps, SRE, Sysadmin 的分析概览
频道 Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 10 338 名订阅者,在 技术与应用 类别中位列第 11 827,并在 俄罗斯 地区排名第 61 477 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 10 338 名订阅者。
根据 27 十月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -44,过去 24 小时变化为 -3,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 10.79%。内容发布后 24 小时内通常能获得 4.87% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 1 115 次浏览,首日通常累积 503 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 2。
- 主题关注点: 内容集中在 devops'a, навигация, скрипт, docker, git 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351”
凭借高频更新(最新数据采集于 28 十月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# или
brew install ingress2gateway
Запуск:
# из файлов
ingress2gateway print --input-file my-manifest.yaml --providers=ingress-nginx > gwapi.yaml
# из неймспейса кластера
ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml
# из всего кластера
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml
regex-матчи в Ingress-NGINX по умолчанию case-insensitive, поэтому инструмент добавит (?i) в начало паттерна. Скорее всего, вы захотите убрать это вручную.
Вывод ingress2gateway v1.0 совместим с Gateway API v1.4. Инструмент следит за версиями Gateway API и обновляется вместе с ними.
➡️ Блог разработчиков
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераdebootstrap stable /var/lib/machines/mydebian
Запускаем:
systemd-nspawn -D /var/lib/machines/mydebian
Запускаем как полноценный systemd-контейнер:
systemd-nspawn -D /var/lib/machines/mydebian --boot --network-veth
Нет хайпа, нет логотипа с китом, нет конференций. Просто инструмент, который работает, весит ноль байт сверх того что уже есть, и не требует отдельного сервиса в продакшне.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераfrozen для интерфейсов с несколькими родительскими интерфейсами.
Новый запрос wl_surface.get_release для per-commit коллбэков освобождения буфера
Функция wl_display_dispatch_pending_single() для диспетчеризации одного события
Wayland 1.25 продолжает закрывать белые пятна в документации и добавляет низкоуровневые API, которых не хватало.
➡️ Источник
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрииchmod -R 755 на проекте и git показывает 300 изменённых файлов. Код не трогали. Сейчас разберёмся почему так.
Git отслеживает не только содержимое, но и исполняемый бит файла. Рекурсивный chmod меняет права с 644 на 755 у всех файлов. Git видит смену режима 100644 → 100755 и считает их изменёнными.
Как починить:
git config core.fileMode false # для текущего репозитория
git config --global core.fileMode false # для всех реп на машине
Если права уже попали в staging:
git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" \
| git apply
С fileMode false git будет молча игнорировать и намеренные изменения исполняемого бита. Если в проекте есть деплой-скрипты, то стоит предупредить команду перед глобальным включением.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_prompttime-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов.
Также в программе:
— оценка качества, трейсинг и защита от деградации пайплайнов;
— мультиагентные паттерны и интеграция по протоколу MCP;
— локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу).
Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям.
Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ DBaaS (Никита Жига выкатит внутренний чек-лист и покажет архитектуру);
— в чём реальная разница между FoundationDB и Cassandra 5, если смотреть на практику и продакшн, а не на красивые статьи;
— альтернативный путь масштабирования S3 (спойлер: пошли вразрез с привычными паттернами бигтеха, и это сработало).
Честно говоря, доклад про S3 звучит интригующе — всегда полезно посмотреть, как пересобирают архитектуру, когда коробочные решения уже не тянут нагрузку.
Регистрация на офлайн и онлайн тут 👈cluster-admin, общий jump-бокс или долгоживущий SSH-ключ.
У этого подхода два системных последствия: аудит теряет смысл, потому что непонятно, кто и что делал, а временные исключения тихо становятся постоянной нормой.
Три принципа
1. Минимальные права через RBAC
Вместо cluster-admin выдавать роль с конкретным набором действий, которые нужны дежурному.
Привязывается к группе, а не к конкретному пользователю:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: oncall-debug
namespace: payments
rules:
- apiGroups: [""]
resources: ["pods", "events"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"]
- apiGroups: [""]
resources: ["pods/exec", "pods/portforward"]
verbs: ["create"]
- apiGroups: [""]
resources: ["pods/ephemeralcontainers"]
verbs: ["update"]
RBAC умеет ограничивать, может ли пользователь запустить pods/exec, но не может ограничить, какие команды он выполнит внутри сессии. Это задача для отдельного слоя поверх RBAC.
2. Краткосрочные учётные данные, привязанные к личности
Статичные kubeconfig с долгоживущими токенами — классический вектор компрометации. Цель: каждая сессия дебаггинга должна иметь учётные данные, которые истекают через 15-30 минут и однозначно идентифицируют конкретного человека.
Два способа реализации.
Вариант А — короткоживущие OIDC-токены. Большинство managed-кластеров это уже поддерживает. Достаточно настроить kubeconfig так, чтобы токен обновлялся автоматически, а не копировался вручную в конфиг:
users:
- name: oncall
user:
exec:
apiVersion: client.authentication.k8s.io/v1
command: cred-helper
args: ["--cluster=prod", "--ttl=30m"]
Вариант Б — короткоживущие X.509-сертификаты. Если API-сервер доверяет клиентскому CA, можно выдавать временные сертификаты через CertificateSigningRequest API. Приватный ключ остаётся на машине инженера, в идеале в аппаратном токене.
openssl genpkey -algorithm Ed25519 -out oncall.key
openssl req -new -key oncall.key -out oncall.csr \
-subj "/CN=user/O=oncall-payments"
После подписания CSR используем вместе с приватным ключом в kubectl. Через 30 минут сертификат протухает автоматически.
3. Just-in-time access gateway
Это точка входа, которую разворачивают в кластере по запросу — на время сессии. Работает по SSH-протоколу. Инженер запрашивает доступ, получает короткоживущий OpenSSH user certificate, подключается.
Gateway аутентифицирует пользователя, применяет политики и от его имени делает вызовы Kubernetes API. Сессия пишется в лог. После завершения гейт удаляется.
RBAC для такого сценария выглядит так:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: jit-debug
namespace: payments
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: jit-debug
namespace: payments
subjects:
- kind: Group
name: jit:oncall:payments
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: jit-debug
apiGroup: rbac.authorization.k8s.io
Имя группы jit:oncall:payments берётся из короткоживущего сертификата или OIDC-токена — так в логах всегда видно, кто именно и к чему имел доступ.
Три принципа работают как слои: RBAC определяет, что разрешено; краткосрочные учётные данные убирают риск утечки; JIT gateway даёт полный аудит каждой сессии. Каждый из них можно внедрить отдельно, не переписывая всё сразу.
➡️ Блог разработчиков
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераtime-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов.
Также в программе:
— оценка качества, трейсинг и защита от деградации пайплайнов;
— мультиагентные паттерны и интеграция по протоколу MCP;
— локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу).
Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям.
Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ ps -p 1
Вывод покажет systemd с PID 1. Всё просто.
Почему это важно
Каждый процесс в Linux имеет родителя. Терминал запускает bash, bash запускает скрипт, скрипт запускает что-то ещё. Если подняться выше по этой цепочке, в конце всегда окажется PID 1.
Упрощённый вид дерева процессов:
systemd (PID 1)
├── sshd
├── nginx
├── docker
├── cron
└── bash
└── команды пользователя
Есть и ещё один момент. Если какой-то процесс завершается, а его дочерние процессы остаются запущенными, они становятся сиротами. Linux автоматически передаёт их под контроль PID 1. systemd разбирается с ними сам.
Что именно делает systemd
systemd занимается не только стартом при загрузке. Это менеджер всей системы. Он читает юнит-файлы с конфигурацией и запускает сервисы: SSH, сеть, логирование, планировщики задач, Docker, веб-серверы. При сбое сервиса systemd может перезапустить его автоматически, остановить зависимые компоненты и записать всё в журнал.
В отличие от старых SysV-систем, где сервисы стартовали строго по очереди, systemd запускает их параллельно. Именно поэтому современные Linux-системы загружаются заметно быстрее.
Посмотреть всё дерево процессов и убедиться, что оно начинается с PID 1, можно командой:
pstree -p
PID 1 это не просто технический факт из учебника. Это точка, с которой начинается вся работа системы.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераsystemd-sysv-generator, systemd-rc-local-generator, rc-local.service и хук systemd-sysv-install. Если у вас где-то ещё живут старые init-скрипты, самое время их переписать на нативные unit-файлы.
Что появилось
varlinkctl list-registry теперь показывает все публичные интерфейсы из /run/varlink/registry/.
Появился новый systemd-report с экспериментальной системой репортинга через /run/systemd/report/.
systemd-networkd получил секцию [MobileNetwork] для интеграции с ModemManager.
systemd-vmspawn теперь умеет регистрировать виртуальные машины в пользовательском инстансе systemd-machined, а не только в системном.
systemd-ask-password теперь можно запускать от обычного пользователя через политику PolKit.
Добавили поддержку SCHED_EXT в CPUSchedulingPolicy юнита.
➡️ Источник
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрии