oci - Open Container Initiative (OCI) images

Open container images for robotics, neuromorphic engineering, systems and embedded applications.

Alphabetical index of images

Image	Description	Location
aws-cli	Amazon Web Services Command-Line Interface	aws-cli
black	Black is the uncompromising Python code formatter	black
cinc cinc-auditor	Cinc is an automation platform built from Chef	cinc cinc/cinc-auditor
doctl	Digital Ocean command-line interface	doctl
flake8	Flake8: Your Tool For Style Guide Enforcement	flake8
fpm	fpm Packaging made simple	fpm
go2chef	A Golang tool to bootstrap a system from zero so that it's able to run Chef to be managed	go2chef
golang	Go (golang) is a general purpose, higher-level, imperative programming language	golang
hadolint	Containerfile/Dockerfiles linter	hadolint
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
node	Node.js is a JavaScript-based platform for server-side and networking applications.	node
pgweb	Simple web-based and cross platform PostgreSQL database explorer.	pgweb
postgres	The PostgreSQL object-relational database system provides reliability and data integrity.	postgres
prometheus alertmanager blackbox_exporter node_exporter	Prometheus monitoring system and time series database	prometheus/prometheus prometheus/alertmanager prometheus/blackbox_exporter prometheus/node_exporter
pulumi-base pulumi-python	Pulumi Infrastructure as Code CLI	pulumi-base pulumi-python
python	Python is an interpreted, interactive, object-oriented, open-source 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 (ROS) is an open source project for building robot applications.	humble-jammy iron-jammy noetic-focal rolling-jammy
ruby	Ruby is a dynamic, reflective, object-oriented, general-purpose, open-source programming language.	ruby
shellcheck	Linter for bash/sh shell scripts	shellcheck

Why are you re-publishing some official images?

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 a lot of robotics applications.

Also because a lot of AI applications use 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 our applications while not having too much that we don't need.

Navigating

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.

Developing

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. GitHub Actions pipelines in .github/workflows have been set up to publish these images to the boxcutter org on DockerHub.

Since container image source code packaging is small, for convenience all the source is together in one big repo. There 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 an InSpec profile with tests for the contaimer image.

Building these container images locally

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 - use wrapper that can handle tests on matrix builds
$(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