1. Step: production.

Production, we need 3 VMs. Deploy and done. First users are joining! 🎉

• production: 3 VMs
• total: 3 VMs

2. Step: testing

We got updates for the service! 📈 However we are no gigachads, so option to test in production is a no-go. Lets create a test environment with 3 VMs. It just works, nice.

• production: 3 VMs
• testing: 3 VMs
• total: 6 VMs

3. Step: scaling

New users are joining our service, we scale production: node scaling, load balancers, proxies 🚀

• production: 16 VMs
• testing: 9 VMs
• total: 25 VMs

4. Step other environments

Because our testing is far away to match our production, we introduce one production-similar last step test environment: staging. To support agile development, short-lived experimental environments start appearing… 🧪

• production: 16 VMs
• staging: 16 VMs
• testing: 9 VMs
• experimental: 5 x 3 VMs
• total: 56 VMs

5. Step: geo redundancy

Because we fear downtime and blackout (or something else relevant), we decide to introduce geo-redundant infrastructure to our system.

• production: 2 x 16 VMs
• staging: 2 x 16 VMs
• testing: 2 x 9 VMs
• single site testing: 9 VMs
• experimental: 5 x 3 VMs
• total: 106 VMs

(could have happened at any step): bad design choice

We made a bed design step with all best intention. Eg: We dug too deep into microservice-oriented architecture and doubling VMs everywhere.

• total 212 VMs

How we ended up there and was it inevitable?

We have 212 VMs plus multiple environments and this gets very expensive, not talking about the man-hour cost to manage all of it.

All the steps are reasonable by themselves, but when all combined it might easily get over our head. Quite often we can see at conferences/posts that these techniques are praised for their pros, but much less often the cons are mentioned as well. So we should ask ourselves every time if we really need it:

• Testing: If it’s a rarely used service, would scheduled maintenance windows be enough to resolve issues directly in production?
• Scaling: Would vertical scaling be sufficient? Is there room for optimization instead?
• Staging: MCould a larger testing environment — something between testing and staging — catch most scale-related issues?
• Geo: How quickly can we restore from an offsite backup? Would that be sufficient instead of full geo-redundancy? In many cases, geo-redundancy only makes sense for truly global or critically high-availability services.

None of these decisions are wrong on their own. Complexity grows when reasonable decisions accumulate without regular re-evaluation. Redundancy is not just about availability — it is about the operational cost we silently accept.

The Docker Machine executor was deprecated in GitLab 17.5 and is scheduled for removal in GitLab 20.0 (May 2027).

one of the two simple options for runner are now gone, one of which is docker runner and the other shell runner. But as shell runner runs into problem even when using only by one developer. Talking about security not being concern in one manned team but the environment is then kept the same for all jobs.

Fortunately there is a Kubernetes executor runner. This might seem complicated at first, but it is not if we choose the right Kubernetes implementation. Well installing regular Kubernetes will be big overkill for small or one manned team, but there are also smaller installs of it like minikube. However minikube is not meant to be production ready, thus stuff like K3s or microK8s come into play. They can to be installed into both one node mode or multi-node mode. As K3s is quite powerful and easy to install it is not as straightforward as microK8s. With microK8s you just install with snap and we have set up Kubernetes.

Well if we have snap availible just running is enough:

snap install microk8s --classic

Now we have very easy live, we have all setup up and working. Kubectl and Helm are just availible like so:

microk8s kubectl get pod --all-namespaces
microk8s helm list --all-namespaces

and if we even need we are not stopped if we need to automate it as we can access the same directly with binaries.

As a last step we just install the runner with a helm chart as it come prebundled already!

Is it all really that great?

Yes and not, it all depends on the needs. One big downside is the fact that it is more a plug and play installation very suitable for experiments and such stuff as updates might be cumbersome. However we do have very good experience with it even in extensively used environments and as it cannot be updated as easily is not as a big of downside in case of runners as they do not keep any persistent settings other then these stored in manifests (our .yamlconfigs).

This short article will go over the terraform file which will show most of the connections and principles. The rest of the implementation is omitted for simplicity.

1. HAProxy

First get all stuff like provider and images then start with HAProxy itself. Lets start with it as other container depends on it:

resource "docker_container" "external_load_balancer" {
  image = docker_image.haproxy.image_id
  name  = "external_load_balancer"
  restart = "always"
  ports {
    internal = 80
    external = 80
  }
  ports {
    internal = 443
    external = 443
  }
  ports {
  	internal = 22
  	external = 22
  }
  networks_advanced {
  	name = docker_network.gitlab_network.name
  }
  mounts {
  	source = "/MY_PROJECT_PATH/gld/data/certs/deploy-certs/"
  	target = "/deploy-certs/"
  	type = "bind"
    read_only = true
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/haproxy.cfg"
    target = "/usr/local/etc/haproxy/haproxy.cfg"
    type = "bind"
    read_only = true
  }
}

The ports noted are all the ports needed for GitLab, however Certbot is needing 80 port as well. This can be solved by HAProxy rule in its config to route requests on /.well-known/acme-challenge/ subpath to Certbot. We cannot forgot about mounting the certificates so we can use them in HAProxy as well as the config.

2. GitLab

GitLab itself is not hard to deploy on docker. Lets take a look on the deployment:

resource "docker_container" "gitlab" {
  image = docker_image.gitlab.image_id
  name  = "gitlab"
  restart = "always"
  depends_on = [
  	docker_container.external_load_balancer
  ]
  networks_advanced {
  	name = docker_network.gitlab_network.name
  }
  mounts {
  	source = "/MY_PROJECT_PATH/gld/data/gitlab/config"
  	target = "/etc/gitlab"
  	type = "bind"
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/gitlab/logs"
    target = "/var/log/gitlab"
    type = "bind"
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/gitlab/data"
    target = "/var/opt/gitlab"
    type = "bind"
  }
}

Note that gitlab depends on external load balancer and we have to bind all the three directories.

Busybox server

Before the last step we have to install the simplest webserver possible, bussybox httpd. That is because we are going to use the http challange of the acme protocol. This will be great because of zero downtime for the certificate renewal.

resource "docker_container" "busybox_httpd" {
  image = docker_image.busybox.image_id
  name  = "busybox_httpd"
  restart = "always"
  networks_advanced {
  	name = docker_network.gitlab_network.name
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/certs/www"
    target = "/var/www"
    type = "bind"
    read_only = true
  }
  command = [
  	"httpd", "-f", "-v", "-p", "80", "-h", "/var/www"
  ]
}

Note that we have to mount the webpages folder shared with Certbot.

Certbot

As the last step we are going to spin up the Certbot container that will move the files to the served folder and will take care of the certificate request and renewal.

resource "docker_container" "certbot"  {
  image = docker_image.certbot.image_id
  name = "certbot"
  restart = "always"
  depends_on = [
  	docker_container.external_load_balancer
  ]
  networks_advanced {
  	name = docker_network.gitlab_network.name
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/certs/www"
    target = "/var/www/"
    type = "bind"
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/certs/letsencrypt"
  	target = "/etc/letsencrypt/"
  	type = "bind"
  }
  mounts {
    source = "/MY_PROJECT_PATH/gld/data/certs/deploy-certs"
  	target = "/deploy-certs"
  	type = "bind"
  }
  mounts {
  	source = "/MY_PROJECT_PATH/gld/cert-deploy-script.sh"
  	target = "/etc/letsencrypt/renewal-hooks/deploy/cert-deploy-script.sh"
  	type = "bind"
    read_only = true
  }
  command = [
    "certonly", "--webroot", "--webroot-path", "/var/www", 
    "--non-interactive", "--agree-tos", "-m", "gitlab-team@example.com", 
    "-d", "my-gitlab.example.com",
  ]
}

Here we can see, that we don’t only make the interconnection with HAProxy to pass it the certificates, but we have to use the webserver path to serve the files for the acme challenge to renew certificates.

Why and why not

This is probably not the most common solution to do the same functionality. We can imagine tech-stack such as Traefik, docker-compose and GitLab all in docker to fill in the same functionality. However the stack might not be available, or this one might suit better the overall tech or skills. One big advantage is the ease of change to VMs, just one has to implement shared storage. Also proxy like HAProxy is more performant then Traefik.

Post content First the idea is introduced, then the features and future features are explained and in the end the used architecture and technologies brief description is elaborated.

Why is there need for such apllication

Texture features are specific data extracted for a wide variety of tasks, such as in computer vision. There are many algorithms for extracting these features, but each one has different characteristics. Although comparative studies have been written, they are often limited by the number of features and the specific testing environment. So there is no tool or resource in which to universally compare textural features. Maybe until now. The developed benchmark does just that. The benchmark can test and evaluate features universally for multispectral data (for any number of spectra).

Application

I would like to briefly introduce the application. Where you can: Managing own experiments

Exploring experiments of others

Setup and run an experiment and the view the results in detail

Visualize the features

Future application features The benchmark is still in development and I work on it in my free time, there are going to be added following essential application features soon:

• Algorithm comparison
• User input of features

and other application features:

• more features
• more evaluation criteria
• choice of criteria

Architecture and technologies

It is a web application with cloud computing and symptom evaluation. The entire benchmark is divided into a client application and a server part.

The client application is programmed using the Flutter framework, and since it is a multi-platform technology, it can be deployed not only as a web application but also as a native application for Windows or Linux.

The server part of the application is then created using three servers: a communication server, a solution server and a database server. The communication server serves the web application and provides security and sends requests that it cannot handle to the resolving server (typically requests for the extraction and evaluation of texture features). The solving server then contains a queue for the extraction and evaluation of features, which is served by workers, the amount of which can be scaled and the overall performance of the benchmark can be scaled. Both previously mentioned servers then communicate with the database server (MongoDB), in which they store and retrieve data. In the server part, Python and the Flask framework are used for the most part, but also, for example, binary files compiled from C++ subprograms containing feature extraction algorithms. These are then supplemented with Python subprograms with the same purpose.

Main idea is about creating application in Python, that would detect and display the pulse frequency. The output values are between 55 and 170 for one person.

Descritption

The application looks like this:

In the previous image can be seen the main part of the application, which is displayed in two windwos. The camera settings is easy and with the face locking mechanism is visible on the next images:

It is good to note, that on first sight unpractical face locking, is actualy important for the accuracy of meassurements.

Accuracy

The accuracy was tested with the fitness armband Fitbit Charge 4, which meassures heartrate on the wrist (quite accurate armband at the time). It was shown that the accuracy of the meassurements is only approximate (same as in other seen and tested solutions) and mainly depends on the camera quality and video compression. It was tested on four cameras total on which three gave normal accuracy (among the set) and using one of them the application gave much more accurate results.

There is one image frm testing which shows happy case, when the detections matches (the real one still might be bit different):

On this image the innacuracy is visible. The overall is wrong, but at the moment, the current pulse was meassured correctly (most dominant frequency):

Installation and run

The Python 3 is needed with the installed package opencv-python (tested with version 4). To run the program it is needed to type python3 ./pulse_detector.py in the correct folder in terminal.

Other already created solutions at the time

There are already existing solutions for that, one of them is webcam-pulse-detector. That one is in Python, but there is also one in Javascript. Most detectors (our as well) uses forehead as detecting zone, but this one uses cheeks.

Results

The resulting localization accuracy is higher by using this solution than by using GPS and other mobile sensors. The accuracy was tested on multiple tests and the accuracy gain by using the implemented solution was on average 11.94 meters more accurate than GPS It can be visualized by following example.

On the left is aerial map and on the right is the detected location of localized house.

• yellow line: house facade
• green pin: calculated location
• cyan pin: GPS sensor location

I have done or been included on many object digitizations but namely I have worked on the The Old Town Madonna and New Town Shoemaker’s Guild Chest and I think that these are the nicest of these I worked on. The goal of the work was to automatize the digitization process as much as possible, that was done using Python scripting.

Game description

Starting phase: first the players need to put down their basic units (the Drake and two Clubmen). Game phase: after placing the basic units players can start to play. They play in turns and in each of them the player can place a unit or move one of their units on the board. The goal of the game is to capture the enemies units (similarly as in chess). The game ends when one player captures Drake of the opposite player.

The complication is that each unit has different pattern of moving. The possible directions of movement are switching with the unit moves as well.