After a long break I complete a series of posts on building smaller container images, this time showing how to build lightweight images for RDKit using buildah. In the previous post I introduced using buildah. In short, it showed how to package what you want into a container images without needing to include the build infrastructure (make etc.) or package managers (yum etc.).

[Actions] are a welcome addition to the GitHub service. They add a free, built-in CI/CD capability similar to [GitLab-CI], [Travis] and others.

What we’ll see in this blog post is a simple pattern to build a container image and push it to [Docker Hub]. What happens is based on whether we’re on a branch, responding to a pull-request, or responding to changes on main.

In this article we’ll see how to deploy container images from a [GitLab] private registry into Kubernetes.

Public container images, in registries like [Docker Hub], can be deployed easily without needing to provide any credentials. Kubernetes Deployments (and other objects like StatefulSets) simply need the image, i.e. informaticsmatters/neo4j:3.5.20. However, images resident on a private registry will require you to deploy an ImagePullSecret that Kubernetes uses to pull the image.

[Kubernetes documentation] describes such secrets with a section explaining how they can be created from the command-line.

Here we provide a brief cheat-sheet that explains how to create a pull-secret using [GitLab] and then use that in a Deployment.

We now have a better approach for building Centos based RDKit Docker images now that Centos 8 is available.

We previously described our approach to building container images for RDKit (see here for example). Key to our approach is keeping the image size relatively small.

Up till now building Centos based images has been tricky as since the March 2019 release of RDKit a very recent version of the boost libraries were required (due to the switch to modern C++), but the ones that come with Centos 7 are too old, as well as RDKit now requiring Python 3 which traditionally has not played nicely with Centos 7. We did find a workaround for all this, but it was not nice.

Now that Centos 8 is available this problem is solved and we’ve been able to simplify the process. The approach closely follows the one we use for Debian based images. We’ve pushed Python3 and Java images for the October 2019 RDKit releases and a build from the master branch and from now on will do our best to generate these as well as the Debian based images for future releases. We might also provide Centos based cartridge and Tomcat images, but generating those is more complex so stick with Debian based images for those for now.

See the GitHub repo for all the details (and the various branches you’ll find there).

In this post we look at using buildah to generate container images that only contain what we want, no extra fluff. We show how this can let us generate truly small images that will load faster and be more secure, and do this without the need for the Docker daemon to be running.

This series of posts describes how we can generate smaller Docker images. In the first post we outlined a common problem with container images - that they frequently contain artefacts that were needed to build the software or to install it into the container. We’ll show one approach that can be used to avoid this extra bloat, and so generate smaller and more secure containers.

This is the first in a series of blog posts about building better Docker images.

Docker Inc is widely acknowledged for transitioning containers from geekdom to the real world inhabited by us developers, and did this by providing easy to use tools for building, sharing and running containers. Key to this is docker build command and the Dockerfile.