Category: Development

Having an app running from within Docker container is fun, that’s for sure. But do you know what would be even more fun? Many apps running from within containers and talking to each other. Imagine that after playing enough with microservices, you finally decided to split some real monolithic web application into:

container, serving static web content, and

container, serving data through some sort of RESTful API.

First container opens 80th port and, while serving html/css/js by himself, talks to the second container when data request comes.

So idea is simple, but there’s one thing. How exactly those containers will communicate? How do they even find each other?

Imagine you have Node.js app you would like to run from within Docker container. Maybe you want to check if it still works on ‘another’ machine, or it’s a test run before adopting containers as the way of software delivery. Reasons may vary.

In order to have something tangible, let’s pick hello.js app which prints out ubiquitous ‘Hello World’:

What’s Docker.

On the surface Docker looks like another virtual machine (VM). Just pick Ubuntu image with hello-world app inside, type
docker run ubuntu hello-world in your terminal of choice, and hello-world will start, thinking it owns a whole machine running Ubuntu.

But Docker is not a VM, manager of VMs, or hypervisor of any kind. Docker is a platform for creating, launching and managing containers. Those looks like VMs, quack like VMs, but are much closer to a fence with a barbwire on top of it. No app can enter, no app can leave. What is bad for humans works great for applications in production environment.

Because Docker doesn’t have to deal with guest operating system and hardware abstraction, it can work with the speed that VMs can only dream of, while doing quite similar job. Continue reading “Quick intro to Docker”

Recently I was asked to build a small internal app: dynamic dashboard for one of our projectors, which are hanging all over the office and display some company info onto the walls: customer statistics, server-to-server latency, what tasks are in development, etc. My particular goal was to add release and builds statistics: build duration, failed/unreliable tests and anything else that could motivate us to produce more stable builds.