DevOps

🏎💨Не позволяйте вашим приложениям терять скорость! Обрабатывайте задачи эффективно с FastAPI.

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

Освойте FastAPI и научитесь улучшать производительность приложений. Повышение скорости ответа и снижение нагрузки — это реально.

⚡️Присоединяйтесь к открытому вебинару 20 мая в 20:00 мск и получите скидку на большое обучение «Python Developer. Basic»: https://vk.cc/cLX2tL

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Radius — это платформенный уровень с открытым исходным кодом, предназначенный для облачных приложений. Он помогает разработчикам и операционным командам сосредоточиться на разработке и сопровождении приложений, а не на управлении инфраструктурой.

Radius предоставляет:

* Единый опыт разработки для приложений, развертываемых в разных облаках и средах.
* Поддержку нескольких облаков и Kubernetes.
* Интеграции с популярными инструментами, такими как Terraform, Bicep, Helm и другие.
* Ресурсы приложений и вычислений, включая службы, базы данных, кэш, очереди и т. д.
* Безопасность и сетевые политики, управляемые централизованно.

https://github.com/radius-project/radius

#devops #девопс

Подпишись 👉@i_DevOps

⏳ Хотите перестать тратить часы на рутинные задачи сборки релизов 1С и автоматизировать весь процесс одним нажатием?

⏺На открытом вебинаре 21 мая в 20:00 МСК вы узнаете, как использовать Docker, Jenkins и OneScript для автоматизации сборки релизов 1С. Разберёмся с настройкой окружения контейнера и запуском конфигурации напрямую из репозитория.

После урока вы сократите время на сборку и получите навыки для профессионального роста как DevOps-инженер 1С.

🚀 Присоединяйтесь к открытому вебинару и получите специальную скидку на курс «DevOps 1С»: https://vk.cc/cLX1pz

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Централизованный vs Децентрализованный ArgoCD

Разворачивая в Kuberentes ArgoCD есть 2 подхода, которые можно использовать, если у вас в контуре несколько кластеров Kubernetes, развертывания в которых неободимо с помощью ArgoCD:

Централизированный. Когда в одном Kubernetes разворачивается один ArgoCD и к нему подключаются все доступные кластера Kuberentes.

Децентрализованный. Когда в каждом Kuberentes’e разворачивается свой персональный ArgoCD, который занимается деплоем в этот Kuberentes.

Разберём плюсы и минусы каждого подхода.

Централизированный ArgoCD

Плюсы:
1️⃣ Единый интерфейс. Можно быстро отсортировать проблемные компоненты и понять причину ошибки.

2️⃣ Мощные CRD ApplicationSets (документация). Позволяют описать один компонент и разом раскатить его на все подключённые кластеры.

3️⃣ Удобное обновление ArgoCD. Достаточно обновить в одном месте, и оно сразу применяется ко всем кластерам.


Минусы:
1️⃣ Сетевые сложности. ArgoCD должен иметь доступ к kube-apiserver всех кластеров. Соответственно нужно продумать маршруты до этих API и защитить их.

2️⃣ Единая точка отказа и уязвимость. Если ArgoCD падает, управление всеми кластерами временно недоступно. Слабое место с точки зрения безопасности. Особенно опасно, если подключать кластеры с Cluster-Admin правами (что все и делают).


Децентрализированный ArgoCD

Плюсы:
1️⃣ Полная автономность кластеров. Каждый кластер полностью управляется своим ArgoCD. Если один ArgoCD сломается, это не повлияет на другие кластеры.

2️⃣ Упрощённая безопасность. Нет необходимости прокидывать сетевые доступы к kube-apiserver из централизованного ArgoCD.

3️⃣ Гибкость в настройке. Можно кастомизировать ArgoCD под конкретный кластер. Удобно для multi-tenant окружений, где каждый проект или команда живут в отдельный Kuberentes кластерах и управляет своим ArgoCD.

Минусы:
1️⃣ Больше инфраструктуры и поддержки. Нужно поддерживать N независимых ArgoCD-инсталляций. Дополнительная нагрузка на команду DevOps.

2️⃣ Отсутствие единого интерфейса. Придётся заходить в каждый ArgoCD по отдельности, чтобы мониторить состояние. (Решается мониторингом). Если нужно что-то обновить во всех кластерах, придётся делать это вручную или автоматизировать через внешние инструменты (еще один ArgoCD?).

3️⃣ Сложность в управлении глобальными компонентами. Например, если нужно одновременно обновить общий Helm-чарт во всех кластерах, придётся либо использовать внешние механизмы (типа CI/CD), либо делать это вручную.


🎯 Какой вариант выбрать?

✔ Много кластеров (10+) → Централизованный ArgoCD, но с HA и жёсткими мерами безопасности.

✔ Изолированные кластеры (air-gapped, private) → Локальный ArgoCD в каждом кластере.

✔ Нужна гибкость в управлении → Децентрализованный вариант.

✔ Важно минимизировать затраты на инфраструктуру → Централизованный ArgoCD.

#devops #девопс

Подпишись 👉@i_DevOps

Распределённый инференс и шардирование LLM. Часть 2: скрипт vLLM, Ray Serve для вывода API и настройка KubeRay Cluster

Часть 1

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

В первой части статьи мы подготовили всё необходимое для развёртывания распределённого инференса с Ray Serve и vLLM. Сегодня этим и займёмся. Мы напишем скрипт vLLM, используем Ray Serve, чтобы предоставить внешний HTTP API, а также настроим KubeRay Cluster и развернём в нём Gemma 3.

https://habr.com/ru/companies/flant/articles/906702/

#devops #девопс

Подпишись 👉@i_DevOps

🚀 Открой для себя идеальный путь к лидерству с карьерным тестом от ОЭЗ «Алабуга»! 🌟

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

После прохождения теста вы можете заполнить заявку и получить приглашение на эксклюзивную лидерскую программу. Участие в программе открывает реальные перспективы трудоустройства в ОЭЗ «Алабуга», предоставляя шанс начать путь к профессиональному признанию.

Сделайте первый шаг к своему будущему сегодня! Пройдите тест, подайте заявку и начните строить свою карьеру вместе с нами. 🎯

💡 Как DevOps'у не утонуть в логах

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

Вот несколько проверенных приёмов, которые реально спасают время:

🔹 Стандартизируй формат логов. JSON — твой друг. Структурированные логи можно парсить, фильтровать и индексировать.

🔹 Сразу думай про central logging. Loki + Grafana, Elasticsearch + Kibana или даже простой Fluent Bit + S3. Главное — не SSH на 20 серверов.

🔹 Добавляй trace_id во все логи. Это твой маяк в море. Особенно полезно, когда надо отслеживать один запрос через всю систему.

🔹 Фильтры, фильтры, фильтры. Хорошие правила фильтрации в Grafana или Kibana — это как хороший кофе с утра. Делают день лучше.

🔹 Логи — это не помойка. Не пиши туда print("Hello from service X"). Пиши полезное: ошибки, статусы, идентификаторы.

И напоследок: не забывай про ротацию и retention. Логи не должны жить вечно, особенно если ты не хочешь платить лишнее за storage.

#devops #девопс

Подпишись 👉@i_DevOps

📢 JSON — это удобно. До тех пор, пока всё не ломается.

Гибкий формат без схем кажется спасением, но на масштабе превращается в источник ошибок, конфликтов и головной боли.

🔍 Schema Registry — это способ вернуть контроль. На открытом уроке 19 мая в 19:00 МСК разберём:
— В чём слабые места JSON без схем;
— Как Schema Registry помогает валидации и версионированию;
— Когда всё-таки можно обойтись без схем;
— Какие инструменты реально работают (Avro, Protobuf, JSON Schema).

📊 Урок будет полезен разработчикам, дата-инженерам, архитекторам и PM, которые сталкиваются с интеграциями и масштабируемыми системами.

👉 Регистрируйтесь и получите скидку на программу обучения «Apache Kafka»: https://vk.cc/cLVDDQ

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Распределённый инференс и шардирование LLM. Часть 1: настройка GPU, проброс в Proxmox и настройка Kubernetes

Когда модель DeepSeek R1 стала широко обсуждаться в сообществе, я заинтересовался, можно ли эффективно использовать её и другие крупные модели в домашних условиях, не прибегая к дорогостоящим облачным сервисам. Поскольку DevOps и инфраструктурой я увлекаюсь уже несколько лет, у меня постепенно сформировалась домашняя лаборатория, на которой я и решил проверить эту идею.

Эта статья в трёх частях — результат моего опыта в решении этой задачи. Внутри вас ждёт пошаговое руководство по реализации бюджетного распределённого инференса с использованием Ray Serve, vLLM, Kubernetes, Proxmox и других технологий. В первой части мы разберём настройку GPU и его проброс в Proxmox, развернём Kubernetes-кластер, установим GPU Operator и KubeRay Operator.

https://habr.com/ru/companies/flant/articles/906700/

#devops #девопс

Подпишись 👉@i_DevOps

Почему Fedora CoreOS — это container optimized дистрибутив

Fedora CoreOS на официальном сайте представлена как container optimized, container-focused, container based и так далее OS. Но что это вообще значит? Там предустановлен какой-то container runtime? А еще что? В этой статье попытаемся разобраться.

→ Что такое optimized
→ Иммутабельная система и транзакционные обновления
→ Автоматические background-обновления
→ Запуск системы на основе контейнер-образа
→ Безопасность
→ Предустановленные инструменты для контейнеров
→ Гибкий деплой
→ Заключение

https://habr.com/ru/companies/selectel/articles/817299/

#devops #девопс

Подпишись 👉@i_DevOps