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.
ConfigMap
A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.
In a nutshell, you want to use ConfigMap for setting configuration data separately from application code.
First we’ll create a minimal external nginx.conf that we will use to feed our ConfigMap in later on (we store in our code repository under a configs/ directory).
user nginx;
error_log /var/log/nginx/error.log;events {
worker_connections 4096; ## Default: 1024
}http {
server {
listen 8080;
server_name localhost; location / {
proxy_pass http://localhost:5000/;
} error_page 500 502…
