Библиотека девопса | 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) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
.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
#арсенал_инженера