Public container images published by Polymath Robotics.
The images are pubished to https://hub.docker.com/u/polymathrobotics
| Image | Description | Source Location |
|---|---|---|
| aws-cli | Command-line interface v2 for Amazon Web Services | aws-cli |
| black | The uncompromising Python code formatter | black |
| buildpack-deps | A collection of common build dependencies used for installing various modules, e.g., gems | buildpack-deps |
| certbot certbot-dns-cloudflare lego |
Automatic Certificate Management Environment (ACME) clients for obtaining SSL/TLS certificates. | acme/certbot acme/certbot-dns-cloudflare lego |
| cinc-auditor | Cinc is an automation platform built from Chef | cinc/cinc-auditor |
| doctl | Command line interface for the DigitalOcean cloud | doctl |
| cinc dokken-almalinux-8 dokken-almalinux-9 dokken-amazonlinux-2 dokken-amazonlinux-2023 dokken-centos-stream-8 dokken-centos-stream-9 dokken-debian-11 dokken-debian-12 dokken-opensuse-leap-15.3 dokken-opensuse-leap-15.4 dokken-oraclelinux-8 dokken-oraclelinux-9 dokken-rockylinux-8 dokken-rockylinux-9 dokken-ubuntu-20.04 dokken-ubuntu-22.04 |
Operating system images for use with the kitchen-dokken Test Kitchen plugin | cinc dokken-almalinux-8 dokken-almalinux-9 dokken-amazonlinux-2 dokken-amazonlinux-2023 dokken-centos-stream-8 dokken-centos-stream-9 dokken-debian-11 dokken-debian-12 dokken-opensuse-leap-15.3 dokken-opensuse-leap-15.4 dokken-oraclelinux-8 dokken-oraclelinux-9 dokken-rockylinux-8 dokken-rockylinux-9 dokken-ubuntu-20.04 dokken-ubuntu-22.04 |
| flake8 | flake8 is a python tool that glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code | flake8 |
| gh | The GitHub CLI tool | github-cli |
| glab | The GitLab CLI tool | glab |
| go2chef | A Golang tool to bootstrap a system from zero so that it's able to run Chef | go2chef |
| golang | Go (golang) is a general purpose, higher-level, imperative programming language. | golang |
| grafana-oss | Grafana - the open observability platform | grafana/grafana-oss |
| hadolint | Containerfile/Dockerfile linter | hadolint |
| jfrog-cli | JFrog CLI provides a simple interface that automates access to JFrog products. | jfrog-cli |
| ldap-utils | OpenLDAP client utilities. | ldap-utils |
| lego | Let's Encrypt/ACME client and library written in Go. | acme/lego |
| markdownlint | A tool to check markdown files and flag style issues | markdownlint |
| meshcmd | Command line tool used to perform many tasks related to computer management of Intel Active Management Technology (AMT) devices | meshcmd |
| netbox | Repository for modeling and documenting networks. | netbox |
| node | Node.js is a JavaScript-based platform for server-side and networking applications. | node |
| nvidia-l4t-base nvidia-l4t-jetpack nvidia-l4t-ros |
NVIDIA L4T is a Linux based software distribution for the NVIDIA Jetson embedded computing platform. | nvidia/l4t-base nvidia-l4t-jetpack nvidia-l4t-ros |
| op | 1Password command-line interface 2 | op |
| paperspace-cli | Command-line interface for the Paperspace cloud | paperspace-cli |
| portainer-ce | ortainer Community Edition GUI-based container management platform. | portainer-ce |
| postgres | The PostgreSQL object-relational database system provides reliability and data integrity | postgres |
| prometheus alertmanager blackbox_exporter collectd_exporter node_exporter |
Prometheus monitoring system and time series database | prometheus/prometheus prometheus/alertmanager prometheus/blackbox_exporter prometheus/collectd_exporter prometheus/node_exporter |
| pulumi-base pulumi-python |
Pulumi Infrastructure as Code CLI | pulumi-base pulumi-python |
| python | The Python programming language | python |
| redis | Redis is an open source key-value store that functions as a data structure server. | redis |
| ros | The Robot Operating System | humble-jammy iron-jammy jazzy-noble noetic-focal rolling-jammy |
| ruby | Ruby is a dynamic, reflective, object-oriented, general-purpose, open-source programming language | ruby |
| shellcheck | Static analysis tool for shell scripts | shellcheck |
| smokeping | Smokeping network latency grapher | smokeping |
| stereolabs-zed stereolabs-zedbot |
StereoLabs ZED SDK | stereolabs-zed stereolabs-zedbot |
| terraform | Terraform enables you to safely and predictably create, change, and improve infrastructure. | terraform |
| ubuntu-autoinstall | Generate Ubuntu autoinstall images/ISOs. | ubuntu-autoinstall |
Re-packaging is a time-honored trend in system administration! It's not as common as you might think to use a vanilla install to manage a fleet of servers. Software installs often need to be re-packaged and re-mixed for a specific purpose. In our case for robotics, neuromorphic engineering, systems and embedded applications.
It's not as consistent as one would hope to allow a rootless deploy of some official images. In some cases we need to re-mix a container image for that reason.
For embedded and systems work, we need images built for a variety of processors, not all official images provide builds even for intel, arm64 and arm32 chips. So we try as much as we can for a wider variety of platforms.
Very few official images use Ubuntu as a base image in their "FROM" field. The container images produced from this repository nearly all consistently use Ubuntu as the base image, which is the preferred base for the Robot Operating System (ROS).
Because ROS uses Python heavily, it's not a good idea to use an alpine base image. It does not have a compatible C-runtime. And adding all the necessary C dependencies to an alpine image ironically makes it BIGGER than an equivalent Debian/Ubuntu image.
The official Debian images aren't nearly as good as a base for container images as the Ubuntu ones, because they are updated less frequently with security updates than the Ubuntu ones. Most Debian base images contain more security vulnerabilities than the equivalent Ubuntu ones, simply because they aren't updated as often. Also the commonly used "buildpack-deps" base images contain a lot of extra unused packages that aren't ever used in ROS, like the subversion, bzr and mercurial source control management programs to try to save space for a broader set of images. This unfortunately also increases the threat surface with a lot of extra packages we don't need, so we prefer not to use "buildpack-deps" where feasible.
It would be best to use Google's distroless images, but they are on the other end of the spectrum for dependencies, they don't include nearly enough. The Ubuntu images strike the best compromise in having most of the packages we need for ROS while not having too much that we don't need.
The repo has the following structure:
-
bin/contains supporting scripts used to create container images. This allows maintainers to more easily run parts of the build locally for troubleshooting. The build system shells out to the same scripts so everything uses the same code, whether or not you are building locally or using automated builds in the cloud. -
Rest of the directories contain all the source code for the images, primarily Containerfiles/Dockerfiles in BuildKit format. An alphabetical index is also provided in this README.md.
Following container image conventions there is a separate directory for each container image. The container image
tools have a single target directory for source files and by default the image tools scan all files in a directory
for some operations. Thus there is a subdirectory per image, though a single image may be built for multiple
platforms. The source for all the container images is under the src/ tree in this repo. GitHub Actions pipelines
in .github/workflows have been set up to publish these images to the
polymathrobotics org on DockerHub.
Since container image source code packaging is small, for convenience all the source is together in one big repo. There is an alphabetical index for all the images below.
When a new image is added, the base directory is added to the list of directories in .github/workflows/ci.yml.
There's a rule that fires a build for each image only when a particular directory contents are changed.
Each source directory has a similar basic structure. The image directory is not required to be at any particular level in the directory hieararchy. Some of images have are grouped vendor or application type.
├── <image name>
│ ├── .dockerignore
│ ├── Containerfile
│ ├── docker-bake.hcl
│ ├── README.md
│ ├── test
│ │ ├── controls
│ │ │ ├── <inspec *.rb files>
The files are as follows:
.dockerignore- standard .dockerignore, list of files that should be ignored during a build to increase performance.Containerfile- a file using the Dockerfile DSL that includes commands for building an image. We process Containerfiles with BuildKit and encourge image authors to make use of BuildKit-specific features in image builds.docker-bake.hcl- A Docker Bake file that builds the image with docker buildx bake.test/- subdirectory containing a Chef InSpec profile with tests for the contaimer image.
Normally we just use the GitHub Actions pipelines that have been configured in .github/workflows to build
these images. However, the scripts to build the container images in the /bin subdirectory can be used to
build any image locally on your machine. For example, to build ros-core:
# Make the current working directory the location of the Containerfile for the image you want to build
cd ros/ros-core
# Check the Containerfile with hadolint
$(git rev-parse --show-toplevel)/bin/lint.sh
# Build the image for testing on the local processor architecture
docker buildx create --use
docker buildx bake local --local
# Run tests on the image with cinc-auditor
$(git rev-parse --show-toplevel)/bin/test-matrix.sh
# (Optional) build and push the image to the container repository on dockerhub - ideally this should be done via a GitHub Actions workflow and not locally
docker buildx bake default --push