DevOps MemOps

Почему я создал ctx_: переключатель контекстов, который действительно понимает работу DevOps

ctx рассматривает вашу среду DevOps как единый переключаемый контекст. kubectx отлично справляется с тем, что делает, но решает лишь одну часть головоломки: контексты Kubernetes. А как насчет учетных данных AWS/GCP/Azure, SSH-туннелей к базам данных, VPN-соединений, переменных окружения, токенов Vault, конфигураций пользователя Git и профилей браузера для SSO?

📌 Подробнее: https://dev.to/vlebo/why-i-built-ctx-the-context-switcher-that-actually-gets-devops-work-3059

MemOps 🤨

MemOps 😃

openrun — платформа с открытым исходным кодом (лицензия Apache-2.0) для развертывания веб-приложений. OpenRun упрощает декларативное развертывание контейнеризованных веб-приложений. OpenRun может развертывать приложения на одном узле или в кластере Kubernetes. OpenRun предоставляет декларативное развертывание по принципу GitOps (blue-green), контроль доступа через OAuth/OIDC/SAML, управление сертификатами TLS и секретами. OpenRun создан для команд, чтобы они могли легко развертывать внутренние инструменты с полной поддержкой RBAC. Приложения OpenRun развертываются напрямую из репозитория git, сервер сборки не требуется. OpenRun масштабирует приложения до нуля в режиме простоя и поддерживает атомарные обновления для нескольких приложений.

📌 Подробнее: https://github.com/openrundev/openrun

MemOps 🤨

MemOps 😃

Как я подружил self-hosted Supabase с VictoriaMetrics, VictoriaLogs, Grafana и Vector

Я развернул self-hosted Supabase в Docker и собрал для него отдельный observability-контур. Метрики собирает vmagent и хранит VictoriaMetrics, логи собирает Vector и отправляет в VictoriaLogs, а Grafana стала единым интерфейсом. Сначала я прокидывал логи через HTTP-адаптер на Edge Function, но затем перенёс ingestion в Vector: он уже входит в Supabase-стек, читает docker-логи, умеет нормализовать их в VRL и отправляет данные батчами на отдельный сервер мониторинга.

📌 Подробнее: https://habr.com/ru/articles/1057950/

MemOps 🤨

MemOps 😃

Как я уведомления мониторинга в мессенджер национальный переносил

Я в первую очередь хочу заострить внимание на той категории пользователей данных сервисов, у которой от оперативности прихода уведомлений о статусе работы поддерживаемых систем напрямую зависит лояльность их клиентов, а соответственно доход и наличие средств к существованию в принципе. Да, речь о нашей админской доле. Потому всем, кто ожидал здесь лучи праведного гнева в адрес всем известных ведомств нашей страны, можно статью дальше не читать и искать за этим другую - их в сети сейчас достаточно.

До весны текущего года пока работал Telegram с его отличнейшим (без сарказма, не побоюсь этого слова) Bot API, данная проблема в принципе не всплывала. Zabbix мониторил сервера, при проблемах кидал уведомления в Бота, Бот их кидал в нужную группу. Из группы брали в работу и спокойно приводили к статусу Resolved. Но в начале весны для RU сегмента все кардинально изменилось. API эндпоинты Telegram заблокировали, соответственно уведомления приходить перестали.

📌 Подробнее: https://habr.com/ru/articles/1059120/

MemOps 🤨

MemOps 😃

teleskopio —- небольшой и красивый веб-клиент для Kubernetes с открытым исходным кодом.

Возможности:
— поддержка нескольких конфигураций: переключение между кластерами происходит без усилий. Teleskopio считывает переменную $KUBECONFIG и проверяет файл config.yaml.
— простая авторизация с помощью JWT-токена.
— роли администратора и наблюдателя: полный доступ (администратор) или доступ только для чтения (наблюдатель) к кластеру.
— обзор кластера: получите общее представление о состоянии и активности кластера.
— редактор/создатель ресурсов: интегрированный редактор Monaco Editor с подсветкой синтаксиса.
— обновления в реальном времени: изменения ресурсов в режиме реального времени с помощью наблюдателей Kubernetes.
— журналы подов и события: просматривайте журналы и историю событий непосредственно в пользовательском интерфейсе.
— ссылки владельца: переход от ресурса к его владельцу.
— CRD: редактор пользовательских определений ресурсов.
— множество вариантов шрифтов: настройка внешнего вида пользовательского интерфейса, светлая и темная темы.
— запуск CronJob вручную
— масштабирование ресурсов (развертывания, репликационные наборы)
— отфильтруйте любой ресурс с помощью CTRL + F.
— переход к разделу CTRL + J в любом меню.
— операции множественного выбора объектов (удаление, удаление, блокировка и т. д.)
— это нативная реализация на языке Go, которая взаимодействует напрямую с API-сервером Kubernetes.
— схемы ресурсов Kubernetes для каждой версии API.
— интеграция Helm.
— нет необходимости устанавливать в систему какие-либо внешние зависимости или инструменты.
— готовы к использованию изолированные среды. Внешние запросы не принимаются.

📌 Подробнее: https://github.com/teleskopio/teleskopio

MemOps 🤨

MemOps 😃

Your Container Is Not a Sandbox — статья о том, как microvm могут стать тем самым решением для ситуаций, когда использовать контейнеры становится не так уж и безопасно. Автор показывает и сравнивает несколько технологий, которые доступны для использования сегодня. Отдельный смак в интерактивных элементах на странице.

📌 Подробнее: https://emirb.github.io/blog/microvm-2026/

MemOps 🤨

MemOps 😃

G2ray — удобный VLESS-менеджер прокси для GitHub Codespaces.

G2ray - это мощная интерактивная панель Bash, предназначенная для мгновенного развертывания и управления конфигурациями Xray VLESS XHTTP. Разработанная специально для среды GitHub Codespaces, она автоматизирует управление портами, мониторинг трафика и поддержание соединений.

Возможности:
- развертывание и управление в один клик: создавайте и запускайте модули за считанные секунды. Удобный интерфейс командной строки с меню делает управление узлами и просмотр конфигурационных ссылок в реальном времени простым и удобным.
- интеллектуальная система автоматического поддержания жизни: встроенные фоновые циклы и продвинутые симуляторы Tmux предотвращают отключение GitHub Codespaces из-за бездействия, поддерживая туннель открытым.
- аналитика в реальном времени и квоты: отслеживает потребление данных RX/TX в режиме реального времени и активно контролирует использование ресурсов (процессор/оперативная память). Точно оценивает оставшуюся квоту бесплатного тарифа на 60 часов.
- настройка сети сообщества: передайте сгенерированную конфигурацию напрямую из командной строки, чтобы безопасно предоставить доступ сообществу, не влияя на скорость работы и не раскрывая личные данные.

📌 Подробнее: https://github.com/Code-Leafy/G2rayXCodeLeafy

MemOps 🤨

MemOps 😃

ClusterHound — инструмент, который встраивает Kubernetes в BloodHound. С помощью kubectl он собирает топологию кластера и его RBAC-конфигурацию, после чего выгружает результат в OpenGraph JSON для импорта. Главная идея в том, что многошаговые цепочки атак в Kubernetes — захват сервис-аккаунтов, эскалация привилегий, побег с хоста, доступ к секретам — превращаются в проходимые рёбра графа, по которым можно строить маршруты атак.

Под капотом кластер моделируется как 15 типов узлов и 27 типов рёбер, а рёбра отдаются как structured graph, который нативно понимает встроенный pathfinding BloodHound. В комплекте идёт 31 готовый Cypher-запрос — от анализа точек входа до кратчайших путей до полной компрометации кластера. Инструмент работает только на чтение (get/list) и мапит ровно столько, сколько видят используемые учётные данные, поэтому его можно запускать как на весь кластер, так и в рамках отдельных namespace.

Требуется Python 3.8+, kubectl и BloodHound CE версии 9.0 и выше. Проект активно развивается.

📌 Подробнее: https://github.com/dovesec/ClusterHound

MemOps 🤨

MemOps 😃

chainloop — хранилище доказательств с открытым исходным кодом для аттестаций цепочки поставок программного обеспечения, спецификаций материалов программного обеспечения (SBOM), VEX, отчетов SARIF, отчетов QA и многого другого. С помощью Chainloop команды по безопасности, соответствию требованиям и управлению рисками могут определять политики безопасности и соответствия, какие доказательства и артефакты они хотят получать и где их хранить. С другой стороны, разработчики защищены от всей этой сложности, получая простые инструкции о том, что предоставлять при внедрении их конвейеров CI/CD.

📌 Подробнее: https://github.com/chainloop-dev/chainloop

MemOps 🤨

MemOps 😃

Как снизить Latency в Kubernetes?

Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!

1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:

kubectl edit configmap -n kube-system kube-proxy

Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.

2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:

helm install cilium cilium/cilium --namespace kube-system

3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов.

4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

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

5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.

MemOps 🤨

Работа сисадмина:

MemOps 😃