⚙️10 стратегий снижения рисков в гибридных облаках

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

Чтобы эффективно управлять гибридной инфраструктурой, необходимо соблюдать правила, которые помогут снизить эти риски и повысить стабильность.

➡️ Про стратегии минимизации рисков в статье

🐸Библиотека devops'a

#буст

📰 Недельный дайджест

Собрали для вас материалы прошедшей недели.

— AWS CLI v2 теперь доступен для macOS

С версии 2.30.0 AWS CLI v2 предоставляет универсальные бинарные установщики для macOS, которые работают нативно как на процессорах Apple Silicon, так и на Intel.

— Динамическое обновление доступных слотов в k8s

В Kubernetes v1.34 поддержка динамического обновления количества доступных слотов для CSI-драйверов перешла в стадию Beta. Теперь драйверы могут периодически обновлять информацию о количестве доступных слотов для подключения томов.

— Вышел KDE Linux Alpha

— Unit-лид и Technical Owner

— FreeBSD 15.0-ALPHA1

🐸Библиотека devops'a

🐳 Шпаргалка по сетям Docker

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

Основные типы сетей

• Bridge — сеть по умолчанию.

Контейнеры получают внутренний IP и могут общаться друг с другом. Для связки нескольких сервисов в одной среде лучше создавать свои пользовательские сети (docker network create). Тогда контейнеры будут доступны по имени, например ping db.

• Host — общая сеть с хостом.

Контейнер не имеет отдельного IP: он использует сетевой стек машины. Это снижает изоляцию, но убирает накладные расходы на маршрутизацию. Подходит для сервисов, где важна скорость.

• None — полная изоляция.

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

• Overlay — сеть для кластера.

Объединяет несколько Docker-хостов. Используется в Swarm и Kubernetes. Контейнеры на разных серверах работают так, будто они рядом.

• Macvlan — контейнер как полноценный участник LAN.

Контейнер получает MAC-адрес и «выглядит» в локальной сети как отдельное устройство. Это удобно, если требуется доступ из реальной сети напрямую, например для IoT или legacy-приложений.

Полезные команды

Список сетей:

docker network ls

Подробная информация о сети:

docker network inspect bridge

Создать сеть:

docker network create mynet

Удалить сеть:

docker network rm mynet

Подключить контейнер к сети:

docker network connect mynet app1

Отключить контейнер от сети:

docker network disconnect mynet app1

🐸Библиотека devops'a

#буст

🔄 Как переехать из Kubernetes в Terraform

Когда инфраструктура разрастается — десятки кластеров, множество регионов, разные окружения — управление Kubernetes через локальные манифесты, Helm-чарты, скрипты и ad-hoc утилиты становится болью.

Почему вообще стоит рассматривать Terraform

— Единый подход к инфраструктуре как к коду (IaC). Меньше ad-hoc скриптов, меньше особенных случаев.

— Одинаковые шаблоны, модули, terraform-пакеты можно применять для разных кластеров, регионов, окружений.

— Когда инфраструктура описана декларативно в Terraform, её проще тестировать, планировать изменения и откатывать.

С чего начать переезд

Прежде чем двигать сервисы, стоит договориться о структуре: где хранится код, как выглядят модули, как будут разделены окружения вроде dev, staging и prod.

Важно определиться с управлением состоянием: локальные файлы .tfstate неприемлемы в продакшене, поэтому лучше сразу настроить удалённое хранилище — например, S3 с DynamoDB для блокировок или Terraform Cloud.

Следующий шаг — начать с малого. Не стоит пытаться перенести сразу весь кластер или десятки сервисов. Лучше выбрать один изолированный сервис, у которого нет сложных зависимостей, и попробовать описать его в Terraform.

Так команда поймёт процесс, столкнётся с первыми проблемами импорта и научится проверять планы перед применением.

Когда базовые принципы обкатаны, становится ясно, что без инструментов миграция будет мучительной. Поэтому стоит вложиться в создание шаблонов и модулей. Один модуль может описывать типовой сервис — Deployment, Service и Ingress. Другой — целый namespace или набор ресурсов для окружения.

Самая непростая часть — импорт существующих ресурсов. Kubernetes кластеры редко пустые, в них уже работают десятки объектов. Их нужно постепенно поднимать под контроль Terraform, используя команду terraform import. Но просто импортировать недостаточно — нужно сверять, чтобы конфигурация в HCL совпадала с реальностью.

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

Главная ценность миграции — в стандартизации. Инфраструктура становится предсказуемой и масштабируемой, а команды получают единый язык управления. Это долгий процесс, но итогом становится устойчивая и безопасная платформа.

🐸Библиотека devops'a

#буст

😊 Выберите свой класс

🐸Библиотека devops'a

#развлекалово

🔄 Миграция пайплайнов

GitHub Actions и GitLab CI/CD похожи по сути, но несовместимы по форме. Просто копипаста из .github/workflows недостаточно — у GitLab свой формат, правила и возможности. Поэтому мы подготовили для вас промпт для удобного переезда.

Промпт:

Перенеси нашу текущую систему CI/CD с платформы GitHub на GitLab CI/CD, включая все workflow, скрипты и конфигурации из .github/workflows. Адаптируй конфигурации под формат .gitlab-ci.yml с учётом особенностей GitLab CI, языков программирования, используемых инструментов и окружений в проекте. Обеспечь корректную работу всех этапов сборки, тестирования и деплоя, а также настрой уведомления и артефакты. В конце опиши поэтапно весь процесс миграции, укажи все необходимые изменения и предоставь рекомендации по проверке и отладке нового CI/CD конвейера.

🐸Библиотека devops'a

#буст

🚀 Grafana Mimir: улучшения производительности и экономии памяти

В Grafana Mimir представили новый движок запросов (Mimir Query Engine, MQE) и теперь работать с данными стало проще, быстрее и экономичнее.

Что изменилось

• Большие запросы больше не тормозят систему — данные обрабатываются частями прямо на лету.

• Использование памяти упало на 70%, а запросы стали выполняться до 80% быстрее!

• Даже при высоких нагрузках система держится уверенно, без сбоев.

Теперь Grafana Mimir — это инструмент, который не только собирает данные, но и делает это умно, быстро и без лишней нагрузки на серверы.

➡️ Блог разработчиков

🐸Библиотека devops'a

#пульс_индустрии

🛠 4 утилиты для работы с текстом в терминале

Когда работаешь с логами в ход обычно идут grep и awk. Но есть и другие инструменты, которые спасают не меньше:

• tr — заменяет или убирает символы:

cat names.txt | tr '[:lower:]' '[:upper:]'

Команда превратит весь текст в CAPS LOCK.

• sort — сортирует строки:

cat errors.log | sort

Хаос превращается в аккуратный список.

• uniq — убирает дубликаты:

cat users.txt | sort | uniq

• nl — нумерует строки:

cat config.yaml | nl

Удобно искать по номерам, а не на глаз.

Вместе они превращают любой текстовый файл в данные, с которыми приятно работать.

Например:

cat access.log | cut -d' ' -f1 | sort | uniq -c | sort -nr | nl | head

Топ-10 IP-адресов по количеству запросов, с нумерацией.

🐸Библиотека devops'a

#арсенал_инженера

🌐 Делим ресурсы умно в k8s

В Kubernetes 1.34 появилась возможность DRA Consumable Capacity. Теперь можно выделять конкретные части устройства (например, 8 ГБ памяти из виртуальной GPU) для разных Pod'ов, не ограничиваясь полным выделением устройства. Один ресурс может быть разделён между несколькими Pod'ами или контейнерами, если это поддерживается драйвером устройства.

Введено новое ограничение DistinctAttribute, предотвращающее многократное выделение одного и того же ресурса внутри одного ResourceClaim, что важно для обеспечения отказоустойчивости и распределения нагрузки.

Чтобы активировать эту функцию, необходимо включить флаг DRAConsumableCapacity в kube-apiserver, kubelet, kube-scheduler и kube-controller-manager:

--feature-gates=...,DRAConsumableCapacity=true

➡️ Блог kubernetes

🐸Библиотека devops'a

#пульс_индустрии

👋 Amazon уходит из облака

Amazon Web Services остаётся крупнейшим игроком на рынке, но всё чаще звучит тезис: компания пересматривает стратегию облака. Разбираем, что стоит за этим и куда движется инфраструктура.

AWS остаётся ядром компании, но Amazon перестраивает архитектуру и уходит от модели «чистого облака». Причина в том, что централизованные дата-центры всё чаще сталкиваются с ограничениями.

Во-первых, задержки: для логистики, IoT и real-time приложений критично, чтобы вычисления происходили ближе к пользователю, а не через тысячи километров.

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

В-третьих, регуляторика: данные приходится хранить локально, а не в удалённых центрах, из-за требований GDPR и национальных законов.

Ответ Amazon на эти вызовы — активные инвестиции в edge-computing, развитие гибридных решений и оптимизация инфраструктуры через Nitro Systems. Это не отказ, а эволюция: облако остаётся, но становится более распределённым и ближе к конечным пользователям.

В перспективе нас ждёт сдвиг: вместо выбора между «облаком» и «on-prem» компании будут строить гибридные системы, балансируя между скоростью, стоимостью и безопасностью.

🐸Библиотека devops'a

#разбор_полётов