Pruning Elements¶
This document holds a detailed step-by-step guide to deploy the elastic deployment variant of a web shop application to showcase the reduced modeling effort when pruning elements. The application can be deployed in the following deployment variants, see Figure 1.
- static with medium resources on a single virtual machine on a local OpenStack (OS) instance
- static with large resources on a single virtual machine on a local OpenStack (OS) instance
- elastic with high availability and backups on Google Cloud Platform (GCP)
Requirements¶
We need to fulfill the following requirements to follow this step-by-step guide.
- Ubuntu 22.04
- Access to a GCP project
- GCloud
- Git
- xOpera
- Ansible
Preparation¶
First, we install OpenTOSCA Vintner. For more information see Installation.
Next, we configure xOpera as the orchestrator that should be used for the deployment. For more information see Orchestrators.
Import the Template¶
First, we clone the repository.
Next, we import the Variability4TOSCA template.
Next, we initialize an application instance.
We can optionally inspect the Variability4TOSCA template. This template contains all possible elements having conditions assigned. However, due to pruning, only a handful of condition must be modeled, e.g., the condition checking if a medium or large virtual machine is required. An overview is given in Figure 2.
Resolve Variability¶
We intend to deploy the elastic variant. We specify this when resolving variability.
We can optionally inspect the generated TOSCA-compliant template. This template contains only the elements required for the elastic variant, e.g., the MySQL database. An overview is given in Figure 3.
Deploy the Application¶
Finally, we deploy the application.
Therefore, we need to provide deployment inputs, e.g., credentials to GCP.
Possible deployment inputs are specified in topology_template.inputs
of the TOSCA-compliant template.
The deployment will take around 15-20 minutes.
Undeploy the Application¶
Afterward, we undeploy the application.
Optionally, we can remove the instance and cleanup the filesystem. Cleaning up the filesystem removes any data including, e.g., all imported templates and created instances.
Complexity Analysis¶
The templates for our complexity analysis can be found here.
Logs¶
This deployment is also executed in our integration pipeline, which is executed once a week. The logs of the corresponding GitHub action can be accessed here. Relevant jobs start with "Unfurl Artifacts". Note, a GitHub account is required to access these logs. The raw logs are available without requiring an GitHub account.
Zenodo¶
The assets of this guide can be also found on Zenodo.
Publication¶
This guide is part of our paper published at the UCC 2023. Also check our other publications.