Rabbitmq: Azure Container Instance - RabbitMQ

Created on 12 Oct 2018  路  5Comments  路  Source: docker-library/rabbitmq

az container create     
--resource-group rabbitmq     
--name rabbitmq-next     
--image rabbitmq:3.7.8-management     
--dns-name-label rabbitmq-next     
--ports 15672 5672 5673     
--azure-file-volume-account-name xxxxxxxxxxxxxxxxxxxxxxxxxx
--azure-file-volume-account-key XXXXXXXXXXXXXXXXXXXXXXXXX    
--azure-file-volume-share-name rabbitmqnext     
--azure-file-volume-mount-path /var/lib/rabbitmq/mnesia 
--environment-variables RABBITMQ_ERLANG_COOKIE=XXXXXXXXXXXXXXXX RABBITMQ_NODENAME=rabbitmq-next

It appears the machine will boot the first time and create the correct folder structure but fail when destroying and recreating the instance with the same volume mapped:

Successful Boot Example

2018-10-12 13:49:01.442 [info] <0.202.0> 
 Starting RabbitMQ 3.7.8 on Erlang 20.3.8.5
 Copyright (C) 2007-2018 Pivotal Software, Inc.
 Licensed under the MPL.  See http://www.rabbitmq.com/

  ##  ##
  ##  ##      RabbitMQ 3.7.8. Copyright (C) 2007-2018 Pivotal Software, Inc.
  ##########  Licensed under the MPL.  See http://www.rabbitmq.com/
  ######  ##
  ##########  Logs: <stdout>

              Starting broker...
2018-10-12 13:49:01.548 [info] <0.202.0> 
 node           : rabbitmq-next@wk-caas-xxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxx
 home dir       : /var/lib/rabbitmq
 config file(s) : /etc/rabbitmq/rabbitmq.conf
 cookie hash    : xxxxxxxxxxxxxxxxxxxxxxxxxxxx
 log(s)         : <stdout>
 database dir   : /var/lib/rabbitmq/mnesia/rabbitmq-next

Failed Boot Example

2018-10-12 13:45:01.692 [info] <0.225.0> 
 node           : rabbitmq-next@wk-caas-xxxxxxxxxxx-xxxxxxxxxxxxxx
 home dir       : /var/lib/rabbitmq
 config file(s) : /etc/rabbitmq/rabbitmq.conf
 cookie hash    : xxxxxxxxxxxxxxxxxxxxxxxxx
 log(s)         : <stdout>
 database dir   : /var/lib/rabbitmq/mnesia/rabbitmq-next
2018-10-12 13:45:12.095 [info] <0.231.0> Memory high watermark set to 572 MiB (599998464 bytes) of 1430 MiB (1499996160 bytes) total
2018-10-12 13:45:12.138 [info] <0.233.0> Enabling free disk space monitoring
2018-10-12 13:45:12.138 [info] <0.233.0> Disk free limit set to 50MB
2018-10-12 13:45:12.156 [info] <0.236.0> Limiting to approx 1048476 file handles (943626 sockets)
2018-10-12 13:45:12.156 [info] <0.237.0> FHC read buffering:  OFF
2018-10-12 13:45:12.156 [info] <0.237.0> FHC write buffering: ON
2018-10-12 13:45:12.238 [error] <0.224.0> CRASH REPORT Process <0.224.0> with 0 neighbours exited with reason: {{failed_to_cluster_with,['rabbitmq-next@wk-caas-xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'],"Mnesia could not connect to any nodes."},{rabbit,start,[normal,[]]}} in application_master:init/4 line 134
2018-10-12 13:45:12.239 [info] <0.33.0> Application rabbit exited with reason: {{failed_to_cluster_with,['rabbitmq-next@wk-caas-xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxx'],"Mnesia could not connect to any nodes."},{rabbit,start,[normal,[]]}}
{"Kernel pid terminated",application_controller,"{application_start_failure,rabbit,{{failed_to_cluster_with,['rabbitmq-next@wk-caas-xxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxx'],\"Mnesia could not connect to any nodes.\"},{rabbit,start,[normal,[]]}}}"}

Kernel pid terminated (application_controller) ({application_start_failure,rabbit,{{failed_to_cluster_with,['rabbitmq-next@wk-caas-xxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxx'],"Mnesia cou

Note: Some values replaced in the above example for privacy

I believe this issue may be related to https://github.com/docker-library/rabbitmq/issues/6

question

Most helpful comment

I got around this issue by using

RABBITMQ_NODENAME=rabbit@localhost
RABBITMQ_USE_LONGNAME=true

That way despite the azure container instance having a new hostname each time (that i can't control) the localhost will always be accessible and the queue volume name will match the defined nodename

All 5 comments

As far as im aware there is no way to provide the docker equivelent of a hostname value

One of the important things to note about RabbitMQ is that it stores data based on what it calls the "Node Name", which defaults to the hostname. What this means for usage in Docker is that we should specify -h/--hostname explicitly for each daemon so that we don't get a random hostname and can keep track of our data

Docker Hub docs

If Azure's implementation of containers doesn't let you set the hostname, then that sounds like an issue to bring up with them and not really a problem with the image.

One random suggestion is to try one of the environment variable used by RabbitMQ, RABBITMQ_NODENAME (https://www.rabbitmq.com/configure.html#define-environment-variables) with a value of rabbit@rabbitmq-next (ie use a dns name that the system can resolve as itself).

Since this isn't a problem with the image, in the future it'd be better to post questions like this in the Docker Community Forums, the Docker Community Slack, or Stack Overflow.

But isnt that the point of the node name environment variable (RABBITMQ_NODENAME)? Which does work on the first boot but fails on the second boot

See how i did this above before this ticket was closed

I got around this issue by using

RABBITMQ_NODENAME=rabbit@localhost
RABBITMQ_USE_LONGNAME=true

That way despite the azure container instance having a new hostname each time (that i can't control) the localhost will always be accessible and the queue volume name will match the defined nodename

I got around this issue by using

RABBITMQ_NODENAME=rabbit@localhost
RABBITMQ_USE_LONGNAME=true

That way despite the azure container instance having a new hostname each time (that i can't control) the localhost will always be accessible and the queue volume name will match the defined nodename

this worked for me too.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michaelkrog picture michaelkrog  路  5Comments

556u5ut picture 556u5ut  路  5Comments

aram535 picture aram535  路  4Comments

zhousujian picture zhousujian  路  5Comments

fanhualei picture fanhualei  路  4Comments