By now, you’re probably familiar with the concepts of exchanges, bindings, and queues in RabbitMQ. When you actually explore RabbitMQ, however, you will soon realize there is a concept that hasn’t always been covered in detail, namely, vhosts (Virtual Hosts).
What is a vhost?
Think of vhosts as individual, uniquely named containers. Inside each vhost container is a logical group of exchanges, connections, queues, bindings, user permissions, and other system resources. Different users can have different permissions to different vhost and queues and exchanges can be created, so they only exist in one vhost. When a client establishes a connection to the RabbitMQ server, it specifies the vhost within which it will operate, as in the following example: amqp://myuser:mypassword@localhost:5672/myvhost
Resources such as exchanges and queues are named resources inside the vhost container, making each vhost essentially a RabbitMQ mini-server. When configuring RabbitMQ, at least one vhost is needed, which in default is just a slash “/”.
Vhosts are created through the management portal, through the HTTP API or via rabbitmqctl. View vhosts by entering the admin tab and select the Virtual Hosts. Select the Add New Virtual Host options to create a new vhost. The permissions within the vhost and the users assigned to it depend on your system requirements, and it’s up to you to assign users to the vhost. A newly created vhost always has a default set of exchanges, but no other entities and no user permissions.
A vhost is a virtual separation
Vhosts do not share exchanges or queues between them, and users, policies, etc. are unique to each vhost. Essentially, RabbitMQ vhosts are like a virtual machine for a physical server, allowing for multiple secure application operations through virtual rather than physical separation. As the separation is virtual, it is important to remember that the vhosts are not physically separated from each other and therefore they might affect each other’s performance.
If one service is experiencing a traffic spike or a code bug, this may cause problems for other services and affect their performance. A vhost can be created for each service to hold all of the logical infrastructure, which also allows for better individual topology management.
Flexibility - Same broker, different applications
RabbitMQ vhosts make it possible to have many different virtual brokers within one single RabbitMQ instance. The same broker can be used on parts of different applications. You can separate environments, e.g. production to one vhost and staging to another vhost, within the same broker instead of setting up multiple brokers.
Resource permission within a vhost
Resource permissions in RabbitMQ are dependent on each vhost. A user does not have global permissions, just permissions in one or more vhost(s), specified by you. This ensures absolute separation since all users, exchanges, queues, and bindings in each vhost cannot be reached from any other virtual hosts. This makes vhosts extremely useful to avoid naming collisions and to separate multiple customers.
Limits and Security within a vhost
An exchange on one vhost cannot be bound to a queue on another, which is good for security and for portability. For instance, a banking app that has a deposit function using its own vhost. This deposit vhost may initially operate on the same instance that houses other functions of the app, but one day the deposit traffic goes way up and uses excessive server resources, slowing down the other functions. Because deposits happen on a separate vhost, this function can easily and safely be moved to another server.
Connection leaks and users that create way too many queues are two common errors in RabbitMQ. As of RabbitMQ version 3.7.0, it is possible to set a per-vhost limit. This means that you can set a limit on the maximum allowed number of queues or concurrent client connections in a vhost.
Shared servers in CloudAMQP are separated though vhosts
Shared servers on CloudAMQP, like Little Lemur and Tough Tiger are virtual hosts located on a large shared RabbitMQ server. This means that a single instance of RabbitMQ is running to serve multiple tenants.
Explore our blog for great tutorials and information on how to configure RabbitMQ. Remember that you can get started with RabbitMQ at CloudAMQP within two minutes. Please email us if you have suggestions, questions, or other feedback!
