Last week, our friends at Microsoft launched Cloud Native Application Bundle (CNAB) and duffle, a CLI tool to manage CNAB bundles. CNAB is an open source, cloud-agnostic specification for packaging and running distributed applications. Because of our experience in application packaging, they asked Bitnami to partner with them to explore the benefits and limitations of the initial version.
Our goal was not to create another "Hello world" example, but to apply our experience helping users run our applications in the real world to make sure that we were creating a truly production ready bundle.
For us, production ready means that the application:
- Uses a managed database (AWS RDS, Azure Managed DB, etc…) to store application state.
- It is exposed via a custom domain secured with TLS.
- Requires some operational support in the form of logging and monitoring.
Some of our users are also running cross-cloud scenarios in production, so we wanted to stress that part of the implementation as well.
Therefore, we created a bundle with the following features:
- Provisions an AWS RDS database.
- Deploys WordPress in Kubernetes (using Azure Kubernetes Service in this example) connected to that database.
- Application domain and TLS are configurable and work out of the box (this requires the Bitnami Kubernetes Production Runtime (BKPR) to be pre-installed, which is described later on in this post).
- Leverages built in logging and monitoring support.
All this, by just running one command! Next, I will walk you through the features listed above.
1. Deploy Amazon RDS and WordPress in Kubernetes
The first part of our challenge was to provision an RDS database along with the deployment of WordPress in Kubernetes, and then connect them together. To achieve it, we relied on the first tool in our workbench, CNAB.
Cloud Native Application Bundles (CNAB) is a package format specification that describes a technology for bundling, installing, and managing distributed applications, that are by design, cloud agnostic. CNAB website
Roughly speaking, a CNAB bundle runtime consists on a set of well defined file paths and an arbitrary number of executable programs that are stored inside an invocation image. The CNAB bundle spec does not define how to implement your bundle, but just the contract with the outside world, parameters, credentials and so on.
Having that flexibility allowed us to choose the best tools for the job, in this case an AWS Cloud Formation Template to deploy the RDS database and Helm to deploy and configure WordPress on Kubernetes. Then we wrote some glue code to put everything together.
2. Ingress and TLS
Writing the CNAB bundle was fun, but that was just part of the challenge. What about custom domains with TLS?
Enter BKPR, the Bitnami Kubernetes Production Runtime: an open source collection of services (such as certificate management and monitoring) that make it easy to run production workloads in Kubernetes. The services are ready-to-run and pre-integrated with each other, so they work out of the box.
My colleague, Angus Lees, wrote an excellent blog post that introduces the different bundled stacks in BKPR, one of them is the HTTPS Ingress stack which includes NGINX, ExternalDNS, cert-manager and oauth2_proxy.
Not coincidentally, that is exactly what we needed. ExternalDNS will setup the custom domain DNS entry, cert-manager will provision our TLS certificate and Nginx Ingress will take care of the routing.
To take advantage of BKPRs Ingress stack, we just need to configure our CNAB bundle to set the correct parameters that enable Ingress with TLS and adds the cert-manager annotation to the Bitnami's WordPress Helm Chart underneath.
3. Logging and Monitoring
The last stop in our journey is to make sure that once deployed, our application is properly monitored and its logs are retained.
BKPR provisions two more stacks that fit our needs:
- Monitoring: includes Prometheus, Alertmanager, and Node Exporter.
- Logging: includes Elasticsearch, Fluentd, and Kibana.
By deploying our Kubernetes application on top of BKPR, we get all of this out of the box. The best part is that those components are already configured (although can be customized) to watch for any new workload in the cluster. Nothing to do from our end :)
The result: WordPress + RDS custom CNAB bundle
If you want to kick the tires on our bundle, you can get it here. Deploy WordPress in Kubernetes exposed via a custom domain with TLS and connected to a newly provisioned RDS database is as simple as:
$ duffle install my-release -c wordpress-creds \ --set app-domain=wordpress.kubeprod-domain.com \ --set app-tls=true -f ./bundle.cnab
After that, you can use the other commands in the CNAB contract to upgrade, uninstall, or check the status of the application.
See it in action in this video:
Closing thoughts on BKPR and CNAB
In using CNAB, I liked that I could use tools that I was familiar with in order to fulfill the CNAB contract.
More importantly, this exercise also demonstrated that I could use a packaging tool to allow end users to get the benefits of BKPR with very little effort or knowledge on their part.
Based on Bitnami experience with cloud applications and cloud marketplaces, CNAB technology shows a lot of promise.
It is particularly promising as it applies to cross-cloud marketplace use cases, where different ISVs could target their applications to different clouds and even different platforms on those clouds. Using tools and techniques that they already know will work well for them and their specific applications.