Cloud Native Applications: Creating a Mail Server Environment with Docker

Short Backstory on Deploying a Mail Server App into a Docker Container

Here’s a little backstory: I was recently going over the process of converting a standard RPM package to a cloud application with a friend who’s a Software Engineer. He’d already read a lot of what’s out there about containerization and was ready to take the next step, to try to do it himself. 

That’s how we got here, experimenting and going over the basic steps of how to deploy a mail server application into a Docker container, and then into a Kubernetes cluster. We hope us sharing this real-time, intuitive experiment with our community piques your interest, as it did ours. 

We’re going to show you every step, what issues we encountered, and how we solved them.

We want to avoid switching to ‘cloud native’ just because it’s a trendy buzzword. So, as we examine the technology, we also take a look at who can benefit the most from this particular mail server approach.

The Sample Application — Axigen Mail Server

For this demonstration, we’re going to be using the Axigen Docker Mail Server as a sample application. Why? I find that, while it’s specific to mail server technology, it shares a lot of modern web application requirements:

• A front end part where user requests are received.
• A backend that stores state.
• A static component that displays a nice user interface and connects to the front end.

This experiment can, therefore, be replicated with other applications as well.

Why Run a Cloud Native Mail Server 

As a stateful application, the benefits of turning a mail server into a cloud native, container-based app have only recently become known:

1. Weak coupling with the underlying operating system (running the container)

• the container can be easily moved without repackaging;
• relinquishes control of the underlying operating system, in terms of monitoring, software upgrades & more; (unlike the ‘Rehost’ model where the customer still needs to manage an operating system image provided by cloud providers)
• independence from the provider itself (no more application reinstall and data migration when switching providers).

2. Significantly simplified scale-up

• while vertical scaling is fairly simple in a virtualized environment (add CPUs, Memory and Disk capacity), horizontal scaling is considerably more limited;
• the container paradigm forces the application developer/packager to ‘think cloud native’, thus separating compute from storage from the model itself;
• due mainly to overwhelmingly lower overhead of a container versus a virtual machine, the number of instances can scale from tenths to thousands, thus lowering the burden on the software itself to handle too high of a concurrency level.

Who can benefit the most from a Cloud Native mail server approach?

The question is: why not just ‘rehost’? After all, there are numerous platforms out there (like AWS, Azure, IBM Cloud, to name a few) that offer cloud machines on which the same product package can be installed and operated just as easy (if not easier) than on premises.

Since going ‘cloud native’ is a significant initial investment in research and training, and most often yields benefits further down the road, it might make more sense to be embraced by users for whom the ‘cloud native’ benefits are higher:

• software developers, that can provide their customers with ‘cloud native’ benefits;
• medium to large companies, harnessing the resources needed for the initial investment;
• service providers, for whom scalability and maintenance costs reduction are important business factors.

Now that we’ve answered the why and for whom questions, let’s get started on the how. 

The Cloud Native Approach — Replatform

We’ve already touched on the ‘rehost’ or 'lift and shift’ approach - aka virtualizing a physical machine and importing it to a cloud provider, or simply migrating an existing on-prem virtual machine towards a cloud service.

With the steps below, we’re closing in significantly on our holy grail, cloud nativeness, via the ‘replatform’ approach.

Creating an Email Server Environment with Docker

Here’s the simplest way to achieve a container image based on a legacy packaged application (RPM, DEB).

For starters, since we need to run this application on Kubernetes, the first step we need to take is to Dockerize it. That is, to enable it to run on Docker.

While you can choose between several container software providers, Docker still reigns king, with a staggering 79% market share. 

As for the standard package to start from, we used the RPM distribution, this time based on what we know best and use most (RedHat vs Debian / Ubuntu).

Creating a docker image is quite similar to installing a package on a ‘real’ operating system. We assumed that the user has a basic knowledge of using the command line and has Docker installed. The goal, as stated above, is to exemplify how to obtain a container from a CentOS image.

1. Creating a CentOS Docker Instance

Let’s go ahead and create this Docker instance from the CentOS image:

From another terminal, we can observe the newly created instance:

Next, we perform OS updates, as we would with any regular operating system instance:

Great - everything is up to date now.

2. Installing Axigen in the Container Instance 

First, get the RPM:

Then install it:

Now we have Axigen installed in the container. It’s even already running (the installer starts it automatically):

Let’s see what happens when we leave the shell:

Is the instance still running?

No; that’s because the CentOS image runs ‘bash’ as the main container process; when bash exists, the container stops as well.

This is in fact the entire nature of experimentation: trying out different means of achieving the desired results and seeing exactly where that gets us. Good or bad. 

This is a crucial difference between a container and a classical Linux ‘host’ - there are no ‘daemons’ — in other words, no need to fork in the background (as, usually, programs started by SystemV-style — and Systemd, as well — init scripts work). 

We can take advantage of this when creating the Axigen image. Start the container again:

And check if it’s running:

Attach to it and check if Axigen is still running:

It’s not — and the reason for this shouldn’t come as a surprise: the Axigen process (and all subprocesses it forks / threads it starts) are stopped along with the original bash — 'the grandfather of them all’. 

Nonetheless, Axigen is still installed:

Good. We have a container with Axigen installed. However, our goal was an image, not a container.

3. Creating an Image from a Container

Stop the container again by leaving the shell:

And then summon the Docker magic:

Excellent; from the existing container, we’ve created a new image (my_new_and_shiny_axigen_image), that we may now use to create another container, with the OS updates already applied and Axigen installed: 

We still have to configure the container to start the Axigen binary on instantiation.
As the newly created image has inherited the entrypoint of the CentOS image, which is ‘bash’. We could, of course, start it:

But this is not the proper way to have a container running an app. The correct way is to configure the binary that will be used when the container is started, directly in the image. 

4. Setting the Entrypoint in the Container

To do that, we must revisit the image creation step:

In the image configuration, add the name of the command and arguments to be executed when the container is started:

Remember that the main process of the container must not fork in the background; it must continue to run, otherwise the container will stop. This is the reason the ‘--foreground’ argument is needed. 

Like Axigen, most Linux servers have such an argument, instructing them to run in foreground instead of forking in background.

5. Running the Created Image

Let’s check the updated image:

We’ve changed the -it ‘docker run’ parameter to ‘-dt’; without diving too much into details, this instructs docker to detach from the process. Axigen is the main process, hence an interactive mode does not make sense, as it would for a bash shell.

Docker allows us to run another process (not main, but a secondary process) by using ‘exec’. We shall run a bash, in interactive mode, so that we may review what happens in the container.

Ok, so Axigen is running. Is the WebAdmin interface (port 9000) running as well? 

It is, and it redirects us to the initial setup flow (/install).

Now, is the 9000 WebAdmin port also available from outside the container?

We need to instruct the container, upon instantiation, to map the 9000 port to the host, so it may be accessed from the outside.

Notice the ‘-p 9000:9000’ parameter. This instructs Docker to make the 9000 container port available in the host as well, on the same port number. And now, voilà:

Wrapping Up 

So what have we learned from this little experiment?

1. Converting an existing RPM / DEB package to a container image is fairly simple:

• instantiate a container with an OS of your preference, and for which you have the target software package;
• from the container, install the software (and optionally, perform some configurations);
• stop the container and convert it into an image, making sure to set the appropriate entrypoint (CMD);
• create as many containers as desired, using the new image;
• publish the image, if you need to make it available to others as well. 

2. The image we’ve created above is not yet ready for production. Here’s what it would take for it to become ready: 

• implement persistent data storage (it’s an email service, it stores mailboxes, so some data needs to be persistent);
   
• create network communication definitions: 
  • Docker will, by default, through NAT, allow the processes to communicate with outside (initiate connections);
  • we need, though, to be able to receive connections (email routing, client access) on specific ports.
• define options to preconfigure the Axigen instance upon startup (we may want to deploy it using a specific license. 

Now that a basic image is available, we would need to do some further digging into addressing the issues above, as well as automate the creation of the image (what happens when an updated CentOS image is available? How about when a new Axigen package is available?).

These topics above go way outside the scope of this article, but here are a few hints into what it would take:

• use a Dockerfile to create the image instead of instantiating the base then manually installing the Axigen software;
• define and map, in the Dockerfile, the required ENV, EXPOSE, VOLUME, and CMD directives;
• make use of Docker push / pull to share your image with others, through a public or private docker registry (image repository).

Now that we’ve created a containerized version of our Axigen package, what we have is a re-packaging of the app that allows deployment in the cloud.

Part 2 of this series is now up! Read on to see how we address actually creating and running this mail server environment with Kubernetes on Google Cloud.

Note: Axigen already provides a fully functional, ready for use Docker image in Docker Hub. You can find all the information and try it out for yourself here. 

We also offer an Axigen Helm chart for anyone who wants to deploy a clustered Axigen Mail server on Kubernetes platforms.

For help in gathering prerequisites, performing the installation, configuring your settings, and upgrading or uninstalling  your deployment, please visit our dedicated documentation page for the Axigen AxiHelm.

Both AxiHelm and the Axigen Docker Image are intended for actual production use and are adjusted as such.