6 Lessons from Bitnami’s Transition to Container-Based Ops – InApps Technology 2022

Containers may be getting smaller and smaller, but they are filled with lessons to learn.

Adnan Adulhussein, software developer at Bitnami, shared with the crowd at a recent Docker London Meetup the lessons he learned over three years of containerization. During this time Bitnami, which is known for packaged applications in the cloud for any platform, went from no Docker containers to an entire container app library of more than 70 container-based apps.

Bitnami has automated most of the build > deploy > maintain pipeline applications for containers, clouds, virtual machines or bare metal, he said. But by mid-2014, around the time when Adulhussein joined Bitnami, “We had this huge container Docker file where we crammed everything in it. It was like a VM. We also developed an internal tool for managing this huge container.”

He said that adapting to the container mindset was hard and container documentation at the time was very poor. This was when the ops team realized they were doing containers wrong, but they decided to stay the course and see if they could improve.

A year later, they released the first set of eight runtime and infrastructure Bitnami images to the public. Each was:

• open sourced on Github
• an automatic build on Docker Hub
• a strong focus on documentation
• dogfooded (the Bitnami team was using these images in its day-to-day operations)

A bit later they started experimenting with all-in-one images like WordPress, Drupal and other simple PHP apps.

They applied the agile iterative approach to containerization, evolving their strategy as needed, like seeing how it responded to s6-Overlay for multi-process supervision.

Here are some of the lessons the Bitnami team learned along the way:

#1: One Task per Container

Sometimes when containerizing your work, you end up compartmentalizing too much. You go too far in breaking down everything into tiny tasks which often makes for more containers than you can handle or make secure. On the other hand, it can be easy for developers to get into the habit of shoving a lot of stuff into each container. You can’t forget that this light, stand-alone, executable piece of software only needs — according to Docker — code, runtime, system tools, system libraries and settings. The freedom of containers for developers to release early and often can sometimes get stuck in old habits of releasing larger than necessary.

Adulhussein said you need to look for logical points to break code up, often focusing on tasks, something he says the Docker documentation has now changed to recommend. This forces developers to think about the code in a more holistic way that you then break up into tasks.

“Like how Unix does one job and does it really well — same thing for Docker containers,” he said, offering the example of “Where it does make sense to split containers, when you have a Web server and a database, you want to scale out separately.”

This is how Bitnami created multi-container apps, like splitting the database containers from the app containers.

#2: Overcome the Lack of Out-of-the-Box Options

Starting in mid-2016, Bitnami took what it was doing with its own containers and created development containers, containerizing popular frameworks like Rails and Eclipse. Adulhussein says they went this route because most of the apps that they work with aren’t scalable out of the box because:

• Most apps are not cloud-native nor container-native;
• Many apps they use, like WordPress, have file uploads stored in a filesystem that you can reconfigure the plugins, but not out-of-the-box;
• Many apps they use, like Magento, have a reliance on .HTAccess rules

Adulhussein said these development containers allow other teams to perform actions like “bring up a development environment in seconds, bootstraps a new app. If the local directory is empty, it mounts a local directory.”

#3: Pay Attention to Container Entrypoints

Through Bitnami, the container entrypoints are in the Dockerfile. This runs on the container startup and receives the container’s command (CMD) as arguments, typically used to start a

• FROM bitnami/node:latest ENTRYPOINT [“node”]
• docker run mynonde -e “console.log(‘hello!’)”

n interactive shell.

He says you could choose a runtime binary to be the image entry point:

Docker outlines more best practices surrounding entrypoints.

#4: Heed the Importance of Init Systems

For about two years now, the container community has realized that you can run lightweight containers without initialization or init systems. However, skipping this can lead to an incorrect handling of processes and signals, which can lead to leaking containers or those that can’t be easily stopped. Bitnami applies Yelp’s dumb-init for simple init systems for containers.

#5: Optimize Images to be Smaller

Adulhussein offers the following benefits of smaller Docker images:

• smaller footprint,
• faster transmission,
• lower attack surface.

“Things like Alpine and Busybox are really useful containers with really, really small images,” he pointed out, as they are each about 5MB.  He also offered Bitnami’s open source Minideb, released toward the end of 2016, as a larger 50MB alternative.

He said “having a familiar package manager with a large library is a good alternative if you can’t be compatible with Alpine.”

#6: Leverage Non-privileged Containers

Following the advice of the popular can I haz non-privileged containers? website, Adulhussein advocates following the OpenShift best practices for non-privileged containers. He says to run every container as the random GID — GID is 0, assuming UID is unknown:

$ docker run —user 1001 bitnami/minideb id
uid=1001 gid=0 (root)
groups=0 (root)

He continued that files can have read-write-execute permissions for the root group, and that the services bind to non-privileged ports. However, he warned you can get a weird “have no name” message if it’s executed wrong.

What’s Next for Bitnami’s Open Source Offering?

Bitnami is working to optimize Docker images by rolling out non-privileged and multi-stage builds to all apps. They are also adding to the Bitnami documentation and tutorials, and they are experimenting with Bazel container builds and how those can benefit a CI/CD platform (continuous integration and continuous delivery) by running container clusters. Finally, he said Bitnami is also working on some tools for Kubernetes, including Helm package manager and Kubeless native serverless framework.

Red Hat is a sponsor of InApps Technology.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.