Cartridge
- Former user (Deleted)
- Former user (Deleted)
Overview
A cartridge is a virtual machine (VM) on an IaaS that has software components to interact with Private PaaS. Private PaaS provides cartridges for PHP, MySQL and Tomcat based applications on OpenStack and Amazon EC2 out of the box. Cartridges will vary based on the operating system (OS) and IaaS. Therefore, for each OS and IaaS a custom cartridge should be created. All cartridges in Private PaaS provide a very secure, OS level isolated environment for cloud applications. Cartridges can operate in two modes: Single tenant and Multi-tenant. Furthermore, the cartridge type will vary based on the method it has been created: Generic cartridge and Fully configured cartridge.Cartridge instances
In a live Private PaaS environment each virtual machine (VM) is known as a cartridge instance in Private PaaS terminology.
Cartridge types
Cartridges can be created as either a single tenant cartridge or as a multi-tenant cartridge. These cartridge types have been illustrated in the following sub-sections.
Single tenant cartridge
In Private PaaS , if a tenant user subscribes to a single tenant cartridge, a separate cartridge instance will be spawned for each tenant user. Thereby, single tenant cartridges provide tenant users process level isolation and instance level dedicated tenancy. Single tenant cartridge users can be mapped to one or more cartridge instances.
Multi-tenant cartridge
Multi-tenant cartridges in Private PaaS are cartridges that allow multiple tenants to share a single cartridge instance. Although tenant users share a single cartridge instance, the tenant user traffic will be securely directed to isolated application code within the cartridge instance.
User roles
The following are the user roles in a cartridge development lifecycle:
- Cartridge developer
The cartridge developer creates cartridge images for different IaaS. - Cartridge deployer
The cartridge deployer registers the cartridge with Stratos to create Stratos cartridges. - Cartridge subscriber
The cartridge subscriber will subscribe to cartridges and upload applications to the cartridges. The cartridge subscriber will allow cartridge users to access the cartridge via its hostname and also access the Git repository of the cartridge. Resources such as the persistent file system and a database (DB) with scaling parameters are used for the subscription process and the subscription details are kept in Private PaaS DB.
- Cartridge Users
Cartridge users are tenant users (e.g., users with domains such as, abc.com). Cartridge users will be able to carryout the following actions:- Use deployed cartridge Instances.
- Upload applications to cartridge instance.
Puppet based cartridge configuration
In Private PaaS Puppet is used to automate the configuration process of all cartridges. In a Private PaaS deployment a Puppet Master will be setup, which includes Puppet scripts for setting up cartridges, cartridge software and Cartridge Agent . Every cartridge instance will include a Puppet Agent that will communicate with Puppet Master to get the required software installed and configured.
When a cartridge is started, a start up script (e.g., init.sh) will invoke Puppet Agent. Thereafter, Puppet Agent will communicate with Puppet Master and based on the SERVICE_NAME, which is a payload parameter that defines the service type, Puppet Agent will automatically configure the respective cartridge. For example, if SERVICE_NAME=PHP, Puppet Agent will communicate with Puppet Master and will configure the cartridge to host PHP applications.
As a result of configuring cartridges using Puppet, DevOps will be able to easily reconfigure all running cartridge instances and future cartridge instances without changing the virtual machine image. In the future, Puppet configuration will be used to automate the cartridge image creation process.
Cartridge creation methods
Private PaaS allows DevOps to create cartridges as either fully configured cartridges or generic cartridges. The latter mentioned cartridge creation methods have been explained and analyzed in the following sub-sections.
Generic cartridge
A generic cartridge is a cartridge where all the software needed for the cartridge instance are installed only at run-time when a cartridge instance is spawned. Generic cartridges are cartridges that only have the base image operating system (OS) and Puppet Agent (PA) pre-installed with some setup scripts. The steps involved in creating a cartridge will vary based on the IaaS being used. For more information on creating a cartridge, see Creating a Cartridge.
Initially, DevOps will have to execute the setup script, which is OS specific (e.g., config.sh
). Private PaaS ships config.sh for Debian/Ubuntu operating systems. Note that DevOps will have to write their own script for any other operating system. When this setup script is executed, Puppet Agent will get installed in the cartridge. Thereafter, DevOps needs to create an initialization script (e.g., init.sh) to trigger Puppet Agent at the instance start up. When a user subscribes to a generic cartridge, Cloud Controller will send a payload to the IaaS and in turn the IaaS will start-up a cartridge instance based on the snapshot of the generic cartridge. When the cartridge instance starts up, the start up script (e.g., init.sh
) within the cartridge will get automatically executed and start up Puppet Agent, which will communicate with Puppet Master and install the Cartridge Agent and all the required software in the cartridge, which will communicate with Private PaaS to carry out the required operations.
Fully configured cartridge
A fully configured cartridge also known as a pre-configured cartridge is a cartridge where all the software and configurations are pre-configured. Fully configured cartridges include the base image operating system (OS), setup scripts, required software, Puppet Agent (PA) and Cartridge Agent (CA). The steps involved in creating a cartridge will vary based on the IaaS being used. For more information on creating a cartridge, see Creating a Cartridge.
Initially, DevOps will have to execute the setup script (e.g.,
config.sh
), which is OS specific. Private PaaS ships config.sh for Debian/Ubuntu operating systems. Note that DevOps will have to write their own script for any other operating system. When this setup script is executed, Puppet Agent will get installed in the cartridge. Puppet Agent will communicate with Puppet Master and install the Cartridge Agent and all the required software in the cartridge. DevOps needs to create an initialization script (e.g.,
init.sh) to trigger Puppet Agent at the instance start up. When a user subscribes to a pre-configured cartridge, Cloud Controller will send a payload to the IaaS and in turn the IaaS will start up a cartridge instance based on the snapshot of the pre-configured cartridge. When the cartridge instance starts up, the start up script (e.g.,
init.sh) within the cartridge will get automatically executed and start up Cartridge Agent, which will communicate with Private PaaS in order to carry out the required operations.
Overall comparison
The two cartridge creation approaches that Private PaaS provides have their own advantages and disadvantages. Therefore, it is important that DevOps select the most suitable cartridge creation method based on the needs of their organizations.
As all the applications and configurations have been pre-configured in a fully configured cartridge , DevOps will be able to spawn new cartridge instances faster with fully configured cartridges than generic cartridges. However, as generic cartridges do not possess any specific applications and configurations, the same cartridge can be used to spawn many different types of cartridge instances rather than needing a separate cartridge image to be created for each cartridge type.
Cartridge deployment
Initially, when deploying a cartridge, DevOps will have to define the cartridge using a
cartridge.json
via the CLI , Web UI or REST API and send it to Stratos Manager. Thereafter, Stratos Manager will send the cartridge definition to Cloud Controller (CC) to be deployed. Cloud Controller will carry out a validation process based on the cartridge image ID (e.g., On EC2 an Amazon Machine Image [AMI]). If the cartridge already exists, Cloud Controller will undeploy the cartridge. If the cartridge does not exist, Cloud Controller will proceed with the cartridge deployment process. Cloud Controller will add the cartridge definition to its in-memory data structure and persist it in its registry. Thereafter, Cloud Controller will update the Topology with the service definition and publish the Topology event to Message Broker (MB). For more information, see the Cartridge Deployment Workflow.
Deploying a single tenant cartridge
To deploy a single tenant cartridge in Private PaaS, DevOps need to deploy the following (either via CLI, web UI or REST API) in sequential order:
- Partition - For more information, see Working with Partitions.
- Deployment policy - For more information, see Working with Deployment Policies.
- Auto-scaling policy - For more information, see Working with Auto-scaling Policies.
- Load Balancer cartridge
As Private PaaS has a default Load Balancer and also as a cartridge can be deployed without a Load Balancer, it is not mandatory to deploy a Load Balancer cartridge. For more information, see Working with Cartridges. - Cartridge - For more information, see Working with Cartridges.
Deploying a multi-tenant cartridge
To deploy a multi-tenant cartridge in Private PaaS, DevOps need to deploy the following (either via CLI, web UI or REST API) in sequential order:
- Partition - For more information, see Working with Partitions.
- Deployment policy - For more information, see Working with Deployment Policies.
- Auto-scaling policy - For more information, see Working with Auto-scaling Policies.
- Load Balancer cartridge
As Private PaaS has a default Load Balancer and also as a cartridge can be deployed without a Load Balancer, it is not mandatory to deploy a Load Balancer cartridge. For more information, see Working with Cartridges. - Cartridge - For more information, see Working with Cartridges.
- Multi-tenant service cluster
A multi-tenant service cluster too needs to be deployed after the multi-tenant cartridge has been deployed. A multi-tenant service cluster can be deployed either via the Web UI or REST API. For more information, see Working with Multi-tenant Service Clusters.