Предыстория

Предыдущая статья

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

В Sitri данная проблема решается достаточно просто — с помощью локального режима для ваших классов настроек, то есть вам не придётся даже переписывать ничего или дублировать код, да и структура json файла для локального режима будет почти полностью повторять структуру секретов.

Итак, ну а теперь, давайте добавим в наш проектик буквально пару строк кода + я покажу, как со всем этим можно работать, если ваш проект локально запускается в docker-compose.

«@Netflixhelps Почему "Король тигров" не идет на моем телефоне?» — подписчик Netflix спрашивает через Twitter

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

Всем привет! 

Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта? 

Всем привет. Сегодня мы хотели бы поговорить про выявления аномалий в микросервисной среде. Данный пост является краткой выжимкой нашего 40 минутного доклада, который мы делали на онлайн конференции DevOps Live 2020 и, чтобы не писать лонгрид, мы решили сфокусироваться на обзоре инструментов выявления аномалий в распределении значений метрик для автоматизации мониторинга микросервисов, которые возможно быстро начать использовать любой команде.

Тема детектирования аномалий сейчас очень актуальна, так как с переходом на микросервисы для SRE и DevOps приоритет задач, связанных с преобразованием алертов в осмысленный сигнал, снижением MTTD и упрощением настройки алертов в мониторинге распределенных сред значительно повысился.

Предисловие

Продолжение саги. Сразу, на всякий случай

В данной статье я расскажу о конфигурации для вашей сервисов с помощью связки Vault (KV и пока только первой версии, т.е. без версионирования секретов) и Pydantic (Settings) под патронажем Sitri.

В рамках современной микросервисной архитектуры мы можем разделить микросервисы на две основные группы в зависимости от их взаимосвязи и взаимодействия. Первая группа представляет из себя внешние микросервисы, которые напрямую доступны пользователям. В основном это API на основе HTTP, которые используют обычные текстовые сообщения (JSON, XML и т. д.), оптимизированные для использования сторонними разработчиками, использующие передачу репрезентативного состояния (REST) ​​в качестве коммуникационной технологии. 

Распространенность и хорошая поддержка REST играют решающую роль в успехе внешних микросервисов. OpenAPI предоставляет четко определенные спецификации для описания, создания, использования и визуализации REST API. Для таких API существуют системы управления API, которые обеспечивают безопасность, ограничение скорости, кеширование и монетизацию наряду с реализацией бизнес-требований. В качестве альтернативы REST API на основе HTTP можно использовать GraphQL, но это уже тема для отдельной статьи.

В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?

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

На прошлой неделе мы выложили пост про то, как мы мониторим backend и микросервисную инфраструктуру с помощью Instana, и пообещали написать продолжение про мониторинг frontend.

В итоге мы решили не ограничиваться обзором Instana в качестве инструмента контроля frontend, а копнуть немного глубже и рассказать, для чего вообще нужен End User Monitoring, с какими проблемами производительности фронта мы сталкиваемся чаще всего, какие мы используем сценарии работы с собранными данными, и как Instana помогает нам контролировать пользовательский опыт в целом.

В статье перечислены особенности двух популярных форматов сериализации, которые следует учитывать архитектору, выбирая один из них.

За последние пару лет мне довольно часто приходилось сталкиваться с Kubernetes, однако обычно это всегда происходило с позиции разработчика. Посмотреть список подов, их статусы, логи и т.п. В общем, ничего сложного.

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

Обычно изучение Kubernetes стоит начинать с minikube - консольной утилиты, которая умеет быстро создавать кластер из одного узла с использованием VirtualBox. Это самый лучший вариант для быстрого старта.

Но есть и другой вариант. Можно взять VirtualBox, создать несколько виртуальных машин, например, с Ubuntu Server и настроить небольшой кластер Kubernetes прямо на своём домашнем компьютере.

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

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

Осторожно, трафик! В статье очень много скриншотов.

В одном из проектов возникла необходимость перевести процессы импорта данных сторонних систем на микросервисную архитектуру. В качестве инструмента выбран Apache NiFi. В качестве первого подопытного выбран импорт ЕГРЮЛ ФНС.

В предыдущей статье было описано, как получить файлы XML с данными ЕГРЮЛ, которые требуется импортировать.

В данной статье описан способ преобразования XML в JSON.

В данном техническом обзоре мы детально познакомимся с продуктом Instana – инструментом для автоматического мониторинга производительности микросервисной инфраструктуры, Kubernetes и пользовательского опыта, который использует наша компания в проектах на протяжении последнего года.

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

Мы прошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили на две части.

20 ноября пройдет ежегодная конференция Archdays, где мы c Пашей Канн в рамках демонстрации покажем пример того, как может быть взломано приложение в Docker и как с нуля собрать пайлпайн с проверками безопасности на базе GitLab CI.

Взлом будет проходить в соответствии с инструкцией репозитория Pentest-In-Docker, который мы подготовили специально для Archdays. Есть также версия на русском языке, попробовать получить root на linux-хосте можно уже сейчас.