В этой статье я хочу поделиться историей разработки одного из наших проектов и моими размышлениями на этот счёт.

Сегодня поговорим про то, что мы используем для мониторинга, логирования 👀событий, а также централизованного сбора логов инфраструктуры RNDSOFT. Эта статья продолжение небольшого цикла Infra про нашу инфраструктуру.

Для любого системного администратора или DevOps’а построить VPN или пробросить нестандартный метод инкапсуляции пакетов (туннелирование) не очень сложно. Часто для этого используют OpenVPN для постоянного использования, либо ssh-туннелирование на один-два раза. Однако есть организации, которые должны соблюдать строгие рамки передачи данных, установленные законодательством. Под такие организации попадают банки, микрофинансовые организации (да и многие организации, которые так или иначе имеют отношения к финансовым операциям). Защита персональных данных тоже является “защищаемой информацией” во всех законопроектах и положениях.

Самое время рассмотреть “достаточно хороший” алгоритм для борьбы с Poison Message. Здесь будет уже специфика RabbitMQ и к Apache Kafka она не применима, точнее применима только частично - но это уже совсем другая история.

У нас в RNDSOFT есть один проект, в котором очень интенсивно используется брокер сообщений RabbitMQ. Под "очень интенсивно" я подразумеваю, что это единственный канал взаимодействия десятков сервисов - никаких вам HTTP и REST. И в этой статье мы рассмотрим понятие "Poison Message" и как с ним можно жить.

В современном мире тяжело представить разработку приложений без тестирования. Особенно в мире ruby. Особенно когда лёгкая виртуализация стала уже стандартом и любой разработчик знает, как запускать докер. Качественные тесты позволяют не столько надеяться, что код работает правильно, сколько смело вносить изменения и не бояться при этом сломать то, что есть.

В этой статье я хочу поделиться своими мыслями о трудностях, которые возникают в ходе написания тестов на Go и о том, как эти трудности преодолеть.

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

Все, кто работают с руби, рано или поздно попадают на какую-нибудь статью, рассказывающую почему никогда и ни при каких обстоятельствах нельзя использовать Timeout::timeout. А я хочу поделиться другим подходом к таймаутам.

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