Thanks for your feedback!

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.

Note

If you state a custom nodeGroup value for Docker containers, the corresponding container is placed to the Extra layer. Subsequently, this nodeGroup value can be used within the same-named actions field to point to the particular Extra layer. dockerextra

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:

wildcard-mask

  • 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.

Note

Node selectors have higher priority than containers specified next to the action, but lower than parameters set in the actions object.
If you specify all three parameters (nodeId, nodeGroup, and nodeType), actions for indicated containers are executed in the following order: nodeId -> nodeGroup -> nodeType.

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: nodeGroup-alias

Note

nodeGroupAlias option works only within current JPS manifest.

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 and Aliases Supported Tags Link
bl nginx, varnish, haproxy, apache-lb Load-Balancers
cp tomcat7, tomcat8, tomee, glassfish, glassfish3, glassfish4, jetty, jetty6, jetty8, jetty9, smartfox-server, powerdns, railo4, wildfly, springboot, apache2, nginxphp, apache2-python, apache2-ruby, nginx-ruby, nodejs, iis8 Application Servers
sqldb, nosqldb mysql, mysql5, mysql5-6, mariadb, mariadb10, postgres9, postgresql, percona, mssql, mongodb, mongodb2, couchdb, redis, redis3, redis4, cassandra, cassandra2, cassandra3, neo4j, neo4j2-1, neo4j3, orientDB, orientDB2 Databases
vps, cache, build, proxysql, storage centos6, centos7, ubuntu16-04, memcached, maven3, proxysql, storage, windows2008, windows2012 Additional Stacks

Note

In case the root privileges are required within the certified template, it should be created as custom docker via image parameter. If so, take into account that some functionality/automation won’t be available such as Custom SSL, Managed Firewall, etc. To create custom docker follow the Supported Tags Link column to get the proper name of certified Jelastic docker images.

Engine versions

Stacks Java PHP Ruby Python Nodejs ii8
engine java6
java7
java8
jdk-9
jdk-10
jdk-1.8.0_144
jdk-1.8.0_152
php5.3
php5.4
php5.5
php5.6
php7
php7.1.13
php7.1.7
php7.2.1
ruby1.9
ruby2.0
ruby2.1
ruby2.2
ruby2.3
ruby2.4.1
python2.7
python3.3
python3.4
python3.5
nodejs6.11.5
nodejs6.12.3
nodejs8.9.0
nodejs8.9.4
nodejs9.0.0
nodejs9.4.0
.NET 4

Note

The list of supported software stacks can vary depending on your Jelastic Platform version - it can be checked at your dashboard.

What’s next?

v: 1.7.5