Jelastic Cloud Scripting (CS) it’s a scripting engine, designed for programming the cloud platform behavior at specific application lifecycle points. Or in other words, you can give extra tasks to the platform for managing your application or environment in autopilot mode. We use it for automating frequent tasks, management of 3rd party licenses or service subscriptions, interconnection of multiple environments for building required CI/CD topologies and auto-clustering configurations of the most popular software templates.
In other words, with CS you can:
- create environments of simple and advanced topologies
- package applications with Jelastic Packaging Standard (JPS)
- deploy applications and services
- attache public IP addresses
- define environment behavior during its lifecycle
- make and restore backups
- update application code
- upgrade database or application server stacks
- inject custom configuration settings
- configure high availability
- rebalance or recover clusters
In this article, we’ll go through the main notions of Cloud Scripting and review a sample scenario to facilitate understanding.
Get Started with Cloud Scripting
Cloud Scripting solutions are wrapped into packages and distributed with Jelastic Packaging Standard (JPS). This is accomplished through preparing a manifest file in YAML or JSON format using a regular text editor.
There are four main pillars while creating a Cloud Scripting scenario:
- Placeholders — predefined values that temporarily take the place of the final data
- Actions — scripted logic for executing a set of commands to automate the tasks
- Events — specific triggers for executing actions on a required application lifecycle stage such as start, deploy, scale, update and others
- Injection — supplying default actions, environment variables, API methods, request parameters and input settings in custom scripts by default
1. Placeholders are very much like keywords with predefined values, or like a key-value storage that is dynamically updated during the lifecycle of an environment. There are many pre-defined and ready-to-use placeholders:
- Environment Placeholders
- Node Placeholders
- Event Placeholders
- Account Information
- Input Parameters
- Action Placeholders
- UI Placeholders
- Custom Global Placeholders
- Function Placeholders
- Data Processing Placeholders
- Array Placeholders
- File Path Placeholders
To print and review all available placeholders in the dashboard console, use a special keyword ${placeholders} in your manifest. For example: log: ${placeholders}.
Note: The dashboard console is a tool to perform manifest debugging and troubleshooting. E.g. you can check the manifest action logs or add a custom log across the manifest.
Also, custom placeholders can be defined in ${globals} scope. It’s useful when some values are needed to be used multiple times or just for easy customization. For instance, we can define the URL of our application archive to be deployed afterward, e.g. ${globals.appSource}.
2. Actions — scripted logic for executing a set of commands to automate the tasks:
- Container Operations
- Topology Nodes Management
- Database Operations
- User-Defined Operations
- Custom Actions
The system provides a default list of actions and possibility to script custom actions using Linux shell commands, JavaScript and Java snippets, and API calls.
3. Events — you can simply attach the actions described above to a wide range of the default platform events. These actions will be executed at specific lifecycle points such as onInstall, onAfterScaleOut, onBeforeDelete, onBeforeRedeployContainer, onAfterChangeTopology and many others.
Almost each lifecycle point has a pair of related events — one is executed before, and the other is triggered after. Events can be divided logically into groups according to the action mission:
4. Injection — literally injecting in the JPS execution scope ready-to-use actions, placeholders, platform API methods, environment variables, request parameters and input settings by default, so it gives a super easy way to script the business logic.
Cloud Scripting Scenario Overview
1. For greater user convenience, Jelastic Dashboard includes a built-in text editor with an automatic syntax checking tool. Click on Import > JPS to open the editor. Here we have inserted an example scenario that is more thoroughly covered below.
2. Line #1 defines the JPS type which can be specified as:
- install — can be used for two cases:
→ create a new environment (provision specified nodes) and execute related actions — also called like Application JPS
→ just execute actions if nodes section is not specified — Service JPS
- update — used to update or extend an existing environment, and also called as Add-On JPS
3. Line #2 defines a mandatory JPS package name e.g. My Cloud Scripting.
type: install
name: My Cloud Scripting
4. Lines #4–8 define that the environment topology should include a single apache application server node with vertical scaling limit of 4 dynamic cloudlets. This section can be changed or even complimented with other node definition parameters.
nodes:cloudlets: 4
count: 1
nodeGroup: cp
nodeType: apache
The cloudlets parameter defined in line #5 is important and you have to realize what the minimum required level of cloudlets for your application is. Otherwise, if you define fewer resources than required your application server can be stuck and the application will become not responsive.
Line #8 sets a mandatory nodeType parameter which can be defined as either nodeType or as an alias to it. Each nodeType is a certified software stack template prepared for running in Jelastic PaaS. All nodeTypes are grouped in nodeGroups (layers). In our case, we use the application servers layer — cp. The list of nodeTypes, aliases and nodeGroups is presented and updated on a regular basis in the Supported Stacks section of Cloud Scripting documentation.
5. Lines #10 and 11 add section globals and describe placeholders in global scope visibility that can be used within the manifest. Here we specify only one with a custom name appSource which contains the URL of the application to be deployed.
globals:
appSource: https://github.com/vlobzakov/basic-examples/raw/master/introduction/HelloWorld.zip
6. Lines #13 invokes onInstall event which is the entry point for executing any action in the manifest. For the installation type install, the onInstall event is triggered right after the environment creation. If the installation type is update, the onInstall is the first event that is performed during the manifest installation.
onInstall:
deploy:
archive: ${globals.appSource}
name: Hello World
context: ROOT
As for our example, the triggering runs deploy action, which installs an archived HelloWorld.zip application to the Apache web server under ROOT context (/var/www/webroot/ROOT/). Parameter archive in line #15 defines the URL where the compressed application should be taken from. Thus you may provide any URL with your application archive in formats: zip, .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tar.Z, .tgz, .tbz, .taz, .tlz, .txz, .gz, .bz2, .xz, .lzma, .Z.
7. Each successful manifest installation is completed with a successful installation window appeared. This window can contain an arbitrary text in combination with useful placeholders’ data such as URLs, logins, passwords, etc. For the current example, we simply set up an encouraging text result.
success: First application deployed successfully!
The Open in Browser button provides access to the deployed application.
8. The entire process, from defining manifest type to application testing, is demonstrated in the brief animation below.
Automate environment provisioning, applications deployment, clustering, scaling, management and multi-service interconnections by simply scripting the required application blueprints. Invest minimum efforts and resources into repetitive tasks using pre-configured application lifecycle flows. Follow our next blog posts to find out how to package more complex topologies and cover various configuration scenarios with Cloud Scripting. Register at one of Jelastic Hosting Providers and try it yourself.
