Skip to content
Snippets Groups Projects
Select Git revision
  • main default
1 result
Name Last commit Last update
DevOps_Cycle.png
DevOps_Cycle_Tools.png
PIACERE_Context_IaC.png
PIACERE_Design_Time.png
PIACERE_Run_Time.png
README.md
README.md

PIACERE framework

PIACERE aims to increase the productivity of DevOps teams in the development and operation of IaC through the provisioning of an integrated DevSecOps framework. DevOps teams can program IaC as if they were programming any software application.

VISION

Table of Contents

Description

PIACERE enables the automation of several deployment, configuration and management tasks that otherwise would have to be performed manually by an operator. PIACERE solution consists of an integrated DevSecOps framework to develop, verify, release, configure, provision, and monitor infrastructure as code. Main PIACERE users are

  • DevSecOps teams
  • Application architects
  • Platform architects

DEVOPS

PIACERE supports the different DevSecOps activities with a set of tools. Using a single integrated environment to develop (IDE) infrastructural code will unify the automation of the main DevSecOps activities and will shorten the learning curve for new DevSecOps teams.

PIACERE allows DevSecOps teams to model different infrastructure environments, by means of abstractions, through a novel DevOps Modelling Language (DOML), thus hiding the specificities and technicalities of the current solutions. PIACERE also provides an extensible Infrastructural Code Generator (ICG), translating DOML into source files for different existing IaC tools, to reduce the time needed for creating infrastructural code for complex applications. The provided extensibility mechanisms (DOML-E) ensures the sustainability and longevity of the PIACERE approach and tool-suite (new languages and protocols that can appear in the near future).

Another key innovation of PIACERE is a comprehensive toolkit for verification and trustworthiness. Firstly, a verification tool (VT), that applies static analysis to both the abstract model and the related infrastructural code, to execute consistency checks and other quality verifications according to identified best practices. Secondly, an IaC Code Security Inspector that offers a form of Static Analysis Security Testing (SAST) by checking the IaC code against the known cybersecurity issues (misconfigurations, use of non-secure libraries, non-secure configuration patterns). Thirdly, a Component Security Inspector that by analysing also the IaC code, reports the potential vulnerabilities and proposes potential fixes. Fourthly, a Canary environment that allows unit testing of the behaviour of the infrastructural code on an isolated environment, which would enable the simulation of conditions for the production environment and identify some of the most common anti-patterns.

DEVOPS_TOOLS

In the Ops part of the DevSecOps lifecycle, PIACERE also presents several key innovations: The Optimized Platform (IOP) presents the DevSecOps teams with the most appropriate deployment configurations that best meet their defined constraints out of their catalogue of services, resources and infrastructural elements by means of optimization algorithms. The Execution Platform will automatically plan, prepare, and provision the infrastructure and plan, prepare, and install the corresponding software elements needed for the application to seamlessly run. At runtime, PIACERE continuously monitors the metrics associated with the defined measurable NFRs (e.g. performance, availability, and security through the Runtime Security Monitoring) and be able to self-learn, implementing machine-learning algorithms, and realizing an incremental learning strategy by continuously analysing divergences in the decision boundaries and detecting anomalies in the metrics being collected while retaining only the most up to date data to avoid model degradation. Whenever these self-learning mechanisms detect an anomaly or a potential SLA violation, an alarm is triggered, and a self-healing mechanism launched. A self-healing mechanism will entail to launch again an optimization algorithm for the actual problem domain and an automatic execution platform, monitoring and so on.

Repository structure

The Public repository of PIACERE project is organized as follows:

  • /agents: contain the monitoring agents that need to be deployed along with the IaC to monitor the infrastructure
  • /demos: different demos that can serve as a basic examples of using PIACERE
  • /The Platform: is divided in many repositories where the several components of the PIACERE framework can be found

Three branches Y1, Y2, Y3 gather the versions delivered in the three main milestones of the project (at M12, M24 and M30). The main branch stores the final version of the components, as some development and code fixes could continue until the end of the 36-months long project.

Components

The PIACERE framework can be divided, attending the workflow, in two parts: the Design-time

DESIGN-TIME

and the Run-time.

DESIGN-TIME

An user employs different tools of the PIACERE framework in each of these phases. The list of tools and the respective repository can be seen in the following table:

Component Repository
CSE - Canary Sandbox Environment The Platform/cse
IOP - IaC Optimized Platform The Platform/iop
Runtime Monitoring The Platform/runtime-monitoring
Runtime security monitoring The Platform/runtime-security-monitoring
DOML - DevSecOps Modelling Language The Platform/doml
DOML Model Checker The Platform/doml-model-checker
IaC Scan Runner The Platform/iac-scan-runner
ICG - Infrastucture as Code Generator The Platform/icg
IDE The Platform/ide
IEM - IaC Executor Manager The Platform/iem
Self-Healing The Platform/self-healing
Self-Learning The Platform/self-learning

Contact

Juncal Alonso, PIACERE project manager, TECNALIA Juncal.Alonso@Tecnalia.com

Acknowledgement

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 101000162. EU FLAG

(TO BE DELETED) *** Uniform approach for component repos *** (TO BE DELETED)

  • README: Each repo must include a README file with the following sections (see aprox. model in iac-scan-runner/README.md, Thx @XLAB! :-))
    • Description of the component
    • Installation
    • Documentation (point to)
    • License
    • Contact
    • Acknowledgement
  • BRANCHES: The branches to be present in each repository are:
    • y1, y2 and y3 (M30-may code). Please upload the respective code for each branch.
    • main (versions from now on). This has to be the default branch.
      1. If the main branch doesn't exist, create it in your public repo (Code>Branches>New branch)
      2. Make it the "default" branch (Settings>Repository>Branch defaults)