GQDELTEX

Server

Description

This server is running docker containers in docker swarm mode on a virtual machine running at my webhosting provider of choice. It is the base to everything you see on this page right now.

Motivation

I started building web applications and actually wanted people to see them, so I started this website and I'm looking forward to update it with more content and functionality

How it works

Structure

First off, the structure of all this machinery running this website. This Website is running on Microservice architecture which is fed by build pipelines from my local git repositories. Which actually just means that every single service on this website is running in its own little container. Those Containers get created by a 'docker-stack.yaml' file, which describes the desired state of the containers and how to deal with errors during deployment and such. This file (and many others), are stored on our local gitlab server, where, when you commit new changes, they will automatically get checked and uploaded to the Server. Basic continuous integration/delivery/deployment. Some containers have 'special needs', they need, for example, access to the docker socket or a database. But those things make the System more vulnerable to attacks and may lead to data loss. So I have implemented two 'barricades' to stop people from getting in:

  1. Secure the docker socket, by allowing access only via a proxy which filters malicious requests
  2. Secure the databases by putting them on a seperate network which is only accessible by the containers needing access to the data

The (rather long) journey of web requests

  1. If a request reaches my server, it is first off checked by the firewall, if it is allowed (not everything is allowed to enter the server).
  2. If the Request comes through, the next station is the Traefik reverse proxy / router. This Container is the only one with direct internet access. It manages all of the required SSL-Certificates and routes the request to the specified service
  3. Now the Request gets (probably) routed to the right container of the desired service. This is done by the internal docker swarm ingress controller.
  4. Now the request has reached his target and can be fulfilled.