Exposing our non-SSL application with NGINX and a ‘sidecar’ container

If you’ve been accompanying us in our journey, this is the third post, following up on the previous two posts where we had laid the foundations of our Slack Bot application and the use of IBM Secrets Manager as external vault for our secrets… and now our SSL certificate too.

As you probably know, Werkzeug is a comprehensive WSGI (Web Server Gateway Interface) web application library, and not a web server for production use. We’ve been using this in development for our Slack Bot application, but now things are getting serious. That’s why we will explore the Kubernetes sidecar pattern to expose our non-SSL application with NGINX. In our next blog, we will dig deeper in the use of a real web server, such a Gunicorn. For now, let’s focus on the SSL piece of it.

The Kubernetes Sidecar Pattern

The sidecar pattern consists of a main application — i.e. your web application — plus a helper container with a responsibility that is essential to your application, but is not necessarily part of the application itself.

Given the above definition, it’s exactly what we need to expose our non-SSL application to the Slack API.

First, let’s create a ConfigMap for our NGINX configuration file. Let’s dive into it.