Jelastic CLI: Automatic Application Lifecycle Management via API

By September 6, 2016 HowTo No Comments
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Today we are glad to present another guide of Jelastic CLI series, continuing to observe capabilities of this powerful tool. In case you’ve just came around, we have already learnt how to set up Jelastic CLI for work and have considered several basic use cases for it.

And this time we are going to focus on CLI methods, devoted to smart application lifecycle organization – a commonly used approach to speed up development, avoid downtimes during updates and, in general, to deliver a high-quality product. Usually, this is achieved through building a 3-stages pipe like development > testing > production.


So below we’ll see how Jelastic CLI can help you to automate processes of conducting your project through this flow with a few related operations examples, handled right via your terminal without the necessity to connect to your Jelastic dashboard through browser.

To be more precise, we’ll consider such specific actions as environment cloning (which can be used for creating multiple environment copies, dedicated to different development stages), environment migration between platform regions (to move it across available hardware with different parameters) and external IP addresses swap (which can help to easily exchange production app versions).

So, without further hesitation, let’s move directly to the new methods examination.

Environment Cloning

The environment cloning feature can be easily called through Jelastic CLI to help you in creation of new branches/multiple versions of your application. So, to duplicate your environment, just execute the next line:

~/jelastic/environment/control/cloneenv --appid {src_env} --domain {new_env}


  • {src_env} – name of the environment you’d like to clone
  • {new_env} – name for your the environment copy


In a few minutes, you’ll get a new environment within your account, that is similar to the source one.

Environment Migration

Sometimes, it may be required to move your application to another environment region with better conditions and\or location or, for example, to distribute several cloned environment copies among different hardware sets to achieve increased availability. To perform this remotely, you’ll need to execute the corresponding migrate CLI method via your terminal. So, let’s consider it in more details.

1.To start with, you have to get the list of regions which are available at a Platform.

For that, the getregions command should be used, with the appropriate search filter being applied in order to shorten the output and simplify the perception:

~/jelastic/environment/control/getregions | sed -rne '/(uniqueName|isEnabled|displayName)/{/Name/,/isEnabled/p}'


You’ll see the list of environment regions, available for your account (i.e. where “isEnabled” states in true), with their names at dashboard (displayName) and unique identifiers (uniqueName). Here, the last parameter is the one you need to remember.

Note: The first list level displays global info on data centers, whilst the regions’ parameters you actually require to retrieve for further operations are shown a level below (such lines are shifted to the right).

To make it more clear, the appropriate uniqueName values are circled in the image above.

2. It is also a good practice to check the migration possibility before running the operation itself. Use the appropriate simple CheckMigrationPossibility CLI method for this:

~/jelastic/environment/control/checkmigrationpossibility --envName {env_name} --hardwareNodeGroup {region_id}


  • {env_name} – name of the environment you’d like to relocate
  • {region_id} – unique identifier of the target environment region from the previous step


3. Now you have all the required data to call the migration procedure:

~/jelastic/environment/control/migrate --envName {env_name} --hardwareNodeGroup {region_id} --isOnline {true/false}

The only new parameter here is the isOnline one, which can be set as {true/false} for using the live or offline migration mode correspondingly.


Soon (the exact time of migration may vary depending on your environment content) the operation will be finished and your application will be successfully relocated.

Public IPs (External Addresses) Swap

The operation of Public IPs swap can come in handy for routing of the incoming requests to the required environment or application. This possibility may be especially useful whilst, for example, switching testing and production environments.

The appropriate CLI method gives you the ability to exchange external IP addresses between two nodes or, in case one of them doesn’t have the Public IP attached, just to move an address from one instance to another. Herewith, this can be handled for any nodes within the confines of a single user account, i.e. even for the ones, that belong to different environments or run different services. As usual, the operation requires just a single line of code for being executed:

~/jelastic/environment/control/swapextips --envName {env_name} --srcnodeid {source_node_id} --dstnodeid {target_node_id}

Here, the following parameters should be specified:

  • {env_name} – name of the environment, where the transferred external IP is currently attached
  • {source_node_id} – identifier of the node from the stated environment, which IP should be swapped\moved
  • {target_node_id} – ID of the target node (can belong to any environment of an account)



  • this process may cause a short-term unavailability of the corresponding Public IP address(es) (up to 10 seconds)
  • nodes of the following types will be automatically restarted for the necessary changes to be applied: GlassFish, Apache-PHP, Apache-Ruby, NGINX-PHP, NGINX-Ruby. This is required for forcing the corresponding services to start listening on new addresses
  • if operating with VPS or Docker containers, you need to handle the necessity of the appropriate instance restart by yourself (i.e. to perform it manually if needed), as it depends on a particular service, running inside. In such a way, you can be sure that the operation of IPs swap won’t result in the unrequired downtime of your application.

In a few minutes the operation will be finished and your IPs will be either exchanged or moved (like in the image above) between nodes within your account, whilst the details on the newly applied parameters will be provided in the response output.


Summing this up, the described methods represent a good basis to start managing your application lifecycle through Jelastic CLI during various development stages (e.g. development > testing > production). Try it right now – create your account at one of our partner’s Platforms for a two-weeks trial. And in case you’ll need any assistance while working with Jelastic CLI, we are always here to assist you within comments below or at Stackoverflow.

Meanwhile, subscribe to our blog to not miss even more useful guides (including the upcoming article of Jelastic CLI serie, dedicated to Docker containers management) and Jelastic most significant news.

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

Leave a Reply

Subscribe to get the latest updates