Your First Steps in a Containerized World Using Docker

i personally think the concept behind running your (micro)services inside containers is a big game changer in the tech landscape. in every tech article, at every conference, or when just having a chat with someone in the tech community, there is a word or two on containers.

picking up containers and transforming your architecture, team, or company isn't that straightforward. this blog post gives you some hand-holding for your first steps into containers and starting the transformation.

shipping containers

like real world shipping containers, it's all about playing by the rules. if your container is built following those rules (dimensions), it can be shipped everywhere.

a port can handle those containers, a ship can transport them over the ocean, and a truck can bring the container to your doorstep. any the nice thing that it doesn't matter what is inside a container because it's isolated by the form factor of the actual container.

container isolation

like the real world example of a container, the contents are isolated. software containers are doing the same thing, it's an isolated process. a secure sandbox where your (micro)service can freely play and make its own rules. one container can contain a golang app and the other container, 100% isolated, runs a java app or even a database.

as shown is this little cat animation, containers are isolated, but using networking, they still discover each other and consume their services, if needed.

vms vs. containers

why containers are not equal to vms.

a virtual machine (vm) is an isolated operating system

a vm is isolated by the hypervisor and can consolidate bare-metal power into separated chunks. each chunk is an isolated system. services ( processes ) running on a vm are not isolated from each other. they can interact with the same cpu, network, and memory space.

running a polyglottic microservice architecture on a vm or a set of vms is hard.

a container is an isolated process

a container shares the kernel of the underlying operation system (vm or bare-metal server) and uses its own isolated runtime environment for the process. running services ( processes ) on the underlying operation system is just as simple starting a new container . the container runtime makes sure they are isolated from the root filesystem, user space, cpu, network, and memory space.

running a polyglottic microservice architecture with containers is easy.

the containerization machine

running a service using containers starts with creating the contents of your container. the dominant container technology is still docker . if you want to containerize your services with docker, you need to understand the dockerfile format. the dockerfile is the contract explaining how the contents of your container look like, and the output is what we call the container image .

you need to understand and make the containerization process your own. steps you need to take:

• install the docker runtime on your local box
• run and understand the hello world tutorials and the docker commands:

$ docker run hello-world

• writing your own dockerfile
• building your first image:

$ docker build -t=awesomeimage:1.0.0 .

• run you first service using a container:

$ docker run awesomeimage:1.0.0

of course, if you are into service oriented architecture, mix-and-match technologies, or add a database to the mix, it's time to learn docker-compose .

docker-compose gives you a simple dsl (domain specific language) using a yaml format to define which service you want to run and how services are related (networking).

with both those tools mastered and by understanding how things are related, you can start deploying your application to production .

final note

have fun learning docker and the containerization machine. it's a journey with ups and downs. at the end of your journey, you'll find enlightenment and start releasing more often, breaking down monoliths, and transforming your company with containers.