Библиотека девопса | 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 808 місце в категорії Технології та додатки та 61 456 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 338 підписників.
За останніми даними від 26 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -42, а за останні 24 години на -6, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 10.35%. Протягом перших 24 годин після публікації контент зазвичай збирає 4.81% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 1 070 переглядів. Протягом першої доби публікація в середньому набирає 497 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 3.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як devops'a, навигация, скрипт, docker, git.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351”
Завдяки високій частоті оновлень (останні дані отримано 27 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
.bashrc или .zshrc убирают эти паузы.
Создать папку и сразу зайти в неё:
mkcd() {
mkdir -p "$1" && cd "$1"
}
Флаг -p создаёт все промежуточные директории, если их нет. Работает с вложенными путями без дополнительных усилий.
Подняться на несколько уровней вверх:
up() {
local d=""
for ((i=1;i<=$1;i++)); do
d+="../"
done
cd "$d"
}
Если вы глубоко внутри проекта, up 3 заменяет cd ../../... Не нужно считать точки и слэши вручную. Просто передаём число уровней.
Найти файл по имени:
ff() {
find . -type f -iname "*$1*"
}
Обёртка над find с поиском без учёта регистра. Удобно, когда помним часть имени файла, но не знаем точный путь. В больших репозиториях работает быстрее, чем ручная навигация.
Найти директорию по имени:
fd() {
find . -type d -iname "*$1*"
}
То же самое, но ищет только директории. Заменяет несколько попыток cd с угадыванием пути.
Как подключить
Добавьте функции в конец файла ~/.bashrc или ~/.zshrc, затем выполните:
source ~/.bashrc
После этого функции доступны в любом новом терминале.
Четыре небольших дополнения, и часть рутины исчезает. Это не революция, просто меньше лишних нажатий за день.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptРабота с AI начинается с систем. Системы — с AgentOps.🔥 Забрать скидку и изучить программу.
ConfigMap обновлён. Что происходит дальше в работающем поде?
piVersion: v1 kind: ConfigMap metadata: name: app-config data: LOG_LEVEL: "info" DB_POOL_SIZE: "10"Вы меняете
LOG_LEVEL на debug. Применяете через kubectl apply. Под работает, не перезапускался.
Приложение видит info или debug?
➡️ Ответ тут
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#задача_со_звёздочкой#!/bin/bash
set -euo pipefail
LOG_FILE="/var/log/myscript.log"
log() { echo "[INFO] $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; }
warn() { echo "[WARN] $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; }
error(){ echo "[ERROR] $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; exit 1; }
log "Script started"
warn "Config file missing, using defaults"
error "Database connection failed" # здесь скрипт остановится
Три уровня: log для обычных событий, warn для подозрительного, error для критического с немедленным выходом.
tee -a пишет одновременно в терминал и в файл. Флаг -a означает append, то есть каждый запуск дописывает в конец, а не перезаписывает лог с нуля.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptjobs:
build:
runs-on: ubuntu-latest
steps:
# Добавьте этот шаг ПЕРВЫМ в каждом job
- uses: step-security/harden-runner@v2
with:
egress-policy: audit # 'audit' только логирует, 'block' блокирует
allowed-endpoints: > # белый список разрешённых эндпоинтов
registry.npmjs.org:443
github.com:443
objects.githubusercontent.com:443
- uses: actions/checkout@v4
- run: npm ci
# Любое соединение с sfrclak.com теперь попадёт в логи безопасности
Два режима работы
В режиме audit Harden-Runner пишет в лог все исходящие соединения, ничего не блокируя. Это безопасный старт: билды не ломаются, но вы видите реальный сетевой профиль своего пайплайна.
Когда понимаете, какие соединения для вас нормальные, переключаетесь на block с белым списком. Любое неожиданное исходящее соединение сразу роняет билд.
Начните с audit, посмотрите на трафик неделю, потом переходите на block. Большинство легитимных билдов ходят в три-пять известных эндпоинтов, и белый список для них составляется за пять минут.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераh() {
history | tail -n "$1"
}
Вызываете h 20 и получаете последние 20 команд.
Поиск по истории:
hg() {
history | grep "$1"
}
Когда помните только часть команды, hg docker или hg ssh быстро находит всё, что вы когда-либо запускали с этим словом.
Положите обе функции в ~/.bashrc или ~/.zshrc и перезагрузите конфиг:
source ~/.bashrc
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptMicrosoft.PowerShell.Native собиралась новым инструментом, несовместимым с Alpine.
Следом в ноябре добавились новые требования по комплаенсу: пришлось менять инструменты упаковки пакетов для не-Windows-платформ. Это сдвинуло выход исправлений с октября на декабрь.
В декабре вышел preview.6, но из-за заморозки изменений на праздники и ограниченной доступности ключевых людей не удалось опубликовать пакеты в PMC и NuGet.
В январе 2026-го всплыла ещё одна проблема: библиотека libpsl-native на RHEL 8 требовала сборки под glibc 2.28, а не 2.33, которую использовали для RHEL 9 и выше.
Команда честно признала системные сбои в процессе. Не было чёткого владельца релиза, не хватало структурированного отслеживания состояния, а замедление цикла preview-версий означало, что проблемы обнаруживались поздно, когда их исправление обходилось дороже.
Что теперь меняется: команда назначила явного ответственного за каждый релиз, настроила внутренний трекинг блокеров, восстанавливает регулярный график preview и упрощает систему сборки пакетов.
➡️ Блог разработчиков
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#разбор_полётовspec.externalIPs в Service помечается как устаревшее. Оно позволяло проводить man-in-the-middle атаки на трафик кластера. Альтернативы: LoadBalancer, NodePort или Gateway API.
Ingress NGINX выведен из строя 24 марта 2026 года. Новых релизов, патчей безопасности и багфиксов больше не будет.
Что стабилизируется
SELinux-лейблинг для томов. Вместо рекурсивного перелейблинга файлов теперь применяется монтирование с опцией -o context=XYZ. Метка применяется ко всему тому сразу при монтировании.
Внешнее подписание токенов ServiceAccount. Kube-apiserver делегирует подписание токенов внешним системам: облачным KMS или аппаратным HSM.
Dynamic Resource Allocation получает новые возможности
Пометки устройств и допуски для DRA переходят в бету и включаются по умолчанию. DRA-драйверы могут помечать устройства как недоступные для планировщика — тогда они не используются, пока нагрузка явно не запросит такое устройство.
Разделяемые устройства в DRA: одна физическая карта теперь может делиться на несколько логических единиц для разных нагрузок. GPU больше не нужно отдавать целиком одному поду.
➡️ Репозиторий
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрии.env и надеяться на лучшее. Есть несколько рабочих способов защититься без сторонних платных инструментов.
Docker Secrets
Docker Swarm умеет хранить секреты отдельно от контейнера. Файл не попадает в образ, не светится в docker inspect, не передаётся через переменные окружения.
Создаём секрет:
echo "my_super_password" | docker secret create db_password -
Используем в docker-compose.yml:
version: "3.8"
services:
app:
image: myapp:latest
secrets:
- db_password
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
external: true
Внутри контейнера секрет доступен как файл /run/secrets/db_password. В коде читаем так:
with open("/run/secrets/db_password") as f:
password = f.read().strip()
Если Swarm не нужен и работаете в обычном Compose, секрет можно передать через файл на хосте:
secrets:
db_password:
file: ./secrets/db_password.txt
Файл ./secrets/db_password.txt добавляем в .gitignore. В репозиторий он не попадает, но и на машине лежит в читаемом виде.
GitHub Actions: repository secrets
Секреты хранятся на стороне GitHub, в код не попадают. Добавляем через Settings → Secrets and variables → Actions.
Пример воркфлоу, который использует токен для деплоя:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy to VPS
env:
SSH_KEY: ${{ secrets.VPS_SSH_KEY }}
VPS_HOST: ${{ secrets.VPS_HOST }}
run: |
echo "$SSH_KEY" > /tmp/deploy_key
chmod 600 /tmp/deploy_key
ssh -i /tmp/deploy_key -o StrictHostKeyChecking=no user@$VPS_HOST "cd /app && git pull && systemctl restart app"
Что здесь важно: ${{ secrets.VPS_SSH_KEY }} нигде не выводится в логи — GitHub автоматически маскирует значения. Если случайно напишете echo ${{ secrets.VPS_SSH_KEY }}, в логах увидите ***.
Для разных окружений используйте энвы:
jobs:
deploy:
environment: production # у этого environment свой набор секретов
runs-on: ubuntu-latest
VPS без managed-сервисов: systemd и переменные окружения
Если приложение запускается через systemd, секреты можно передать через EnvironmentFile. Файл лежит на сервере с ограниченными правами доступа.
Создаём файл с секретами на VPS:
sudo mkdir -p /etc/myapp
sudo nano /etc/myapp/secrets.env
Содержимое файла:
DB_PASSWORD=my_super_password
API_TOKEN=abc123xyz
Ограничиваем доступ:
sudo chmod 600 /etc/myapp/secrets.env
sudo chown root:root /etc/myapp/secrets.env
В юнит-файле systemd подключаем файл:
[Unit]
Description=My App
[Service]
User=appuser
EnvironmentFile=/etc/myapp/secrets.env
ExecStart=/usr/bin/myapp
Restart=always
[Install]
WantedBy=multi-user.target
Приложение получает переменные окружения как обычно. Файл с секретами читает только root, в репозиторий он не попадает никогда.
Дополнительный слой: git-crypt
Если секреты всё-таки нужно хранить в репозитории (например, конфиги для команды), можно шифровать их прямо в git.
git-crypt шифрует выбранные файлы с помощью GPG-ключа. Все видят зашифрованный blob, расшифровать может только тот, у кого есть ключ.
# Инициализация
git-crypt init
# Добавляем пользователя по GPG-ключу
git-crypt add-gpg-user USER_ID
# Указываем какие файлы шифровать (.gitattributes)
echo "secrets.env filter=git-crypt diff=git-crypt" >> .gitattributes
После этого secrets.env в репозитории выглядит как бинарный мусор. На машине с ключом обычный текст.
Ни один из этих способов не заменяет полноценный менеджер секретов, но каждый из них закрывает конкретную дыру лучше, чем голый .env.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераEXPOSE и -p оба про порты, но работают по-разному. Один объявляет намерение, другой реально открывает доступ.
EXPOSE это документация, не настройка
EXPOSE в Dockerfile говорит только одно: "контейнер слушает этот порт". Это подсказка для разработчика и для Docker, но не более. Трафик снаружи всё равно не пройдёт:
FROM node:18
EXPOSE 3000
CMD ["node", "index.js"]
После docker build и docker run без дополнительных флагов порт 3000 недоступен с хоста. EXPOSE ничего не открывает.
PUBLISH это реальное пробрасывание порта
Флаг -p при запуске контейнера связывает порт хоста с портом контейнера. Вот это уже работает:
# хост:контейнер
docker run -p 8080:3000 myapp
Теперь запрос на localhost:8080 попадает в контейнер на порт 3000. Без -p — не попадает, даже если EXPOSE 3000 прописан.
Варианты использования -p:
# конкретный порт хоста
docker run -p 8080:3000 myapp
# случайный свободный порт хоста
docker run -p 3000 myapp
# только на localhost хоста, не наружу
docker run -p 127.0.0.1:8080:3000 myapp
# все порты из EXPOSE на случайные порты хоста
docker run -P myapp
Последний вариант с -P это единственный случай, когда EXPOSE влияет на поведение. Docker смотрит, какие порты объявлены через EXPOSE, и пробрасывает их все на случайные порты хоста.
В Docker Compose
Та же логика, другой синтаксис. expose — только между контейнерами внутри сети. ports — наружу на хост:
services:
app:
image: myapp
expose:
- "3000" # видно другим сервисам в сети, не хосту
ports:
- "8080:3000" # видно хосту
Важный момент: контейнеры в одной Compose-сети и так видят друг друга по всем портам без expose и без ports. Директива expose в Compose нужна только для явной документации намерений.
EXPOSE — документация для людей и инструментов. На реальный трафик не влияет. -p / ports — реальное пробрасывание, без него порт снаружи недоступен.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераsudo curl -L https://github.com/MuyleangIng/MekongTunnel/releases/download/v1.1.0/mekong-linux-amd64 \
-o /usr/local/bin/mekong
sudo chmod +x /usr/local/bin/mekong
Для Linux amd64 меняете linux-amd64 на darwin-arm64 . Windows: скачиваете .exe и добавляете в PATH.
Запуск туннеля:
mekong 3000В терминале появится публичный URL вида
https://happy-tiger-a1b2c3d4.mekongtunnel.dev, QR-код для телефона и URL уже скопирован в буфер.
Или через чистый SSH без CLI:
ssh -t -R 80:localhost:8080 mekongtunnel.dev
Сервер имеет встроенную защиту от злоупотреблений. На один IP можно открыть не больше 3 туннелей, запросы ограничены 10 в секунду с бёрстом до 20. Если клиент переподключается слишком часто, IP блокируется на 15 минут.
Чтобы не попасть в блок, держите соединение живым:
ssh -t -R 80:localhost:8080 \
-o ServerAliveInterval=60 \
-o ServerAliveCountMax=3 \
yourdomain.com
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераcurl и рендерится в терминале ANSI-символами. Никаких зависимостей, никакого GUI — только браузер терминала и HTTP.
Как запустить:
curl -sL http://localhost:3000 | bash
Есть и второй вариант: без bash, чистым curl. Но тут придётся вручную переключить терминал в raw mode, иначе curl не увидит нажатие клавиши до Enter:
stty -echo -icanon min 1 time 0 && curl -sN -X POST -T - localhost:3000/play
После игры терминал нужно починить командой reset.
Сессии без активности удаляются через 60 секунд. Игра стартует сразу с E1M1 на сложности «Hurt me plenty», без меню.
➡️ Репозиторий
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрии