Эта статья предлагает способ интеграции Terraform с Argo CD путём коммита выходных значений инфраструктуры напрямую в Git.

Это гарантирует, что Git остаётся единственным источником истины, и позволяет использовать Helm/Kustomize без ограничений, накладываемых прежними паттернами

🔹Читать

👉 DevOps Portal

dockprom — это решение для мониторинга Docker-хостов и контейнеров с Prometheus, Grafana, cAdvisor, NodeExporter и алертингом через AlertManager

GitHub: dockprom

👉 DevOps Portal

Зависимости сетевых протоколов

👉 DevOps Portal

Дерево процессов в Windows, запускаемых при старте системы

👉 DevOps Portal

Терминальная утилита, которая получает метрики нод и подов Kubernetes в реальном времени через эндпоинт Kubelet /stats/summary, с TUI-функциями: поиск, сортировка, фильтрация по меткам, просмотр подов и использование диска

GitHub: KubeNodeUsage

👉 DevOps Portal

Docker 101: Автоматический рестарт контейнера при сбое

Некоторые контейнеризованные приложения более устойчивы, чем другие. Попрактикуйтесь в настройке политики перезапуска контейнера, чтобы он продолжал работать даже после краша приложения

Тренируемся здесь

👉 DevOps Portal

14 Linux-команд, чтобы познакомиться со своей ОС… меньше чем за 60 секунд 👍

👉 DevOps Portal

В начале моей карьеры в DevOps я удалил 5-гигабайтный лог-файл на продакшн-сервере, где заканчивалось место

Я запустил df -h, ожидая увидеть, что использование диска уменьшилось. Не снизилось. Всё ещё показывало 100% заполнения.

Ни ошибок, ни варнингов. Просто та же картинка, как будто я ничего не удалял.

Тогда я и понял, что удаление файла не всегда сразу освобождает место.

В Linux то, что мы считаем «файлом», на самом деле состоит из двух сущностей: имени файла (это всего лишь указатель) и inode (в нём хранятся данные и метаданные). Когда вы удаляете имя файла, вы всего лишь убираете указатель. Inode и его данные остаются на диске до тех пор, пока какой-то процесс держит файл открытым.

В моём случае веб-сервер всё ещё писал в этот лог. Хотя я уже снёс имя файла, процесс сервера продолжал держать файловый дескриптор. Inode оставался «живым», невидимым в обычных списках файлов, но продолжал занимать место.

Диск освободился только после того, как я перезапустил веб-сервер, и он закрыл все свои файловые дескрипторы.

Вот почему нужны разные команды, чтобы видеть реальную картину:

# Проверить использование ФС
df -h  

# Проверить реальные размеры директорий
du -sh /var/log/*  

# Найти удалённые файлы, которые всё ещё держат процессы
lsof +L1

du показывает, что реально занимает место в директориях, а df - использование на уровне файловой системы.

Если цифры не сходятся, скорее всего, у тебя есть удалённые файлы, которые всё ещё держат процессы.

По этой же причине корректная ротация логов не просто удаляет файлы. Инструменты вроде logrotate переименовывают файлы и шлют сигнал процессам, чтобы те закрыли и заново открыли дескрипторы.

Три ключевых вывода:
1. Имена файлов — это всего лишь указатели на inode
2. Удаление действительно происходит, только когда ни один процесс не ссылается на inode
3. При разборе проблем с местом на диске всегда смотрите и df, и du

Мелочь, но понимание этого может спасти от очень запутанных инцидентов в продакшене.

👉 DevOps Portal

Как работает контроль доступа в Linux

👉 DevOps Portal

Полный курс по GitHub Actions от новичка до профи (на английском)

Изучите всё: от основ платформы до построения полноценной DevOps-системы с воркфлоу для тестирования, сборки и деплоя микросервисных приложений

https://youtu.be/Xwpi0ITkL3U?si=7JwUaKlRQ7mfxwLQ

👉 DevOps Portal

Эта статья объясняет Kubernetes Services: их типы и конфигурацию с практическими примерами для работы с кластерной сетью.

В ней рассматриваются такие типы сервисов, как ClusterIP, NodePort, LoadBalancer, ExternalName и Headless Service.

Читать здесь

👉 DevOps Portal

Плагин для kubectl, который позволяет выполнять запросы к ресурсам Kubernetes с использованием SQL-подобного синтаксиса. Вы можете фильтровать, проецировать и сортировать Pod’ы, PVC и т. д., без написания «сырого» jq или JSONPath

GitHub: kubectl-df-pv

👉 DevOps Portal

Одним из ключевых элементов продакшен-готовности кластеров Kubernetes является обеспечение высокой доступности (HA).

Однако достижение HA само по себе недостаточно; нужно быть готовыми реагировать на отказы.

Проводите эксперименты по отказам в контролируемой среде, чтобы эффективно устранять реальные инциденты:
https://labs.iximiuz.com/playgrounds/kubernetes-ha-d02b8d83

👉 DevOps Portal

Инструмент, который автоматически выполняет чекпойнтинг контейнеров на диск через определённое время после последнего TCP-соединения, что позволяет быстро и бесшовно масштабироваться до нуля

GitHub: zeropod

👉 DevOps Portal

Быстрый совет для Linux

Вы можете посмотреть неудачные попытки входа на ваш Linux-сервер с помощью команды:

$ lastb

Эта команда просто считывает данные из /var/log/btmp и отображает их в удобном для чтения формате.

👉 DevOps Portal

Пауза и возобновление процессов в Linux с помощью cgroup Freezer

Заморозка позволяет безопасно приостановить процесс без его завершения. Это полезно для:

🔹Приостановки тяжёлого джоба в часы пиковых нагрузок

🔹Паузы сервиса для переконфигурации окружения

🔹Аудита безопасности и отладки

Практика тут

👉 DevOps Portal

Неймспейсы: пошаговое руководство по изоляции в Kubernetes

Узнайте, как создавать, управлять и чистить неймспейсы в Kubernetes с помощью простых команд kubectl. Организуйте свой кластер и избегайте дорогостоящих ошибок.

Читайте здесь

👉 DevOps Portal

12 практик по усилению безопасности Kubernetes

Статья для тех, кто только начинает знакомиться с миром безопасности Kubernetes. В ней описан набор из 12 практик, которые точно будут полезны

Читайте здесь

👉 DevOps Portal

Все пользуются Docker, но очень немногие знают, как дебажить контейнер Docker

Нет, я не про docker logs, или docker inspect, или docker exec.

Я про docker events.

Скорее всего, ты даже не знал, что он существует. Но он стримит низкоуровневые события в реальном времени прямо от Docker-демона; не только по твоему контейнеру.

Представь ситуацию:

Ваш контейнер в проде постоянно рестартится. А у вас локально всё ок.

И как настоящий герой, ты заходишь по SSH на сервер и начинаешь привычный дебаг-ритуал:

👉 docker logs → ничего
👉 docker inspect → статика
👉 docker exec → не успеваете подключиться, он умирает раньше

Знакомо, да?

Что дальше? Дай угадаю:

Ты начинаешь шаманить с Dockerfile и гонять его подряд через docker run. Просто потому, что никогда не слышал про docker events.

А теперь попробуй вот так:

docker events --filter container=<your_container_id>

Пример вывода:

2025-05-04T18:20:01Z container create ...
2025-05-04T18:20:02Z container start ...
2025-05-04T18:20:03Z container health_status: unhealthy ...
2025-05-04T18:20:04Z container kill signal=SIGTERM
2025-05-04T18:20:04Z container restart

И вуаля. Healthcheck завалился → контейнер прибили → Docker его автоматически перезапустил.

А в логах твоего приложения этого нет. Потому что healthcheck живёт вне основного процесса.

Бонус-фичи:

🔹Ограничить интервал по времени:

docker events --since 30m --until "2025-05-04T18:00:00"

🔹Хотите структурированный вывод?

docker events --format '{{json .}}'

🔹Нужен полный таймлайн по системе во время инцидента? Просто убери фильтр:

docker events

И прежде чем сказать:

«Ну вообще-то, в современной инфре надо использовать Grafana, Loki, Prometheus для наблюдаемости…»

Окей. Удачи дебажить:

🔹OOM-киллы до того, как метрики успели заскрейпиться
🔹Пропущенные монтирования томов
🔹Сломанные init-контейнеры
🔹Сайдкары, которые тихо падают и рестартуются

docker events всё это видит. В реальном времени.

Если вы дебажите Docker без этого, вы не дебажите - вы гадаете.

👉 DevOps Portal