---
title: Charmhub | Deploy Gunicorn using Charmhub - The Open Operator Collection
description: Deploy the latest version of Gunicorn as a Kubernetes Operator on any
  cloud.
url: https://charmhub.io/gunicorn-k8s/docs/Architecture
---

# Gunicorn

[Franco Luciano Forneron Buschiazzo](https://charmhub.io/publisher/gtrkiller "View all packages from Franco Luciano Forneron Buschiazzo")

* [Franco Luciano Forneron Buschiazzo](https://charmhub.io/publisher/gtrkiller "View all packages from Franco Luciano Forneron Buschiazzo")

Platform:

stable 45

```
juju deploy gunicorn-k8s
```

[Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications)

---

#### Relevant links

* [Homepage](https://github.com/canonical/gunicorn-k8s-operator/)

---

Share your thoughts on this charm with the community on discourse.

[Join the discussion](https://discourse.charmhub.io/)

At it’s core, Gunicorn is a basic charm that deploys a docker image and allows us to inject environment variables into the container using configuration options.

In designing the charm, we’ve leveraged the sidecar pattern to allow us to run multiple containers in each pod as follows:

1. The Gunicorn-k8s container itself, which contains the implementation of the docker image we have passed as a resource (gunicorn by default).
2. A statsd-prometheus-exporter container which can be used to provide statistics on web traffic.

As a result, if you run a `kubectl get pods` on a namespace named for the Juju model you’ve deployed the gunicorn-k8s charm into, you’ll see something like the following:

```
NAME                             READY   STATUS    RESTARTS   AGE
gunicorn-k8s-0                   3/3     Running   0          3h47m
```

This shows there are 3 containers - the two named above, as well as a container for the charm code itself.

Let’s look at each container in turn in a bit more detail.

## Gunicorn-k8s container

This container will have the docker container for the image we have loaded as a resource. If we hit the juju unit’s IP and exposed port we’ll see a simple web page containing all the current env variables the image has and their respective values.

## Statsd-prometheus-exporter container

This container runs the `prom/statsd-exporter` image.

This image is exposed on ports `9102` and `9125` and metrics about web traffic to the pod can be scraped on the former.

This operator can be used to deploy Gunicorn workloads on Kubernetes. It supports relations with PostgreSQL or InfluxDB, but doesn’t require them.

## Environment variables and relations

This charm has been designed to easily allow you to pass information coming from relation data to your pods. This is done by using the `environment` config option. This config option is a Jinja2 template for a YAML dict that will be added to the environment of your pods.

The context used to render the Jinja2 template is constructed from relation data. For example, if you’re relating with influxdb, you could do the following :

```
juju deploy gunicorn-k8s my-awesome-app
juju config my-awesome-app environment="INFLUXDB_HOST: {{influxdb.hostname}}"
```

The charm will notice that you’re trying to use data from the `influxdb` relation, and will block until such a relation is added. Once the relation is added, the charm will get the `hostname` from the relation, and will make it available to your pod as the `INFLUXDB_HOST` environment variable.

If you want the charm to handle more “basic” relations such as the `influxdb` one described above, all you have to do is add the relation to metadata.yaml and rebuild the charm with `make`.

Some relations, such as the `postgresql` relation, are a bit more complex, in that they’re managed by a library. Instead of using raw relation data, you use the library to get useful and usable information out of the relation. If you want to use such a relation, you will need to add a bit more code to make the information provided by the library available to the Jinja2 context. An example is provided in the charm with the `postgresql` relation implementation.

---