SAP HANA Cloud: Automating your deployments

Why command line?

Because you can automate the cloud operations using shell scripts or continuous integration servers (Jenkins/Hudson for instance).

Additionally the command line interface (CLI) allows much faster development cycles, and allows us to accumulate the customer feedback than some visual tool. This is partially due to the lack of complicated UI design reuired to get a "native" IDE look and feel.

Application context root

You may have noticed that we used "ROOT.war" as archive name in my first blog. The reason for this was that I wanted to use the "/" context root and access the application without context path.

The name of the application determines the context path as mentioned in the official documentation.

Scaling your application

In SAP HANA Cloud you can scale your application:

• vertically - adding more resources to a single application node
• horizontally - adding more application nodes

To scale your application vertically you just need to specify the compute unit you'd like to use. HANA Cloud offers several compute unit sizes that increase in both CPU and memory.

Horizontal scaling is possible as well by deploying with two additional parameters:

• minimum number of nodes that can handle the usual load of requests to your application
• maximum number of nodes that you can afford to pay for :)

The horizontal scalling can be done for instance with the following deploy parameters:

neo deploy mytemplate.properties --minimum-processes 2 --maximum-processes 4

The above command line means that I want to have at least 2 application processes and my application can handle unlimited load with 4 processes (or most probably that I can afford to pay for just 4 compute units).

Please note that the trial landscape does not support neither vertical nor horizontal scaling as mentioned in the account types description.

Start / Stop / Restart

The start command actually provides you with an application process from the deployed binaries. You can repeat the start as many times as the number of your compute units. In other words - if you have bought 4 units you cannot start 5 application processes.

The default behaviour is that the start is asynchronous. This allows you to quickly start as many processes as you want without waiting for them to finish.

However if you want to be sure that the processes are started you can:

• poll for their status (status command)
• use the --synchronous flag

To stop the whole application use the stop command. At present you cannot stop a single application process but this is in the pipeline.

The restart command is a convinience shortcut and actually does the same as stop with --synchronous flag and subsequent start. The start can be synchronous or not (depends on the parameters you used).

Managing multiple applications

Probably you already know well the properties file you can use with all NEO CLI commands. As you noticed this properties file serves two purposes:

• a placeholder for your settings
• automation helper

What you probably missed is that the file can be used as well to manage:

• multiple applications
• multiple command parameters

Let's assume that the your file contains:

application = test

If you use neo start with this file you'll start one application process for the test application. However what if you used:

neo start myfile.properties --application demo

The result from the above command is that the demo application would be started. To allow this the CLI parameters take precedence over the properties file values.

The properties file can also hold parameters that are not needed by the currently executed command, but are meant to be used for subsequent commands. 

In this way we can use the same file for most of our needs and amend the parameters on the command line only in some rare cases.

Undeploy

Undeploy command does what its name says (I hope) - it simply deletes the binaries you uploaded with deploy command.

To successfully execute the command however you have to first stop your application. This is a way to protect not only ourselves from requests such as "I deleted my application and now I cannot start it any-more", but our customers as well from making such stupid mistakes.

Passwords

The password required for all of the above commands:

• cannot be stored in the template properties file
• can be passed as CLI parameter

We currently accept plain-text password, so we don't want to force users to store it in properties file. This is the shortest road to email the password to someone accidentally.

In the same time to enable automation we accept the --password parameter. Since this is a CLI parameter this has an important implication - the password requires some pre-processing if it contains special characters depending on the shell or command interpreter used.  

For example:

• the ! character has to be escaped as ^! in Windows
• if you have space in the password (pass word) you have to quote it ("pass word")

We redirect users to "your console/shell user guide on how to use special characters as command line arguments", but with Windows this seems to be a nightmare since there is almost no official resources, rather than for the retired Windows XP.

Proxy

The proxy settings can also be a pain so my advice here is to use the console to set the proxy. Setting proxy globally for the system, using a fancy UI, almost certainly means that the console is being left out of scope by the developers of this UI :)

You can check our minimal effort to explain how to use proxy with NEO CLI. Have in mind that the continuous integration servers, VCS tools or other executables may also require proxy set for the user you are running them with.