Architecting Portable Applications with Docker

"But it works on my machine!"

Thats the endless cry of developers working on a team and developing in different environments. There's always one that just can't get the program to run, no matter what they try.

Sure, this problem is unfortunate, but what's worse is deploying applications across inconsistent environments. The more that an application must scale, the larger chance there is for inconsistency.

Enter Docker- a containerization platform that obliterates the problem of inconsistent environments and also provides other benefits like a smaller footprint compared to VM deployments.

What is a container?

A container is a standardized compute environment (like a Virtual Machine) that only contains the libraries and components that an application needs to run. Containers have a smaller footprint because they do not run their own kernel, but instead connect to the host's kernel through the containerd runtime.

How are containers so portable?

Containers can be hardened into images that can be replicated across machines, but it is the automated build process that truly makes containers rock.

When software is ready for deployment, it can be run through an image build pipeline, where a standardized set of commands (a Dockerfile) can be run to produce a container image.

This is an example of a Dockerfile used to build a NodeJS backend application:

FROM node:12

WORKDIR /home/node/app

COPY package.json ./
RUN yarn install

COPY . .

CMD [ "yarn", "start" ]

What do all of those commands mean?

• FROM: This Dockerfile builds an application backend on top of a nodejs 12 base image
• WORKDIR: This changes the working directory of the build process
• COPY: This copies files from the host computer into the container as it is being built
• RUN: This executes a command within the container itself (i.e., to install the required packages in this case)
• CMD: This provides a command that will be run when the container is started

So, when building a container image through a Dockerfile, it is important to think about a few things:

1. What software do I need on my container? This will determine your base image (node, mysql, python, etc.)
2. What files do I need to copy to my container?
3. Do I need to run any commands to build my software?
4. What command or process do I want to start when the container runs?

After considering these questions, you will have enough information to build your container through a Dockerfile. Regardless of the environment or application, these principals can be applied to produce a standardized image that will run anywhere.