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.
No comments:
Post a Comment