Portainer and VDC in use within the cloud architecture

The post on the cloudtec platform stack was about its structure in layers. Here we look at the lowest of those layers: the infrastructure on which all applications run.

The foundation is virtualised. Resources are pooled and shared over a network instead of setting up a separate machine for each project. On top of this run Linux, web servers, MariaDB and PHP, complemented by services from other ecosystems. The full-text search, for example, brings its own Java environment. Instead of renting from a hyperscaler, we operate a private cloud and package the applications in Docker containers.

What lies beneath the containers

The hardware doesn’t belong to us: it sits with a Swiss provider in a data centre in Switzerland. On it runs our Virtual Data Center (VDC), divided into virtual machines that we set up and operate ourselves. How much memory, processing power and disk space a platform gets is therefore a matter of configuration, not a hardware purchase.

The VDC is based on OpenNebula, an open-source platform for cloud computing. In it run the virtual machines, mostly Linux, connected via a virtual LAN and together forming a Docker Swarm.

In front of it sits network security: a firewall and a web application firewall check every request against the defined rules, complemented by network segmentation and VPN access for operations. Whatever gets through is taken over by the reverse proxy, which connects the request to the responsible container, including SSL termination and load balancing when a platform runs on several instances.

One container per project

Docker separates the application from the infrastructure. An application thus runs the same everywhere: on the developer’s laptop, on staging and in production. The operating system is containerised and abstracted instead of being set up anew for every project.

A container bundles an application’s software processes: web server, database and the programming language. It is provided via an image that contains all executable components.

Every client project has at least one container of its own. This isolates and segments the data, and the software components involved only see their own application. We also provide auxiliary services such as virus scanners or PDF indexing as containers; they talk locally to the project containers over virtual networks. These networks also determine which service can see which other service at all.

Docker Swarm assigns the containers to the hosts. If a host fails, the container starts automatically on another one. The whole set-up is managed with Portainer: configuring, orchestrating, securing and monitoring containers centrally, with a web interface instead of only via the command line.

Why our own cloud instead of a ready-made kit

Large providers supply ready-made building blocks but dictate release cycles and policies. With our own architecture, we decide what gets updated when, and we can adapt it when a project requires. Thanks to containerisation, a new service benefits all projects, and Docker Swarm keeps operations running even when a host drops out.

Regardless of our set-up, the following generally applies to a private cloud:

• full control over access rights
• separation of resources and storage location
• high security standard including encryption
• high bandwidth through exclusive access
• flexibly scalable resources

The price for this is that we are responsible for operations ourselves. In return, the same team builds and operates the platform: when there is a fault, there is no chain of tickets across three providers.