I finished it about a year ago, but due to reasons outside of my control (administrative decisions), i had to write it in my native language, Latvian, so it's probably a tad useless to a wider audience.

In case anyone desires to mess around with PDFs and machine translation:

  - research praxis: https://files.kronis.dev/s/AJRCs84D7WngLzD
  - development praxis: https://files.kronis.dev/s/Xz6mtbAamoA7Pe8
  - the full text: https://files.kronis.dev/s/ioiW96dpnD5YcLk

Here's a tl;dr summary of what i did during it: essentially i set out to improve the way applications are run within the infrastructure of the company that currently employs me. To achieve that, i researched both the ways to utilize systemd services for everything as well as improve configuration management with Ansible, later introduce containers into the mix and compare their orchestrators (Docker Swarm and K3s in this case), as well as how to manage them, in this case, with Portainer. Then, after finishing that stuff up for the company, i proceeded with some further research of my own, into whether it's feasible to develop bespoke server configuration management tools and to integrate them with container management technologies, as well as do further benchmarks on how well the orchestrators actually handle containers running under load, since this doesn't often get tested.

There are probably a few reasons for those choices:

  - at work, it was really disappointing to see environments where servers are started manually
  - similarly, in the current day and age it's not acceptable to keep domain knowledge about how to start services and where the configuration is to yourself
  - manual configuration management simply increases the risks of human error greatly, especially due to turnover
  - in contrast, containers are a surprisingly usable way to introduce "infrastructure as code"
  - that said, their orchestrators still need a lot of work and it's probably a good idea to compare them
  - i was also curious to see whether it would be hard to create my own automation tools like Ansible, but executing remote Bash scripts through SSH
  - lastly, i was a participant in the development on https://apturicovid.lv/ which was a Latvian COVID contact tracing solution; i was curious about the choice of using Ruby, so i wanted to create my own mock system to see how it'd perform under load in a real world scenario, with tools like K6s https://k6.io/

More importantly, i wanted to see how much load a GPS based approach (as opposed to Bluetooth) with PostGIS would generate and whether Ruby would still be okay, as described on my blog https://blog.kronis.dev/articles/covid-19-contact-tracing-wi...

And, without further ado, here's my findings:

  - if you're not using Ansible or another alternative for managing the configuration of your environments, you should definitely look into it
  - if you can't or don't want to run containers, at least consider having systemd services with environment config files on your servers
  - Docker Swarm and the lighter distributions of Kubernetes, like K3s are largely comparable, even though Kubernetes takes a little bit more resources
  - tools like Portainer can make managing either or both of them a breeze, since it's one of the few solutions that support both Docker, Docker Swarm and Kubernetes clusters
  - despite that, you'll still probably want to configure your applications (e.g. HTTP thread pool sizes, DB pool sizes) and introduce server monitoring or APM into the mix
  - as for Python, it's pretty good for developing all sorts of solutions, even for remote server management: with Paramiko (for SSH), jsonpickle (serialization), Typer (CLI apps) and other libraries
  - for my tool, i used JSON as an application data format, so one command could pipe its JSON output (e.g. returned tokens from cluster leader server for follower servers) as an input for another; there are few cases where this can work, but when it does, it is pretty nice
  - that said, any such tool that you write will probably just be a novelty and in 90% of the cases you should just look at established solutions out there
  - load testing is actually pretty feasible with tools like K6s, but only as long as you just want to test Web APIs - anything more complex like that might be better tested with something like a server farm running instances of Selenium

Here's a few Git repos of the projects:

  - A very simple COVID infection tracking system which generates heatmaps to attempt to preserve anonimity: https://git.kronis.dev/rtu1/kvps5_masters_degree_covid_1984
  - The K3s benchmarks for it: https://git.kronis.dev/rtu1/kvps5_masters_degree_covid_1984_load_test
  - The Python configuration management tool: https://git.kronis.dev/rtu1/kvps5_masters_degree_astolfo_cloud_servant

Oh, and here's a test environment for the mock system that shows the generated heatmaps, you'll need to press the "Start" button to preview the data, though you can change the visualization parameters at runtime: https://covid1984.kronis.dev/