This page implement the second "C" in the C4Model: the Ccontainer Model.
It recommended that you understand the Context Model (first "C") before moving on to this page.
One of the most important architectural benefits with OCI Containers is modularity. For example: it is relatively easy to switch out the Reverse Proxy Container (below) from NGINX to HAProxy. Modularity enables alternate Core Node System compositions, which will minimise the risk of single point of failures in a Radix Network. The long-term plan is to have alternate implementations of all Containers including RadixCore.
Our beloved RadixCore is implemented in Java. To protect the RadixCore, we have introduced some specialised Containers (Reverse Proxy, Rate Limiter) in front of it.
Correctly implemented OCI Containers improve security vs. running the app directly on the host machine. It is also possible to run OCI Containers on hypervisors with tools like Kata Containers, which improves isolation between Containers and Host even further.
At this level we do not discrimate between the Core and Boot nodes since they are identical and in normal case run the same Software stack + configuration.
This Container is designed to offload/protect the RadixCore API with:
TLS (1.2) Termination
DDoS mitigation through
Rate-limiting of Connections/bandwidth
Caching API Requests
HTTPS (L7) Filtering of Requests
Authentication to protected end-points
This Container is responsible for configuring the Host Kernel to protect the RadixCore from attacks targetting the Sync/Gossip protocol, which is over UDP.
Please read Core Nodes.