Библиотека девопса | DevOps, SRE, Sysadmin

🧠 Фичи в Kubernetes, которые ты почти точно не используешь (а зря) Сегодня делюсь парочкой полезных, но часто игнорируемых возможностей Kubernetes, которые могут упростить жизнь DevOps'а. 🚀 Init Containers Всё ещё пихаешь скрипты и ожидания в основной контейнер? Init containers — твои друзья. Они запускаются до основного контейнера и идеально подходят для всяких подготовительных задач: прогрев кэша, валидация конфигов, ожидание зависимостей и т.д. 🔒 PodSecurityPolicy (PSP) (устарело, но ты знал?) Да, PSP deprecated, но оно до сих пор используется в куче продакшенов. Если не хочешь мигрировать на OPA/Gatekeeper прямо сейчас — хотя бы убедись, что PSP у тебя не дырявая. 📦 Ephemeral Containers Идеальны для отладки. Хочешь зайти в прод-под без шелла или нужных утилит? Добавляешь ephemeral контейнер с bash’ем, curl’ом и всем нужным, не перезапуская под. kubectl debug -it pod-name --image=busybox 🌐 NetworkPolicy Ты уверен, что твои поды не могут лезть куда угодно? Пока не включены NetworkPolicy, твой кластер — как квартира без дверей. Даже самый кривой Dev может случайно (или не очень) сломать пол интернета изнутри. ⏱ Liveness vs Readiness Это не одно и то же. Readiness говорит, когда трафик можно пускать. Liveness — когда под умер. Если перепутал — получишь либо DDoS от своих же сервисов, либо перезапуск в вечном цикле. Пользуешься всеми? Респект. Нет? Самое время попробовать. Подпишись 👉 @channel_devopslib

🚀 История одной фичи: systemd-run (aka когда надо быстро запустить что-то от другого пользователя) Ситуация: ты по SSH, нужно срочно что-то запустить от имени другого пользователя. sudo su? su -? screen? tmux? crontab? Остановись. Посмотри на это: sudo systemd-run --uid=appuser --pty bash 💡 Что происходит: Ты создаёшь временный unit в systemd, от имени пользователя appuser, и получаешь интерактивную сессию в его окружении. Всё красиво, под контролем systemd, с логами, cgroup и т.п. Можно запускать и отдельные команды: sudo systemd-run --uid=appuser --pty top Или фоново: sudo systemd-run --uid=appuser --scope my-command 🔥 Преимущества: - работает даже если shell пользователя отключён - не требует входа в сессию - всё логируется в journald - systemd сам подчищает за собой 👀 Используй, когда: - хочешь тестить что-то от другого юзера - автоматизируешь запуск задач - нет желания возиться с su/sudo/scripts Подпишись 👉 @channel_devopslib

🧩 Почему важно использовать .env файлы в DevOps-проектах Когда проект начинает обрастать конфигурацией, секретами, API-ключами и разными переменными окружения — легко всё потерять или случайно выложить в Git. Именно тут на сцену выходят .env файлы. 📦 Что такое .env? Это простой текстовый файл с ключ-значениями, например: DB_HOST=localhost DB_USER=admin DB_PASS=secret Он не исполняется напрямую, но может быть подгружен в окружение с помощью утилит вроде dotenv, source, или встроенных механизмов в Docker, Compose, CI/CD и так далее. 🔐 Почему это круто: - Безопасность: не хардкодим чувствительные данные в коде - Гибкость: можно легко переключаться между dev/stage/prod окружениями - Поддержка: большинство инструментов CI/CD и фреймворков умеют работать с .env - Удобство: один файл — все переменные 🛡️ Совет: Добавь .env в .gitignore, иначе можно случайно закоммитить секреты. 📌 Если работаешь с Docker Compose — укажи env_file в docker-compose.yml: services: app: env_file: - .env Так контейнеры будут сразу знать, какие переменные им нужны. Подпишись 👉 @channel_devopslib

🧵 Чеклист перед выкладкой инфраструктурного кода в прод Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main. ✅ 1. План применён? terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД». ✅ 2. Есть backend? Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё. ✅ 3. -target не попал в CI/CD Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия. ✅ 4. Защищён ли state? Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных. ✅ 5. Модули не обновились «магически»? Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу. ✅ 6. Документация и комментарии есть? Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу. ✅ 7. Прогонен tflint / checkov / terraform validate? Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут. ✅ 8. Обратная совместимость учтена? Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик. ✅ 9. Всё в Git? Terraform code без Git — это как сервер без мониторинга. Безответственно. ✅ 10. Apply сначала в staging! Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка. 🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока. Подпишись 👉 @channel_devopslib

🚨 Как быстро вычислить утечку памяти в Linux? Когда система начинает “подтормаживать” без видимой причины — пора заподозрить утечку памяти. Вот как можно быстро найти виновника. 🔍 1. Проверяем использование памяти: free -h Если available стремится к нулю, есть повод копнуть глубже. 🔧 2. Сортируем процессы по потреблению RAM: ps aux --sort=-%mem | head -n 10 Тут видно, кто больше всех ест память. 🧠 3. Следим за slab-объектами: cat /proc/meminfo | grep Slab Если значение растёт со временем — это сигнал утечки в ядре или драйверах. 🧪 4. Используем smem для точной оценки: smem -r | sort -k 4 -nr | head smem учитывает shared memory — оценка куда точнее, чем просто ps. 🎯 5. Если подозрение на конкретный процесс: pmap — покажет, что именно грузит память: pmap -x <PID> 🔥 Совет: Запусти htop, нажми F6, выбери колонку RES, отсортируй. Увидишь — кто на самом деле обжора. Подпишись 👉 @channel_devopslib