Найти тему
Закреплено автором
Жизнь в IT
Poison Message #1
2 года назад
Захотелось поиграть в шикарную старую игрулину моего детства Capitalism 2. Захотеть то я захотел, а вот чтоб её запустить пришлось вспомнить свои старые навыки - ведь я Core/Kernel Linux Developer (хоть и в прошлом). Получилось инетресно и позновательно - рекомендую для ознакомления.
1 месяц назад
Infra3: Мониторинг, Event Logging и сбор логов
Сегодня поговорим про то, что мы используем для мониторинга, логирования 👀событий, а также централизованного сбора логов инфраструктуры RNDSOFT. Эта статья продолжение небольшого цикла Infra про нашу инфраструктуру. Оригинал: https://blog.rnds.pro/021-infra3 Что мы используем? Prometheus давно стал стандартом de facto, если у вас микросервисная архитектура. Мы его используем в гармоничном сочетании с consul service discovery, чтобы смотреть за нашими инстансами в облаках, виртуалках на bare metal, colocation и микросервисами, просто микросервисами...
2 года назад
Вы хочете песен? Их есть у меня! (Poison Message #2)
Самое время рассмотреть “достаточно хороший” алгоритм для борьбы с Poison Message. Здесь будет уже специфика RabbitMQ и к Apache Kafka она не применима, точнее применима только частично - но это уже совсем другая история. В первой части мы разобрали несколько примеров и сформулировали проблему Poison Message, здесь же рассмотрим сам алгоритм её решения. Оригинал (08.11.2021): https://blog.rnds.pro/019-poison2 Если коротко, то нам надо попытаться обработать “ядовитое” сообщение несколько раз и только после этого принять решение о его пропуске...
2 года назад
Poison Message #1
У нас в RNDSOFT есть один проект, в котором очень интенсивно используется брокер сообщений RabbitMQ. Под "очень интенсивно" я подразумеваю, что это единственный канал взаимодействия десятков сервисов - никаких вам HTTP и REST. И в этой статье мы рассмотрим понятие "Poison Message" и как с ним можно жить. Оказалось, что постановка проблемы тянет на отдельную статью, поэтому для нетерпеливых сразу даю ссылку на сам алгоритм. Оригинал (08.11.2021): https://blog.rnds.pro/018-poison1 Постановка проблемы...
2 года назад
Ракторы (Ractors) в Ruby постепенно проникают в разработку. представляем вам перевод хоть и старо, всё равно актуальной статьи об этом функционале: blog.rnds.pro/...ors
2 года назад
RSpec на страже микросервисов
Оригинал (20.06.2021): https://blog.rnds.pro/017-gorspec В современном мире тяжело представить разработку приложений без тестирования. Особенно в мире ruby. Особенно когда лёгкая виртуализация стала уже стандартом и любой разработчик знает, как запускать докер. Качественные тесты позволяют не столько надеяться, что код работает правильно, сколько смело вносить изменения и не бояться при этом сломать то, что есть. Эта статья продолжает тему использования языка ruby в отрыве от фреймворка rails. И сегодня речь пойдет про Go...
2 года назад
Portainer и Traefik
Оригинал (01.04.2021): https://blog.rnds.pro/013-portainer На днях поднимали небольшое продуктовое окружение на несколько нод. Для этого решили использовать Docker Swarm. Не смотря на то, что сам по себе Swarm мало отличается от "голого" докера, всё же приятно будет иметь инструмент для визуального контроля состояния всего кластера. Версии запущенных контейнеров посмотреть или переменные окружения проверить. Ну и вдвойне удобнее если такого рода задачи возникают редко и ты уже знать забыл что там и где настроено - раз в месяц например...
2 года назад
Вежливый таймаут Все, кто работают с руби, рано или поздно попадают на какую-нибудь статью, рассказывающую почему никогда и ни при каких обстоятельствах нельзя использовать Timeout::timeout. А я хочу поделиться другим подходом к таймаутам: https://blog.rnds.pro/014-timeouter
2 года назад
Infra2: Consul Registrator
Оригинал: https://blog.rnds.pro/009-infra2 Пришло время рассказать про замечательный инструмент Consul Registrator. Давно его используем и очень довольны - никогда нас не подводил. Более того, в одном из проектов нам пришлось использовать не его, а упрощенный аналог 🚲 - и это оказалось очень легко реализовать. Но обо всём по порядку. Прелюдия В прошлой статье мы рассказали как устроена наша внутренняя инфраструктура и общие подходы в наших продуктах. Остановились на том, как собственно происходит склейка Docker ->Consul ->Traefik после деплоя...
2 года назад
Infra1: Service Discovery, Cloud Native Proxy и деплой Для одного из наших динамично развивающихся проектов появилась задача актуализировать документацию, описать инфраструктурные моменты и вообще закрыть весьма большую тему с мультитенантностью. https://blog.rnds.pro/005-infra1
2 года назад
Consul, Lusnoc, Rufus и фоновые задачи В прошлой статье я обещал рассказать о конкретном использовании распределенных блокировок с использованием нашей собственной Ruby-библиотеки Lusnoc. Про это и поговорим.: https://blog.rnds.pro/rufus
2 года назад
Consul, distributed locks и как мы с этим работаем (Lusnoc) За последние пару лет Consul плотно вошёл в наш технологический стэк. Сначала как хранилище конфигурации потом как service provider для внутренних систем таких как prometeus и traefik и наконец как инструмент для distributed locks и leader election. О том как мы с этим работаем: https://blog.rnds.pro/lusnoc
2 года назад