This first version of the MEDINA framework is a prototype integrating all components with the core functionalities implemented. To carry out the integration of the components, the DevOps strategies and CI/CD principles have been adopted, with a strong focus on software security.
According to the Continuous Integration practice, the software source code is managed via a versioning control system and for this purpose all the MEDINA projects are available on a private GitLab repository. The MEDINA framework functionalities are made up by the collaboration of all the micro-services, which communicate each other through REST API, are packaged in Docker images stored in a private Docker Registry and run in Docker containers. Kubernetes orchestrates all these containers in a virtual environment running on a high-available cluster and Jenkins automates the release process of each component, starting from the build step up to the deploy of the component in the Kubernetes cluster.
Three CI/CD pipelines have been designed and implemented for the MEDINA project:
- Build pipeline: it automatizes the build of the project, the creation of the Docker image and its push on the Artifactory.
- Deploy pipeline: if the previous pipeline succeeded, this pipeline automatically deploys the component to the development/test environment.
- Security pipeline: it is added to guarantee Quality & Assurance into the overall workflow performing different types of security analysis of the software artefacts. The results are displayed in dashboards and diagrams that give an overall view on vulnerabilities to the developer.
To make all the deployment process more automated, we use the Jenkins Seed Jobs for automating the creation of the three pipelines. This utility permits to fill out a form by entering parameters such the software repository URL where to retrieve the source code, the container file descriptor (in Docker format), the generated container image for publishing to an internal private registry and a list of one or more Kubernetes deployment manifest files. Once these details are provided, the Seed Job automatically creates the three standardized pipelines for build, deploy and security, ready to be executed.
The MEDINA Kubernetes cluster is made up by three nodes and virtualize two environments, the Development and the Test environment, making them independent and isolated. Such environments host the MEDINA micro-services containers depending on their current maturity level: development is by nature unstable, while test contains the more stable codebase and hosts the reference implementation of MEDINA.
The developer can address the environment s/he wants from the Internet via HTTPS using this URL naming convention:
https://<component_name>-<environment [dev or test]>.k8s.medina.esilab.org
And now… all the MEDINA microservices are up and running in the Development environment! After setting up all the MEDINA infrastructure and automation tools described above, the partners released their components into the Development environment of the MEDINA Kubernetes cluster through just one click: the push of the code on the GitLab repository triggers the associated Jenkins pipeline which automates all the steps required up to the deployment. Moreover, recently we had an integration session in which the teams collaborated each other to established and test point-to-point connections between MEDINA components. After verifying everything is correctly working, we will deploy out first stable version of the framework onto the Test environment.