{{announcement.body}}
{{announcement.title}}

EnMasse: Basic Setup and Usage on Kubernetes

DZone 's Guide to

EnMasse: Basic Setup and Usage on Kubernetes

In this article, we discuss how to get started using EnMasse, an open-source project for managed, self-service messaging on Kubernetes and Openshift.

· Cloud Zone ·
Free Resource

In this article, we are are going to learn and take a deep dive into EnMasse basics.

EnMasse is an open-source project for managed, self-service messaging on Kubernetes and Openshift. EnMasse can run on your own infrastructure or in the cloud and simplifies running a messaging infrastructure for your organization.

This is a project that provides Messaging as a Service in Kubernetes and Red Hat Openshift.

Developers/application owners can quickly spin up their own queues and topics without worrying about the scalability, network setting, and all sorts of operation setup.

Defining User Roles in EnMasse:

There are 2 types of Users in EnMasse

  • Admin: Administration-side to spin up and manage the platform. Responsible to install, set resource quotas, and create what is called as an 'Application Plans'.  The admin installs all the basic elements that control the necessary brokers, routers, user console, monitoring tools and also takes care of setting up the authentication and authorization of who has access to the platform. Admins control over the resource limitation and creates different 'Application Plan' that can apply to accompany different users’ needs.
  • End Users /Developers/Application Owners or 'Tenants': These are the users of the platform, that will be creating 'Address Space', and they will create destinations (queues/topics) by applying the plans on top of it. 

A typical overview of the EnMasse components and the workflow looks like below:

EnMasse workflow

  • Admins install EnMasse from Operator Hub or using YAML files, install it manually. 
  • Admins will create needed objects in the Enmasse namespace:
    1. AuthenticationService(s).
    2. StandardInfraConfig(s) Or BrokeredInfraConfig(s)..
    3. AddressSpacePlan
    4. AddressPlan
  • Each User/Tenant will be assigned to an 'Address Space'.
  • Each 'Address Space' consists of separate sets of brokers, router and console for it.
  • When additional user asks to access queues and topics on the same 'Address Space' they will be running on top of these sets of brokers and routers.
  • Admins do not create the actual ‘Address Space’,  they create ' Application Plans' that specify the resource limits, configuration.
  • When a new user comes in, they can create 'Address Space and create destinations’ based on the Plans.
  • After the queue and topics are created, the tenants can go ahead and create credentials maps to different access roles, they can decide what account has access to the admin console, which account has consume/produce right to any addresses(queues/ topics) in the Address Space.
  • Users have no visibility to queue or topics of other ‘Address Space’, unless specified. Once the addresses are created and configured correctly, applications will be able to use the credential to read/write to the messaging address.

Below are the things which the Developer/Tenant creates:

  • Address Space
  • Address — the destination created for user access. Maps to 'Address/Application Plan'.
  • Message User — defines the authentication method for destination access, and the authorization of destinations to this user.

Now that we have taken a quick tour of a typical workflow above, it is also important to understand 'Application Plan' and 'Address Space' in a bit more detail:

What Are Application Plans Really?

Similar to Kubernetes Pods, "ApplicationPlans are a layer of encapsulation on a set of brokers, their resource limits, the quotas on limits, the number of brokers in the address".

Types of Application Plans:

  • Infrastructure configuration: Configures the hardware resource allocated to the components, such as CPU, memory, storage of console, broker and router.
  • Address Space Plan: Applied to know how much hardware can be used by referring to infrastructure configuration, as well as controls the number of routers/brokers in the system. And so what queue/topic plans are available in the address space.
  • Address Plan: Address plan defines the consumption of resources based on the percentage. The sum of the number of brokers/routers of the entire address space will determine how many instances of broker and router will be running in the namespace.

What Is an Address Space?

An address space is a group of addresses that can be accessed through a single connection (per protocol).

  • ‘Address Space’ supports multiple protocols, which is defined by the ‘address space type’.

  • Clients/Users connected to the endpoints of an address space can send messages to or receive messages from any address it is authorized to send messages to or receive messages from within that address space.

  • Each messaging service provisioned in the service catalog creates a new address space.

  • Address space may share messaging infrastructure with other address spaces.

  • An address is part of an address space and represents a destination used for sending and receiving messages.

  • An address has a type, which defines the semantics of sending messages to and receiving messages from that address. An address also has a plan, which determines the amount of resources provisioned to support the address.

Installing EnMasse in Kubernetes:

You can install EnMasse Locally in your Kubernetes environment. You will need to have minikube installed. You need to make sure your Kubernetes cluster has the 'cluster-role'/ RBAC installed. To verify this, issue the below command,

Shell


The simplest way to install EnMasse is to use the predefined YAML bundles. Download the latest release from here.

Create the Kubernetes namespace where you will install EnMasse:

Shell


Change to the directory where you have downloaded the release files. Deploy the Enmasse bundle.

Shell


Install the example plans that come with the bundle. (This is optional):

Shell


After the example plans, install the example roles. (This is also optional as you can define your own roles)

Shell


Install the 'standard' authentication service.

Shell


Create an 'Address Space' YAML Definition

Shell


Check to make sure the status of the Address Space is in 'Ready' state. It will take some time for the address space to be 'Ready'.

Now, create the Actual addresses to send and receive the messages.

Shell


Create Users who wants to use the created addresses. You can create a non-authenticated user without credentials. However, it is advisable to have authentication of user using Base64 Encoding password. Before creating a new user, you must have already created an 'Address Space'.

Shell


That's it! You can now start sending and receiving the messages. I hope this article would help you explain the basics of EnMasse taking a deep dive into the most common and important concepts. I will look forward to continue publishing my next article on we can send and receive message efficiently using EnMasse and its features.

Topics:
cloud, enmasse, kubernetes, messaging, openshift

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}