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
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/--hostnameexplicitly for each daemon so that we don't get a random hostname and can keep track of our data
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=trueThat 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.
Most helpful comment
I got around this issue by using
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