OpenObserve — cloud-native платформа наблюдаемости, специально созданная для логов, метрик, трейсов, аналитики и RUM (Real User Monitoring — производительность, ошибки, воспроизведение сессий), спроектированная для работы в петабайтном масштабе

https://github.com/openobserve/openobserve

👉 DevOps Portal

В сети поделились секретом, как правильно обновить Kubernetes: без падения прода

👉 DevOps Portal

На YouTube вышел свежий англоязычный курс по DevOps. Собираем и деплоим масштабируемый продакшен-готовый API

Быстро освоите базу DevOps в этом крэш-курсе, охватывающем Git и GitHub, CI/CD-пайплайны, Docker, Kubernetes, IaC и деплой API. Всё, что нужно, чтобы автоматизировать разработку и деплой

5 часов контента здесь

👉 DevOps Portal

Создаём контейнер наподобие Docker с нуля

Освойте ключевые пространства имён Linux, собрав небольшой, но реалистичный контейнер, используя только штатные команды Linux: unshare, mount и pivot_root. Никакой магии рантайма и (почти) никаких упрощений.

Изучаем здесь

👉 DevOps Portal

Что будет с вашими данными, если система упадёт до того, как они будут сохранены?

Здесь и появляется концепция Write-Ahead Log (WAL).

Это простой принцип проектирования систем.

- Каждая операция (например, вставка в базу данных) сначала записывается в специальный лог-файл.

- Как только запись надёжно зафиксирована в логе, система обновляет реальную базу данных или хранилище.

- Если система падает, вы можете воспроизвести лог (система читает сохранённые шаги), чтобы вернуть данные в корректное состояние.

Вот короткое руководство, которое охватывает несколько реальных кейсов:
https://newsletter.devopscube.com/p/write-ahead-log-wal

👉 DevOps Portal

Как работают Kubernetes Services?

Вероятно, вы знаете, что где-то там замешаны iptables, но знаете ли вы точную последовательность цепочек, задействованных при маршрутизации трафика к ClusterIP? А как насчёт NodePort - там по-другому?

Вот очень подробная статья, разбирающая всю «магию» за сервисами Kubernetes, простыми словами объясняя базовые вещи и продвинутые темы, такие как сохранение исходных IP, обработка завершающихся endpoints и интеграция с облачными балансировщиками нагрузки.

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

👉 DevOps Portal

CLI-утилита Kubernetes Resource Recommender помогает оптимизировать выделение ресурсов в кластерах Kubernetes.

Она собирает метрики использования подов из Prometheus и рекомендует значения requests и limits для CPU и памяти.

Это снижает расходы и повышает производительность.

Забираем на GitHub

👉 DevOps Portal

Годная шпаргалка по cron в Linux с примерами

👉 DevOps Portal

Быстрый совет по Linux

При просмотре файла через less можно вывести краткий статус, нажав клавишу =.

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

👉 DevOps Portal

Практика с Docker: обновление контейнеризованного приложения без потери данных

По умолчанию у контейнеров есть относительно постоянная файловая система - изменения, внесённые приложением, переживают перезапуски контейнера, вызванные падениями приложения, перезагрузками хоста и т. п.

Однако иногда может потребоваться использовать тома, чтобы сделать некоторые части файловой системы контейнера более долговечными, чем остальные. С томами, даже если вы полностью удалите контейнер (а не просто перезапустите его), вы сможете продолжить использовать данные приложения в контейнере-преемнике (например, то же приложение, но на более новом образе).

Попрактикуйтесь в использовании томов Docker в этом практическом задании здесь

👉 DevOps Portal

CloudNativePG — это оператор Kubernetes, который охватывает весь жизненный цикл высокодоступного кластера PostgreSQL с архитектурой primary/standby, использующей нативную стриминговую репликацию.

GitHub: CloudNativePG

👉 DevOps Portal

Как легко мигрировать ingress на Gateway API в Kubernetes

Статья рассказывает, как мигрировать с Ingress на Gateway API в Kubernetes, связав контроллер GatewayAPI и существующий Ingress-контроллер за одним LoadBalancer, чтобы минимизировать простой и сделать переход поэтапным

Читать здесь

👉 DevOps Portal

Grafana + Kubernetes

Репозиторий для любителей Grafana - огромное количество действительно стоящих дашбордов для Kubernetes.

GitHub: grafana-dashboards-kubernetes

👉 DevOps Portal

Эта статья предлагает способ интеграции 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