Specifying Target Container¶

Running a specific action requires to specify a target container, in confines of which this action is executed. Thus, it is possible to specify a particular container, all containers within a layer by the nodeGroup value, or all containers of the same type by the nodeType value.

Particular Container¶

The nodeId parameter is used to specify a particular container for the action execution. If you know the Node ID of your container (displayed at the Jelastic dashboard next to the required node), you can set it statically as follows.

writeFile:
  - nodeId: 123
    path: /var/www/webroot/hw.txt
    body: Hello World!

{
  "writeFile": [
    {
      "nodeId": "123",
      "path": "/var/www/webroot/hw.txt",
      "body": "Hello World!"      
    }
  ]
}

If you don't know the Node ID or a container is not created yet, you can set a dynamic value, using special placeholders as follows.

writeFile:
  - nodeId: ${nodes.apache2[0].id}
    path: /var/www/webroot/hw.txt
    body: Hello World!

{
  "writeFile": [
    {
      "nodeId": "${nodes.apache2[0].id}",
      "path": "/var/www/webroot/hw.txt",
      "body": "Hello World!"
    }
  ]
}

For more information, visit the Placeholders documentation page.

All Containers By Group¶

The nodeGroup parameter is used to specify all containers within a specific layer.

The Jelastic Platform supports the following predefined nodeGroup values:

• bl

• cp

• cache

• sqldb

• nosqldb

• storage

• vds (for VPS)

• build

Actions for the specified nodeGroup are executed successively one by one. For Docker containers the nodeGroup value is not predefined, therefore, you can state it to any value above or your custom one.

All Containers By Type¶

The nodeType parameter is used to specify all containers that are built upon the same software stacks.

Examples

Using the nodeType parameter while performing the writeFile action.

writeFile:
  nodeType: apache2
  path: /tmp/example.txt
  body: Hello World

{
  "writeFile": {
    "nodeType": "apache2",
    "path": "/tmp/example.txt",
    "body": "Hello World"
  }
} 

where:

• writeFile - action to write data to the file
• nodeType - parameter that specifies the node type
• path - parameter that specifies the path to the file
• body - data that is written to the file

Using the engine and nodeType parameters while creating a new environment.

type: install
name: install Tomcat7 node
engine: java7

nodes:
  nodeType: tomcat7

{
  "type": "install",
  "name": "install Tomcat7 node",
  "engine": "java7",
  "nodes": {
    "nodeType": "tomcat7"
  }
}

where:

• engine - parameter that specifies the engine version
• nodeType - parameter that specifies the node type

Selector Types¶

There are three alternative approaches, provided to specify a target container in a manifest:

• specifying a target container within a name of an action (node selectors)

Through the following example, a new file is created in the compute layer ([cp]) and a new directory is created in the compute ([cp]) and balancer ([bl]) layers, and container with the Node ID 123. Actions for the specified containers are executed in the declared order.

- createfile [cp]:
    path: /tmp/test.txt

- createDirectory [cp,bl,123]:
    path: /tmp/test

[
  {
    "createFile [cp]": {
      "path": "/tmp/test.txt"
    }
  },
  {
    "createDirectory [cp,bl,123]": {
      "path": "/tmp/test"
    }
  }
]

A defined action in manifest could be executed in all nodes of all layers within an environment where JPS is executed. For example:

type: update
name: cmd in all nodes
onInstall:
  cmd [*]: echo hello world!

{
  "type": "update",
  "name": "cmd in all nodes",
  "onInstall": {
    "cmd [*]": "echo hello world!"
  }
}

There is a console log screen which displays that cmd action has been executed in all nodes by unique identifier one by one:

• specifying a target container next to the performed action

Through the following example, the createFile and createDirectory actions are applied to the specified nodeGroup, namely the compute layer ([cp]).

- createFile:
    path: /tmp/test.txt
  createDirectory:
    path: /tmp/test
  nodeGroup: cp

[
  {
    "createFile": {
      "path": "/tmp/test.txt"
    },
    "createDirectory": {
      "path": "/tmp/test"
    },
    "nodeGroup": "cp"
  }
]

• specifying a target container as a parameter in the actions object

Learn more on this parameter within the Custom Actions documentation page.

NodeGroup Aliases¶

An existed nodes in environments can be targeted not only by their defined *nodeGroup*s and by aliases. That aliases could be defined in manifests like in example:

type: update
name: Alias for nodeGroup
nodeGroupAlias:
  cp: sqldb2
onInstall:
  log: ${nodes.sqldb2.id}

{
  "type": "update",
  "name": "Alias for nodeGroup",
  "nodeGroupAlias": {
    "cp": "sqldb2"
  },
  "onInstall": {
    "log": "${nodes.sqldb2.id}"
  }
}

In the example above JPS add-on with type update could be applied on any existing environment. In this case all compute nodes with nodeGroup cp can be called by aliases (Nodes with nodeGroup sqldb2 are absent in environment). So the example result is displayed in the screen:

Supported Stacks¶

The supported software stacks are categorized in the table below with specified names and aliases that can be used within Cloud Scripting, as well as the links to the available tags.

nodeGroup	Supported nodeType Values (Aliases)	Supported Tags Link
bl	nginx-dockerized (nginx), varnish-dockerized (varnish), haproxy(haproxy2), apache-lb (apache-balancer), litespeedadc (litespeedadc2, litespeedadc3)	Load-Balancers
cp	tomcat (tomcat10, tomcat7, tomcat85, tomcat9), tomee-dockerized(tomee), glassfish (glassfish6, glassfish3, glassfish5), payara (payara5, payara3), jetty (jetty9, jetty10, jetty11), wildfly (wildfly21, wildfly22, wildfly23), springboot, apache (apache2), nginxphp-dockerized (nginxphp), apache-python (apache2-python), apache-ruby (apache2-ruby), nginxruby (nginx-ruby), nodejs, iis8, litespeedphp(litespeedphp5, litespeedphp6), lemp, llsmp, golang	Application Servers
sqldb, nosqldb	mysql (mysql5, mysql5-6), mariadb-dockerized (mariadb10), postgresql (postgres9, postgres10, postgres11, postgres12, postgres13), perconadb (percona5.5, percona5.6, percona5.7, percona8), mssql, mongodb-dockerized(mongodb), couchbase, redis (redis4, redis5, redis6)	Databases
vps, cache, build, proxysql, storage	centos-vps(centos7), ubuntu-vps(ubuntu16, ubuntu18, ubuntu20), memcached-dockerized(memcached), maven(maven3), proxysql, storage, windows2012	Additional Stacks

Engine versions

Stacks	Java	PHP	Ruby	Python	Nodejs	ii8	Go
engine	graalvm8 dragonwell8 java8 java11 openj98 openj911 openj916 openjdk7 openjdk8 openjdk11 openjdk14 openjdk15 openjdk16 openjdk17 adoptopenjdk8 adoptopenjdk11 adoptopenjdk16 correttojdk8 correttojdk11 correttojdk15 correttojdk16 libericajdk8 libericajdk11 libericajdk14 libericajdk15 libericajdk16 zulujdk7 zulujdk8 zulujdk11 zulujdk13 zulujdk14 zulujdk15 zulujdk16	php7.3 php7.4 php8.0	ruby2.5 ruby2.6 ruby2.7 ruby3.0	python3.6 python3.7 python3.8 python3.9	nodejs12-supervisor nodejs14-supervisor nodejs15-supervisor nodejs16-supervisor	dotnet3 dotnet5	go

Selecting Hardware Hosts¶

There is an ability in Jelastic PaaS to select the hardware for the user's application with the help of the multi zones approach. If a user is aware all of the labels assigned for the hardware hosts within the platform he can decide which hosts across all of the available regions can be used to install the user's environment.
Hardware host selection is performed by distribution parameter which defines the logic in the layer specifics, which consist of the following two options:

• zones - sets a filter for allowed zones (groups of hosts custom-defined by labels) in the “{name}: {value}” format, e.g. zones: [{provider: azure}, {provider: amazon}]

• mode - defines the behavior in case of the target zone unavailability

  • SOFT - the operation should proceed on the next zone/host defined by the multi zones algorithm (this option is used by default)

  • STRICT - the operation should be terminated with an error

For example, the distribution configured in the following package ensures nodes are created only on the hosts with the disk: ssd label.

name: "multi-zone"
type: install

nodes:
  nodeType: docker
  fixedCloudlets: 1
  flexibleCloudlets: 8
  image: jelastic/tomcat:latest
  count: 2
  distribution:
    mode: SOFT
    zones: 
    - disk: ssd

{
  "name": "multi-zone",
  "type": "install",
  "nodes": {
    "nodeType": "docker",
    "fixedCloudlets": 1,
    "flexibleCloudlets": 8,
    "image": "jelastic/tomcat:latest",
    "count": 2,
    "distribution": {
      "mode": "SOFT",
      "zones": [
        {
          "disk": "ssd"
        }
      ]
    }
  }
}

The zones parameter can be provided dynamically defining pair of label name and value via user interface.
For example:

name: "multi-zone"
type: install

settings:
  fields:
  - hideLabel: false
    type: string
    caption: Label name
    name: labelname
  - hideLabel: false
    type: string
    caption: Label value
    name: labelvalue

nodes:
  - nodeType: tomcat
    cloudlets: 6
    distribution:
      mode: SOFT
      zones: 
      - "${settings.labelname}": "${settings.labelvalue}"

      {
  "name": "multi-zone",
  "type": "install",
  "settings": {
    "fields": [
      {
        "hideLabel": false,
        "type": "string",
        "caption": "Label name",
        "name": "labelname"
      },
      {
        "hideLabel": false,
        "type": "string",
        "caption": "Label value",
        "name": "labelvalue"
      }
    ]
  },
  "nodes": [
    {
      "nodeType": "tomcat",
      "cloudlets": 6,
      "distribution": {
        "mode": "SOFT",
        "zones": [
          {
            "${settings.labelname}": "${settings.labelvalue}"
          }
        ]
      }
    }
  ]
}

What’s next?

• Explore the list of available Actions

• See the Events list the actions can be bound to

• Find out the list of Placeholders for automatic parameters fetching

• Read how to integrate your Custom Scripts

• Learn how to customize Visual Settings