The document provides a comprehensive guide on running Axigen, a mail service, within a Docker container, detailing the setup, architecture, and operational commands. It explains how Docker enables quick application development, testing, and deployment while emphasizing the benefits of lightweight containerization. Instructions for creating, stopping, starting, updating, and managing Axigen instances are included, along with information on relevant Docker commands and configurations.

1. DETAILS
OF RUNNING
AXIGEN ON
DOCKER
Details of Docker
Docker, an open source technology, is used primarily for developing /
shipping and running applications. Docker enables you to segregate the
applications from your underlying infrastructure so that the software delivery
is quicker than ever. Management of infrastructure is made simple and easy
via Docker, as it can be managed just the same way how we can manage
our own applications. Bringing in the advantages of Docker for shipping,
testing, deploying the code – we can significantly reduce the delay between
the development stages to hosting the same code on Production.
Axigen on Docker
────
Axigen Based Mail
Service on Docker
Architecture
────
Deploying
────
Running
────
BUSINESS SOFTWARES
& SOLUTIONS
64 Santoshpur Avenue D2
Kolkata 700075
+9133 24724013
www.bssit.net

2. The Docker Platform:
Docker provides the flexibility of packaging and running the application in a loosely coupled
environment that surpasses the hardware related boundaries called as a Container. The levels of
isolation and also the Docker security makes it possible to run many containers at the same time on a
host which is Docker enabled. Containers can be thought of as the Virtual Computers but with the
only difference of reduced OS. In other words, Containers are light weighted as they do not really need
to run on a hypervisor but can run directly on the Host machine’s Kernel. This also means that there
can be more containers on a given Docker enabled host than if it were to be using Virtual machines.
An irony here is that you can run Docker containers within hosts which are virtual machines itself!
Docker provides the required tooling and also a platform to manage the lifecycle of your Docker
containers:
We can develop applications and their supporting components using containers.
With the above, the container becomes the basic unit for distribution and also in testing application.
When the application is already, we can deploy your application into a production environment. This
can either be done as a container or as an orchestrated service. This works the same whether your
production environment is a local data
center, a cloud provider, or a hybrid of the
two.
The Docker Engine:
The Docker Engine is a client-server
application with the following major
components running as the internals of it
and they are:
A server that is long-running which is called
as a daemon process (the dockerd
command).

3. A REST API which specifies interfaces that programs can use to communicate with the daemon and
also be able to instruct it on what to do next.
A command-line interface (CLI) client (the docker command).
The CLI uses the Docker provided REST APIs to control or interact with the Docker daemon through
scripting or even the direct Docker CLI commands. Many of the other applications also use the
underlying APIs and also uses the CLI interface as well. The daemon manages the part of creating and
managing the Docker objects as like the Images, Containers, Networks and also the volumes.
Docker can be used for more than what we can actually think of, but to limit to the very useful
scenarios and the most used scenarios – let us take the very important ones to take a closer look into
it.
1. Fast, consistent delivery of your applications:
Docker enables and also streamlines the development lifecycle into a disciplined environment where
developers are allowed to work in these standardized environments with the use of local containers
that provide the applications and services. Docker Containers form the biggest usage for the
Continuous Integration and Continuous Development
workflows (CI / CD).
2. Consider the following example scenario:
Developers can concentrate on coding the modules
locally and then it can be shared over to their
colleagues using the Docker containers.
The developers can put Docker to use in pushing their
applications into a test like an environment and also
execute automated and manual regression tests.

4. Developers if they find bugs, they can put in their efforts in resolving them and then push the fix into
the same local environment and then test the fix for correct working as well.
Once the testing phase is completed, delivering the fix to the Customer is nothing difficult as it is just
going to be pushing the fix into the Production environment from the Test environment.
3. Responsive deployment and scaling:
Docker with its container-based platform makes it very easy and also allows highly portable
workloads. Docker containers have the flexibility running on a developer’s laptop, a physical machine,
a virtual machine, a virtual machine in a data center, on cloud providers, on-premise providers, or an
amalgam of all the mentioned environments until now. Dynamically managing the workloads is very
easy with the Docker’s portability and light weighted nature. It also makes it every easy to scale up or
to tear down applications and services, as and how the business dictates it to.
4. Running more workloads on the same hardware:
As discussed in the above sections that Docker is
lightweight, along with it, it is lightning fast as well. It
provides viable, cost-effective alternative to its
counterparts as like the hypervisor-based virtual
machines. This enables than you can consume more
on these resources and at the same time achieve the
business goals as well. It is very much recommended
for high-density environments and also for the
small/medium deployments where there is always
more to be done with fewer resources.
How does Docker work?
Docker as any other counterpart in this arena has a client-server architecture. Docker Daemon which
forms the server component can be held responsible for any of the actions that relate with containers.
The Docker daemon receives these commands from either the Docker client via the Command Line
Interface (CLI) or through the Docker REST APIs. Having said that the Docker client can reside on
the same host as that of Docker Daemon or it may be available on a totally different machine
altogether.
Images from the basic building blocks in the context of Docker and Containers are built from these
images. We can understand Images to be templates with the required configurations of applications
and then containers are just copies of these images. Images are always maintained and organized in a
layered manner. Each and every change in an image is added as a layer on top of it.

5. With the basic understanding of what Docker Images and Docker Containers are, let us now try to
understand what Docker registries are all about. Docker registry can be understood as a repository of
all Docker images. Using this super cool feature named Docker registry, we can build and share
images amongst peers and colleagues of your team. Docker registries can be either Public or Private as
well. If you Docker registry is public, then it means that all your images can be accessible by the
Docker hub users. Docker registry which is Private in nature is nothing less than GIT, we can build
images locally and commit it them to push it to Docker Hub.
A Docker Container can be understood as the actual execution environment for Docker as such. As
explained earlier, Docker containers are created out of Docker images. You can configure all the
required applications with the required configuration in a container and commit it to make a golden
image out of it. We can then build more containers from it as we like. Two or more containers may be
linked together to form a tiered application architecture, fulfilling business needs and requirements.
Docker containers can be started or stopped, committed or terminated altogether – but a point to
remember here is that if a docker container is terminated without being committed, all the changes
made to that specific Docker container will be lost forever.

6. Conclusion:
In this article, we have introduced the concepts of Docker and where this wonderful application finds
its usage. Docker provides containerization of services into secluded individual virtual machines
without really worrying about the OS and networking resources. We have also understood the usage,
architecture and the design of Docker. Hope this article was in detail for you to understand the
concepts pretty well.
RUNNING AXIGEN ON DOCKER
Introduction
The Axigen Docker image is provided for users to be able to run an Axigen based mail service within a Docker
container.
Image structure
The image relies on a Centos 7 (centos:7) image; on it, Axigen is installed (from RPM) and basic configuration is
performed.
The disk structure obeys the RPM defined structure:

/opt/axigen — binaries and other files

/var/opt/axigen — data files
The "/var/opt/axigen" is configured as a Docker volume and must be preserved between container runs, to
preserve the mail server data (configuration, mailbox data, etc.).
The following services are enabled and mapped as 'exposed' TCP ports in Docker:
 SMTP (25 - non secure, 465 - TLS)
 IMAP (143 - non secure, 993 - TLS)
 POP3 (110 - non secure, 995 - TLS)
 WEBMAIL (80 - non secure, 443 - TLS)
 WEBADMIN (9000 - non secure, 9443 - TLS)
 CLI (7000 - non secure)

7. Using the Axigen image / container
An important point is that the Axigen instance data is not the container itself (which holds just package
files — binaries and so on) but the "/var/opt/axigen" volume, which holds the actual server configuration and
the server (mailbox / users) data. A container may be deleted, upgraded (new container created from a newer
image), stopped, started, and the server data will be preserved, as long as the Docker volume which is mapped
upon container startup is preserved.
CREATING A NEW AXIGEN MAIL SERVER INSTANCE
The Axigen data volume may be mapped, upon container creation, to the Docker volume or to a host filesystem
path (bind mount). The latter approach is recommended, allowing the administrator to examine the Axigen data files
(storage, logs, configuration) directly from the Docker host.
# docker run --name=axigen -dt -v <volume>:/var/opt/axigen -p 443:443 -p 9443:9443 -p 993:993
-p 995:995 -p 25:25 -p 465:465 -p 9000:9000 -p 7000:7000 axigen/axigen
The following options are used:

-d → detach from the container (since we want it to run in the background)

-t → allocate a pseudo-TTY to allow capturing Axigen stdout in the Docker logs

-v → map a volume in /var/opt/axigen; <volume> may be a Docker volume or a local host path (bind
mount). See the The Axigen data volume section below for more details
 -p → port mapping: map the ports exposed by the container (Axigen, in this case) to host ports. In the
example above, ports 443 (WebMail), 9443 (WebAdmin), 993 (IMAPs) and 995 (POP3s), 25 (SMTP) and
465 (SMTPs) are mapped. The Axigen container also exposes other ports which may me mapped, if needed
(see the Image structure section).
When the Axigen data volume (be it a Docker volume or a bind mount) is first used in the container, it will be
initialized.
Upon creation, the container will also be started.
Check that the container is running:
# docker ps -f ancestor=axigen

8. The output should display a running container, along with the port mapping and other information:
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS
NAMES
03fa1abc15d2 axigen/axigen "/bin/sh -c /app/run…" 6 minutes ago Up 6
minutes 80/tcp, 110/tcp, 0.0.0.0:25->25/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:465-
>465/tcp, 0.0.0.0:993->993/tcp, 143/tcp, 0.0.0.0:995->995/tcp, 0.0.0.0:9000->9000/tcp,
0.0.0.0:9443->9443/tcp, 8443/tcp axigen
At this point, if the WebAdmin port was mapped (-p 9443:9443), the Axigen WebAdmin interface should be
accessible via the host IP: https://localhost:9443/. Since Axigen will only run in demo mode for a limited period
without an assigned license, please use the WebAdmin to upload your license file (free or commercial), before this
period expires. After the demo period expires, the container will no longer start, and the Axigen data volume will
need to be reinitialized (deleted and recreated).
The administrator password is set randomly upon the data volume initialization, and is available in the container logs
(note that you invoke the docker logscommand using the Container ID from the previous output; alternatively you
can invoke also with the container given name, see the --name parameter of the docker run command):
# docker logs 03fa1abc15d2
Initializing workdir
Administrator's password saved
Admin password is: L5NuNBVZXA6mr
Axigen[18]: INFO: Starting Axigen Mail Server version 10.1.4 (Linux/x64)
Axigen[18]: SUCCESS: supervise ready... (respawns per minute: 10)
Axigen[18]: INFO: supervise: spawning a new process to execute Axigen Mail Server version
10.1.4 (Linux/x64)
In the example above, the generated administrator password is L5NuNBVZXA6mr
STOPPING AND STARTING THE CONTAINER
A running Axigen container may be stopped by using the docker stop <container_id> command, where
the <container_id> is obtained from the output of the docker ps command. Axigen containers (including stopped
ones) may be viewed with the docker ps -a -f ancestor=axigen command. When a container is stopped, its
full state is preserved, only the Axigen process is stopped.
A stopped Axigen container may be started by using the docker start <container_id> command.
UPDATING AN AXIGEN IMAGE TO THE LATEST VERSION AVAILABLE
Use the following command to update your local axigen/axigen image to the latest version:
work_macbook:axigen_data user$ docker pull axigen/axigen

9. Using default tag: latest
latest: Pulling from axigen/axigen
af4b0a2388c6: Already exists
f7670ac967c0: Already exists
0ac75bc5506e: Pull complete
6c9808647fc6: Pull complete
8c563906b2d1: Pull complete
93ca44a4ef4f: Pull complete
9116a082e08b: Pull complete
b961a44e6e82: Pull complete
34caaa3f2d4f: Pull complete
ba4a6f28b6ed: Pull complete
b10af91db8f9: Pull complete
01309461c6d5: Pull complete
Digest: sha256:1cebda79647fc86db7ec26f0087d864ff01700ef6aa4265f80452d436d659d53
Status: Downloaded newer image for axigen/axigen:latest
work_macbook:axigen_data user$
After an image is updated, you will need to recreate the axigen instance with an existing axigen data volume as
described below.
DELETING A CONTAINER
The administrator may delete an Axigen container (without deleting the actual data — configuration and domains,
which is stored in the Axigen data volume).
A stopped Axigen container may be deleted by using the docker rm <container_id> command. Please note that
only stopped containers may be deleted.
Along with the container, all data which is not Axigen data volume (e.g. shell history, system logs) will be lost.
RECREATING AN AXIGEN INSTANCE WITH AN EXISTING AXIGEN DATA VOLUME
If the Axigen data volume was preserved, a new container may be created using the same volume; the admin
password, configuration and domain data will be preserved. The same command as for the initial instance creation
is used, but providing an existing, populated Axigen data volume as the fist parameter in the -vmapping.

10. docker run --name=axigen -dt -v <volume>:/var/opt/axigen -p 443:443 -p 9443:9443 -p 993:993 -
p 995:995 -p 25:25 -p 465:465 -p 9000:9000 -p 7000:7000 axigen/axigen
This method is also used for the following purposes:
 Upgrading to a newer version of Axigen
 Recreating the container ↔ host port mapping
THE AXIGEN DATA VOLUME
Using a host filesystem path (bind mount)
A directory on the host must be created. If selinux (for Linux hosts) is used,
the folder must be labeled with the svirt_sandbox_file_t selinux label.
Example:
mkdir /var/axigen_var
chcon -t svirt_sandbox_file_t /var/axigen_var
This way, the administrator may access files from the axigen var partition (logs, configurations) without accessing
the Docker container itself.
Important Note
Since Axigen is accessing (reading / writing) files in the data volume, it is
imperative that the administrator does not modify files in the mapped host
folder, as this action may have unpredictable results.
More information about Docker bind mounts here: https://docs.docker.com/storage/bind-mounts/
Using a Docker volume
A persistent Docker volume may be used. If it does not exist, it will be automatically created on the container
instantiation.
More information about Docker volumes here: https://docs.docker.com/storage/volumes/