Многие начинающие DevOps'ы, осваивающие kubernetes сталкиваются с вопросом: "Как организовать Persistent Storage в своём kubernetes-кластере?" Для этой цели есть много вариантов: ceph, nfs, mayastor, iscsi, linstor, longhorn. Сегодня мы рассмотрим один из них - linstor (он же piraeus). Мы настроим свой Persistent Storage и подключим его к нашему kubernetes-кластеру.
Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами.
На одном из проектов, где я работаю, у меня возникла проблема: используемые инструменты для тестирования Kafka были недостаточно удобными:
Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение).
UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик.
В поисках более удобного решения коллега посоветовал Plumber — графическое приложение, с возможностью коньюмера и продюсера сообщения.
В этой статье я не буду объяснять, что такое Kafka и как работают брокеры — на эти темы уже есть множество отличных материалов, например, вот. Хочу поделиться своим опытом использования этого инструмента. Я не ставлю цель сравнивать его с другими существующими решениями, а просто расскажу, как Plumber помог мне упростить процесс ручного тестирования Kafka на стейджах.
Нынешний век — век импортозамещения. Многие компании сейчас сталкиваются с возникшей необходимостью переходить на отечественное ПО. Приходится осваивать вновь появившиеся нюансы, связанные с новым программным обеспечением. В данной статье мы в подробности рассмотрим настройку и шаг‑за шагом настроим single‑node kubernetes‑кластер в одной из популярных отечественных ОС — RedOS.
Сейчас OpenTelemetry — это самый быстрорастущий проект CNCF. Опытом внедрения этого набора инструментов для отладки и анализа производительности распределённых систем поделился тимлид платформенной команды Норвежского управления труда и социального обеспечения. В переводе под катом вас ждёт тернистый путь от первых коммитов до реального применения OpenTelemetry в production, а также планы команды на будущее.
Привет, Хабр! Я — Артем, ведущий специалист в дирекции эксплуатации и развития автоматизированных рабочих мест в Страховом Доме ВСК. Сегодня я вам расскажу о том, как мы подружили Jira и Telegram в нашем проекте «Telegram Bot «Поддержка ВСК».
План повествования:
Привет! Меня зовут Юрий, я старший разработчик в Купере в команде Ruby Platform, занимающейся разработкой внутренних библиотек, инструментов мониторинга и поддержки микросервисов.
У нас в Купере более 200 микросервисов на разных стеках, а также монолиты. С точки зрения инфраструктуры интеграционное тестирование такого количества компонентов - довольно затратная задача, но при этом хочется обеспечить стабильность системы, не проводя ручные интеграционные регресс-тесты. В таких условиях оптимальным решением являются контрактные тесты.
Из данной статьи вы узнаете:
- общий принцип работы контрактных тестов;
- о проблемах, с которыми мы столкнулись при внедрении контрактного тестирования и как их решали;
- как мы разработали свое решение для контрактного тестирования Ruby-приложений;
- о настройке CI/CD для автоматизации контрактных тестов.
Материал будет полезен тем, кто задумывается о повышении надежности интеграций между сервисами и внедрении контрактных тестов в свои проекты.
В мире разработки ПО поддержка высокого уровня наблюдаемости (observability) для приложений с архитектурой, управляемой событиями (event-driven architecture, EDA) стало критически важным. Сложность таких систем, связанных с обработкой огромных объемов данных в режиме реального времени, требует надежных инструментов для мониторинга, отладки и анализа. Однако традиционные методы, использующие логи и метрики, часто оказываются недостаточными, когда необходимо глубоко понять взаимодействие между различными компонентами системы и выявить узкие места.
Именно с этой проблемой мы столкнулись в нашей команде, поэтому я, Дмитрий Титаренко (QA-инженер в компании TAGES), решил поделится найденным решением в статье на Хабр. Надеюсь, что будет полезно!
Переход от PosgreSQL-only решения к собственному DataLake для отделения read нагрузки под нужды аналитики и AI.
Привет! В продолжение темы изучения микросервисов решил разобраться с взаимодействием этих самых «сервисов», и написать простой пример взаимодействия двух сервисов между собой.
Перед чтением данной статьи, настоятельно рекомендую ознакомиться с данной статьей, по теме kafka (Kafka за 20 минут. Ментальная модель и как с ней работать)
Пример реализации можно найти тут...
Привет! В продолжение своих статей на тему микросервисов, решил выделить важный вопрос отношений разработки и бизнеса в целом.
Как микросервисная архитектура решает проблему взаимодействия бизнеса и разработки?
Следующий возникающий в голове вопрос, когда разобрался с тем, как работать с данными в данной архитектуре (а может у кого то этот вопрос стоит первым) - как микросервисы будут взаимодействовать между собой?
В данной статье разберемся с синхронным и асинхронным взаимодействием, сложностями и разными подходами.
В этой статье поговорим об одном из ключевых компонентов в архитектурах микросервисов и веб-приложений — API шлюзах. Данные шлюзы являются централизованной точкой входа для управления запросами клиентов и перенаправления их к соответствующим микросервисам или внутренним службам внутри целевой системы.
По сути, API Gateway представляет собой службу, которая находится между клиентами приложения с одной стороны, и внутренними компонентами с другой, действуя как обратный прокси-сервер для приема входящих запросов от клиентов, выполнения различных операций, таких как маршрутизация, аутентификация и ограничение скорости, и последующей пересылки этих запросов соответствующим внутренним службам.
Исследования никогда не утоляют мой голод к изучению, поэтому в этот раз, они подтолкнули меня к написанию статьи. Тут постарался ответить на возможные насущные вопросы о микросервисной архитектуре.
Добрый день, Хабр!
Меня зовут Сергей Игнатенко, я — девлид в поезде «Операционная платформа» ВСК. Хочу сегодня рассказать об опыте использования SchemaRegistry и Avro в Kafka.
Начну с базовой схемы работы с Kafka, которая, возможно, будет знакома многим, но важна для понимания контекста.
Принцип работы прост: продюсер отправляет сообщение в Kafka, где оно размещается в очереди. Далее один или несколько консюмеров считывают это сообщение.
И вот настал тот день, когда я наконец соизволил встать с дивана и дописать следующую статью о микросервисах. Кто не в теме - в прошлой части мы выяснили, как сильно неправильная пунктуация и тупые приколы могут раздражать. Ну и немного обсудили что такое микросервисы и зачем они вообще нужны. Не будем мы отходить от трендов и в этой части - продолжим погружаться в этот дивный машинного перевода, шуточек за 300 и микросервисов.
Одним из важных компонентов современной разработки программного обеспечения является мониторинг. Он позволяет непрерывно следить за состоянием приложений и инфраструктуры, что дает возможность активно обнаруживать проблемы, предотвращать возникновение аварий и оптимизировать работу системы.
Метрики собирает и анализирует Prometheus – гибкая система с открытым исходным кодом, являющаяся одним из самых распространенных инструментов для реализации мониторинга.
Цель данной статьи - рассмотреть процесс разработки сервиса мониторинга на основе Prometheus и оценить его значимость в контексте современной разработки программного обеспечения.
В этой статье рассмотрим, как можно организовать простое управление секретами для приложений в Kubernetes при использовании GitOps-подхода. Храним секреты в git безопасно и управляем ими из Helm-чарта приложения.
Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.
В 2022 году многие компании, имеющие зарубежный головной офис, успели позаботиться о переносе IT-инфраструктуры в Россию. Оставшаяся часть компаний, которым «повезло» сохранить работу при поддержке центрального офиса, только начинают задумываться о локализации.
Откладывая локализацию IT-инфраструктуры «на потом», бизнес рискует столкнуться с экстренной локализацией, при которой часть данных перенести будет очень сложно, а может быть, и невозможно.
Меня зовут Алексей Горюнов. Я работаю руководителем проектного офиса в компании ALP ITSM. Поделюсь своим опытом в локализации, когда она требуется срочно.
