Developing Stock-Market Bar Software 2020, Part 1: Dockerize, Modernize and Optimize

---

If you haven't yet read my blog about the Stock-Market Bar Software from February this year, I suggest you read it here before continuing with this post

A can of worms

As February approaches it is once again time to look into the Stock-Market Bar Software. When I reopened my GitHub repository and started looking thorugh my code from last year, I felt a mix of different emotions. On the one hand I was terrified at the "can of worms" I had obviously created. I hadn't really done much to document the code and not every element was terribly well-written. I was moreover also really happy. Happy because a lot of improvements suddenly became terribly obvious to me. This must have meant one thing - I've gotten better at writing code in the last year, and this benchmark alone should always be interpreted as a huge accomplishment for anyone.

Getting the infrastructure ready

Back in January I got a helping hand from my Computer Science friend, whom had some great ideas about how to handle the traffic within the backend of the software. For the 2020 event however I've chosen to set this up myself and in the meantime practice my Linux/Networking skills.

The main problem at hand is that the party is going on at the university campus. The only accessible network at this location is the international Eduroam. This network however is incredibly restrictive and does not allow routing from outside the network, it is also restrictive within the LAN, so having all data inputs coming from people on Wi-Fi isn't an option either (although it also does raise numerous practical challenges and annoyances) .

My Computer Science friend, Ulrik and I solved this obstacle in a really cool way back in January. We used "software defined networking" (SDN) through ZeroTier and a reverse Nginx proxy to route the traffic " below " the limits of the university network.

This implementation may sound awfully convoluted but I'll try to explain it. The input server is hosted on my laptop. This laptop is also hosting the entire software stack controlling both the prices and the dashboard broadcasted to a projector in the main room of the party.

The input server is a simple webserver (built using the Flask framework, running in a Docker Container for the sake of privilege isolation and dependency mangement) , where the bartenders can login and register every sale of a beer/drink etc. This means that I am able (in real time) to calculate the relative changes in prices dependent upon the increase/decrease in demand for a certain drink.

So, to circumvent the networking challenges the back-end infrastructure is designed this way:

• A bartender queries https://borsbar.me . This domain is routed to my Linux Virtual Private Server hosted at Digital Ocean

• Any traffic going to the server at port 80 or 443 is then forwarded to my Nginx reverse proxy running at that server.

  • This is all running within two Docker Containers. One running the CertBot Docker Image from Let's Encrypt taking care of all SSL encryption/certificate management and another handling the Nginx proxy.

  • The server only accepts SSL connections and re-routes HTTP requests at port 80 to a secure HTTPS connection at port 443.

• The Nginx reverse proxy then takes all incoming traffic at port 443 and forwards it to my synthetic ZeroTier IP at port 5000, which my Flask Docker Container is running at. However, this Flask server is running locally on my laptop.

  • My ZeroTier client looks (for the Nginx server) like a completely normal machine on the LAN - although I am actually located about 1000 km away from my server, which is located in Frankfurt, Germany.

  • All traffic is encrypted using Peer-to-Peer technology, so I don't need a central hub or VPN to manage this connection. It is secure and I get a lot more control over what I'm able to host. Another advantage is that, no matter which network I am using for my laptop, I'll always be able to access the input server using the domain above - that's some pretty freaking cool tech!

What to do next?

So! All is fine'n'dandy, I'm able to accept connections from anywhere. Use best practises and encrypt all the traffic automatically, and generally have a very robust back-end using enterprise-level secure communications and very solid software.

Now it is time to look a bit more into the actual code of my software, but I think I'll pick that up in one of my next blog-posts.