Deployment and deployment monitoring service
This is a very first approach where we will only consider:
GitLab + “SmartCLIDE Interpreter + Jenkins + Docker + Kubernetes/AWS
The deployment and deployment monitoring microservice makes use of the following elements to perform the deployment and monitoring tasks, from the GitLab-ci pipeline file until the deployment is monitored as it runs on the Kubernetes cluster, be it on any cloud infrastructure.
| Element name | Role |
|---|---|
| Kairos interpreter | The Kairos interpreter is a microservice developed by our partner KAIROS whose main function is, from a GitLab-ci file, to obtain a Jenkins pipeline file. |
| Jenkins | Jenkins was chosen as the CD/CI engine since it is the main target of the Kairos interpreter as a CD/CI engine. In addition, since it is open-source software, it can be deployed on the developer’s machine in the development and testing tasks of the deployment microservice. As more and more organizations are using Docker to unify their build and test environments for their applications, Jenkins allows us to interact with Docker through default Docker support in its pipelines. On the other hand, Jenkins pipelines allow images to be built from the Dockerfile found in the main folder of the software project. |
| Docker registry | Docker Registry is an application that manages to store and deliver Docker container images. Registries centralize container images and reduce build times for developers. Docker images guarantee the same runtime environment through virtualization, but building an image can involve a significant time investment. Docker registry will be used as a central repository of images once they are built. It will be from this service from where the Kubernetes deployment will obtain the image of the containers to be deployed in the cluster. |
| Kubernetes cluster | Because Kubernetes is an open-source project, you can use it to run containerized applications in any environment without having to change your operational tools. A large community of volunteers maintains and improves Kubernetes software. In addition, many other vendors and open-source projects create and maintain Kubernetes-compatible software that you can use to enhance and extend your application infrastructure. The scope of the service also includes the use case of obtaining information about the status of the service while it is running in Kubernetes. Some of this data can be RAM memory in use, network information, or CPU usage. It is assumed that a Kubernetes cluster is running on any of the clouds, such as AWS, Azure, or Google Cloud Platform. |
SmartCLIDE CI/CD
The proposed basis for the SmartCLIDE CI/CD infrastructure is the built-in CI/CD capability provided natively by the chosen version control system, GitLab. For the Continuous Integration (CI) component of this, there are several areas to consider:
- What elements of the system are subject to CI
- How CI integrates with the development strategy
When considered at the level of individual services, CI is a requirement for those services which are defined within the SmartCLIDE source code repository, i.e., services which are developed from scratch, modified from a template, or generated as source code with SmartCLIDE tooling. CI on GitLab is generally configured by means of a configuration file, namely the GitLab-ci.yml file, at the root of the corresponding source repository. Within this configuration file, the various stages of the build pipeline are defined. A build pipeline might typically involve the following stages:
- Build – compile the code in the repository
- Unit test – run unit tests
- Package – package the service into a deployable unit
- Integration test – run integration tests
- Deploy – deploy to an environment
For Continuous Delivery (CD) at the workflow definition level, the flexibility afforded by the GitLab CD functionality, with built-in support for Docker and Kubernetes deployments and the ability to run arbitrary scripts, may serve as the basis for the deployment of the composed service.
| Subcomponent name | Functionality |
|---|---|
| CI Server & testing Component | Perform automated build, test, and packaging of services from source code. |
If you wish to learn more about this aspect of the SmartCLIDE project, we invite you to read the public deliverable entitled “D3.1 – Early SmartCLIDE Cloud IDE Design“.
No responses yet