Introduction

Important

Image names and tags in this documentation are provided without the registry prefix. Hence, REGISTRY/[ARCHITECTURE/][COLLECTION/]* needs to be prefixed to the image names shown in Tools and images.

Official guidelines and recommendations for using containers suggest keeping them small and specific for each tool/purpose (see docs.docker.com: Best practices for writing Dockerfiles). That fits well with the field of web microservices, which communicate through TCP/IP and which need to be composed, scaled and balanced all around the globe.

However, tooling in other camps is expected to communicate using a shared or local filesystem and/or pipes; therefore, many users treat containters as lightweight virtual machines. That is, they put all the tools in a single (heavy) container. Those containers are typically not moved around as frequently as microservices, but cached on developers’ workstations.

In this project, both paradigms are supported; fine-grained images are available, as well as all-in-one images.

Note

hdl examples in gh:im-tomu/fomu-workshop showcase a Makefile based solution that supports both strategies: the fine-grained pulling and the all-in-one approach. An environment variable (CONTAINER_ENGINE) is used for selecting which approach to use. For didactic purposes, both of them are used in Continuous Integration (CI). See im-tomu/fomu-workshop: .github/workflows/test.yml.