I got the question how to configure multiple domains in Traefik when one of the domains is a network internal domain without the possibility for a Let’s Encrypt certificate. Actually, it’s pretty easy: Just add your services. Let’s look at an example.

Multiple Domains

Traefik will discover your services using the method you specified in the configuration file. There are several discovery variants available. Here, we will use auto discovery on docker containers.
When Traefik encounters a Docker container it will read the labels of the container to deduct the domain the service shall run on and wether or not you want to use TLS. When you enable the Let’s Encrypt certificate resolver beforehand and set the right labels, the new domain with TLS will just work.

Today, I had to figure out how to format a Grafana datasource with a custom CA literally for the 99th time. How can this be so hard? Also, it doesn’t help that there is conflicting information on how to format certs in yaml even in the Grafana community threads. That’s always the first page I find about the topic. The second is the stackoverflow post on how to break strings in yaml which sends you down a totally wrong path.
The error messages you get from the Grafana server logs are also not very helpful, given you can access them:

Failed to call resource" error="Get \"https:///tnglab.fritz.box/prometheus...": x509: certificate signed by unknown authority

Well, thanks for nothing!

So, once and for all! This is the way:

In the good old days you had one server running your services. When something failed, you logged in via SSH and checked the corresponding log file. Today, most of the time no one server is running all your services. So the log files are distributed over multiple machines and ways of accessing them. From journald, docker logs, over syslog to simple files there are just too many options to check the logs efficiently, especially if you use scale sets on Azure or something equivalent to dynamically adjust the number of VMs to the workload.
Sometimes one solves this problem by introducing an Elasticsearch, Logstash and Kibana (ELK) stack that gathers the logs and makes them searchable. That’s a nice solution, albeit a resource intensive one.

We want to look at a more lightweight alternative: The log aggregator Grafana Loki. Like Elasticsearch it stores logs that are gathered by log shippers like Promtail. You can then display the logs using Grafana.
But unlike Elasticsearch Loki is more lightweight. That’s mostly because it omits the main feature of Elasticsearch: search. Instead, and much more like Prometheus, Loki stores log lines annotated with tags that you can later filter on. So there is no real-time search on log text.
The upside is low hardware requirements. I myself run Loki comfortably on a Raspi 3B where it collects logs from several systems using below 1% CPU at all times. An ELK stack would have serious problems even running on the Raspi 3B, mostly due to the 1GB of system memory.

When running more and more machines it becomes impractical to check on each of them by logging in and going through the numbers yourself. This is especially true for a variable number of machines like in cloud scale sets.
So what can we do? Prometheus is a popular solution to collect and store metrics from your machines. You can then browse them either via its included web interface or third party apps like Grafana.

In this post we will look at a practical example of metric collection with Prometheus on Microsoft Azure scale sets. I assume that you already have an Azure deployment set up. If not, check out my post on Microsoft Azure VM deployment.

We will run Prometheus in a docker container on a jumphost VM utilizing the also present Traefik. I got a post about how to set up Traefik with Ansible on your jumphost if you need it. Prometheus will then fetch the metrics from a small exporter app on each of the Azure scale set VMs. Finally, we display the data with Grafana that also runs in a container on the jumphost.

My last comparison between the Logitech c922 and the Raspberry Pi High Quality Camera left me wanting: The Logitech c922 has a very bad image quality but the Raspberry Pi High Quality Camera is very cumbersome to use as a webcam.
So, off to our favourite online bookstore. Shortly after, 4 new shiny contemporary webcams arrived for testing:

• Logitech StreamCam
• Logitech Brio
• Razer Kiyo Pro
• Elgato Facecam

I will again include the Raspberry Pi High Quality Camera as a point of reference and because it’s fun to see what you could do in the DIY department.

The latest version of the Raspberry Pi operating system brings significant changes. Apart from the ususal software updates to the Debian 11 Bullseye base, Raspbian now got rebranded to Raspberry Pi OS. It now comes with a completely new software stack to access its various camera options called libcamera. Unfortunately that means that the old commands raspivid and raspistill will no longer work. So it’s time to update our previous post about how to stream with a Raspberry Pi.

Privacy coins rallied in the last days in light of the current geopolitical events. So is it the perfect time to finally start mining? And how do we do it? We already saw that mining Monero on Raspberry Pis makes no sense. And we surely don’t want to buy a whole server farm, do we?

So how about mining in the cloud? After all, Monero prices are rising, so it should be profitable, right?

Spoiler: No, it isn’t. But if you want to know how to set up Monero mining on Azure with Packer and Ansible and see the gathered data, keep on reading.

You might already know the “cloud native” proxy Traefik from Kubernetes. Or not, as Kubernetes hides most of the configuration from you. But Traefik can be really useful on its own and has a lot of functionality. I find two of its features especially useful for smaller servers ot home servers: the configuration/service discovery and Traefiks ability to resolve and renew Let’s Encrypt certificates.

Traefik Configuration Discovery

Traefik configuration discovery decouples the service configuration from the proxy configuration. Instead of editing a proxy config file every time you want to add a new webpage, you place the configuration at a known source and let Traefik pick it up. This allows for modular deployments where the services that Traefik serves do not have to be known beforehand with minimal downtime of the proxy.

Traefik can watch multiple sources for new configurations of services that it shall act as a proxy for. The service configurations can be read from a file, etcd, Redis and others. One particularly useful variant is the Docker configuration discovery where Traefik reads the configuration from the labels of a running container.

Automatic Lets’t Encrypt certificates with Traefik

Traefik is able to obtain Let’s Encrypt certificates for the domains of your services. When discovering a new configuration, for instance when a docker container starts up, Traefik will check wether SSL is required and how the certificate shall be resolved. If the ACME resolver is selected, Traefik will obtain a SSL certificate for the domain the service will run on and also keep it up to date.
The domain in question has to point to the server that runs Traefik, of course.

The following example shows how to set up Traefik in a Docker container and discover services on the same Docker network, serving them with SSL certificates. I will reuse the jumphost VM created in my guide for Azure VM Deployment With Ansible.

Lately, I wanted to try some web service that would scale to multiple machines so putting them in the cloud seemed to be a good idea.

But before scaling a set of machines, I need a single VM that can do some monitoring and also serve as a jumphost to reach the scale set. I turned the resulting Ansible script into this howto for deploying VMs on Azure with Ansible.

For tasks like that, everyone else is using AWS and Terraform, so I thought: too mainstream. Instead, I went with Azure and Ansible.

v1.1.0 of Squeezefix is out! Finally with support for newer Fujifilm Cameras. I tested everything with an X-T4 and X-T10, but the script might also work with other Fujifilm cameras. I just don’t have these lying around.