Radius — это платформенный уровень с открытым исходным кодом, предназначенный для облачных приложений. Он помогает разработчикам и операционным командам сосредоточиться на разработке и сопровождении приложений, а не на управлении инфраструктурой.
Radius предоставляет:
* Единый опыт разработки для приложений, развертываемых в разных облаках и средах.
* Поддержку нескольких облаков и Kubernetes.
* Интеграции с популярными инструментами, такими как Terraform, Bicep, Helm и другие.
* Ресурсы приложений и вычислений, включая службы, базы данных, кэш, очереди и т. д.
* Безопасность и сетевые политики, управляемые централизованно.
https://github.com/radius-project/radius
#devops #девопс
Подпишись 👉@i_DevOps
Radius предоставляет:
* Единый опыт разработки для приложений, развертываемых в разных облаках и средах.
* Поддержку нескольких облаков и Kubernetes.
* Интеграции с популярными инструментами, такими как Terraform, Bicep, Helm и другие.
* Ресурсы приложений и вычислений, включая службы, базы данных, кэш, очереди и т. д.
* Безопасность и сетевые политики, управляемые централизованно.
https://github.com/radius-project/radius
#devops #девопс
Подпишись 👉@i_DevOps
👍2
🔧 Про grep, который умеет больше, чем ты думаешь
Все знают
📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?
Покажет 3 строки до и после найденной.
📍 Ищем по слову, а не по вхождению
Не хочешь ловить
Совпадение только по целому слову.
📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:
📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:
📍 Цвет для глаз
Визуально быстрее цепляться за результат:
Если ты думаешь, что
#devops #девопс
Подпишись 👉@i_DevOps
Все знают
grep как утилиту “найди мне это слово в этих логах”. Но давай копнём глубже — вот тебе пара трюков, которые удивят даже видавшего виды девопса:📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?
grep -C 3 "ошибка" /var/log/syslog
Покажет 3 строки до и после найденной.
📍 Ищем по слову, а не по вхождению
Не хочешь ловить
ошибка, если в логе есть предошибкака?
grep -w "ошибка" файл.log
Совпадение только по целому слову.
📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:
grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' лог.txt
📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:
grep -rIn --exclude-dir={.git,node_modules} "TODO" .
📍 Цвет для глаз
Визуально быстрее цепляться за результат:
grep --color=auto "fail" журнал.log
Если ты думаешь, что
grep — это просто "найди слово", то, возможно, ты не используешь весь его потенциал. А зря 😉#devops #девопс
Подпишись 👉@i_DevOps
👍14❤1
Когда Kubernetes и Go не очень хорошо работают вместе
Go не знает об ограничениях, установленных для его контейнера, что приводит к некоторым проблемам, которые нелегко отследить. Это история о том, как я наткнулся на одну из них.
https://lalatron.hashnode.dev/when-kubernetes-and-go-dont-work-well-together
#devops #девопс
Подпишись 👉@i_DevOps
Go не знает об ограничениях, установленных для его контейнера, что приводит к некоторым проблемам, которые нелегко отследить. Это история о том, как я наткнулся на одну из них.
https://lalatron.hashnode.dev/when-kubernetes-and-go-dont-work-well-together
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Домашняя серверная для DevOps: установка GitLab + Let's Encrypt
Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру.
Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).
Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.
В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить, что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).
https://habr.com/ru/companies/banki/articles/909028/
#devops #девопс
Подпишись 👉@i_DevOps
Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру.
Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).
Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.
В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить, что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).
https://habr.com/ru/companies/banki/articles/909028/
#devops #девопс
Подпишись 👉@i_DevOps
👍5❤3
Сложная оркестрация
Статья посвящена оркестрации инфраструктуры в гибридных облаках. Описываются подходы к автоматизации сложных рабочих процессов, включая управление конфигурациями, миграции баз данных, динамическое управление инвентарем и кросс-облачную оркестрацию. Особое внимание уделяется отказоустойчивости, масштабируемости и интеграции различных инструментов для обеспечения надежной и эффективной работы распределенных систем.
https://habr.com/ru/articles/910422/
#devops #девопс
Подпишись 👉@i_DevOps
Статья посвящена оркестрации инфраструктуры в гибридных облаках. Описываются подходы к автоматизации сложных рабочих процессов, включая управление конфигурациями, миграции баз данных, динамическое управление инвентарем и кросс-облачную оркестрацию. Особое внимание уделяется отказоустойчивости, масштабируемости и интеграции различных инструментов для обеспечения надежной и эффективной работы распределенных систем.
https://habr.com/ru/articles/910422/
#devops #девопс
Подпишись 👉@i_DevOps
👍3❤1
aws-network-policy-agent — это агент политики сети для Kubernetes, который обеспечивает реализацию Kubernetes NetworkPolicy на уровне VPC для Pod'ов в Amazon VPC Lattice. Он используется в сочетании с VPC Lattice integration for Amazon EKS.Агент реализует политики сети Kubernetes, управляя исходящим трафиком Pod'ов через VPC Lattice Service Network, разрешая или блокируя соединения в соответствии с правилами, заданными в NetworkPolicy.
https://github.com/aws/aws-network-policy-agent
#devops #девопс
Подпишись 👉@i_DevOps
👍3
AList — это система для индексирования и управления файлами в облачном хранилище, предоставляющая веб-интерфейс и API. Поддерживает множество облачных хранилищ, таких как OneDrive, Google Drive, Dropbox, WebDAV и другие. Позволяет просматривать, скачивать и делиться файлами через веб-интерфейс без необходимости скачивать их на локальное устройство. AList написан на Go и легко разворачивается.
Основные возможности:
* Поддержка множества облачных хранилищ
* Удобный веб-интерфейс
* Гибкие настройки прав доступа
* REST API для интеграции
* Простота установки и настройки
https://github.com/AlistGo/alist
#devops #девопс
Подпишись 👉@i_DevOps
Основные возможности:
* Поддержка множества облачных хранилищ
* Удобный веб-интерфейс
* Гибкие настройки прав доступа
* REST API для интеграции
* Простота установки и настройки
https://github.com/AlistGo/alist
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Docker Images for Frp Based on Alpine and Debian
(amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le,riscv64, s390x)
https://github.com/snowdreamtech/frp
#devops #девопс
Подпишись 👉@i_DevOps
(amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le,riscv64, s390x)
https://github.com/snowdreamtech/frp
#devops #девопс
Подпишись 👉@i_DevOps
GitHub
GitHub - snowdreamtech/frp: Docker Images for Frp.
Docker Images for Frp. . Contribute to snowdreamtech/frp development by creating an account on GitHub.
👍1
Понимание динамического масштабирования ресурсов Kubernetes и ускорения CPU
Одним из ключевых преимуществ Kubernetes является его способность эффективно управлять ресурсами контейнеров. Однако, по мере роста приложений и увеличения нагрузки, понимание того, как Kubernetes масштабирует ресурсы и использует возможности процессора, становится критически важным.
Что такое динамическое масштабирование ресурсов?
Динамическое масштабирование ресурсов — это механизм Kubernetes, который позволяет подстраивать лимиты ресурсов контейнеров во время их выполнения. Это особенно полезно в сценариях с переменной нагрузкой, где контейнеры могут требовать больше ресурсов в пиковые моменты и меньше — в периоды простоя.
Для этого Kubernetes использует такие инструменты, как:
* Vertical Pod Autoscaler (VPA) — автоматически регулирует запросы и лимиты ресурсов у подов.
* Horizontal Pod Autoscaler (HPA) — масштабирует количество подов в зависимости от метрик (например, загрузки CPU).
Что такое CPU Boost?
На уровне ядра Linux существует функция под названием CPU Boost (часто называемая Turbo Boost на процессорах Intel), которая позволяет временно увеличивать частоту CPU выше номинальной, если это необходимо.
Kubernetes позволяет использовать CPU Boost, но важно понимать, что:
* CPU boost не гарантируется, даже если ты укажешь высокий лимит CPU.
* Он может сработать, если:
* Контейнер запущен с
* У узла есть свободные ресурсы.
* Система не перегружена по температуре и энергопитанию.
Почему это важно?
Если твои приложения чувствительны к задержкам и требуют быстрой реакции (например, real-time обработка), то использование CPU Boost может дать кратковременное, но значительное улучшение производительности.
Но полагаться на него как на стабильную стратегию масштабирования не стоит — это больше бонус, чем гарантированный ресурс.
Практические рекомендации
1. Используй
2. Настрой
3. Не рассчитывай на CPU Boost как на основу производительности.
4. Мониторь реальные метрики и подстраивай конфигурации.
https://cloud.google.com/blog/products/containers-kubernetes/understanding-kubernetes-dynamic-resource-scaling-and-cpu-boost
#devops #девопс
Подпишись 👉@i_DevOps
Одним из ключевых преимуществ Kubernetes является его способность эффективно управлять ресурсами контейнеров. Однако, по мере роста приложений и увеличения нагрузки, понимание того, как Kubernetes масштабирует ресурсы и использует возможности процессора, становится критически важным.
Что такое динамическое масштабирование ресурсов?
Динамическое масштабирование ресурсов — это механизм Kubernetes, который позволяет подстраивать лимиты ресурсов контейнеров во время их выполнения. Это особенно полезно в сценариях с переменной нагрузкой, где контейнеры могут требовать больше ресурсов в пиковые моменты и меньше — в периоды простоя.
Для этого Kubernetes использует такие инструменты, как:
* Vertical Pod Autoscaler (VPA) — автоматически регулирует запросы и лимиты ресурсов у подов.
* Horizontal Pod Autoscaler (HPA) — масштабирует количество подов в зависимости от метрик (например, загрузки CPU).
Что такое CPU Boost?
На уровне ядра Linux существует функция под названием CPU Boost (часто называемая Turbo Boost на процессорах Intel), которая позволяет временно увеличивать частоту CPU выше номинальной, если это необходимо.
Kubernetes позволяет использовать CPU Boost, но важно понимать, что:
* CPU boost не гарантируется, даже если ты укажешь высокий лимит CPU.
* Он может сработать, если:
* Контейнер запущен с
Guaranteed QoS.* У узла есть свободные ресурсы.
* Система не перегружена по температуре и энергопитанию.
Почему это важно?
Если твои приложения чувствительны к задержкам и требуют быстрой реакции (например, real-time обработка), то использование CPU Boost может дать кратковременное, но значительное улучшение производительности.
Но полагаться на него как на стабильную стратегию масштабирования не стоит — это больше бонус, чем гарантированный ресурс.
Практические рекомендации
1. Используй
requests и limits с умом: слишком заниженные requests могут привести к throttling.2. Настрой
HPA и VPA, чтобы обеспечить гибкость и эффективность.3. Не рассчитывай на CPU Boost как на основу производительности.
4. Мониторь реальные метрики и подстраивай конфигурации.
https://cloud.google.com/blog/products/containers-kubernetes/understanding-kubernetes-dynamic-resource-scaling-and-cpu-boost
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤2
Forwarded from Bash Советы
🔁 Как перезапускать сервис только если он завис?
Иногда не хочется перезапускать сервис "на всякий случай", но вот если он реально завис — другое дело. Вот простой способ проверять, активен ли сервис, и перезапускать его при зависании:
🛠 Можно добавить в крон, например, проверку каждые 5 минут:
📁 Не забудь сделать скрипт исполняемым:
💡 Можно заменить
👉@bash_srv
Иногда не хочется перезапускать сервис "на всякий случай", но вот если он реально завис — другое дело. Вот простой способ проверять, активен ли сервис, и перезапускать его при зависании:
#!/bin/bash
SERVICE="nginx"
if ! systemctl is-active --quiet "$SERVICE"; then
echo "$(date): $SERVICE не активен, пробую перезапустить..." >> /var/log/service_monitor.log
systemctl restart "$SERVICE"
else
echo "$(date): $SERVICE работает нормально" >> /var/log/service_monitor.log
fi
🛠 Можно добавить в крон, например, проверку каждые 5 минут:
*/5 * * * * /usr/local/bin/check_nginx.sh
📁 Не забудь сделать скрипт исполняемым:
chmod +x /usr/local/bin/check_nginx.sh
💡 Можно заменить
nginx на любой другой системный сервис.👉@bash_srv
🥴5❤3👍3👎2
This media is not supported in your browser
VIEW IN TELEGRAM
k'exp - Kubernetes Explorer
Создан не для управления продом, а для изучения кубера через визуализацию.
k'exp предназначен для:
Изучение и исследование возможностей Kubernetes
Разработка приложений (предварительные наборы объектных графов для каждого приложения)
Разработка контроллеров и операторов (динамические графы объектов)
[скоро появится] Postman-подобный клиент и конструктор запросов для Kubernetes API
k'exp может отражать состояние вашего кластера в режиме реального времени:
https://github.com/iximiuz/kexp
#devops #девопс
Подпишись 👉@i_DevOps
Создан не для управления продом, а для изучения кубера через визуализацию.
k'exp предназначен для:
Изучение и исследование возможностей Kubernetes
Разработка приложений (предварительные наборы объектных графов для каждого приложения)
Разработка контроллеров и операторов (динамические графы объектов)
[скоро появится] Postman-подобный клиент и конструктор запросов для Kubernetes API
k'exp может отражать состояние вашего кластера в режиме реального времени:
https://github.com/iximiuz/kexp
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Как проверить, что твои бэкапы не просто занимают место?
Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?
🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.
🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.
🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.
🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.
🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.
Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!
#devops #девопс
Подпишись 👉@i_DevOps
Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?
🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.
🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.
🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.
🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.
🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.
Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!
#devops #девопс
Подпишись 👉@i_DevOps
👌4
🚀 Kubernetes 1.32: пять фич, которые стоит попробовать прямо сейчас
* Auto-delete PVC для StatefulSet
StatefulSet наконец-то умеет сам удалять PVC, когда поды и сам объект больше не нужны. Включите
* Память-backed emptyDir с динамическим размером
Теперь
* Field Selectors для CRD
Custom Resource теперь поддерживает
*
Подам больше не нужен костыль, чтобы узнать IPv4/IPv6 узла в dual-stack-кластере: адреса приходят прямо в Downward API.
* Node name в ServiceAccount JWT
Узел теперь прописывается в SA-токен, что упрощает Validating/Mutating Admission Policies и сокращает риск эскалации прав.
💡 Как обновиться
1. Скачайте свежий
2. Проверьте deprecated API в релиз-нотах.
3. Включите нужные Feature Gates — и в бой!
#devops #девопс
Подпишись 👉@i_DevOps
* Auto-delete PVC для StatefulSet
StatefulSet наконец-то умеет сам удалять PVC, когда поды и сам объект больше не нужны. Включите
StatefulSetAutoDeletePVC и задайте persistentVolumeClaimRetentionPolicy — забудете про ручную очистку хранилища. * Память-backed emptyDir с динамическим размером
Теперь
emptyDir { medium: "Memory" } может автоматически подстраиваться под лимиты RAM вашего пода (или заданный лимит), а не фиксированные 50 %. Отлично для временных кэшей и build-джобов. * Field Selectors для CRD
Custom Resource теперь поддерживает
--field-selector, как “родные” объекты K8s. Фильтруйте CR легко, без дополнительных label-index. *
status.hostIPs в GAПодам больше не нужен костыль, чтобы узнать IPv4/IPv6 узла в dual-stack-кластере: адреса приходят прямо в Downward API.
* Node name в ServiceAccount JWT
Узел теперь прописывается в SA-токен, что упрощает Validating/Mutating Admission Policies и сокращает риск эскалации прав.
💡 Как обновиться
1. Скачайте свежий
kubeadm 1.32 и выполните kubeadm upgrade plan && kubeadm upgrade apply v1.32.2. Проверьте deprecated API в релиз-нотах.
3. Включите нужные Feature Gates — и в бой!
#devops #девопс
Подпишись 👉@i_DevOps
👍6❤1
Изучение групп и версий API в Kubernetes
Kubernetes — мощная платформа оркестрации контейнеров, предлагающая широкий набор возможностей через свой API (интерфейс программирования приложений). Для эффективного использования функционала Kubernetes крайне важно понимать структуру его API, включающую группы API и версии. В этой статье мы рассмотрим виды групп API в Kubernetes с примерами, демонстрирующими их значение, а также подробно остановимся на версиях API для полного понимания.
https://devopsvoyager.hashnode.dev/exploring-kubernetes-api-groups-and-versions
#devops #девопс
Подпишись 👉@i_DevOps
Kubernetes — мощная платформа оркестрации контейнеров, предлагающая широкий набор возможностей через свой API (интерфейс программирования приложений). Для эффективного использования функционала Kubernetes крайне важно понимать структуру его API, включающую группы API и версии. В этой статье мы рассмотрим виды групп API в Kubernetes с примерами, демонстрирующими их значение, а также подробно остановимся на версиях API для полного понимания.
https://devopsvoyager.hashnode.dev/exploring-kubernetes-api-groups-and-versions
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Forwarded from Библиотека девопса | DevOps, SRE, Sysadmin
Привет, друзья! Сегодня разберём, как выстроить надёжный GitOps-процесс с помощью Argo CD и Kubernetes.
1. Архитектура репозитоpиев
* Monorepo vs Multirepo: в зависимости от масштаба проектов выбирайте единое или раздельное хранилище манифестов.
* Разделяйте окружения (prod/stage/dev) по разным папкам или веткам.
2. Декларативность
* Храните все Kubernetes-манифесты (Deployment, Service, Ingress, ConfigMap, Secret) в Git.
* Все изменения проходят через MR/PR с обязательным код-ревью и автоматическим CI-проверками (lint, kubeval).
3. Установка и конфигурация Argo CD
* Подключите репозиторий:
* URL: ваш Git-сервер
* Type: Git
* Auth: SSH-ключ или токен
* Создайте приложение (
4. Автосинхронизация и управление откатом
* Включите
* Настройте
* Активируйте
5. Мониторинг и оповещения
* Подключите Prometheus и Grafana к Argo CD через метрики и вебхуки.
* Настройте оповещения в Slack или Telegram о неудачных синках и drift’ах.
6. Секреты и конфигурации
* Используйте Sealed Secrets или HashiCorp Vault для безопасного хранения.
* Аргокаталоги монтируйте через CSI-драйверы, чтобы не держать секреты в Git.
7. Best Practices
* Разделяйте права доступа через RBAC — кто может мёржить изменения в prod.
* Периодически пересматривайте Git-историю и чистите устаревшие ветки.
* Проводите тренировку «chaos engineering» — симулируйте сбои при помощи LitmusChaos или Chaos Mesh.
Небольшой чеклист перед деплоем:
* [ ] CI-лейблы зелёные
* [ ] Артефакты в артефактном репозитории
* [ ] Инфраструктурные тесты пройдены
* [ ] Определён ответственный за rollback
Успешного вам релиза и минимальных «рывков» в проде!
Подпишись 👉@devopslib
1. Архитектура репозитоpиев
* Monorepo vs Multirepo: в зависимости от масштаба проектов выбирайте единое или раздельное хранилище манифестов.
* Разделяйте окружения (prod/stage/dev) по разным папкам или веткам.
2. Декларативность
* Храните все Kubernetes-манифесты (Deployment, Service, Ingress, ConfigMap, Secret) в Git.
* Все изменения проходят через MR/PR с обязательным код-ревью и автоматическим CI-проверками (lint, kubeval).
3. Установка и конфигурация Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
* Подключите репозиторий:
* URL: ваш Git-сервер
* Type: Git
* Auth: SSH-ключ или токен
* Создайте приложение (
Application), где укажете target-кластер и путь к манифестам.4. Автосинхронизация и управление откатом
* Включите
syncPolicy.automated для мгновенного применения изменений.* Настройте
pruneResources: true, чтобы удалять неактуальные объекты.* Активируйте
selfHeal: true — Argo CD будет восстанавливать конфигурацию при ручных правках.5. Мониторинг и оповещения
* Подключите Prometheus и Grafana к Argo CD через метрики и вебхуки.
* Настройте оповещения в Slack или Telegram о неудачных синках и drift’ах.
6. Секреты и конфигурации
* Используйте Sealed Secrets или HashiCorp Vault для безопасного хранения.
* Аргокаталоги монтируйте через CSI-драйверы, чтобы не держать секреты в Git.
7. Best Practices
* Разделяйте права доступа через RBAC — кто может мёржить изменения в prod.
* Периодически пересматривайте Git-историю и чистите устаревшие ветки.
* Проводите тренировку «chaos engineering» — симулируйте сбои при помощи LitmusChaos или Chaos Mesh.
Небольшой чеклист перед деплоем:
* [ ] CI-лейблы зелёные
* [ ] Артефакты в артефактном репозитории
* [ ] Инфраструктурные тесты пройдены
* [ ] Определён ответственный за rollback
Успешного вам релиза и минимальных «рывков» в проде!
Подпишись 👉@devopslib
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Statusnook — это открытое (MIT) self-hosted решение для быстрого развёртывания страницы статуса и мониторинга HTTP-эндпоинтов с оповещениями в Email и Slack.
https://github.com/goksan/statusnook
#devops #девопс
Подпишись 👉@i_DevOps
https://github.com/goksan/statusnook
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Selectel Billing Exporter
Это экспортёр для Prometheus, который позволяет собирать метрики расходов в Selectel. С его помощью можно мониторить свои траты на сервисы Selectel прямо через привычные инструменты наблюдения.
Он поддерживает получение информации о балансе и детализации расходов по каждому сервису. Для работы потребуется указать API-токен Selectel.
https://github.com/mxssl/selectel-billing-exporter
#devops #девопс
Подпишись 👉@i_DevOps
Это экспортёр для Prometheus, который позволяет собирать метрики расходов в Selectel. С его помощью можно мониторить свои траты на сервисы Selectel прямо через привычные инструменты наблюдения.
Он поддерживает получение информации о балансе и детализации расходов по каждому сервису. Для работы потребуется указать API-токен Selectel.
https://github.com/mxssl/selectel-billing-exporter
#devops #девопс
Подпишись 👉@i_DevOps
👍6❤🔥1
🗂️ Как найти большие файлы в системе
Иногда на сервере внезапно заканчивается место, и нужно срочно найти, какие файлы занимают больше всего пространства. Вот простая команда на bash:
🔹 Что делает этот скрипт:
* Ищет все файлы больше 500 МБ по всему серверу.
* Показывает их размер и путь.
* Сортирует список по размеру — самые большие файлы будут вверху.
Совет:
Если нужно искать не по всему серверу, а только в домашней папке, просто поменяй
#devops #девопс
Подпишись 👉@i_DevOps
Иногда на сервере внезапно заканчивается место, и нужно срочно найти, какие файлы занимают больше всего пространства. Вот простая команда на bash:
find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null | awk '{ print $NF ": " $5 }' | sort -hr -k2
🔹 Что делает этот скрипт:
* Ищет все файлы больше 500 МБ по всему серверу.
* Показывает их размер и путь.
* Сортирует список по размеру — самые большие файлы будут вверху.
Совет:
Если нужно искать не по всему серверу, а только в домашней папке, просто поменяй
/ на ~/.#devops #девопс
Подпишись 👉@i_DevOps
👍11🔥4
Лечим проблемы Kubernetes на лету по мере масштабирования проекта: опыт команды VK Cloud
Производительность etcd-кластера со множеством объектов — головная боль команд, которые любят и ценят Kubernetes. И вот почему: чаще всего для роста производительности кластера используют горизонтальное скалирование, а это приводит к нагрузке на кластер из-за увеличения времени согласования записи данных. В результате вместо шустрого кластера получается неповоротливый тяжеловес.
Меня зовут Алексей Волков. Я менеджер продукта Cloud Containers в VK Cloud. В этой статье я расскажу о кейсе одного из наших клиентов: с каким запросом он пришел и с какими сложностями сталкивался, как мы провели тюнинг etcd-кластера и какие настройки нужны, чтобы повысить производительность Kubernetes.
https://habr.com/ru/companies/vktech/articles/911542/
#devops #девопс
Подпишись 👉@i_DevOps
Производительность etcd-кластера со множеством объектов — головная боль команд, которые любят и ценят Kubernetes. И вот почему: чаще всего для роста производительности кластера используют горизонтальное скалирование, а это приводит к нагрузке на кластер из-за увеличения времени согласования записи данных. В результате вместо шустрого кластера получается неповоротливый тяжеловес.
Меня зовут Алексей Волков. Я менеджер продукта Cloud Containers в VK Cloud. В этой статье я расскажу о кейсе одного из наших клиентов: с каким запросом он пришел и с какими сложностями сталкивался, как мы провели тюнинг etcd-кластера и какие настройки нужны, чтобы повысить производительность Kubernetes.
https://habr.com/ru/companies/vktech/articles/911542/
#devops #девопс
Подпишись 👉@i_DevOps
👍3❤1
Docker на каждый день: Ключевые команды в одной статье-шпаргалке
Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.
https://habr.com/ru/articles/913978/
#devops #девопс
Подпишись 👉@i_DevOps
Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.
https://habr.com/ru/articles/913978/
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤1