Jelastic CLI. Basics of the Fully Functional App Control via API

    Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

    Not so far ago, we’ve revealed what the Jelastic CLI is and how to get started with this comprehensive tool. Today we are going to push deeper, discovering some of its possibilities and getting to know how to take an advantage of the full-functional remote Cloud management it provides.

    CLI methods’ integration within your projects can help to speed up and simplify performing of some of common operations through the corresponding actions’ automation. This can be accomplished by means of wrapping separate procedures into easily executable scripts, where the majority of standard management flows can be covered. Consequently, such templates could be combined into the much more advanced and complex scenarios, aimed to handle almost any procedure without manual interaction. As a result, this can help to save some of your personal time or a bit of your company human resources, allowing to use them elsewhere with a greater outcome.

    So, let’s consider some common usecases, where Jelastic CLI can be effectively used, starting with a new environment creation and discovering some subsequent simple operations for its management – like start/stop actions, projects’ deployment via VCS and performing basic topology changes (with the example of servers’ scaling).

    Create an Environment

    To start with, let’s find out how to create a new environment, since it’s the most obvious task as an obligatory step for any project hosting.

    Tip: Automation of this process with CLI can come in handy for the variety of different solutions, including handling of complex DevOps scenarios.

    1. At the beginning, we’ll consider a few variants this operation can be implemented through.

    • The most straightforward way to create a new environment with CLI is to declare the required parameters manually via the appropriate command. Simply execute the following createenvironment method with your custom parameters specified:
    ~/jelastic/environment/control/createenvironment --env '{"shortdomain" : "{env_name}", "engine" :
    "{engine_type}"}' --nodes '[{"nodeType" : "{node_type}", "fixedCloudlets" : 
    {cloudlets_number}, "flexibleCloudlets" : {cloudlets_number}}]'

    In the example above, the highlighted placeholders should be substituted with the following data:

    • {env_name} – name for the new environment
    • {engine_type} – engine for being used in this environment
    • {node_type} – stack type identifier, according to the list
    • {cloudlets_number} – number of fixed and flexible cloudlets to allocate for a particular node
    Tip: More detailed information on available parameters can be found within the corresponding API method description and at the CreateEnvironment API overview.

    Pay attention that in the image above CLI responded with the “result” property equal to 0 – this means that the performed operation has passed successfully and without errors (this is applicable for all of the commands you run).

    • The second option, supported by Jelastic CLI, is to use JSON file with all of your environments’ parameters stated inside. Created once, such file can be used multiple times, which is much faster and convenient than defining everything manually each time.

    For example, let’s create a simple JSON with the next environment topology:

    env: {"shortdomain" : "{env_name}", "engine" : "{engine_type}"},
    nodes: [{"nodeType" : "{node_type}", "fixedCloudlets" : {cloudlets_number}, "flexibleCloudlets" : 

    Just don’t forget to change the highlighted parameters in the same way it was described within the previous step.

    Now, all you need to do in order to create an environment is to use the createenvironment method with just a single –myparams parameter, that includes path to your .json file as a value (or just its name if it’s located within the user’s home folder):

    ~/jelastic/environment/control/createenvironment --myparams {path_to_file} 

    In addition, you can redefine or add some of the settings (namely – shortdomain, region and displayName) to the env section of your configuration file, by stating them inside square brackets within this method parameters. For example, with the optional –shortdomain string (like in the image below) you can override the same-named setting from JSON, so the environment will be created with the same topology but under a different name.image00 2. Creation of a Docker-based environment is almost similar to the above-described methods, but includes a few specific parameters. So, in order to get a Docker container using Jelastic CLI, you need to execute the following line:

    ~/jelastic/environment/control/createenvironment --env '{"shortdomain" : "{env_name}"}' --nodes 
    '[{"nodeType" : "docker", "fixedCloudlets" : {cloudlets_number}, "flexibleCloudlets" : 
    {cloudlets_number}, "docker" : {"image" : "{image_name}"}}]'

    According to the command above, the nodeType parameter needs to be stated in docker and the newly added {image_name} placeholder should be replaced with the address of Docker template you’d like to deploy (in the format).


    • in case a template is located within the Registry Hub, the registry hostname can be skipped
    • optionally, you can add the version tag after the “:” separator at the end of image address
    • in order to get authenticated at a private registry, the additional registry parameter should be declared, with url to it and the appropriate credentials (i.e. password and user) stated as values.
    Note: The full list of the special Docker parameters can be found at the appropriate document.

     In a short while, your Docker-based environment will be created, being ready to work.

    Environment Start/Stop

    Among the most common operations for environment management, the start and stop ones can be denoted. Wise usage of these methods can help to significantly cut your spends, especially what’s regarding handling of development and testing environments (for example, you can stop them for the nighttime, when you are sleeping, and start again at the morning to continue developing).

    1. In order to stop an environment that is temporarily non-required, execute the following command (where the highlighted {env_name} placeholder should be substituted with the corresponding environment name):

    ~/jelastic/environment/control/stopenv --envName {env_name}

    2. Later on, you can start your environment with a similarstartenv method and make it operable again:

    ~/jelastic/environment/control/startenv --envName {env_name}

    Yes, the environment management is that simple!

    VCS Project Deployment

    Deployment via VCS is a rather popular and convenient way for projects’ integration into the Cloud, as it simplifies operating with app’s sources and allows to easily update its version (either manually or automatically with a certain interval). And the variety of options, available for the VCS deployment management via CLI, gives you the full control on your app.

    1. For example, in order to add VCS project to the environment, the following command should be run:

    ~/jelastic/environment/vcs/createproject --envName {env_name} --type {type} --project {project}
    --url {url} [--branch {branch}] --autoupdate {true/false} [--interval {interval}]
    --autoResolveConflict {true/false} --zdt {true/false}

    Here, the list of parameters can be divided into the following groups:

    • main configurations
      • {env_name}– name of your environment
      • {type} – VCS type, either git or svn; in the first case, the additional {branch} parameter is needed, to point to the corresponding projects’ version
      • {project} – context name for a new project
      • {url} – link to the appropriate repository
    • additional options (their activation is defined with the {true/false} values)
      • autoupdate- enables regular autoupdate of the deployed project; if activated, requires the additional {interval} parameter for setting the frequency of redeployments. Please also take into account the details on auto-deploy for multiple containers.
      • autoResolveConflict – switches on the corresponding same-named option
      • zdt – allows to activate ZDT deployment for PHP projects.
    Note: In case you need to connect to a private repository, the additional authentication parameters [–login {login}] [–password {password}] [–keyId {keyId}] should be added to the main command.
    Here, you need to obligatory state the {login} option (to specify your VCS account login) and append one of the following settings depending on the desired (password or SSH key) access type:

    • {password} – the corresponding VCS account password
    • {keyId} – name of the private SSH key you’ve specified while its addition to the dashboard; this allows to establish a secure connection to the repo with the paired public SSH key attached

    After executing, you’ll be shown a brief info on the created project within the received response.

    Tip: The above described command corresponds to the Add project dashboard frame’s functionality, so in case you return to the GUI Jelastic panel and click the Edit button next to the newly appeared project, you’ll see all the appropriate options applied within its settings. If the project is not displayed, just refresh the page with your dashboard.

    2. The next step is running the update command in order to apply these settings and, actually, deploy your project.

    ~/jelastic/environment/vcs/update  --envName {env_name} --project {project}

    Set the same parameters’ values like in the previous step.

    Subsequently, this command can be also used for manual redeployment of your app according to the updated VCS sources.

    3. In case you need to edit project settings (e.g. to switch the version branch), the editproject method should be executed:

    ~/jelastic/environment/vcs/editproject --envName {env_name} --type {type} --oldproject
    {oldproject} --newproject {newproject} --url {url} [--branch {branch}] --autoupdate {true/false}
    [--interval {interval}] --autoResolveConflict {true/false} --zdt {true/false}

    The majority of parameters are already familiar for you, except the following ones that have substituted the previously used {project} property:

    • {oldproject} – name of the project (i.e. context) that should be changed
    • {newproject} – new context for the project (it’s obligatory for specifying; however, could be stated the same as {oldproject})

    The rest of options’ values can be changed based on your needs.

    Note: This command just updates the corresponding project’s settings, whilst for their appliance the update method should be called (we’ve considered it in the 2nd step).

    Server Scaling

    Ok, for now you already have a created environment with the application deployed to it. However, subsequently it may be required to change environment topology, for example – in order to scale a particular server or the whole environment layer (using the vertical and/or horizontal scaling respectively) due to the increased incoming load. This may be accomplished with the corresponding changetopology method:

    ~/jelastic/environment/control/changetopology --envName {env_name} 
    --env '{"engine":"{engine_type}"}' 
    --nodes [‘{"nodeType":"{node_type}","count":{nodes_number},"fixedCloudlets":{cloudlets_number},"flexibleCloudlets":{cloudlets_

    The whole set of parameters is the same as for the 
    createenvironment method, except of the –envName {env_name} – here it is used to point to the already existing environment, that should be adjusted.

    As for the rest of options, here we use the following ones:

    • {engine_type} – type of engine that is already used in environment (an obligatory string)
    • {node_type} – stack type identifier, according to the list
    • {nodes_number} – number of nodes (applies horizontal scaling)
    • {cloudlets_number} – number of fixed and/or flexible cloudlets to be allocated for the specified node (applies vertical scaling)
    Note: For the proper work of the horizontally scaled application server, do not miss to add a load balancing node to your environment topology beforehand.


    As you might notice, even such a small number of CLI methods we’ve described in this article, can be combined into some simple workflow, like:

    create environment >  deploy your application > adjust topology due to the incoming load

    Command line realization of these operations provides a broad range of opportunities for automation of the mentioned or any other flow – try it by your own within one of our partners’ Platforms completely for free (and remember that we are always ready to provide assistance at Stackoverflow if you face any issues or have some questions). Meanwhile, we’ll prepare another guidance, revealing how to facilitate your project’s lifecycle management at different stages of its development with Jelastic CLI – so stay tuned for the upcoming post of the CLI series at our blog 🙂

    Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

    Leave a Reply

    Your email address will not be published.