Improve MifosX installation documentation for other Operating Systems using Docker containers


History of containers

Linux kernel allows running multiple isolated user space instances. A container is such an isolated environment where one or more processes can be run. Containers focus on process isolation and containment instead of emulating a complete physical machine. Historically, chroot in Linux kernel has provided some level of isolation by providing an environment to create and host a virtualized copy of a software system, ever since early ‘80s. But the term process containers didn’t come up until around late 2006. It was soon renamed to ’Control Groups’ (cgroups) to avoid confusion caused by multiple meanings of the term 'containers’ in the Linux kernel. Control Groups is a linux kernel feature available since v2.6.24 that limits and isolates the resource usage of a collection of processes. Subsequently, namespace isolation was added.This lead to the evolution of Linux Containers (LXC), an operating system level virtualization environment that is built on Linux kernel features mentioned earlier, like chroot, cgroups, namespace isolation, etc.

Given the recent massive spike in interest in Linux Containers, you could be forgiven for wondering, “Why now?”. It has been argued that the increasingly prevalent cloud computing model more closely resembles hosting providers than traditional enterprise IT, and that containers are a perfect match for this model. Despite the sudden ubiquity of container technology, like so much in the world of open source software, containerization depends on a long series of previous innovations, especially in the operating system. “One cannot resist an idea whose time has come.” Containers are such an idea, one that has been a long time coming.

Overview & how it relates to Fineract

It's important to reiterate that the next evolution of Fineract Platform focuses on being faster, lighter and cheaper to change (than existing mifos) so that it is more responsive to the needs of Microfinance Institutions and Integrators.One of the ways of increasing agility for all stakeholder is to improve the ability of Fineract platform to deployed faster on Containers and other operating systems.

In the past two years, there has been rapid growth in both interest in and usage of container-based solutions. Almost all major IT vendors and cloud providers have announced container-based solutions, and there has been a proliferation of start-ups founded in this area as well.The rapid growth of the Docker project has served to make the Docker image format a de facto standard for many purposes;

  1. Not bound to higher level constructs such as a particular client or orchestration stack

  2. Not tightly associated with any particular commercial vendor or project

  3. Portable across a wide variety of operating systems, hardware, CPU architectures, public clouds, etc.

Why docker? for automated installations

Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.

The docker build command builds an image from a Dockerfile and acontext. The build’s context is the files at a specified location PATH or URL. The PATH is a directory on your local filesystem. The URL is a the location of a Git repository.A context is processed recursively. So, a PATH includes any subdirectories and the URL includes the repository and its submodules. A simple build command that uses the current directory as context.

Docker containers are created by using [base] images. An image can be basic, with nothing but the operating-system fundamentals, or it can consist of a sophisticated pre-built application stack ready for launch.When building your images with docker, each action taken (i.e. a command executed such as apt-get install) forms a new layer on top of the previous one. These base images then can be used to create new containers.


In this Epic , our aim is to create dockerfiles that will help MFIs and integrators automate the installation of MifosX on different Operating Systems using docker.

  1. Provide essential base OS repositories (for example, ubuntu, centos) that serve as the starting point for the majority of users.

  2. Provide drop-in solutions for popular programming language runtimes, data stores, and other services, similar to what a Platform-as-a-Service (PAAS) would offer.

  3. Exemplify Dockerfile best practices and provide clear documentation to serve as a reference for other Dockerfile authors.

  4. Ensure that security updates are applied in a timely manner. This is particularly important as many Official Repositories are some of the most popular on Docker Hub.

  5. Provide a channel for software vendors to redistribute up-to-date and supported versions of their products. Organization accounts on Docker Hub can also serve this purpose, without the careful review or restrictions on what can be published.


Sub Task 1: Create dockerfile to automate Installation builds of MifosX on Ubuntu 14.04

Sub Task 2: Create dockerfile to automate Installation builds of MifosX on Ubuntu 15.04

Sub Task 3: Create dockerfile to automate Installation builds of MifosX on Ubuntu 15.10

Sub Task 4: Create dockerfile to automate Installation builds of MifosX on Ubuntu 16.04

Sub Task 5: Create dockerfile to automate Installation builds of MifosX on Core OS

Sub Task 6: Create dockerfile to automate Installation builds of MifosX on Photon OS

Sub Task 7: Create dockerfile to automate Installation builds of MifosX on Rancher OS

Sub Task 8: Create dockerfile to automate Installation builds of MifosX on Cent OS

Sub Task 9: Create dockerfile to automate Installation builds of MifosX on Fedora






William Ondenge

Implementation Priority




Story Points




50% Estimate


90% Estimate


productboard URL


Man Day Estimate




Epic Name

Improve MifosX installation