Master Go While Learning Containers

Containers,Programming

I spent half a year deep-diving into the world of containers and their orchestration. I have been enjoying it very much and learned a lot. On my journey, I need to tackle lots of interesting and specific concepts. But there is one commonality almost every project in this area possesses. When it comes to containers - the Go programming language is ubiquitous!

I firmly believe that a real understanding of technology comes only after a thorough look under its hood. Here is the list of projects I stumbled upon digging into containers guts. I've read the source code of these projects to some extent and find some of them really beautiful, while others somewhat - sloppy and inconsistent, but functional. But regardless of the code quality, there is a good opportunity to learn the best common Go practices from one of the hottest real-world projects:

github.com/containerd

This is a home of containerd project. It describes itself as an open and reliable container runtime. If you use docker, you use containerd as well (although indirectly). From the README file: "containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users."

Notable repositories:

github.com/containernetworking

CNI (Container Network Interface) project focuses on the management of networking interfaces via code. From its README file: "... project, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to implement."

Notable repositories:

github.com/containers

I like this one. It's a home for varying projects (mostly driven by Red Hat) aiming to replace docker's monolith with a set of single-purpose utilities (and or libraries) for building, pulling/pushing images, running containers, etc.

Notable repositories:

github.com/cri-o

Historically, Kubernetes used Docker to manage containers on the worker nodes. After a while, people started pushing more container runtimes (rkt for the second one probably) to Kubernetes. To make the task of adding a new runtime easier (and cleaner), the Kubernetes Container Runtime Interface (CRI) was introduced. Basically, the interface consists of the subset of docker commands (run container, pull image, etc). The cri-o project is a production-grade implementation of a CRI-compatible container manager. It seems like another Red Hat project and it's heavily based on the packages from github.com/containers.

github.com/docker

The leftovers of the old docker (after its renaming to moby):

github.com/kubernetes

Well... It's Kubernetes! By the time of writing, its main repo is github.com/kubernetes/kubernetes and it's a home of the multiple components at the same time. You won't believe, how often other projects from the list in this post have a dependency on the main Kubernetes repo just because they need a tiny bit of its code. And yes, it's huge.

Other notable repositories:

  • minikube - minikube implements a local Kubernetes cluster on macOS, Linux, and Windows. minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit.

  • dashboard - Kubernetes Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage applications running in the cluster and troubleshoot them, as well as manage the cluster itself.

  • client-go - Go clients for talking to a kubernetes cluster. This one is nice. If you want to build something new and work with K8s API directly, that's exactly what you need.

  • kubectl - seems like an effort to extract kubectl code from the main monorepo.

github.com/kubernetes-sigs

This is a home for various semi-official Kubernetes-related projects. I personally find interesting these two:

  • kind - Kubernetes IN Docker - local clusters for testing Kubernetes. 🤪

  • cri-tools - CLI and validation tools for Kubelet Container Runtime Interface (CRI). Due to my work on a CRI-compatible container manager I find this project extremely useful. It's like a reduced version of the docker CLI client with an aim to debug and troubleshoot CRI-compatible runtimes. Additionally, it offers an automated conformance test.

github.com/moby

I really like the code quality of everything originated in Docker (including containerd).

  • github.com/moby/moby - aka github.com/docker/docker.

  • buildkit - concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit. Sounds fancy, but haven't checked it out yet.

github.com/opencontainers

This could be one of the most important (but probably not one of the most popular) places when it comes to containers. While runc (also originated by Docker) is the most widely used container runtime out there, the image and runtime specifications are standards that made the interoperability of the container projects possible.

Miscellaneous

Almost every project from the list above uses at least one of the utility packages from the list below (pun intended):

  • github.com/pkg/errors - Package errors provides simple error handling primitives. A handy drop-in replacement for the standard Go errors package.

  • github.com/sirupsen/logrus - Structured, pluggable logging for Go.

  • github.com/spf13/cobra - Cobra is both a library for creating powerful modern CLI applications as well as a program to generate applications and command files.

  • github.com/spf13/viper - Go configuration with fangs! Viper is a complete configuration solution for Go applications including 12-Factor apps. It is designed to work within an application, and can handle all types of configuration needs and formats.

  • github.com/urfave/cli - A simple, fast, and fun package for building command line apps in Go. The goal is to enable developers to write fast and distributable command line applications in an expressive way.

Instead of conclusion

After staring at the code of these projects for a while, you'll notice that more advanced of them are built on top of more basic ones the re-usage of the code is truly impressive. Having enough understanding of the domain, it's possible to combine these components as lego bricks producing an infinite number of the new project. As an example just take a look at the openfaas or rancher ecosystems. It seems there are people out there coming up with ideas of new projects on breakfast =)