# My top 5 must-have base images (CentOS, Nginx, Busybox) When you start using containers in earnest, you quickly come to the realisation that there are a lot of container images out there. One of open source's greatest strengths is choice, and with so many images you have plenty of choice when you need an image to base your work upon. Personally, I find myself going back to the same few images pretty frequently. There are five in particular that consistently make me a happy fledgling cloud architect. ## Nginx I've been running Nginx on servers for over a decade now, usually for its easy config file format and for its ability to do pretty good load balancing. Migrating to Kubernetes to run services has made me love Nginx even more, though, as I see how versatile it is as a reverse proxy, ingress controller, and of course a lightweight web server. The Bitnami [Nginx image](https://quay.io/repository/bitnami/nginx) on Quay.io is what I usually default to when I need a quick and reliable Nginx instance. It's easy to use with Podman, and easy to install with Helm. It's [well documented](https://github.com/bitnami/charts/tree/master/bitnami/nginx), so I always know where to look for important configuration options. ## CentOS Back when I was building AppImages for my users, I developed the habit of basing my work on the *previous* CentOS release from whatever was current. It turned out that basing work you wanted to be "universal" on a stable distribution like CentOS was a really safe practice. Everything I built ran on RHEL, CentOS, Fedora, and Debian workstations, as well as my personal Slackware workstation. From that experience, I've inherited the habit of basing most work I do on a nice, clean CentOS install. For work in the cloud, I use the [official CentOS image](https://quay.io/repository/centos/centos). ## Java on RHEL I develop with Java as often as possible, and as I move my apps into the cloud I've found that the reliability of RHEL is exactly what I need for the software I'm deploying. In fact, of all the images I use, it's the [Java Applications](https://catalog.redhat.com/software/containers/redhat-openjdk-18/openjdk18-openshift/58ada5701fbe981673cd6b10) one that made me truly grasp the advantage of containers. I have plenty of variables (of the code variety and otherwise) when I'm setting up applications in the cloud as it is, so knowing that the runtime is solid is a huge advantage for me. I could configure an OS and a Java infrastructure to safely and reliably run my code, but with this image, a bunch of RHEL and Java experts have already done that for me. That's an advantage I'll gladly accept. ## Busybox If ever I'm stranded on a desert island and can choose only one application to take with me, it'll be [BusyBox](https://opensource.com/article/21/8/what-busybox). With over 400 built-in commands, BusyBox is a tiny powerhouse of [POSIX](https://opensource.com/article/19/7/what-posix-richard-stallman-explains) potential. On the cloud, it's just as useful as it is on the desktop (or mobile, or TV, router, drone, and so on). The [BusyBox image](https://quay.io/repository/openshifttest/busybox?tab=tags) from the OpenShift project is tiny, so it's quick to pull. It's a minimal image, so it's easy to use, but it's been built with support for multiple architectures including x64, Arm64, PPC, s390, and more, so it's suitable for whatever cloud you're on. ## The one I build myself I didn't get into Linux because I wanted to force my workflow into somebody else's solution. The first software I ever built on Linux was the kernel (I'd built other software on Unix previously), and my goal then was to get bzImage as small as I possibly could. I got it down to a 1.5 MB, and was awfully proud of it, even though it didn't actually boot (turns out I'd forgotten to include the filesystem driver). Continuing in that fine tradition, sometimes the best image is the one you build yourself. Chris Collins demonstrates exactly how to do this in his article [How to build tiny container images](https://www.redhat.com/sysadmin/tiny-containers). More importantly, he explains the logic behind the most significant choices ("If we specialize enough and abandon the idea of troubleshooting inside of production containers, do we need Bash?") Take a lesson from the best, and give it a go! ## Your favourites Obviously these three images aren't the only containers I use. There's that [PostgreSQL](https://catalog.redhat.com/software/containers/rhel8/postgresql-13/5ffdbdef73a65398111b8362) one I get a lot of use out of, and an [Etcd](https://catalog.redhat.com/software/containers/rhel7/etcd/57ea8cf49c624c035f96f3d5) that comes up a lot, and many many more. I find it helpful, though, to get familiar with a few reliable go-to container images, so explore your favourite image repositories and see what's out there.