Saudações.
Resolvi criar esse tutorial para ser um guia rápido de instalação, uso e testes do RabbitMQ para operações do dia-a-dia e construção de sistemas modernos de micro-serviços desacoplados.
Pré-requisitos (constam em outros artigos aqui do blog):
- Instalação do Linux (Debian);
- Internet no servidor (sua VPS ou host);
- Docker CE instalado;
- Container do Traefik (opcional);
- Possuir um domínio de DNS (exemplo: seudominio.com.br);
- Possuir conhecimento básico de HTTP e uso do comando curl;
- Possuir conhecimento sobre o formato JSON;
1 – O que é RabbitMQ
O RabbitMQ é um software que implementa o protocolo AMQP 0-9-1.
Explicação curta: O RabbitMQ é um broker AMQP.
Explicação longa: O RabbitMQ é um software que utiliza o protocolo AMQP (Advanced Message Queuing Protocol) para implementar uma mensageria. Ele atua na camada de aplicação como um servidor de mensagens assíncronas entre sistemas distribuídos. Ele atua como um intermediário (broker) que gerencia filas, roteamento e mensagens.
Diferenciais:
- Gratuito: não requer licença para uso comercial;
- Protocolos: oferece suporte a diferentes protocolos de mensageria:
- AMQP 0-9-1: protocolo principal;
- MQTT – Message Queuing Telemetry Transport: protocolo ideal para Internet das Coisas (IoT) e dispositivos com recursos limitados sendo muito comum em automação residencial e industrial;
- AMQP: suporte a AMQP 1.0 via plugins;
- STOMP – Simple Text Oriented Messaging Protocol: é um protocolo de mensagens simples e leve. Ele utiliza comandos fáceis (CONNECT, SEND, SUBSCRIBE) e funciona idealmente sobre WebSockets para comunicação em tempo real, mapeando mensagens para filas e exchanges;
- REST API: controle de configuração e objetos via HTTP POST/GET/PUT/DELETE;
- Administração: interface web simples e completa;
- Suporte a transações: garantia de armazenamento e entrega;
- Plugins: plugins podem ser instalados para adicionar recursos personalizados e expansão de protocolos;
- Observabilidade: logs e estatísticas para monitoramento.
Em termos práticos ele é um sistema de mensagens que funciona como um “whastapp para programas distribuídos”.
Portas utilizadas para comunicação IP (IPv4 ou IPv6):
- 4369 (EPMD): Erlang Port Mapper Daemon. É usado para descoberta de nós em clusters RabbitMQ. Os nós Erlang usam essa porta para se encontrarem. Você só precisa dela se estiver montando um cluster com múltiplos nós.
- 5672(AMQP): Porta principal do protocolo AMQP 0-9-1 (e também AMQP 1.0 no RabbitMQ 4.x). É por aqui que suas aplicações se conectam para publicar e consumir mensagens.
- 15672 (Management UI): Interface web de gerenciamento e API HTTP. É o painel web onde você visualiza filas, exchanges, conexões, etc.
- 15692 (Prometheus): Endpoint de métricas no formato Prometheus (
/metrics). Só precisa expor se estiver coletando métricas com Prometheus/Grafana; - 25672 (Erlang Distribution): Porta usada para comunicação inter-nós no cluster Erlang (é a 20000 + a porta AMQP). Assim como a 4369, só é necessária em cenários de cluster.
Cuidado: as portas do RabbitMQ não possui criptografia TLS/SSL. É necessário usar o Traefik ou algum túnel/VPN para transmitir pela Internet o tráfego de mensageria e autenticação. Risco crítico por transmissão de senha em texto plano.
1.1 – Aplicação prática
Para simplificar sistemas, cada pedaço do software responsável por tarefas específicas passa a receber uma mensagem (escutar em uma fila) para realizar um trabalho (processamento) e colocar o resultado pronto em outra fila (publicar em uma fila).
Uma tarefa que demora 2 segundos para ser feita uma a uma poderá apresentar uma demora de até horas se milhares de mensagens forem depositadas na fila de entrada de uma vez.
Para resolver isso basta que o trabalhador (worker) seja duplicado. Rodando múlplias instâncias as coletas nas filas são mais constantes e os resultados vão saindo sem gargalo.
Essa arquitetura se chama “desacoplamento de sistema“. Esse é o papel do RabbitMQ em um ambiente de engenharia de software.
1.2 – Motivos para desacoplar
Se cada tarefa de um software faz uso de diferentes recursos de hardware, umas consumindo mais memória, outras consumindo mais CPU e outras consumindo serviços externos (APIs), expandir esse sistema rodando várias instâncias envolverá escalar todos esses recursos – ineficiente.
Quando um sistema faz uso de criptografia para assinatura digital ele precisa receber uma mensagem de INPUT e produzir a OUTPUT assinada. O código que lida com a criptografia não precisa estar dentro do sistema principal (acoplamento forte).
Quem precisa assinar documentos precisa apenas enviar uma mensagem para a fila “crypto-input” e aguardar a saída na fila “crypto-output” para que o ambiente possa escalar verticalmente e horizontalmente. Quanto mais mensagens precisarem ser cifradas mais softwares eu preciso rodar em paralelo para processar mensagens que aparecem na fila “crypto-input“.
O ambiente completo pode ter servidores WEB que dependem de CPU e rede. Um sistema de arquivos que depende de espaço de armazenamento (storage), outro sistema que faz a criptografia e assinatura digital depende de GPUs e ASICS e outro que lida com registros em banco de dados depende de I/O rápido NVME.
A implementação de filas entre esses setores dá ao administrador as informações para decidir quais setores precisam de upgrade (mais paralelismo) para dar conta do trabalho acumulado e quais precisam de redução de instãncias por ociosidade para economizar recursos.
1.3 – Arquitetura do RabbitMQ
Internamente o RabbitMQ trabalha num fluxo linear e simples que depende do entendimento desses conceitos para ser administrado (glossário do RabbitMQ):
- MESSAGE (mensagem): É o documento de texto no formato JSON que você deseja submeter ao MQ. Ela é composta de:
- Atributos: parâmetros que manipulam o tratamento pelo MQ;
- Payload: conteúdo transportado pelo MQ da aplicação que enviou a mensagem até a aplicação que irá processá-la;
- PRODUCER (produtores de mensagens): São os sistemas remetentes (softwares) que enviam mensagens o MQ. O ato de enviar é um PUBLISH (publicação);
- CONSUMER (consumidores de mensagens): São sistemas destinatários que precisam coletar trabalho nas filas para processá-las. Ao conectar no MQ o consumidor envia o comando SUBSCRIBE (inscrição) para receber mensagens na fila desejada.
- EXCHANGE (caixa de entrada): A mensagem enviada de um producer para o MQ é recebida na porta 5672/TCP e depositada em uma caixa de entrada. Cada caixa deve possuir um nome único e um tipo específico (direct, fanout, topic, headers) que determina o método de distribuição e o modo de segurança de persistência que depende da propriedade “durable“:
- durable=true: as mensagens são escritas em disco antes de serem confirmadas como aceitas, isso garante que não haverá perda de mensagens;
- durable=false: as mensagens são armazenadas apenas na memória RAM, se houver falha do MQ ou desligamento do container/servidor mensagens podem ser perdidas.
- BINDING (roteamento de escuta): São conexões internas entre a caixa de entrada e a fila de mensagens. Sempre que uma mensagem é depositada na caixa ela percorre todas as escutas vinculadas distribuindo cópias da mensagem a elas. Caberá a regra de escuta entregar a cópia na fila ou ignorá-la. Após percorrer todas as bindings vinculadas a caixa descarta a mensagem inicial. Somente as cópias entregues nas filas permanecem até serem coletadas;
- QUEUE (fila de trabalhos acumulados): É onde as mensagens chegam em seu ponto de armazenamento final. Elas vão se acumulando a espera de algum consumidor. Filas também possuem o atributo de persistência “durable” (true ou false);
- ACK (aceitação): Um consumidor da fila recolhe uma mensagem e confirma ao MQ que ela foi devidamente processada resultando na remoção da mensagem. Se um consumidor não der ACK na mensagem ela será redisponibilizada para outro consumidor;
Para ficar claro o fluxo de mensagens, observe os diagramas.
O producer publicou (PUBLISH) uma nova mensagem na EXCHANGE (ela precisa ter um nome):

Ao detectar uma nova mensagem na entrada (EXCHANGE), as regras de escuta e distribuição (BINDING) conduzirão a mensagem até a fila de armazenamento (QUEUE).

As mensagens se acumulam na fila. O RabbitMQ espera que sistemas se conectem na porta 5672/TCP por meio do comando de inscrição (SUBSCRIBE).

Na visão geral o RabbitMQ é um sistema simples com poucas partes. Entendendo e praticando você se torna especialista muito rápido.
Visão geral:

1.4 – Suporte a virtualização
O RabbitMQ possui um conceito de virtualização chamado de VHOST (virtual host) que facilita a organização de diferentes sistemas em uma única instância.
O vhost padrão se chama “/” (barra), eu pessoalmente altero para “default” por meio da variável de ambiente RABBITMQ_DEFAULT_VHOST:

Uma empresa que construa um super servidor RabbitMQ de alta performance pode criar um VHOST para cada sistema cliente, exemplos:
- O vhost chamado “default” é o meu padrão inicial personalizado;
- Um vhost chamado “n8ntests” para servir às mensagens de sistemas de automações de teste do n8n (ferramenta de fluxo nocode).
Fluxo com VHOSTS:

Obviamente, uma exchange dentro da vhost “default” não aceita bindings para queues em outra VHOST – o isolamento é completo.
1.5 – Tipos de exchanges
Quando uma mensagem é publicada na exchange, o tipo da exchange define o fluxo a ser seguido para transferi-la para a queue.
Esse processo se chama roteamento e pode ser influenciado pela própria mensagem (atributos routing key ou headers).
Resumidamente os tipos de exchange são:
- direct: Entrega por routing key de binding exatamente igual à routing key da mensagem;
- fanout: Tipo de binding que ignora a routing key e entrega a mensagem para todas as filas vinculadas à exchange (broadcast de mensagens);
- topic: Roteia mensagens com base em padrões (patterns) do binding que são comparados com o routing key da mensagem;
- headers: Ignora a routing key. Faz o roteamento com base nos headers (cabeçalhos
x-match) da mensagem;
Vou explicar cada tipo com mais detalhes.
1.5.1 – Exchange do tipo direct
O binding é configurado com a palavra exata para busca do routing key na mensagem.
Exemplo: um sistema de logs simples que envia mensagens com uma das seguintes routing keys : “error“, “warning” ou “info“.
Criando uma escuta (binding) para que todas as mensagens com a routing key “error” para uma fila exclusiva de mensagens de problemas:
x
x
x
- fanout: A exchange ignora a routing key e entrega a mensagem para todas as filas vinculadas a ela funcionando como um broadcast.
- Exemplo: um evento “pedido realizado” que precisa acionar simultaneamente o setor fiscal (gerar nota), o estoque (dar baixa) e o marketing (enviar email de confirmação). Cada setor tem sua própria fila, e todas recebem a mesma mensagem que entrou na exchange;
- topic: A exchange roteia mensagens com base em padrões (patterns) aplicados à routing key usando caracteres coringa * (asterisco, substitui exatamente uma palavra) ou # (cerquilha, substitui zero ou mais palavras). As routing keys de binding são compostas por palavras separadas por ponto (.) como sensor.temperatura.sala05.
- Exemplo: um sistema de monitoramento IoT onde sensores publicam dados com routing keys como sensor.temperatura.sala01, sensor.umidade.sala02, etc. Uma fila pode escutar sensor.temperatura.* para receber apenas dados de temperatura de todas as salas, enquanto outra fila escuta sensor.# para receber tudo de todos os sensores;
- headers: xxx;
x
x
ignora a routing key
2 – Implementando RabbitMQ no Docker
Vou rodar o RabbitMQ em um ambiente que já deve possuir o Docker e o Traefik instalado. Vou considerar que já existe uma rede chamada “network_public” para receber esse novo container.
A parte importante do RabbitMQ é você possuir o endereço IP ou DNS (FQDN) do servidor e a porta 5672/TCP redirecionada para o container. Basta essa porta para que os clientes possam se conectar para relações de PUBLISH e SUBSCRIBE.

O volume serve para armazenar mensagens persistentes que resistem a reinicialização do container “rabbitmq” e do servidor inteiro (host, Docker).
Detalhes do volume:
- Pasta interna: Diretório dentro do container que o MQ utiliza para persistencia de I/O, fixa em “/var/lib/rabbitmq“;
- Pasta externa do volume: use volume nomeado ou informe o diretório específico no host, no caso vou utilizar o diretório host “/storage/rabbitmq“.
2.1 – Site e Proxy-Reverso para administração web
Crie no seu servidor uma entrada para “rabbitmq.seudominio.com.br” apontando para o IP da sua VPS.
Esse nome será usado pelo protocolo HTTP (porta 80/tcp) e HTTPS (porta 443/tcp) para conectar ao Traefik (Proxy-Reverso) e conduzirá via labels do container as conexões até o container rabbitmq na porta 15672/TCP (porta de servidor web do MQ).
Implemente o Traefik primeiro (outros tutoriais do site).
2.2 – Instalação
Personalize as variáveis para valores adequados a cada função descrita nos comentários.
Script em SHELL (para rodar como root):
# Variaveis
# - Nome do container
NAME="rabbitmq";
# - Nome de DNS para acesso pelo navegador
FQDN="rabbitmq.tmsoft.com.br";
# - Timezone para hora local
TZ="America/Sao_Paulo";
# - Troque por uma sequencia hexadecimal aleatoria
RABBITMQ_COOKIE="ffffffffffffffffffffffffffffffff";
# - Credenciais de acesso administrativo inicial
RABBITMQ_USER="admin";
RABBITMQ_PASS="Sua_Senha@segura_123456xxx2026";
# - Pasta do volume
DATADIR=/storage/rabbitmq;
#IMAGE=rabbitmq:management;
IMAGE="rabbitmq:4-management";
# Criar pasta do volume
mkdir -p $DATADIR;
# Parar container atual:
docker rm -f $NAME 2>/dev/null;
# Criar e rodar:
docker run -d --restart=always \
--name $NAME --hostname $NAME.intranet.br \
\
--cpus="2.0" --memory=2g --memory-swap=2g \
\
--tmpfs /run:rw,noexec,nosuid,size=512m \
--tmpfs /tmp:rw,noexec,nosuid,size=512m \
\
--network network_public \
\
-p 4369:4369 \
-p 5672:5672 \
-p 15672:15672 \
-p 15692:15692 \
-p 25672:25672 \
\
-e TZ=$TZ \
-e RABBITMQ_DEFAULT_VHOST=default \
-e RABBITMQ_ERLANG_COOKIE=$RABBITMQ_COOKIE \
-e RABBITMQ_DEFAULT_USER=$RABBITMQ_USER \
-e RABBITMQ_DEFAULT_PASS=$RABBITMQ_PASS \
\
-v $DATADIR:/var/lib/rabbitmq \
\
--label "traefik.enable=true" \
--label "traefik.http.routers.$NAME.rule=Host(\`$FQDN\`)" \
--label "traefik.http.routers.$NAME.entrypoints=web,websecure" \
--label "traefik.http.routers.$NAME.tls=true" \
--label "traefik.http.routers.$NAME.tls.certresolver=letsencrypt" \
--label "traefik.http.services.$NAME.loadbalancer.passHostHeader=true" \
--label "traefik.http.services.$NAME.loadbalancer.server.port=15672" \
\
--entrypoint "docker-entrypoint.sh" \
\
$IMAGE rabbitmq-server;
echo;
echo "Acesso:";
echo "Web......: https://$FQDN";
echo;
Se preferir usar docker compose:
services:
rabbitmq:
image: rabbitmq:4-management
container_name: rabbitmq
hostname: rabbitmq.intranet.br
restart: always
entrypoint: ["docker-entrypoint.sh", "rabbitmq-server"]
cpus: 2.0
mem_limit: 2g
memswap_limit: 2g
tmpfs:
- /run:rw,noexec,nosuid,size=512m
- /tmp:rw,noexec,nosuid,size=512m
ports:
- "4369:4369"
- "5672:5672"
- "15672:15672"
- "15692:15692"
- "25672:25672"
environment:
TZ: "America/Sao_Paulo"
RABBITMQ_ERLANG_COOKIE: "ffffffffffffffffffffffffffffffff"
RABBITMQ_DEFAULT_VHOST: "default"
RABBITMQ_DEFAULT_USER: "admin"
RABBITMQ_DEFAULT_PASS: "Sua_Senha@segura_123456xxx2026"
volumes:
- /storage/rabbitmq:/var/lib/rabbitmq
networks:
- network_public
labels:
- "traefik.enable=true"
- "traefik.http.routers.rabbitmq.rule=Host(`rabbitmq.seudominio.com.br`)"
- "traefik.http.routers.rabbitmq.entrypoints=web,websecure"
- "traefik.http.routers.rabbitmq.tls=true"
- "traefik.http.routers.rabbitmq.tls.certresolver=letsencrypt"
- "traefik.http.services.rabbitmq.loadbalancer.passHostHeader=true"
- "traefik.http.services.rabbitmq.loadbalancer.server.port=15672"
networks:
network_public:
external: truePersonalize:
- Troque “rabbitmq.seudominio.com.br” para seu nome de DNS (FQDN);
- Variável RABBITMQ_DEFAULT_VHOST: O vhost padrão é “/” mas alterei para “default“;
- Altere a senha do usuário admin em RABBITMQ_DEFAULT_PASS;
- Personalize o valor de segurança do RABBITMQ_ERLANG_COOKIE;
- Os parâmetros “cpus” e “mem_limit” devem ser personalizados para montar um ambiente crítico (acima de milhares de mensagens);
- O “networks: … external: true” define que a rede “network_public” já existe previamente, retire o “external: true” se desejar criar uma rede específica.
Comando para gerar cookie seguro:
# Gerar sequencia hexadecimal para cookie seguro:
openssl rand -hex 32;
# Saida de exemplo:
# ce97851904e9d9663116eee446d2dc19fa77808681c5bd8770498b6b05cb7c0f
2.3 – Primeiro acesso web
O RabbitMQ pode ser totalmente administrado pela interface web!
Acesse a URL configurada na variável $FQDN do script acima para abrir no navegador.

Após logar, a interface web permite a criação de objetos (VHOSTs, exchanges, bindings, filas, novos usuários, controle de privilégio, logs, estatísticas, etc).

Vou me ater aos comandos e scripts pois eles facilitam o boot de ambientes automatizados e a criação automatizada de objetos.
3 – Comandos básicos de terminal
Esse capítulo aborda as operações de administração do MQ por meio do shell (terminal).
Se você estiver no terminal do servidor utilize sempre “docker exec …“.
Se estiver no shell dentro do container inicie os comandos em “rabbitmqctl …“.
Para entrar no terminal do container rabbitmq, execute:
# Nome do container
NAME="rabbitmq";
# Entrar no shell do container:
docker exec -it $NAME bash;
3.1 – Status e sanidade do ambiente
Esses comandos visam verificar se o RabbitMQ está rodando e operacional:
# Nome do container
NAME="rabbitmq";
# Comandos básicos
# Status geral
docker exec $NAME rabbitmqctl status; # Status do serviço:
docker exec $NAME rabbitmqctl ping; # Teste de funcionamento
docker exec $NAME rabbitmqctl environment; # Informações detalhadas
# Listar filas
docker exec $NAME rabbitmqctl list_queues;
# Listar exchanges
docker exec $NAME rabbitmqctl list_exchanges;
# Listar conexões
docker exec $NAME rabbitmqctl list_connections;
# Listar plugins habilitados
docker exec $NAME rabbitmq-plugins list --enabled;
# Health check manual
docker exec $NAME rabbitmq-diagnostics -q ping;
# Habilitar um plugin
#- docker exec $NAME rabbitmq-plugins enable <nome_do_plugin>;
3.2 – Operações básicas
Agora vamos manipular os objetos:
# Nome do container
NAME="rabbitmq";
# Comandos básicos de gestão de usuários:
# Listar usuários
docker exec $NAME rabbitmqctl list_users;
# Conferir permissões do usuário
docker exec $NAME rabbitmqctl list_user_permissions admin;
# Adicionar usuário
docker exec $NAME rabbitmqctl add_user user01 tulipa;
# Alterar senha do usuário
docker exec $NAME rabbitmqctl change_password user01 javali;
# Definir tag no usuário (administrator = super-poderes):
docker exec $NAME rabbitmqctl set_user_tags user01 administrator;
# Deletar usuário:
docker exec $NAME rabbitmqctl delete_user user01;
# Gerenciamento de Virtual Host (VHOST):
# Listar virtual hosts
docker exec $NAME rabbitmqctl list_vhosts;
# Criar virtual host
docker exec $NAME rabbitmqctl add_vhost n8ntests;
# Adicionar usuário para uso no VHOST:
docker exec $NAME rabbitmqctl add_user operador tulipa;
# Listar/Verificar usuários:
docker exec $NAME rabbitmqctl list_users;
# Definir permissões de um usuario no VHOST (configure, write, read)
docker exec $NAME rabbitmqctl set_permissions -p n8ntests operador ".*" ".*" ".*";
# Conferir permissões do usuário:
docker exec $NAME rabbitmqctl list_user_permissions operador;
# Retirar todas as permissões do usuário:
docker exec $NAME rabbitmqctl clear_permissions -p n8ntests operador
# Remover virtual host:
docker exec $NAME rabbitmqctl delete_vhost n8ntests;
# Listar/Verificar exchanges
docker exec $NAME rabbitmqctl list_exchanges -p default;
docker exec $NAME rabbitmqctl list_exchanges -p n8ntests;
# Listar/Verificar filas
docker exec $NAME rabbitmqctl list_queues -p default;
docker exec $NAME rabbitmqctl list_queues -p n8ntests;
# Listar/Verificar bindings
docker exec $NAME rabbitmqctl list_bindings -p default;
docker exec $NAME rabbitmqctl list_bindings -p n8ntests;
# Listar/Verificar canais ativos:
docker exec $NAME rabbitmqctl list_channels -p default;
docker exec $NAME rabbitmqctl list_channels -p n8ntests;
# Declarar exchange do tipo fanout para broadcast
docker exec $NAME rabbitmqctl -u operador -p tulipa -V n8ntests \
declare exchange name=broadcast_exchange type=fanout;
# Criar fila n8nq01:
docker exec $NAME rabbitmqctl -u operador -p tulipa -V n8ntests \
declare queue name=n8nq01 durable=true;
# Criar fila n8nq02:
docker exec $NAME rabbitmqctl -u operador -p tulipa -V n8ntests \
declare queue name=n8nq02 durable=true;
# Fazer o binding das filas com a exchange (obs: sem routing key para fanout):
# - binding broadcast_exchange->n8nq01
docker exec $NAME rabbitmqctl -u operador -p tulipa -V n8ntests \
declare binding source=broadcast_exchange destination=n8nq01;
# - binding broadcast_exchange->n8nq01
docker exec $NAME rabbitmqctl -u operador -p tulipa -V n8ntests \
declare binding source=broadcast_exchange destination=n8nq02;
# Conferir:
docker exec $NAME rabbitmqctl list_exchanges -p n8ntests;
docker exec $NAME rabbitmqctl list_queues -p n8ntests;
docker exec $NAME rabbitmqctl list_bindings -p n8ntests;
docker exec $NAME rabbitmqctl list_channels -p n8ntests;
# Conferir canais ativos:
docker exec $NAME rabbitmqctl list_channels -p n8ntests;
# Listing channels ...
# pid user consumer_count messages_unacknowledged
# <rabbit@rabbitmq.1754427035.64342.0> operador 1 0
# Desconectar canal:
docker exec $NAME rabbitmqctl close_connection \
"<rabbit@rabbitmq.1754427035.64342.0>" "Cai-cai-balao"
# Closing connection <rabbit@rabbitmq.1754427035.64342.0>, reason: Cai-cai-balao
# Listar filas com mais detalhes (default):
docker exec $NAME rabbitmqctl list_queues name messages consumers;
# Listar filas com mais detalhes no VHOST n8ntests:
docker exec $NAME rabbitmqctl list_queues -p n8ntests name messages consumers;
# Purgar uma fila (remover todas as mensagens):
docker exec $NAME rabbitmqctl purge_queue -p n8ntests n8nq01;
docker exec $NAME rabbitmqctl purge_queue -p n8ntests n8nq02;
# Parar aplicação RabbitMQ (mantém Erlang VM):
docker exec $NAME rabbitmqctl stop_app;
# Iniciar aplicação RabbitMQ:
docker exec $NAME rabbitmqctl start_app;
# Resetar node (remove dados):
docker exec $NAME rabbitmqctl reset;
# Forçar reset:
docker exec $NAME rabbitmqctl force_reset;
4 – API do RabbitMQ
Software que fazem uso do protocolo AMQP irão se conectar ao seu servidor na porta 5672/tcp e funcionar normalmente.
Já se você quiser controlar o sistema via API HTTP REST você pode usar as endpoints na URL publicada (https://rabbitmq.seudominio.com.br).
Você precisará criar um login (usuário e senha) previamente (seção 3.2) para informar nos comandos da API.
Você pode usar o login admin ou o login operador dos exemplos.
Endpoint de teste básico de funcionamento do acesso à API: /api/whoami
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Acessando endpoint de teste de login:
curl -u "$USER:$PASS" -X GET "$URL/api/whoami";
# Retorno:
# {"name":"operador","tags":["administrator"],"is_internal_user":true}
Endpoints informativas (método GET), troque o nome em negrito pelo nome do objeto desejado:
- /api/overview
- /api/nodes
- /api/cluster-name
- /api/healthchecks/node
- /api/permissions
- /api/users/username_here/permissions
- /api/vhosts
- /api/vhosts/vhostname_here/permissions
- /api/exchanges
- /api/exchanges/exchange_here
- /api/queues
- /api/queues/queue_here
- /api/queues/vhostname_here/queue_here
- /api/bindings
- /api/bindings/vhostname_here
- /api/exchanges/vhostname_here/broadcast_exchange/bindings/source
- /api/queues/vhostname_here/queue_here/bindings
- /api/connections
- /api/connections/connection_name
Os objetos podem ser manipulados alterando o método HTTP, observe:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Criar novo vhost "vtest9988":
# obs: sem retorno, apenas código HTTP 201
curl \
-v \
-u "$USER:$PASS" \
-X POST \
-H "content-type:application/json" \
"$URL/api/vhosts/vtest9988";
# Deletar vhost "vtest9988":
# obs: sem retorno, apenas código HTTP 204
curl \
-v \
-u "$USER:$PASS" \
-X DELETE \
-H "content-type:application/json" \
"$URL/api/vhosts/vtest9988";
4.1 – Manipulação de usuários
Exemplos para manipulação de usuários pela API:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Listar usuários:
curl -u "$USER:$PASS" -X GET \
\
"$URL/api/users";
# Informações de um usuário:
curl -u "$USER:$PASS" -X GET \
\
"$URL/api/users/operador";
# Criar novo usuário xpto1 com senha senha123:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
\
-d '{"password":"senha123","tags":""}' \
\
"$URL/api/users/xpto1";
# Alterar senha do usuário xpto1 com senha 123mudar e add tag "administrator":
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
\
-d '{"password":"123mudar","tags":"administrator"}' \
\
"$URL/api/users/xpto1";
# Deletar usuário
curl -u "$USER:$PASS" -X DELETE \
\
"$URL/api/users/xpto1";
4.2 – Manipulação de exchanges
Exemplos para manipulação de exchanges pela API:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Criar exchange fanout chamada brdinput:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
-d '{"type":"fanout","durable":true}' \
\
"$URL/api/exchanges/n8ntests/brdinput";
# Criar exchange direct chamada excdirect:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
-d '{"type":"direct","durable":true}' \
\
"$URL/api/exchanges/n8ntests/excdirect";
# Criar exchange topic chamada exctopic:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
-d '{"type":"topic","durable":true}' \
\
"$URL/api/exchanges/n8ntests/exctopic";
# Deletar exchanges:
curl -u "$USER:$PASS" \
-X DELETE \
\
"$URL/api/exchanges/n8ntests/brdinput";
curl -u "$USER:$PASS" \
-X DELETE \
\
"$URL/api/exchanges/n8ntests/excdirect";
curl -u "$USER:$PASS" \
-X DELETE \
\
"$URL/api/exchanges/n8ntests/exctopic";
4.3 – Manipulação de filas (queues)
Exemplos para manipulação de queues (filas) pela API:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Criar fila durável chamada qqt001:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
\
-d '{"durable":true}' \
\
"$URL/api/queues/n8ntests/qqt001";
# Criar fila com argumentos específicos chamada qqpersonalite:
JSON='{"durable":true,"arguments":{"x-message-ttl":60000,"x-max-length":1000}}';
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
\
-d "$JSON" \
\
"$URL/api/queues/n8ntests/qqpersonalite";
# Purgar fila (remover todas as mensagens):
curl -u "$USER:$PASS" \
-X DELETE \
-H "content-type:application/json" \
\
"$URL/api/queues/n8ntests/qqt001/contents";
# Deletar filas:
curl -u "$USER:$PASS" -X DELETE "$URL/api/queues/n8ntests/qqt001";
curl -u "$USER:$PASS" -X DELETE "$URL/api/queues/n8ntests/qqpersonalite";
4.4 – Manipulação de bindings
Exemplos para manipulação de bindings (escutas de entrada da fila) pela API:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Criar binding entre exchange broadcast_exchange e a fila qqt001:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
-d '{"routing_key":"","arguments":{}}' \
"$URL/api/bindings/n8ntests/e/broadcast_exchange/q/qqt001";
# Criar binding com routing key específica:
curl -u "$USER:$PASS" \
-X PUT \
-H "content-type:application/json" \
-d '{"routing_key":"error.logs","arguments":{}}' \
"$URL/api/bindings/n8ntests/e/logs_exchange/q/error_queue";
# Deletar binding específico:
curl -u "$USER:$PASS" \
-X DELETE \
"$URL/api/bindings/n8ntests/e/logs_exchange/q/error_queue/error.logs";
4.5 – Publicando na exchange
Exemplo para enviar uma mensagem a uma exchange:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Publicar mensagem em exchange:
# - Mensagem JSON:
JSON='{"properties":{},"routing_key":"","payload":"Teste","payload_encoding":"string"}';
# - Enviando pra endpoint da exchange:
curl -u "$USER:$PASS" \
-X POST -H "content-type:application/json" \
-d "$JSON" \
"$URL/api/exchanges/n8ntests/broadcast_exchange/publish";
# - Retorno: {"routed":true}
4.6 – Coletando mensagem da fila
Exemplo para coletar mensagens de uma fila:
# Variaveis
# - Nome de DNS para acesso pelo navegador
URL="https://rabbitmq.seudominio.com.br";
# - Login para usar a API:
USER="operador";
PASS="tulipa";
# Consumir uma única mensagem de uma fila:
curl -u "$USER:$PASS" \
-X POST \
-H "content-type:application/json" \
-d '{"count":1,"ackmode":"ack_requeue_false","encoding":"auto"}' \
"$URL/api/queues/n8ntests/n8nq02/get";
# Retorno: lista JSON, cada objeto é uma mensagem coletada:
# [
# {
# "payload_bytes":17,
# "redelivered":false,
# "exchange":"broadcast_exchange",
# "routing_key":"",
# "message_count":0,
# "properties":[],
# "payload":"Mensagem de teste",
# "payload_encoding":"string"
# }
# ]
# Consumir múltiplas mensagens (limite de 5 por coleta):
curl -u "$USER:$PASS" \
-X POST -H "content-type:application/json" \
-d '{"count":5,"ackmode":"ack_requeue_false","encoding":"auto"}' \
"$URL/api/queues/n8ntests/n8nq02/get";
# Retorno: lista JSON, cada objeto é uma mensagem coletada:
# [
# { "payload_bytes": 19, … },
# { "payload_bytes": 32, … },
# { "payload_bytes": 21, … },
# { "payload_bytes": 18, … },
# { "payload_bytes": 23, … }
# ]
“Não há assunto tão velho que não possa ser dito algo de novo sobre ele.“
Fiódor Dostoiévski
Terminamos por hoje!
Patrick Brandão, patrickbrandao@gmail.com
