The 4CH Cloud Platform: design and approach
The 4CH project infrastructure is a cloud-based infrastructure. The resources used to host the 4CH Cloud Platform, in fact, are provided by the CLOUD@CNAF infrastructure, based on Openstack, present at INFN-CNAF, the main ICT centre of the National Institute for Nuclear Physics in Italy.
In particular, to support the development of project activities, some IaaS cloud resources, based on OpenStack, have been made available. Those resources will be increased in the deployment phase of the 4CH Cloud Platform (indicated in the text also as 4CH Platform). Nevertheless, the 4CH platform development approach adopted the so-called Infrastructure-as-Code7 (IaC); IaC is the process of managing and provisioning computing resources through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools; this allows for a faster, easier deployment of the CC cloud platform once the final High Performance Computing (HPC) resources will be made available for the production phase.
Following the IaC approach, the Kubernetes solution has been adopted and implemented. Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.
By defining a set of building blocks (“primitives”), Kubernetes can collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory, or custom metrics. Thanks to its loosely coupled nature, Kubernetes is extensible enough to meet
different workloads. The internal components as well as extensions and containers that run on Kubernetes rely on the Kubernetes API. The platform exerts its control over compute and storage resources by defining resources as Objects, which can then be managed as such.
In such respect, to enhance the use of resources and orchestration of different services, a Kubernetes cluster has been created. The cluster is composed of a master and several worker nodes suitable to host the 4CH services. To exposes services and applications to the users, an ingress object has been also made available.
On top of the Kubernetes cluster, some components have been deployed to improve the cluster functionalities. From one hand, network service relies on Calico, from the other
storage service rely on Longhorn.
4CH Platform policies and requirements: integration and federation
To foster the guiding principles expressed by the Tallin Declaration on e-Government, and since the 4CH Cloud Platform is currently hosted by a public research institution (INFN, which is also a partner of the 4CH project), a set of regulations related to the deployment, adoption and use of commercial software should be applied to the whole lifecycle of the services that have to be integrated in the 4CH Cloud Platform. In particular, the integrated applications should embrace the open-source, open-access policies.
Requirements for service integration
Applications providing services for Cultural Heritage applications can be integrated in the 4CH Platform and made available to the community via the 4CH dashboard.
To be integrated in the 4CH platform, the application (or a set of applications) should agree with the following requirements.
-
- The application must expose a REST API or one or more reachable endpoints.
- The resources exposed by the application must be labelled as free or authentication protected.
- The application (or the applications) must be containerized and the image, based on standard images available on the common image repositories, must be made available
- Authentication mechanism:
a) Could be demanded to the 4CH reverse proxy. In this case all the communications must be performed from and to the reverse proxy itself. - Authorization mechanism. Could be demanded to the application: in this case, the application must use the JWT, by extracting from it the needed user information to be used for authorization proposes.
More details can be found in the project Deliverable D3.1 Design of the CH Cloud and 4CH platform.