A cartridge is a virtual machine (VM) on an IaaS that has software components to interact with Stratos PaaS. Stratos provides cartridges for PHP, MySQL and Tomcat based applications on OpenStack and Amazon EC2 out of the box. Furthermore, Stratos supports any pluggable cartridge, which comes under the following categories: data, load balancer, framework or application. Cartridges will vary based on the operating system (OS) and IaaS. Therefore, you need to create a custom cartridge for each OS and IaaS. All cartridges in Stratos provide a very secure, OS level isolated environment for cloud applications. Cartridges can operate in two modes: single tenant and multi-tenant. The cartridge type differs based on the method that you used to to create it: generic cartridge and fully configured cartridge. If required, you can use an orchestration layer, i.e., Puppet, Chef etc., to automate the cartridge creation process. |
In a live Stratos environment, each virtual machine (VM) or a Docker container is known as a cartridge instance in Stratos terminology.
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.
In Apache Stratos, when a single tenant application is deployed, which contains one or more single tenant cartridges, the tenant users are automatically signed up to the application, and a separate cartridge instance is spawned for each cartridge in the application. Thereby, single tenant cartridges and applications provide tenant users process level isolation, and instance level dedicated tenancy. Single tenant cartridge users can be mapped to one or more cartridge instances.
In Stratos, multi-tenant applications contain one or more multi-tenant cartridges, which allow multiple tenants to share a single cartridge instance. Even though tenant users share a single cartridge instance, the tenant user traffic is securely directed to isolated application code within the cartridge instance. After a multi-tenant application is deployed, which contains one or more multi-tenant cartridges, the tenant user has to sign up to the application, to be able to use the application.
Apache Stratos 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.
A generic cartridge is a cartridge where all the software needed for the cartridge instance is 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 New Cartridge.
When a tenant user signs up to an application, which has one or more generic cartridges, Cloud Controller sends a payload to the IaaS, and in turn the IaaS starts up cartridge instances based on the snapshot of the generic cartridges, which correspond to the deployed application. When the cartridge instance starts, the startup script (e.g., init.sh) within the cartridge gets automatically executed, and starts up the Puppet Agent, which will communicate with Puppet Master and install the Cartridge Agent and all the required software in the cartridge. Thereafter, the Cartridge Agent communicates with Stratos to carryout all the required operations.
A fully configured cartridge, which is 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 Puppet Agent will communicate with the Puppet Master to retrieve the required software updates when there is a difference between existing software in the instance and the Puppet Master. 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 New Cartridge.
When a tenant user signs up to an application, which has one or more pre-configured cartridges, Cloud Controller sends a payload to the IaaS, and in turn the IaaS starts up cartridge instances based on the snapshot of the pre-configured cartridges, which correspond to the deployed application. When the cartridge instance starts, the startup script (e.g., init.sh) within the cartridge gets automatically executed, and starts the Cartridge Agent, which communicates with Stratos to carryout the required operations. The Puppet Agent will only communicate with the Puppet Master to retrieve the required software updates, when there is a difference between existing software in the instance and the Puppet Master.
The two cartridge creation approaches that Apache Stratos provide 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 can spawn new cartridge instances faster with fully configured cartridges than generic cartridges. However, as generic cartridges does not possess any specific applications and configurations, the DevOps can use the same cartridge to spawn many different types of cartridge instances, rather than needing a separate cartridge image to be created for each cartridge type.
To learn how to create a cartridge on a Virtual Machine and on Docker, see Creating a New Cartridge. |
Initially, when adding a cartridge, DevOps have to define the cartridge using a cartridge.json via the CLI, Web UI or the REST API, and send it to Stratos Manager. Thereafter, Stratos Manager sends the cartridge definition to Cloud Controller (CC) to be added. Cloud Controller carries 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 deletes the existing cartridge and adds the cartridge again using the modified configuration. If the cartridge does not exist, Cloud Controller proceeds with the process of adding the cartridge. Cloud Controller adds the cartridge definition to its in-memory data structure, and persist it in its registry. Thereafter, Cloud Controller updates the Topology with the service definition, and publishes the Topology event to Message Broker (MB).