King Traefik 2.0, Queen Django, and Jack passHostHeader

Fri, 30 Aug 2019 00:00:00 +0000

Deploying Django application means deploying it behind Nginx webserver most of the time. We are also using this setup. Deploying it this way is easy, since you need to set proxy_pass and proxy_set_header.

The only problem with this setup is when you only have 1 Nginx webserver for multiple Django backend. When you deploy new Django apps, you need to add new setting for it and restart the server. You might be able to reload it by sending SIGHUP to Nginx master process, but we are using container, so it’s hassle. You also need to reload it every time you edited something.

That’s when we look into alternative reverse proxy. We look for more cloud-native proxy, and that’s when we found about Traefik. Traefik is a cloud native edge router. It has integrations into multiple cluster technology. It also supports live reload of configuration files for dynamic settings. We are using podman to manage containers, so we are utilizing the dynamic file reload.

We start playing with Traefik, and use version 2. Tinkering with Traefik is not that easy if you’re not familiar with the earlier version.

The setting that really ticked our testing is passing the proxy host header to backend. The first settings that we look through are middleware headers settings of Traefik. This is the most logical place to look first, if you are playing with headers, right? We played with these settings.

Seems okay, but it didn’t actually work. The host header is still not pass to the backend. I hold some grudge to Traefik this time, then I realized that I need to check the settings for earlier version. There are Traefik settings scattered through Github, so I found this boolean setting.

passHostHeader = true

I guess this setting should be present to Traefik 2.0. After checking the dynamic configuration reference, I found this setting.

services:
 Service01:
 loadBalancer:
 passHostHeader: true

I set this to true and the backend is now responding.

I guess everyone should know about this setting.

Podman, Containerization, and a Poor Guy

Tue, 20 Aug 2019 00:00:00 +0000

Deploying Kubernetes, Docker, and cloud-native apps needs large type of servers, but what if you are a poor guy like me and just want to use containerization technology on small scale servers? One thing that can help you is Podman.

. Ahh, what a great daemonless container engine. Daemonless? Yes. It means that it has minimal footprint on the server, giving much power to those containers.

We currently use Podman to manage our apps on a 4GB/2vCPU Fedora 30 Linode. As of now, we are comfortably running these apps:

Reverse-proxy Nginx
Multiple Django sites
Tor relay node
Ipfs node
Syncthing node
Development containers

You might wonder, but running those multiple containers still consume a lot of resources. This is right, but one other great thing about container is resource limiting. I just simply limit the resources on all production containers to 2GB/1vCPU. I did this by running my containers as a service, then set-up an environment file with this configuration.

[root@prod ~]# grep -i EnvironmentFile /etc/systemd/system/cnginx.service
EnvironmentFile=-/etc/sysconfig/podman
[root@prod ~]# cat /etc/sysconfig/podman
PODMAN_OPTIONS=\"--rm -a stdout -a stderr -m 2g --cpus 1\"

This is to ensure that no one would hog everything, rendering others non-responsive. I also set them as a service to automate container restart if something happens.

[root@prod ~]# grep -i restart /etc/systemd/system/cnginx.service
Restart=always
RestartSec=15s",

There are instances that podman would kill container due to OOM, but restore the service by automated restart. If there’s multiple case of OOM, you will need to adjust the resources accordingly.

After using podman for several months now, I just love it. I wish that they would be able to push their binaries to Debian repository.

Podman | blog.moe.ph

King Traefik 2.0, Queen Django, and Jack passHostHeader

Podman, Containerization, and a Poor Guy