One of the benefits that a Managed Dedicated Load Balancing cluster provides is the ability to interact with it programmatically via a SOAP compliant API.
So for example, you could write a script that would both create a server utilizing the StormOnDemand API, and then make an API call to your Managed Dedicated Load Balancing cluster to add it as a node.
If you've utilized the StormOnDemand API, there will be a slight difference in regards to how you interface with the Stingray API. For a refresher on the Storm API with PHP, take a look here (and updated PHP API class here).
PLEASE BE AWARE: Any user belonging to a permission group with API access HAS FULL ADMIN ACCESS TO THE SERVER. Though they may not have permissions to make changes in the web interface, they still have the ability to create and assign a user to the admin group, which will have such access.
In order to work with the Stingray API, you need a few things:
- A Managed Dedicated Load Balancing cluster
- Appropriate creds for the cluster you desire to work with (see above)
- The language of your choice (mine is PHP, because all the cool kids use PHP)
- Knowledge of how to make SOAP calls using said language
- WSDL Files for the Stingray cluster you're working with
- API Documentation (unless you're a masochist, then just look at the WSDL files)
You can get both the Documentation and WSDL files from the HELP link at the top of the web interface (which, by the way, is defaulted to port 9090). Just click contents, and then choose SOAP API. Unzip the WSDL zip file wherever you plan on coding. It will unzip into a subdirectory called.. wsdl. Creative, huh? Anyways...
Now that you have everything you need, let's get on to the coding. One thing that you will notice is that with WSDL, you specify the methods through the SOAP client object you create in whatever language you use. This is in contrast to the Storm API, where the method is specified via a URI. You'll see what I'm talking about in the example below, which I will also dissect for your analytical pleasure.
The following code will create a new virtual server:
|PHP |||copy code |||?|
$params['location'] = 'https://yourstingraycluster:9090/soap';
$params['login'] = 'username';
$params['password'] = 'password';
$wash = new SoapClient("./wsdl/VirtualServer.wsdl", $params);
$vs_names = 'new-virtserver';
$vs_info['port'] = '80';
$vs_info['protocol'] = 'http';
$vs_info['default_pool'] = 'test-pool';
$return = $wash->addVirtualServer($vs_names, $vs_info);
// Enable the virtserv
$vs_enabled = TRUE;
Ok, so the $params array is what we're using during the instantiation of the SOAP client object. Technically, I think the WSDL file could provide the location information, but in my case, it wasn't, so I had to manually provide it.
Then of course, I'm providing the creds. The other part of the instantiation is the WSDL file you want to use. The Stingray API breaks it down pretty logically (you'll see in the docs). This WSDL file is what provides the methods for Virtual Server related API functionality.
Also note that the method is called as a part of the SOAP client object, not a URI, which, as I mentioned earlier, is the case with the Storm API.
The $vs_names and $vs_info arrays are the information we're providing when we actually call the method. The structure for data supplied is pretty well documented with the method in the Stingray API docs.
The last part just activates the Virtual Server created, since it doesn't get enabled automatically upon creation. Also note that in this case, you'll need to have a pool already created as well.
As you can see, it's pretty simple to work with the Stingray API. If you have any questions, don't hesitate to let me know in the comments, or feel free to call in as well.Tweet