简体   繁体   中英

Persisting RabbitMQ Configuration in Docker Image

Configuring RabbitMQ inside a Docker image is a nightmare. I can connect to the RabbitMQ interface when running RabbitMQ as a linked container with Fig and successfully configure vhosts and permissions for my Celery workers to connect without problems.

However, restarting the Docker loses the configuration settings. How can I persist these settings?

Some things I have tried:

  • Write /etc/rabbitmq/rabbit.config to the Docker image from an export after configuring everything. RabbitMQ ignores it.
  • Setting the hostname in my Docker file with ENV HOSTNAME localhost , but this seems to interfere with linking Docker containers in Fig.

What am I doing wrong? Is there a canonical Dockerfile for getting a configured RabbitMQ docker container for Docker linking development purposes, preferably using Fig?

As ben has mentioned here :

The issue seems to be due to the default hostname changing at every new container with Docker, and RabbitMQ actually binds the configuration to the host name.

So the key is to set the hostname .

Here is a solution with docker-compose:

version: '3'
services:
  rabbitmq:
    image: rabbitmq:management
    hostname: qsearchmq    # specify your hostname here
    volumes:
      - rabbitmq:/var/lib/rabbitmq    # use a volume to store the data
volumes:
  rabbitmq:
    driver: local

This is an old post, but worth answering. It's clear you're not committing your container after it exits. Even if you are, the problem could also be that you're starting a vanilla container, instead of the previously committed version. Look up "docker commit" and "docker start", and contrast with "docker run".

Also be aware that Docker creates ephemeral ports when coupling containers to hosts. When you need to communicate to a socket inside a container, the configuration a client will need to talk to it could vary - for example, the port number for the container that a client needs to use can change every time you restart a committed RabbitMQ container. There is a bi-directional mapping of container port to ephemeral host ports. This means it is mostly the host that has to compensate. Unless of course, you use the -p option, or correctly configure EXPOSE in the Dockerfile, if you're using a custom one. You are using one, right?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM