This design document describes the minimum setup and architecture for creating a SlapOS system. It will describe the administrative layer and the required hard- and software that needs to be installed. It will also provide information on the user layer and its technical requirements.
For a more detailed overview of SlapOS itself, its concept and system design, please refer to the SlapOS architecture design document.
The installation is generic, automated and independent of how the SlapOS network will eventually be used. It requires at least two computers and at most 1 day to install and setup.
This section describes the mininmal setup required for a SlapOS network. It will introduce the SlapOS Master (COMP-ROOT) and first network node (COMP-0) which together form the administrative layer and the minimum required to run a SlapOS network. All other nodes (COMP-1,2,3,...) belong to the user layer. The Master and first network node handle network management, while the additional nodes in the user layer contain the actual software which will be instantiated to users.
A SlapOS network consists of two layers.
The administrative layer consists of two nodes, which run the SlapOS Master (COMP-ROOT) and the first network node (COMP-0) which provides connectivity between all nodes in the network via the Re6st Registry and an Frontend (Apache). For details on why these are required, please refer to installing and configuring a SlapOS node.
All other nodes in a network form the user layer, simple nodes that after having re6st and SlapOS installed will wait for the Master to instruct them as to which software to install and instantiate to users.
Note, that during installation, the SlapOS Master node starts out as a regular formatted node, too (with just the SlapOS Kernel). It is through a software called SlapProxy (a minimal SlapOS Master), which is run during installation of a SlapOS Master, and that installs and instantiates the actual SlapOS Master/ERP5 Cloud Engine along with a Frontend (Apache) for accessing it, that the COMP-ROOT node is created. This means, that SlapOS is used to deploy SlapOS recursively and that there are in fact two networks - the one during installtion with SlapProxy acting as Master and the first node being COMP-ROOT and the second actual network of COMP-ROOT and COMP-0,1,2,3....
The administrative layer is described in the following section. It will introduce the COMP-ROOT and COMP-0 nodes which together form the minimum requirements to setup a basic SlapOS network.
The administrative layer is used to describe the essential (minimal) services required to deploy and manage any type of SlapOS cloud (Edge, Home, Distributed, Datacenter-based). It consists of a Master node (COMP-ROOT) and a first slave node (COMP-0) which provides services to the master for managing and communicating with nodes on the network. At the very minimum these services are a Frontend (Apache) and a Re6st Registry. The Registry connects nodes within the network and handles communication between all nodes over IPv6 while the Frontend provides "user-friendly" IPv4 adresses for accessing the network.
Depending on the type of cloud computing system being created, additional servers can be used to provide Frontends (similar to a CDN) and/or additional services can could be required (like user databased for simcards).
Tutorials are available covering installation and configuration of a SlapOS Master as well as setting up and configuring a Slave node on the administrative and user layer. Separate howtos show how to configure the specific software solutions available in a network (Re6st Registry, Frontend, etc). Additional documentation is available on extending existing software releases or creating a new software to be made available on a SlapOS network.
The COMP-ROOT will host the a Frontend (Apache) and the SlapOS Master (ERP5 Cloud Engine) and requires at a minimum:
The installation is generic, fully automated, and will take ~20 min if installable from cache plus another 20-40 min for running the configurator. It will install SlapOS Proxy and provide 3 access points on ports 80, 443 and 5443.
Note, that this machine must have public IPv4 or private IPv4 reachable from COMP-0 (and users). The above server should be sufficient to run a network of 80-160 actual computers (slave nodes), which then use computer partitions to provide instances of software releases called "hosting subscriptions" to users - see the glossary for the full SlapOS nomenclature. Each hosting subscription (for example erp5 or LET eNodeB) is in turn run through several URL-based services (erp5: 5 services, LTE eNodeB: 5+ services).
Since some of the services on the SlapOS Servers (COMP-1,2,3) require IPv6 interconnection and HTTP entry points, another server called COMP-0 is used to provide these to COMP-ROOT and other nodes on the network. It will have a Frontend (Apache) with IPv6 installed and thus also requires Re6st. Note, that Re6st is required to provide IPv6 to all SlapOS nodes (COMP-[X]) as all nodes are accessed and exchange data over IPv6. The Frontend is necessary, as users will use a browser to access HTTP services running on a remote node accessible via IPv6. The Frontend handles some browser limitations when accessing dsitributed services (eg access HTTPS with valid certificates, access via IPv4, CORS etc).
As mentioned above, initially there are two different types of Masters being used: SlapProxy (minimalistic) and the eventual SlapOS Master (ERP5-based). This is done in order to manage the deployment of a SlapOS Master in the same way as managing any other kind of instance, a recursive approach by which a minimalistic Master (SlapProxy) can deploy another ERP5-based Master. For smaller use cases, like running only a single node, SlapProxy alone could be sufficient (the Nexedi Webrunner is an example of a SlapProxy (IDE) being used to deploy a software instance on a single machine for a single user). However, in case of a larger network of nodes and using SlapOS for cloud orchestration and computing, SlapProxy is used at startup only and retired once the actual SlapOS Master is up and running.
Two softwares will eventually be run on the SlapOS Master - ERP5 Cloud Engine itself for user management, deployment of services, usage accounting and capacity management) and an Frontend (Apache) for accessing the Dashboard.
COMP-0 will provide services to COMP-ROOT and other nodes in the network. The installation is generic for all nodes in a network. Only the configuration or more specifically which services a nodes provides can differ from node to node.
COMP-0 will run at least two services: an Frontend (Apache) and the Re6st Registry meaning it will require having a valid SSL wildcard (!) certificate as well as IPv6. If both are available, deployment will require about an hour. The Frontend (Apache) will communicate over ports 80 and 443 and the registry on port 19201. The minimum requirements for this machine are:
COMP-0 contacts the COMP-ROOT over port 5443 and also requires public IPv4 or private IPv4 reachable by the SlapOS Master and users.
With the above specifications about 8 computers which equates to about 800 partitions (instanciated software services) can be provided through URLs (services in SlapOS are all provided over https).
The COMP-0 node is setup like any node in the network. However, during configuration a required set of services has to be installed on COMP-0 in order to provide these to MASTER and other nodes in the network (see the aforementioned requirement of COMP-0 needing at least IPv4 connectivity to the MASTER and users).
One required software is the re6st Registry, which is a service to inform nodes about other nodes in a network as well as between which nodes tunnels should be established. The registry can issue tokens which nodes can later use to register on a network. It requires IPv6 which is why XXX WHY? XXX. Besides the registry a first network "root" node is also instantiated using re6st.
Besides re6st, another Frontend (Apache) is required to connect to make a node accessible on the network as well as to connect with other services such as the monitor (XXX REALLY? XXX). Since all connections need to be secured and any number of nodes will result in issuance of a significant number of domains and URLs, a wildcard SSL certificate is necessary for the Frontend (Apache).
Depending on the cloud computing system being created additional services like a SimCardDB (LTE eNodeB User database) will have to be installed on the COMP-0 machine. This however is a case by case decision.
The user layer is described in the following section. While it is not required for a minimal setup to have any nodes beyond the COMP-0 node, SlapOS is a solution for orchestration of large networks so in a typical SlapOS network, there will always be a user layer providing software instances to users.
All nodes in the user layer are setup similarly. After installing IPv6, SlapOS is installed during which it will also be associated with a SlapOS Master. After installation and formatting a node, the Master can request installation of specific software releases and then provide instances of these releases to users.
The software provided on nodes depends on the purpose of the SlapOS deployment. For example when using SlapOS to provide a network management system for a phone network provider, the nodes could be used to provide the Amarisoft LTE stack (eNodeB).
Network nodes (denoted by COMP-1,2,3...) are installed in the same way as the COMP-0 node. Hardware requirements depend on the software instances being run on the nodes. For simple services, a machine similar to the one used for COMP-0 will be sufficient whereas more complex softwares running multiple services (such as ERP5 or LTE eNodeB) should look more towards the COMP-ROOT requirements as indicator of what will be necesary.
During installation a node can (and should) also be registered on network (using the token obtained from the re6st registry). Afterwards it is up to the Master to decide which software will be installed and to whom it will be provided. For example a network may consist of nodes separated on different continents with a node on each continent providing the same software. The Master could then decide to provide instances of ERP5 using the node closest to the respective user.