Blog entry by Radosław Piliszek and Marcin Byra from 7bulls
PIACERE Runtime Controller (PRC) is one of the essential components of the PIACERE project, which orchestrates the runtime part of the PIACERE framework and is a bridge for the IDE (Integrated Development Environment) to go from design time to runtime. PRC integrates a lot of runtime components. In this article, we describe the workflow of the PRC and its place in the methodology. The current description is valid for year 1 version of the PIACERE framework.
Functions of the PRC
PRC is responsible for calling other specific tools and allowing these tools to call back. In short, its role is to ensure the designed infrastructure is deployed, monitored, self-healed, and optimised as expected. To this end, the basic concept in the runtime is deployment. Each deployment is managed individually and can be updated by providing an updated design. Deployment Infrastructure as Code (IaC) is passed by a git repository reference.
Underlying technology stack
The core of the PRC is based on the Camunda Platform – a platform for workflow and decision automation that supports Business Process Model and Notation (BPMN) standard. Implementations of some tasks performed by the PRC are written in the Java language as the whole core is a Spring Boot application. The other crucial component, the PRC API server is Python-based and uses FastAPI framework.
The reason behind choosing the Camunda Platform as the backend solution is that it is a platform for workflow and decision automation. It allows running and managing processes specified as BPMN. The primary PRC process is designed as BPMN. Multiple instances of this process can be run in parallel in Camunda; each of them is the deployment responsible for managing a particular IaC.
Description of the BPMN workflow
Figure 1. BPMN model of PRC
What exactly happens during the deployment?
BPMN models are easy to read, and by analysing Figure 1. we believe the reader can easily get the idea behind it. In the upper part of the figure, there is the main process. It is started by passing the initial form, containing the IaC reference in the form of a git repository link.
Then, the repository is cloned and prepared, and the project settings are parsed.
After that, the IaC is deployed using IaC execution manager (IEM) [see the previous blog post], and the process is paused until the confirmation of the success of the deployment. If it passes, the deployment is registered in the Monitoring Controller and then remains alive until receiving the request to finish.
On the diagram, below the primary process, there are two subprocesses. They can be triggered at any time. Their goal is to allow the PIACERE framework to apply a self-healing strategy: redeployment or optimisation of the IaC. To achieve this, PRC communicates with already-mentioned IEM and also IaC Optimisation Platform (IOP).
PRC REST API
We discussed the BPMN diagram and Camunda platform as a backend to explain how the Runtime Controller works. Still, the PRC user doesn’t have to communicate directly with the Camunda backend. To simplify the interface and provide more flexible authentication, we implemented a separate REST API. It is what the user (or an agent, IDE, etc.) sees when they want to interact with the PRC. The API exposes endpoints for:
- Creating a new deployment
- Getting a list of active deployments
- Getting detailed information on a specific deployment
- Triggering one of the self-healing methods
- Finishing the deployment
An essential advantage of this solution is that all the generated identifiers and complex requests used in the Camunda API are hidden. The only name that the user must know is the deployment identifier specified in the initial form.
0 Comments