Continuing on from part 2 where we introduced the concept of container registries to distritbute immutable container images, in the article we are going a step further and introducing the concept of container orchestration.
In our small example application we have four containers but in real world applications, especially in microservice architectures, a lot more containers make up the application’s architecture. This is very difficult to manage using manual methods, instead container orchestration tools are used to deploy and manage these applications on top of a fleet of servers (usually virtual machines) on a cloud infractructure.
Continuing on from part 1 where we introduced the app’s architecture and implemented the solution using Docker and Docker Compose, in this article we will address the issue of distributing the images. Once the Docker image is created it becomes an artifact, two of the biggest advantages that containers add to the software development lifecycle (SDLC) is the fact that they are self-sufficient and immutable.
Being immutable doesn’t lend them to be used with software source control management (SCM) systems like Git or Mercurial, so we need a different type of solution to distribute these Docker images - a container registry.
In this series of articles I will discuss how to build a simple web application on cloud native architectures. The application iteslf is relatively simple comprising of a database (I used MongoDB), a backend application that contains (application) business logic written in NodeJS exposong a REST API which is publically accessible, serving a web front end to the application as well as other 3rd party clients.
The drawing below illustrates the architecture.
For many years I have been yearning to have a single operating system that I run for all my work and leisure needs, but I have always had to run Linux for my software development related tasks, and Microsoft Windows for general usage.
Linux works well for me when doing programming work due to the powerfull bash shell, the Linux command line utilities (like git, grep, cat, etc) and how well they integrate with the shell and a host of development tools that just works so naturally in Linux, like python and node.
In this post I am documenting what steps I made to convert a traditional NodeJS App that is launched from a command line using
node app.js Into a fully dockerized container solution. The App uses a MySQL database which it has static configuration for. I am not going into too much details about the App’s code or architecture but it is just worth noting that it has this piece of configuration for connecting to the database;
Data Science Getting Started Platform To get started quickly with data science, I started looking at python and its powerful set of libraries (like pandas, NumPy, Scikit-Learn, etc) that makes data analysis easier. I wanted to have a platform that is accessible over the internet so I can get to it from any laptop/PC that has internet access.
I decided to get a minimal Virtual Private Server (VPS) that supports containers so I can set up a Docker container with all the languages and frameworks/libraries/tools and mount a path on the VPS that contains all the projects I am working on, which will be checked in to git.
Installing Docker on Ubuntu This post is essentially my notes on getting started quickily with Docker. I set this up in my lab machines running Ubuntu 16.04.1 LTS, the steps are based on the excellent instructions written on the Docker getting started guide
Add the Docker project repository to APT sources sudo apt-get install apt-transport-https ca-certificates sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D echo "deb https://apt.dockerproject.org/repo ubuntu-xenial main" | sudo tee /etc/apt/sources.
Delivery of software as microservices running on immutable and self-sufficient containers is a very sobust method and has gained a lot of popularity in the recent years. Containers usually expose tyhe microservice as a web service acccessible through a certain port number on the host. Because host machines are able to run many conatiners and the fact that these containers need to be started and shut down quickly and easily without any side effects, it is not really feasible for consumers of these web services to point to manually assigned hosts and ports.
