0

I'm using Docker with VirtualBox and dinghy and docker-compose. I'm creating a container via docker-compose. The following is the docker-compose.yml config.

rabbitmq:
  image: rabbitmq:3-management
  ports:
    - "15672:15672"
    - "5672:5672"
  environment:
    VIRTUAL_HOST: 'rabbitmq.docker'
    VIRTUAL_PORT: 15672
    RABBITMQ_DEFAULT_USER: docker
    RABBITMQ_DEFAULT_PASS: docker

Everything works great. I can enter the management page of RabbitMQ by visiting the url rabbitmq.docker:15672 and the user docker is configured correctly.

I wanted to experiment a little so I removed the environment section. I deleted the image and the container and built/run it again. The thing that I don't understand is this, I could still visit the management page using the same uri, although I did not specify a virtual host this time.

The resulting yml file is this

rabbitmq:
  image: rabbitmq:3-management
  ports:
    - "15672:15672"
    - "5672:5672"

What have I missed? Since I no longer specify a virtual host this, to my understanding, shouldn't be happening. Is there a way to see all the virtual hosts that Docker is using?

Alkis Kalogeris
  • 17,044
  • 15
  • 59
  • 113

1 Answers1

2

Is there a way to see all the virtual hosts that Docker is using?

You are misunderstanding the term "Virtual Host" in this context. Docker has no notion of virtual hosts at all. In this context, the term Virtual Host is specific to RabbitMQ (or rather AMQP, which is implemented by RabbitMQ). This is documentated in the RabbitMQ documentation (emphasis mine):

[...] the "virtual host" (or vhost) [...] specifies the namespace for entities (exchanges and queues) referred to by the protocol. Note that this is not virtual hosting in the HTTP sense.

When using the rabbitmq Docker image, the management UI will always be accessible under any hostname, regardless of your VIRTUAL_HOST environment variable (as long as you're using the 3-management tag of that image).

I recommend a thorough reading of the documentation of the rabbitmq Docker image. There you will see that the image supports an environment variable named RABBITMQ_DEFAULT_VHOST. The variables VIRTUAL_HOST and VIRTUAL_PORT are not evaluated in any way by this image and do not have any effect at all.

helmbert
  • 35,797
  • 13
  • 82
  • 95
  • `the management UI will always be accessible under any hostname`, what do you mean? – Alkis Kalogeris Dec 29 '15 at 18:54
  • That it's unimportant which HTTP hostname you use for the management UI, be it `rabbitmq.docker`, then container's IP or any other hostname. If you're mapping port 15672 to localhost, `http://localhost:15672` will also do fine, the same as `http://127.0.0.1:15672` or `http://[::1]:15672`. – helmbert Dec 29 '15 at 19:04
  • That's what I understood, but I wanted to make sure. Have you tested this? Because for me this is not the case. I've already tested this possibility and the only HTTP hostnames that work are the container's ip (which is expected) and `rabbitmq.docker`. – Alkis Kalogeris Dec 29 '15 at 19:08
  • Moreover I wanted to ask about this `The variables VIRTUAL_HOST and VIRTUAL_PORT are not evaluated in any way by this image and do not have any effect at all.`. Do you have any resources so I can read more about this? I've seen the setup that I'm using in a number of examples with `docker-compose` and this is used. So if what you are saying is correct, I need to understand by what these variables are evaluated, what is their purpose. Maybe what you are saying is true with vanilla `Docker`, I really don't know, but I'm using the `docker-compose` tool and maybe there are differencies. – Alkis Kalogeris Dec 29 '15 at 19:16
  • I've googled a bit about this; the `VIRTUAL_HOST` env variable is typically only used by the [`jwilder/nginx-proxy`](https://github.com/jwilder/nginx-proxy) image. Any possibility that you're using this image? – helmbert Dec 29 '15 at 20:07
  • Ok now this makes sense. The tool I'm using (`dinghy`) uses this underneath. `Dinghy will run a HTTP proxy inside a docker container in the VM, giving you easy access to web apps running in other containers. This uses the excellent nginx-proxy docker tool.` – Alkis Kalogeris Dec 29 '15 at 20:11
  • If you want you can include all this new information to your answer and I will accept it. Thank you for your help so far. All these aspects plus the fact that I'm using Docker only for one week made everything complicated. – Alkis Kalogeris Dec 29 '15 at 20:23