Much to my surprise, starting from the last week Kubernetes became the part of my job description. It’s no longer something just interesting to try, I actually have to understand it now. And as you probably could tell from my older k8s post, I’m not quite there. The post sort of builds a logical example (containerized web server) but something just doesn’t click.
I was trying to understand what’s missing, and it seems like the problem is in the tooling. You see, there’re two and a half ways to run something in Kubernetes. One is through ad-hoc commands, like
kubectl run or
kubectl expose. They are simple, but they also skip few important concepts happening in the background, so the whole picture stays unclear. Continue reading “Dissecting Kubernetes example”
I’ve been running two WordPress blogs for some time and my biggest regret is that they are not running in Docker containers. If I did the right thing in the beginning, I wouldn’t have to worry about whether or not the server upgrade will be safe, or will I be able to recall server configuration when time to migrate comes. I actually would be able to spin up local blog replica, run some experiments on it (new settings, features or design change) and decide whether or not I want move that change into ‘production’.
However, it’s never too late. I’m reluctant to make a big change on the real server without prior tests, so today I’ll try to create local Docker replica of one of my blogs and see how that goes. Continue reading “Move existing WordPress site into Docker”
Docker is cool. It is a great tool to pack your application into set of containers, throw them into the host and they’ll just work. However, when it’s all happening within the single host, the app cannot really scale much: there’s fixed amount of containers it can accomodate. Moreover, when the host dies, everything dies with it. Of cause, we could add more hosts and join them with overlay network, so more containers can coexist and they still would be able to talk to each other.
However, maintaining such cluster would be a pain. How to detect if host goes down? Which containers are missing now? What’s the best place to recreate them?
Starting from version 1.12.0 Docker can work in Swarm mode and handle all of those tasks and even more. Continue reading “Quick intro to Docker Swarm mode”
Docker has several types of networks, but one of them is particularly interesting. Overlay network can span across hosts boundaries, so your web application container at HostA can easily talk to database container at HostB by its name. It doesn’t even have to know where that container is.
Unfortunately, you can’t just create overlay network and hope that it magically finds out about all participating hosts. There should be one more component in order to make that happen.
Of cause, we could use Docker in Swarm mode and problem’s solved. But we don’t have to. Configuring multi-host Docker network without Swarm is actually quite easy. Continue reading “Multi-host Docker network without Swarm”
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?
Continue reading “Communication between Docker containers”
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.
We store all relevant data in Google BigQuery and the whole task is basically to extract build results from the storage and present it in clear and simple way. Quite trivial. Continue reading “Playing with microservices”