Глава 1. Как оживает Rabbit

Файлы с кодом этой главы доступны в GitHub.

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

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

В нашем следующем разделе объясняется AMQP, протокол по умолчанию RabbitMQ.

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

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

Такой стиль запроса- отклика используется когда клиент должен получить немедленный отклик или желает обслужить некую задачу целиком без задержки, такой как перевод в ожидание при звонке в ресторан для бронирования столика:

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

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

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

Сообщения текут в одном направлении, от издателя к брокеру и, в конечном счёте к своему потребителю:

Системы и приложения играют обе роли издателей сообщений (производителей) и потребителей сообщений (подписчиков). Некий издатель публикует какое- то сообщение в брокере, на который он полагается при доставке своих данных намеченному потребителю. Когда требуется некий отклик, он возникнет в некий момент времени посредством того же самого механизма, однако в обратном направлении (потребитель и производитель поменяются ролями).

Одним крупным преимуществом построения очередей обмена сообщениями состоит в том, что системы становятся слабо связанными друг с другом. Они не требуют знания местоположения прочих узлов в своей сетевой среде; для его достижения достаточно только названия. Система способны, тем самым, вовлекаться неким независимым образом без воздействия друг на друга, поскольку надёжность доставки сообщений доверена брокеру.

Приводимая ниже схема иллюстрирует слабую связь между издателем и потребителем:

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

Представляемая через очереди сообщений архитектура допускает следующее:

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

Если это всё ещё кажется неясным, воспользуйтесь примером известного протокола SMTP (Simple Mail Transfer Protocol). В этом протоколе электронные письма публикуются (отправляются) в некий сервер SMTP. Этот первоначальный сервер затем сохраняет и переправляет такое сообщение в следующий сервер SMTP и так далее, до тех пор, пока не будет достигнут сервер электронной почты окончательного получателя. В этот момент данное сообщение ставится в очередь во входящих, дожидаясь того, что его прихватит его потребитель (обычно через POP3 или IMAP). Применяя SMTP конкретный издатель не имеет никакого понятия относительно того когда его электронное письмо будет доставлено и будет ли оно вообще доставлено в конечном счёте. В случае отказа в доставке этот издатель позднее по времени уведомляется о проблемах.

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

Более того, кода требуется некий отклик, он появится асинхронно при помощи того же самого механизма доставки, но при этом издатель и потребитель меняются ролями.

Установив эти основополагающие понятия, сейчас самое время окунуться в тот протокол, который будет применяться в данной книге, и им выступает AMQP.

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

RabbitMQ строится поверх спецификации AMQP 0-9-1, однако доступны встраиваемые модули, которые поддерживают AMQP 1.0

Ниже приводится перечень центральных понятий AMQP, которые будут подробно разъясняться в последующих главах.

Следующая схема иллюстрирует обзор неких понятий из AMQP:

Тот брокер с открытым исходным кодом, который подробно описывается в данной книге, был создан с нуля для поддержки AMQP, однако RabbitMQ также поддерживает и многие иные протоколы, такие как MQTT, HTTP и STOMP.

Теперь настало время навести фокус на RabbitMQ.

RabbitMQ это некая реализация Erlang брокера AMQP. Он реализует Версию 0-9-1 AMQP с индивидуальным расширением, как это допускается самим протоколом. Erlang был выбран благодаря внутренне присущей ему поддержке построения распределённых приложений с высокой надёжностью. Действительно, Erlang применяется для работы телекоммуникационных переключателей в некоторых крупных телекоммуникационных системах, причём сообщалось об общей доступности системы с девятью девятками (а именно всего лишь 32 миллисекунды простоя в год). Erlang способен работать в любой операционной системе.

Для постоянного хранения данных RabbitMQ полагается на Mnesia, встроенную в Erlang базу данных в оперативной памяти/ с файлами постоянного хранения. Mnesia хранит сведения о своих пользователях, обменах, очередях, привязках и тому подобном. Значение индекса очереди хранит позицию сообщения и сведения о том было ли доставлено это сообщение или нет. Сообщения хранятся либо в самом индексе очереди, либо в имеющемся хранилище сообщений, неком хранилище ключ- значение, совместно используемом всеми очередями.

Для построения кластера в основном полагаются на пропитывающие Erlang возможности кластеризации. RabbitMQ способен запросто расширяться при помощи дополнительно встраиваемых модулей. Например, благодаря такому механизму в RabbitMQ может быть развёрнута консоль администрирования на веб основе.

RabbitMQ может быть настроен в отдельном, обособленном экземпляре или в качестве кластера на множестве серверов:

Брокеры RabbitMQ могут соединяться воедино с применением различных технологий, таких как федерализация и экскаваторы (shovels), чтобы формировать топологии обмена сообщениями с интеллектуальной маршрутизацией сообщений по брокерам и способностью распространяться во множестве центров обработки данных.

Приводимый ниже снимок экрана отображает федерализацию между брокерами RabbitMQ, расположенными в различных местах по всему миру:

Итак, когда и где применять RabbitMQ? Наш следующий раздел описывает некоторые распространённые варианты применения RabbitMQ.

Наиболее распространённый вариант применения для RabbitMQ состоит в отдельном производителе, отдельной потребляющей очередью. Представляйте себе это как некий конвейер, в котором одно приложение помещает сообщения с одной стороны этого конвейера, а другое приложение считывает те сообщения которые поступают с другой стороны. Сообщения доставляются способом первое пришло, первое вышло (FIFO). Такие сообщения могут быть командами или способны содержать важные сведения. Это звучит простым, но где такой тип архитектуры может применяться? Настало время разобраться где и почему воссияли очереди сообщений!

Очереди сообщений часто применяются между микрослужбами, но что это означает?

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

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

В неком примере вебмагазина, построенного в неком стиле монолитной архитектуры, одна система обрабатывает все имеющиеся функции, включая учёт товаров, платежи, обзоры, рейтинги и тому подобное, как это показано на схеме ниже:

Собранный на архитектуре микрослужб вебмагазин, с другой стороны, подразумевает что каждая часть системы располагает индивидуальной активностью. Одна микрослужба обрабатывает обзоры и рейтинги. Далее, имеется другая для учёта товаров, а затем ещё одна для платежей и так далее, как это показано на приводимой далее схеме:

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

Другим типичным вариантом применения для RabbitMQ является очередь задач, которую мы и обсудим в своём следующем разделе.

События являются уведомлениями, которыми отзываются приложения когда что- то происходит. Одно приложение может подписаться на события от другого приложения и откликаться созданием и обработкой задач для себя. Типичным вариантом применения является ситуация, при которой RabbitMQ действует как очередь задач, которая медленно обрабатывает операции .

Давайте рассмотрим два примера этого:

Приводимая далее схема отображает некую очередь задач, в которой сообщения вначале входят в соответствующую очередь, а затем обрабатываются. Затем новые задачи добавляются в другую очередь:

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

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

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

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

До сих пор система CC работала следующим образом:

Наша старая архитектура иллюстрируется так:

Зачем CC рассматривает добавление RabbitMQ в уже оживлённую среду? Самая основная причина состоит в том,что CC желает предложить своим потребителям некоторые новые функциональные возможности - они хотели бы построить предложение, которое обрабатывает заказы на ходу. CC также желает иметь возможность масштабирования без головной боли. Основной план состоит в построении некого прикладного приложения, которое способно бронировать машину со смартфона, получать подтверждение бронирования и отслеживать приближающуюся к отправной точке машину.

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

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

Чтобы начать, должны быть выполнены три следующих шага установки и настройки:

Давайте начнём с установки своего брокера!

CC запускает свои промышленные серверы на Ubuntu Linux. Один разработчик обладает macOS и Linux, в то время как другой целиком под Windows. Такая разноршёрность не проблема для RabbitMQ, который естественным образом работает во всех этих операционных системах.

RabbitMQ обладает полностью доступными через интернет руководствами по установке для всех поддерживаемых операционных систем и их можно отыскать здесь. Данная книга содержит инструкции для Debian/ Ubuntu, в которых RabbitMQ устанавливается из соответствующего репозитория apt. она также содержит далее в этой главе инструкции для Docker.

Установка RabbitMQ в Ubuntu

Имеется относительно немного шагов, требующихся для установки RabbitMQ. Они таковы:

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

Для выгрузки самых последних выпусков устанавливаемого программного обеспечения выполните команду apt upgrade:

apt upgrade
 	   

Для RabbitMQ необходимо несколько программных пакетов. Убедитесь что curl, apt-transport-https и GnuPG находятся в вашей системе, выполнив следующие команды:

sudo apt install curl gnupg -y
sudo apt install apt-transport-https
 	   

Параметр -y принимает все лицензии для этих зависимостей. Ubuntu установит все необходимые подчинённые пакеты.

Узнайте название своей операционной системы, исполнив одну из следующих команд:

Название выпуска не является техническим. Предыдущие названия содержат focal и bionic. Ubuntu не содержит по умолчанию RabitMQ, поэтому прежде чем продолжать, его необходимо добавить в имеющийся ключ репозитория. Выполните следующий набор команд в Терминале:

curl -fsSL https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc 
sudo apt-key add -
sudo tee /etc/apt/sources.list.d/bintray.rabbitmq.list <<EOF
deb https://dl.bintray.com/rabbitmq-erlang/debian [os release name] erlang
deb https://dl.bintray.com/rabbitmq/debian [os release name] main
EOF
 	   

Эти команды выгрузят сам ключ и добавят его в ваш список репозитория прежде чем добавлять надлежащие пакеты операционной системы для брокера и Erlang.

RabbitMQ написан на Erlang, неком функциональном языке программирования, который обладает надёжной встроенной поддержкой для создания распределённых сетевых сред. Его разработчики сопровождают некий список минимальных версий (https://www.rabbitmq.com/which-erlang.html) этого языка программирования для самых последних выпусков своего брокера. На момент написания этих строк RabbitMQ 3.8 поддерживался Erlang с 21.3 по 23.

Теперь можно правильно установить RabbitMQ.

Для установки RabbitMQ выполните следующие команды:

sudo apt install -y rabbitmq-server
sudo apt install librabbitmq-dev
 	   

Установленная библиотека librabbitmq-dev содержит некого клиента для взаимодействия с нашим брокером. Тем не менее, может быть востребован и лишь сам сервер.

Установка RabbitMQ в Docker

Контроллеры Docker делают возможным разделение и управление ресурсами без риска разрушения самой операционной системы. Инструкции для установки Docker доступны на его официальном веб сайте: https://docs.docker.com/get-docker/ {Прим. пер.: также рекоендуем наш перевод Docker для разработчиков Rails Роба Айзенберга}. имея установленным Docker, вытащите образ RabbitMQ:

docker pull rabbitmq
 	   

Запустите необходимый нам брокер с обоснованными значениями по умолчанию:

docker run -d --hostname my-rabbit --name my-rabbit -p 5672:5672 -p 15672:15672 -e RABBITMQ_ERLANG_COOKIE='cookie_for_clustering' -e RABBITMQ_DEFAULT_USER=user -e RABBITMQ_DEFAULT_PASS=password  --name some-rabbit rabbitmq:3-management
 	   

Необходимо создать контейнер Docker с тем, чтобы он был доступен с localhost с включённой консолью управления.

Запуск RabbitMQ

Установка сервера RabbitMQ из надлежащего репозитория также установит и удобные инструменты командной строки, применяемые для запуска этого сервера в самый первый раз. Это выполняется следующей командой:

rabbitmq-server start
 	   

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

sudo systemctl enable rabbitmq-server
sudo systemctl start rabbitmq-server
sudo systemctl status rabbitmq-server
 	   

Команда systemctl также может применяться для управления службами в Ubuntu. Вывод самой последней команды должен отобразить то, что наш брокер запущен. Если это не так, проконсультируйтесь с соответствующей документацией RabbitMQ.

Выгрузка примеров кода

Выгрузите все файлы образцов кода для этой книги. Их можно приобрести на http://www.packtpub.com/. Если вы приобрели эту книгу где- то ещё, посетите http://www.packtpub.com/support и зарегистрируйтесь чтобы получить эти файлы по электронной почте напрямую.

{Прим. пер.: Весь код в единой упаковке также размещён на GitHub. В случае обновления этого кода, он также будет обновлён и в обозначенном репозитории GitHub.}

Проверка того, что брокер RabbitMQ работает

Теперь проверим что наш брокер в действительности работает при помощи команды status service.

В своём Терминале введите следующую строку:

$ sudo service rabbitmq-server status
  rabbitmq-server.service - RabbitMQ broker
   Loaded: loaded (/lib/systemd/system/rabbitmq-server.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/rabbitmq-server.service.d
           └─10-limits.conf, 90-env.conf
   Active: active (running) since Mon 2019-04-29 13:28:43 UTC; 1h 43min ago
  Process: 27474 ExecStop=/usr/lib/rabbitmq/bin/rabbitmqctl shutdown (code=exited, status=0/SUCCESS)
 Main PID: 27583 (beam.smp)
   Status: "Initialized"
    Tasks: 87 (limit: 1121)
   CGroup: /system.slice/rabbitmq-server.service
           ├─27583 /usr/lib/erlang/erts-10.2.2/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 
           ├─27698 /usr/lib/erlang/erts-10.2.2/bin/epmd -daemon
           ├─27854 erl_child_setup 1000000
           ├─27882 inet_gethost 4
           └─27883 inet_gethost 4

Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:   ##  ##
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:   ##  ##      RabbitMQ 3.7.14. Copyright (C) 2007-2019 Pivotal Software, Inc.
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:   ##########  Licensed under the MPL.  See https://www.rabbitmq.com/
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:   ######  ##
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:   ##########  Logs: /var/log/rabbitmq/rabbit@test-young-mouse-01.log
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:                     /var/log/rabbitmq/rabbit@test-young-mouse-01_upgrade.log
Apr 29 13:28:42 test-young-mouse-01 rabbitmq-server[27583]:               Starting broker...
Apr 29 13:28:43 test-young-mouse-01 rabbitmq-server[27583]: systemd unit for activation check: "rabbitmq-server.service"
Apr 29 13:28:43 test-young-mouse-01 systemd[1]: Started RabbitMQ broker.
Apr 29 13:28:43 test-young-mouse-01 rabbitmq-server[27583]:  completed with 9 plugins.
 	   

Взглянем на запущенные процессы для RabbitMQ и обнаружим что и оболочка службы, и необходимая ВМ Erlang (также именуемая как BEAM) запущены следующим образом:

$ pgrep -fl rabbitmq
27583 beam.smp

$ ps aux | grep rabbitmq
ubuntu   10260  0.0  0.1  14856  1004 pts/0    S+   15:13   0:00 grep --color=auto rabbitmq
rabbitmq 27583  0.5  8.5 2186988 83484 ?       Ssl  13:28   0:36 /usr/lib/erlang/erts-10.2.2/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -K true -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/librabbitmq/lib/rabbitmq_server-3.7.14/ebin  -noshell -noinput -s rabbit boot -sname rabbit@test-young-mouse-01 -boot start_sasl -config /etc/rabbitmq/rabbitmq -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit lager_log_root "/var/log/rabbitmq" -rabbit lager_default_file "/var/log/rabbitmq/rabbit@test-young-mouse-01.log" -rabbit lager_upgrade_file "/var/log/rabbitmq/rabbit@test-young-mouse-01_upgrade.log" -rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir "/usr/lib/rabbitmq/plugins:/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.14/plugins" -rabbit plugins_expand_dir "/var/lib/rabbitmq/mnesia/rabbit@test-young-mouse-01-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@test-young-mouse-01" -kernel inet_dist_listen_min 25672 -kernel inet_dist_listen_max 25672
rabbitmq 27698  0.0  0.1   8532  1528 ?        S    13:28   0:00 /usr/lib/erlang/erts-10.2.2/bin/epmd -daemon
rabbitmq 27854  0.0  0.1   4520  1576 ?        Ss   13:28   0:00 erl_child_setup 1000000
rabbitmq 27882  0.0  0.1   8264  1076 ?        Ss   13:28   0:00 inet_gethost 4
rabbitmq 27883  0.0  0.1  14616  1808 ?        S    13:28   0:00 inet_gethost 4
		

Возможно, что при запуске RabbitMQ также будет запущен и процесс с названием epmd. Это демон сопоставления портов Erlang, который отвечает за координацию узлов Erlang в кластере. Ожидается, что он запустится даже когда не запущено само кластерное приложение RabbitMQ.

Обратите внимание, что по умолчанию служба нашего брокера настроена для запуска в режиме автоматического старта при запуске своего хоста Linux.

По умолчанию RabbitMQ не устанавливает консоль управления, тем не менее, используемый в этом примере не обязательный встраиваемый модуль на веб основе сделает более простым подхват запущенного экземпляра RabbitMQ.

Соответствующий пакет Debian установил некоторое число сценариев. Одним из них является rabbitmq-plugins. Его цель состоит в том, чтобы позволить нам устанавливать и удалять встраиваемые модулию Применим его для установки необходимого нам встраиваемого модуля управления следующим образом:

$ sudo rabbitmq-plugins enable rabbitmq_management 
Enabling plugins on node rabbit@host:
rabbitmq_management
The following plugins have been configured:
 rabbitmq_consistent_hash_exchange
 rabbitmq_event_exchange
 rabbitmq_federation
 rabbitmq_management
 rabbitmq_management_agent
 rabbitmq_shovel
 rabbitmq_web_dispatch
Applying plugin configuration to rabbit@host...
The following plugins have been enabled:
  rabbitmq_management
  rabbitmq_management_agent
  rabbitmq_web_dispatch
 	   

Да, это просто!

Для того чтобы получить домашней страницы нашей консоли управления воспользуйтесь веб браузера, переместившись к http://<hostname>:15672, как это показано на следующем снимке экрана:

Оставайтесь наблюдать за нашим следующим эпизодом - создание и настройка пользователей!

Одним из сценариев, который устанавливается нашим пакетом Debia является rabbitmqctl, который является инструментом для управления узлами RabbitMQ и применяется для настройки всех сторон нашего брокера. Применяйте его для настройки административных пользователей в своём брокере таким образом:

$ sudo rabbitmqctl add_user cc-admin taxi123
Adding user "cc-admin" ...

$ sudo rabbitmqctl set_user_tags cc-admin administrator
Setting tags for user "cc-admin" to [administrator] ...
		

По умолчанию, RabbitMQ поставляется с гостевым пользователем, который аутентифицирован соответствующим гостевым паролем guest. Измените этот пароль на что- то иное, например:

$ sudo rabbitmqctl change_password guest guest123
 	   

Вернитесь обратно в свою консоль управления, где экран входа в систему позволит нам зарегистрироваться в нём с именем пользователя cc-admin и значением пароля taxi123.

Приветственный экран предоставляет нам обзор внутреннего состояния нашего брокера, что отображено на снимке экрана ниже:

Обратите внимание на то, что на данный момент наш пользователь cc-admin не способен изучать никакие обмены или очереди в каком бы то ни было vhost. Сейчас должен быть создан другой пользователь для целей разработки с тем, чтобы приложения имели возможность подключаться к RabbitMQ.

Создайте пользователя cc-dev следующим образом:

$ sudo rabbitmqctl add_user cc-dev taxi123
Adding user "cc-dev" ...
		

Как уже обсуждалось ранее в этой главе, RabbitMQ поддерживает понятие vhost, в котором различные пользователи могут обладать различными полномочиями доступа. Наша среда разработки CC будет обладать виртуальным хостом с названием vhost. Всё что будет происходить в этом виртуальном хосте случается изолированно от всех прочих окружений, создаваемых в дальнейшем (например, в среде QA). Имеется возможность настраивать пределы числа запросов и одновременных клиентских подключений для каждого хоста в поздних версиях RabbitMQ (3.7+).

Создайте vhost с названием cc-dev-vhost таким образом:

$ sudo rabbitmqctl add_vhost cc-dev-vhost
Adding vhost "cc-dev-vhost" ...
		

Это создаёт пользователя и виртуальный хост для разработки.

Настройка выделенных vhosts

RabbitMQ поставляется с виртуальным хостом по умолчанию, именуемым /, для которого гостевой пользователь обладает полными правами. Хотя это и удобно для быстрой проверки, рекомендуется создание выделенного vhost для разделения забот с тем, чтобы было возможным полностью удалять виртуальный хост и перепускать его с нуля без неожиданных воздействий.

Как следует из их аббревиатур, ни пользователь cc-admin, ни пользователь cc-dev не обладают никакими полномочиями делать что бы то ни было с cc-dev-vhost. Вы можете исправить это предоставляя полные права vhost следующим манером:

$ sudo rabbitmqctl set_permissions -p cc-dev-vhost cc-admin ".*" ".*" ".*"
Setting permissions for user "cc-admin" in vhost "cc-dev-vhost" ... 
$ sudo rabbitmqctl set_permissions -p cc-dev-vhost cc-dev ".*" ".*" ".*"
Setting permissions for user "cc-dev" in vhost "cc-dev-vhost" ...
		

Подводя итог тому, что только что было сделано, основная часть команды проста, однако часть &qout;.*&qout; &qout;.*&qout; &qout;.*&qout; выглядит слегка загадочной, поэтому давайте проанализируем её.

Это тройка полномочий для рассматриваемого виртуального хоста, которые предоставляют полномочия configure, write и read (настройки, записи и чтения) на этом выделенном ресурсе для рассматриваемого пользователя и виртуального хоста. Ресурсы, которые состоят из обменов и очередей обозначаются регулярными выражениями, которые устанавливают соответствие их названиям. В данном случае допустим всякий ресурс, запрашиваемый через регулярное выражение &qout;.*&qout;.

Реальные команды, которые предоставляют права, зависят от значения типа ресурса и предоставляемых полномочий. Обратитесь к http://www.rabbitmq.com/access-control.html для получения полного списка поддерживаемых RabbitMQ политик контроля доступа.

В качестве альтернативы всем командным строкам, вернёмся к свойствам управления пользователем нашей консоли управления. Кликните по закладке Admin этой консоли и затем по пользователю cc-dev, перечисляемому в закладке Users для просмотра сведений аналогичных тем, что отображены в нашем следующем снимке экрана. Видна вся конфигурация пользователя, которая была настроена из нашей командной строки и ей можно изменять в этой консоли управления.

Сведения по некому персональному пользователю можно найти кликнув по конкретному имени пользователя в нашей консоли управления:

Итак, были установлены брокер RabbitMQ и встраиваемый модуль управления (Web UI), а также настроены необходимые виртуальный хост и пользователи.

Данная глава исследует архитектурные и проектные перспективы обмена сообщениями, включая то как AMQP и RabbitMQ доставляют эти перспективы. Кроме того, была приведена основная причина, по которой наше агентство такси Complete Car приняла решение ввести в свой профиль программного обеспечения RabbitMQ. Наконец, был установлен брокер RabbitMQ и для него были настроены пользователь и различные виртуальные хосты. Вооружившись основами понимания очередей обмена сообщениями и RabbitMQ, в своей следующей главе мы соберём эти понятия и изучим ту архитектуру, которая стоит за нашим предложением такси Complete Car.

Пришло время взяться за дело и написать код. Перейдём к следующей главе , чтобы начать создание приложения на основе RabbitMQ!