DevOps

🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю. 🧠 Зачем нужен KHI: • Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад • KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами 🚀 Что умеет: • Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения • Поддерживает фильтры и поиск — быстро находит нужные события • Работает без агентов — использует уже существующие логи • Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое 🛠 Подходит для: • Отладки инцидентов и RCA (root cause analysis) • Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда 📎GitHub: https://github.com/GoogleCloudPlatform/khi @devopsitsec

🌒 LunaTrace — бесплатный open-source инструмент для аудита безопасности зависимостей. Он автоматически сканирует зависимости в проектах, выявляет уязвимости и интегрируется с GitHub Pull Requests, чтобы предупреждать о рисках до деплоя. Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем. 🤖GitHub @devsecops

🧠Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с 💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus. Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова. 🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ. 📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления. 🔍Что можно вынести: • Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть • Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение • Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке 📎Оригинальный пост на Reddit @devopsitsec

🏰SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа. Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами. 🤖GitHub @devopsitsec

🖥Шпаргалка по командам Linux для среднего и продвинутого уровня Сохраняйте себе, чтобы не потерять 📌Полная версия онлайн

⚡️OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу. Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose. 🤖GitHub @devopsitsec

🔧DevOps Pro Tips: Оптимизация контейнеров как у SRE Google Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥продвинутые советы по настройке контейнеров: ⚫ Ограничь права контейнера docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ... ▪️--read-only — защищает файловую систему ▪️--cap-drop=ALL — удаляет лишние привилегии ▪️no-new-privileges — запрещает повышение прав в процессе ⚫ Установи лимиты CPU и памяти docker run --memory="512m" --cpus="1.5" ... ▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах ▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки ⚫ Чисти от мусора - Используй multi-stage builds — минимизируй размер образа - Оставляй только необходимые бинарники и конфиги - Пример: FROM golang:1.22 as builder WORKDIR /app COPY . . RUN go build -o app FROM alpine:3.19 COPY --from=builder /app/app /bin/app ENTRYPOINT ["/bin/app"] ⚫ Используй distroless или Alpine - Образы типа gcr.io/distroless/static — без шелла, package manager и мусора - alpine — легче, но следи за совместимостью с glibc ⚫ Пропиши healthcheck HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1 ▪️ Kubernetes будет перезапускать только при реальных сбоях ⚫Подключи observability - Встраивай Prometheus exporter - Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека) - Используй otel, если нужен tracing ⚫ Проверь, чем занят контейнер docker top <container> docker inspect --format '{{ .HostConfig }}' <container> ▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev 💡 Эти практики критичны, если: - Вы деплоите в прод с autoscaling - Контейнеры крутятся в k8s или Fargate - Вам важно сократить издержки на ресурсы и повысить безопасность Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна. @devopsitsec

🚀 VS Code трансформируется в опенсорнсый ИИ-редактор! Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ. Конкуренция - двигатели прогресса! Где-то напряглась команда Cursor 🤓 🔗 Подробности: aka.ms/open-source-ai-editor #VSCode#OpenSource#ИИ#Разработка#Сообщество

🛠️Отправка уведомлений Slack из shell-скриптов Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так. Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях. Сервер упал? Получите уведомление. Скрипт завершил выполнение? Получите уведомление. Добавив уведомления Slack в свои shell-скрипты, вы можете: - 📣 легко делиться результатами работы скриптов с командой, - 🛡️ быстро реагировать на проблемы, - 🔍 быть в курсе событий без просмотра логов. > Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash. 🔗 Webhook + curl: секретная связка Slack позволяет использовать входящие Webhook-и для получения сообщений. А curl позволяет отправлять эти сообщения через HTTP POST. Принцип: - Slack даёт вам URL вида https://hooks.slack.com/services/... - Вы используете curl для отправки JSON с текстом сообщения. ⚙️ Как включить входящие Webhook в Slack 1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps) 2. Создайте новое приложение 3. В разделе Incoming Webhooks — активируйте их 4. Добавьте Webhook в рабочее пространство (выберите канал) 5. Сохраните Webhook URL — он понадобится далее 💬 Bash-скрипт для отправки уведомлений Добавьте Webhook в .bashrc: export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url" Пример скрипта мониторинга: #!/bin/bash source ~/notify_slack.sh disk_usage=$(df -h / | awk 'NR==2 {print $5}') cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs) hostname=$(hostname) message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load" notify_slack "$message" ✅Рекомендации Не хардкодьте токены — используйте переменные окружения Slack ограничивает частоту Webhook-запросов Используйте уведомления только при необходимости (ошибки, алерты и т.п.) Теперь вы можете: - Добавить Slack-уведомления в свои cron-задачи - Отслеживать состояние системы - Получать оповещения об ошибках в скриптах. Подробнее

🌐Задача-ловушка: Пропавший трафик после настройки iptables Условие: На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH: iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок. На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта: docker run -d -p 8080:80 nginx ❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает. Дополнительно, если выполнить: curl http://localhost:8080 — сервер отвечает нормально. Но с других машин — нет. ❓Вопрос: Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему? 🔍Подсказка: Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов. ✅Разбор: 💥Ловушка: Ваш iptables-правила: iptables -P INPUT DROP iptables -P FORWARD DROP iptables -A INPUT -p tcp --dport 22 -j ACCEPT запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так! Когда Docker пробрасывает порт с хоста (например, 8080), схема такая: - Входящий пакет попадает в цепочку PREROUTING (nat) - Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию: iptables -P FORWARD DROP Поэтому трафик до контейнера блокируется именно на этапе FORWARD. 🔧Как проверить: Запустить: iptables -L -v -n Вы увидите, что счётчик пакетов в FORWARD показывает дропы. 🛠Как починить: Добавить правило разрешения проброса пакетов для Docker: iptables -A FORWARD -o docker0 -j ACCEPT Или (более строго): iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT ✅Вывод: • В Linux iptables цепочки работают по строгой логике: - INPUT — для пакетов к хосту - FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы) • Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT. 💡Бонус-вопрос: Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

🦙RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо. Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов. 🤖GitHub @devopsitsec

🧠 DevOps-задача: "Контейнер Шрёдингера" Условие: Ты получаешь баг-репорт: > "Приложение внутри Docker-контейнера после деплоя не работает, но docker exec показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа." Что известно: - Docker-контейнер на основе alpine:3.18 - Приложение запускается через CMD ["/bin/service-start"] - Порт 8080 проброшен (`-p 8080:8080`) - curl localhost:8080 внутри контейнера возвращает 200 OK - curl localhost:8080 на хосте — зависает - netstat -tulpn показывает, что порт 8080 прослушивается внутри Задача: Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ. 📌Разбор: 🕵️ Подвох №1: **приложение слушает 127.0.0.1:8080**, а не 0.0.0.0 • внутри `curl localhost:8080` работает • а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host Решение: - Проверить снаружи: `docker inspect <container_id> | grep IPAddress` - Проверить bind-порт внутри: ```bash netstat -tulpn | grep 8080 # или ss -tulpn | grep 8080 ``` - Если видим `127.0.0.1:8080` — всё ясно: нужно слушать на `0.0.0.0:8080` 🛠 Исправление: 1. Проверь запуск приложения. Может, внутри у тебя: ```bash python3 app.py ``` и он слушает только на localhost? Добавь: ```bash python3 app.py --host=0.0.0.0 ``` 2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на 127.0.0.1 Проверь в настройках приложения или командной строке 🎯 Что проверяет задача: • Умение мыслить в терминах изоляции контейнеров • Понимание сетевых пространств имён (network namespaces) • Знание, как работает NAT между контейнером и хостом • Умение диагностировать "невидимый" bind • Привычку **проверять всё снаружи**, а не только внутри контейнера Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.