Turnkey Containers from Bitnami: A Real World Use Case

As you may have seen recently, VMware recently announced the intent to acquire Bitnami.

Bitnami is a leader in application packaging solutions providing the largest catalog of click-to-deploy applications and development stacks for major cloud and Kubernetes environments.

There are several great use cases for Bitnami package for all the things I have been working on recently. One of the most helpful recently was the turnkey container selection.

These containers are pre-built, fully managed containers, for a multitude of apps and services. For example, these are just a few of the pre-canned containers you can utilize:

Wordpress
Fluentd
Jenkins
Node.js
Nginx
Kubectl
Python
Git

This is just a small sampling of the full list, which can be found here. All of these containers can be used for whatever you need. All of the dockerfiles are fully public on GitHub. Here are some of the reasons you may want to use a Bitnami container image, instead of creating your own or using other pre-built containers:

Bitnami closely tracks upstream source changes and promptly publishes new versions of this image using our automated systems.
With Bitnami images the latest bug fixes and features are available as soon as possible.
Bitnami containers, virtual machines and cloud images use the same components and configuration approach - making it easy to switch between formats based on your project needs.
All our images are based on minideb a minimalist Debian based container image which gives you a small base container image and the familiarity of a leading linux distribution.
Bitnami container images are released daily with the latest distribution packages available.

Real World Use-Case

I recently built a custom docker container while working on my latest blog about budget management in the CI/CD process.

The way that GitLab CI works, you can specify a docker container for the Gitlab runner to work with to complete the tasks for said stage.

Pipeline Stages:

Pipeline Stages

For example, here is the YAML configuration for the pipeline I built:

test:
  stage: test
  image: vtimd/alpine-python-kubectl
  script:
    - chmod +x gitlab-budget-test_py.py
    - ./gitlab-budget-test_py.py
  after_script:
    - if [ -f "overbudget.txt" ]; then exit 1 && echo "overbudget"; else echo "Within Budget. Continuing!"; fi

deploy:
  stage: deploy
  image: vtimd/alpine-python-kubectl
  script:
    - kubectl apply -f redis-master-deployment.yaml
    - kubectl apply -f redis-master-service.yaml
    - kubectl apply -f redis-slave-deployment.yaml
    - kubectl apply -f redis-slave-service.yaml
    - kubectl apply -f frontend-deployment.yaml
    - kubectl apply -f frontend-service.yaml

You can see that each stage has an “image” specified in it. I have the same container specified for both, but don’t have to. The container I built is pretty big, but it’s because of what I needed it to do. It is based on Alpine, which is a super lightweight container OS, and installs Python and Kubectl to run the scripts and commands to execute the budget check, then deploy the app. This means that it has a lot going on.

FROM alpine:latest

RUN apk update
RUN apk add curl

RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
RUN chmod u+x kubectl && mv kubectl /bin/kubectl

# Install Pyton Stuff
RUN apk update && \
    apk add python3 && \
    apk add python3-dev && \
    apk add py-pip && \
    python3 -m ensurepip && \
    rm -r /usr/lib/python*/ensurepip && \
    pip3 install --upgrade pip setuptools && \
    if [ ! -e /usr/bin/pip ]; then ln -s pip3 /usr/bin/pip ; fi && \
    if [[ ! -e /usr/bin/python ]]; then ln -sf /usr/bin/python3 /usr/bin/python; fi && \
    apk add py-requests && \
    rm -rf /var/cache/* \
    rm -rf /root/.cache/*

ENTRYPOINT []
CMD []

So how could Bitnami have helped with this? I could have simply replaced the usage of my container in the test and deploy stages with Bitnami’s Python and Kubectl containers respectively. This is what the YAML for that would look like:

test:
  stage: test
  image: bitnami/python
  script:
    - chmod +x gitlab-budget-test_py.py
    - ./gitlab-budget-test_py.py
  after_script:
    - if [ -f "overbudget.txt" ]; then exit 1 && echo "overbudget"; else echo "Within Budget. Continuing!"; fi

deploy:
  stage: deploy
  image: bitnami/kubectl
  script:
    - kubectl apply -f redis-master-deployment.yaml
    - kubectl apply -f redis-master-service.yaml
    - kubectl apply -f redis-slave-deployment.yaml
    - kubectl apply -f redis-slave-service.yaml
    - kubectl apply -f frontend-deployment.yaml
    - kubectl apply -f frontend-service.yaml

You’ll notice that it is calling the respective bitnami container for each stage. If I were to be using artifacts in some way, GitLab automatically provides access to the different containers.

GitLab Runner using Bitnami/Kubectl container:

Runner / Bitnami

As you can see, they make it pretty easy to utilize a piece of software from within a CI/CD pipeline, but you can use their containers for production workloads as well. Or, if you want, you can even go find their Dockerfile, and use it as a starting point for a custom container of your own.

Conclusion

As you can see, Bitnami is doing some very cool stuff. They are taking the time to provide fully managed, turnkey containers, for everyday use. For free. This will make your process of building, testing, and deploying code and apps far easier, as you won’t have to build your own container images. And we didn’t even talk about their Enterprise Catalog. Be on the lookout for more information on what is next for Bitnami at VMware.

-Tim Davis, Cloud Advocate, VMware Cloud Services