Рубрика «‎эксперименты»:‎ MicroShift

Одноплатники Raspberry Pi всегда были предметом для дискуссий. На них пробовали запускать буквально всё: от Doom до гипервизора VMware ESXi. Тренд на использование Kubernetes не обошёл и Red Hat. Так родился MicroShift — экспериментальная платформа для устройств, развернутых в полевых условиях. С вами Evrone! Устраивайтесь поудобнее и мы расскажем подробности.

Встречаем MicroShift

Начнём с того, что это исследовательский проект. Инженеры Red Hat взяли за основу свою платформу оркестрации OpenShift. Эта платформа была доработана для минимального потребления ресурсов и работает в привычном для одноплатников Linux.

Смысл в том, чтобы записать образ в устройство, доставить его к месту эксплуатации и включить в сеть. После этого таким устройством можно управлять, используя Red Hat Advanced Cluster Manager в соответствии с практиками GitOps. Разрабатываемый образ способен работать в условиях очень ограниченных ресурсов, но при этом остаётся безопасным и устойчивым к сетевым проблемам.

Такая система полезна, когда необходимо наглядно показать работу и поведение оркестрации. Берём с собой в рюкзаке несколько одноплатных компьютеров с MicroShift и самый простой сетевой свитч. Получаем крошечный, но вполне себе серьёзный тестовый стенд для отработки отказов и масштабирования. Кроме того, MicroShift поддерживает интеграцию и управление с помощью стандартного OpenShift.

Grafana Tempo обновилась до v1.3

Распределённая система трассировки Grafana Tempo получила долгожданное обновление до версии v1.3. С приходом архитектуры на основе микросервисов стало сложнее отследить, почему тормозит тот или иной пользовательский запрос. Каждый из них может быть комплексным и состоять из десятков более простых обращений. Выявить проблемное обращение без точной трассировки будет почти нереально, особенно если проблема «плавающая».

Самое заметное — появление поиска по внутреннему хранилищу данных. Высокой скоростью он не отличается, но это будет исправлено в будущих релизах. Разработчики обещают поднять её на порядки и сделать сравнимой с быстрым поиском в Loki. Кстати, скоро эта же функция появится и в Grafana Cloud.

Ещё одним изменением стало решение проблемы с компакторами. Часто при разворачивании новых компакторов, старые отправлялись в своего рода лимб и были обречены вечно оставаться в хэш-кольце со статусом Unhealthy. Приходилось уничтожать их вручную. Отличный сценарий для фильма ужасов, верно? Сейчас же система ждет 2 heartbeat-таймаута и сама отправляет неработоспособные записи в забвение.

Что такое Observability

Читая статьи на тему DevOps, мы часто натыкаемся на слово observability. Наиболее точный перевод этого термина — наблюдаемость. Но что скрывается за этим понятием? За чем мы должны наблюдать и как это делать? Является ли наблюдаемость неотъемлемым свойством или в каких-то случаях им можно пренебречь? Ответ на эти вопросы можно найти в репозитории проекта Cloud Native Computing Foundation, где этому посвящен целый whitepaper.

Советуем более пристально посмотреть не столько на сам термин, сколько на экосистему вокруг него. Метрики, журналы и трассировки — три священных грааля наблюдаемости, но на самом деле есть еще парочка, о которых можно задуматься. Это профили приложений и аварийные дампы.

Первые раньше не использовались из-за высоких накладных расходов. Сейчас же эти расходы на профилировщики не слишком велики. Зато они позволяют понять, какая часть приложения создает проблемы с задержками.

Аварийные дампы, несмотря на очевидную пользу, легко могут стать «бутылочным горлышком‎», особенно в облачной среде. Дело в размере, ведь каждый сбор дампа сгенерирует неприлично большое количество данных, которые надо где-то сохранить (а перед этим еще и передать по сети). Так что применять их можно лишь в весьма конкретных ситуациях, полностью владея данными об инфраструктуре.

CRUD или Event Sourcing

Вопрос выбора правильной архитектуры не всегда прост. Давным-давно архитектура CRUD (Create, Read, Update, Delete) используется в качестве шаблона для отслеживания счетов, данных клиентов и так далее. В целом она действительно проста для понимания, но с точки зрения кода приходится тратить значительные ресурсы на её реализацию. Проблемы возникают на этапе организации балансировки нагрузки и взаимодействии с другими компонентами, такими как микросервисы.

Архитектура источников событий (Event Sourcing) может рассматриваться как доработанный CRUD, из которого выкинули Update и Delete. В CRUD каждое изменение сразу фиксируется, как текущее состояние. В Event Sourcing текущее состояние записывается в виде серии дельт.

Получается история событий из которой легко воспроизвести состояние в прошлом. Такая архитектура подходит для анализа потока событий. Из него легко извлекать важную информацию. Производительность увеличивается, поскольку нет необходимости обновлять и удалять записи, всё концентрируется вокруг операций записи.

Если взглянуть пристально на Event Sourcing, то мы увидим архитектуру, задача которой сохранение полной истории событий, которая легко может быть подвергнута аудиту. Ещё такая история событий может быть использована, к примеру, в качестве входных данных для машинного обучения и аналитики.

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

Из недостатков — по сравнению с CRUD сильно вырастет потребление дискового пространства. Ещё значительно возрастёт когнитивная нагрузка на разработчиков, поскольку происходит полноценная смена парадигм. Возникнут неожиданные эффекты, которые сложно предсказать. Менять ли классический CRUD на Event Sourcing — вопрос остается открытым.

Дорогая, я уменьшил контейнер

Хотите уменьшить свой Docker-контейнер и сделать его раз в 30 меньше по размеру? Тогда вам сюда. DockerSlim — отличный инструмент, позволяющий выбросить из контейнера всё, что не задействуется приложением. С одной стороны это ускоряет процесс развертывания, а с другой делает образы более безопасными, сокращая поверхность атаки.

Большинство принимают размер контейнера как данность, но на самом деле там есть множество компонентов, которые можно выбросить без ущерба для работоспособности и производительности. DockerSlim позволяет посмотреть от чего именно можно избавиться, перед тем, как выполнять оптимизацию, с помощью команды xray. Непосредственная оптимизация выполняется командой build.

Конкурсы для разработчиков