Basics

Recently Docker brought some new stuff that I found very useful for developers. They are still in the experimental phase but are already very useful. Try them and give your feedback to the Docker team. The code I’m using for this is available here. Let’s start… Init Writing a Dockerfile when starting with a new application is tedious. Why? Because we are repeating most of the stuff over and over again. So, in the end, we reach to copy/paste solution. Of course, copy/paste needs to be modified to fit an application’s needs. I do not say that copy/paste is terrible, but with it, we miss new stuff that Docker brings to us. Even seasoned developers miss stuff. If we do not do it every day, we forget. Because of that, the Docker team brought us a new command called init. The init is not new but is still in beta. This time with more improvements. ...

During building services, we often need to build docker images. We do it multiple times a day. It can be a time-consuming task. Locally we only notice it a little, but in CI/CD pipelines, it can be a problem. In this post, I will show you how to speed up the process. I will show you how to use a cache, layer your Dockerfile, and use multi-stage builds, to make your builds faster. ...

As a developer, when working on a service, you face a problem with the working environment. And when I say working environment, I do not think about IDEs, stacks, OS, libraries, etc. I’m thinking about the environment where our services live. These days, our services are usually packed inside some container and put in some kind of distributed system. Most containers and other moving parts are controlled by Kubernetes, Nomad, and similar orchestration systems. ...

A Pod would be the smallest deployable unit one can create and manage inside Kubernetes(K8s). In practice, rarely you create a Pod directly. Instead, one would create a Deployment, a StatefulSet, a DaemonSet, a Job, or a CronJob. These are higher-level constructs that would create Pods for you. Here I’m covering common tasks that one would do with a Pod in daily work, like getting logs, opening a shell inside a container, debugging a Pod, etc. ...

While developing application and using docker-compose one question quickly arise: How to properly rebuild application? Once an image is built new one will not be built with the same tag as long it exists in a local cache. The compose builds an image it names it with the pattern <context>_<service_name>:latest. Where: Context is directory name where compose YAML is Service is service name in compose YAML file This means that you can stop or takedown the compose application, next time you run it your images will not be rebuilt if they already exist. Anyway, we aim to rebuild/restart only parts of the system that are changed. Once the compose application is running, we only rebuild the service we are working on. ...