(One of my summaries of a talk at the 2021 FOSS4G NL one-day conference).
(Note: the BGT (basisregistratie grootschalige topgrafie) is the Dutch database with all buildings, roads, waterways, etcin the whole country, including metadata).
You can download the BGT via an API. Previously, you could only download the entire dataset. Now there’s also a “delta” endpoint that allows only changes compared to your already-downloaded version.
To handle all this, they made a “BGT loader” as a docker image. It can download the initial version + deltas. Output can be into postgis/oracle/SQLserver. They use it themselves to run it every night to update their database.
He demoed it by downloading a fresh copy of all the data for the couple of kilometers around the conference location. Easy: just a single “docker” command. Nice.
The tool stores the download-metadata (like the optional filter and the ID of the most recent change), so that a quick “download update” command is enough to update the current database contents.
Landgoed provides foss geo services, consultancy training, etc. So one of the things they sometimes need is 20 new, nice, freshly installed work environments for students in a course… A prepared geoserver, for instance.
The new, hip thing to do is to use containers. That’s nicer than preparing 20 virtual machines. Containers are much lighter than virtual machines. He mentions two containerization technologies:
Docker. The #1 hip thing. Everybody uses it. It is aimed at having one single application per docker. It also has drawbacks: it doesn’t always behave as on a “normal” vm, you can for instance find docker-specific errors that you never see with the same app on a VM.
Because everything is based on separate apps, you must “orchestrate” those separate apps: geoserver, database, webserver. That’s the drawback and also the advantage: you can selectively scale the various components.
LXD aims at virtualizing a complete system. So it is more like a regular OS. So it is a bit of “a virtual machine without the drawbacks”.
It works more or less like you’re used to. That can be a benefit.
He then demoed LXD. He created a container, modified it and then copied it to a fresh one. It worked pretty well.
Just originally thought about a longer title: deploying geo webapps with gitops.
He showed a google image search for “osgeo installation problem” or so. Everybody started laughing. OSgeo software is very diverse. Written by many different people in different languages. You have to deal with networking and SSL certificates. Oh, and OS updates, “DLL-hell” or conflicting libraries.
Once it works, there’s often a big label on it: don’t touch. An ancient ubuntu 14.04 with python 2…
The solution: docker. And there’s a technology you should really keep in the back of your mind for the future: kubernetes. Kubernetes is a method for managing and deploying and running your dockers. But for most people, that’ll be something for later.
Anyway, docker helps a lot with packaging your applications. But then it needs to be deployed on your server(s). Something he suggests is ansible, a handy configuration-file-based way of performing tasks on servers.
He showed an example project he worked on: https://github.com/Geonovum/ogc-api-testbed
Github: the complete config (the one “source of truth”).
Docker (plus docker-compose).
Ansible (remote deployment) via github actions (automatic workflows based on your code).
From a local dev environment, you push changes to github. Github runs ansible via automatic actions. Ansible deploys docker containers on the server. GITops, hands-off operations via github (or gitlab).
As a demo, he changed the title of the example website and it automatically got deployed to the live production website, without him doing anything on the server. Nice.
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):