Permettant RabbitMQ-Les Connexions Au Serveur

Je vais essayer d'obtenir un Django Céleri travailleur pour se connecter à un serveur RabbitMQ, le tout fonctionnant sur le même hôte.

Cependant, lorsque je lance manage.py celery worker tout ce que j'obtiens est:

[2013-06-11 17:33:41,185: WARNING/MainProcess] celery@localhost has started.
[2013-06-11 17:33:44,192: ERROR/MainProcess] Consumer: Connection Error: Socket closed. Trying again in 2 seconds...
[2013-06-11 17:33:50,203: ERROR/MainProcess] Consumer: Connection Error: Socket closed. Trying again in 4 seconds...
[2013-06-11 17:34:03,214: ERROR/MainProcess] Consumer: Connection Error: Socket closed. Trying again in 6 seconds...
[2013-06-11 17:34:27,232: ERROR/MainProcess] Consumer: Connection Error: Socket closed. Trying again in 8 seconds...

Quand je l'inspection de mon /var/log/rabbitmq/[email protected] je vois plusieurs messages comme:

=ERROR REPORT==== 11-Jun-2013::17:33:44 ===
exception on TCP connection <0.201.0> from 127.0.0.1:43461
{channel0_error,opening,
                {amqp_error,access_refused,
                            "access to vhost 'myapp' refused for user 'guest'",
                            'connection.open'}}

Je suis en utilisant le package standard de Ubuntu 12.04 (repo, avec les paramètres par défaut et mon django-céleri paramètres de ressembler à:

BROKER_HOST = "localhost"
BROKER_PORT = 5672
BROKER_USER = "guest"
BROKER_PASSWORD = "guest"
BROKER_VHOST = "myapp"

Pourquoi est-RabbitMQ refusant les connexions?

OriginalL'auteur Cerin | 2013-06-11

  1. 41

    Il semble que vous devez accorder l'accès à l' "/myapp" vhost pour l'utilisateur "invité".

    À partir de la documentation:

    set_permissions [-p vhostpath] {user} {conf} {write} {read}

    Donc quelque chose de semblable à cela donnera à votre invité à l'utilisateur un accès illimité:

    rabbitmqctl set_permissions -p /myvhost guest ".*" ".*" ".*"
    Que faire si je veux donner, par défaut, l'accès complet à mon vhost lors de la création de rabbitmq image? parce que si nous lancer l'application dans le conteneur docker, puis, dans ce cas, nous ne voulons pas de manuel d'autorisations à obtenir l'application de travail, en général.

    OriginalL'auteur Scott Woodall