Managing Parallels Automation for Cloud Infrastructure with API
Last time we talked about Cloud servers based on Parallels Automation for Cloud Infrastructure (PACI) - estimated prices and functionality. Including, briefly mentioned the presence of an API for managing servers. Today we will take a closer look at actions available through the API and examples of basic commands.
Unfortunately, the previous post was not very highly rated, but we received interesting questions, a lot of feedback, and a few bug reports from habrayers who joined the testing . We will try to cover the topics raised by you in this and the following posts.
As we have already said, the basis of our cloud is Parallels Automation for Cloud Infrastructure, a module of the Parallels Automation billing and provisioning system. The product comes with an excellent RESTful API. We will not cite the entire listing with API teams - it can be viewed in the official documentation . Better show some examples of this way of managing virtual machines and containers.
')
Working with cloud resources is done by sending API requests to the PACI management server. Answers come in XML format, the code is as readable and user-oriented as possible, rather than processed by a soulless parser, so all fields have intelligible names. In addition, you can easily automate the management, and the XML itself can be parsed without any problems, if you suddenly need it.
You need to contact the API at the address of the PACI managing server (we will reduce it to baseURL in the future):
If everything is more or less clear with the ip_address of the hostname and port, then the remaining two fields should focus. / paci / should always look like / paci /, and nothing else. And the version is specified in the v1.0 format (the numbers, respectively, may change in future versions of PACI).
Thus, the finished baseURL will look like this:
Further communication with the virtual server is carried out using the baseURL extension “to the right” - we simply set / and add additional parameters to the baseURL. / ve - access to the virtual server, and since the server usually has its own identifier, after / ve the server name / my-server-01 is appended.
The baseURL string with two additional parameters takes the form:
Which is equivalent to the line:
Some queries allow the definition of additional parameters. Often the parameters are optional, but very useful. All additional parameters are listed after the question mark.
An example of such a request is the following line:
With the syntax, we more or less figured out, now move on to the possibilities.
The possibilities are quite wide. Innocent features are available:
And more serious things:
As you already know, you can view the list of servers with the command
In response, a simple XML will come:
The description of the fields is in the documentation, but their names, in principle, speak for themselves.
You can stop or start a ready server by a simple request:
Instead of {ve-name} we insert the server name (the name field from the answer above), and after it we add a command to start or stop the server. Again, it’s easier than simple and there’s nothing to stop here.
Slightly more difficult is the creation of a new server from the console. This command has a lot of additional parameters, and restrictions on the use of certain resources will have to be remembered or peeped in the cheat sheet, since this is not a GUI with sliders. If the allowed parameters are exceeded, you will get error 406: “Subscription limit for VE number exceeded".
The team itself looks like this:
But then all the magic begins. In addition to the request itself, it is also necessary to generate an XML body in which all the parameters of the required server will be written:
If everything is correct, the answer will come about the successful creation of a new virtual machine:
The functionality embodied in this group of commands allows you to save great time and resources when deploying and scaling new systems.
The following examples imply that the images have already been prepared, and you have read their list with the team.
Suppose the server answered us that there is such an image:
Want to deploy another server out of it? Nothing is easier! Standard request:
in our case turns into
On this, in fact, work with creating a server from an image ends, but no one bothers to create a new server simply by cloning an existing one:
The list of available balancers is “ordered” in the same way as many other lists of available services, services and opportunities:
In response, a short XML comes with information about the load balances created:
It is easy to connect any existing server to the balancer already operating:
Yes, and disconnect no more difficult:
So far, only functions have fallen into this part of the API. One of them is the list of available for use “pre-installed” server OS:
List of presets for automatic backup:
GET request for a server list:
XML response:
PUT request to start / stop the server:
XML response:
POST request for server creation:
XML response:
DELETE request to delete the server
XML response:
Non-commercial testing of Cloud Servers will continue until February 1, 2013. The development of the service largely depends on your feedback. Join now !
For authors of the best reviews of the service, we have prepared prizes .
Cloud servers from Infobox
Official Documentation on Using APIs in Parallels Automation for Cloud Infrastructure (PDF)
Infobox blog
Unfortunately, the previous post was not very highly rated, but we received interesting questions, a lot of feedback, and a few bug reports from habrayers who joined the testing . We will try to cover the topics raised by you in this and the following posts.
As we have already said, the basis of our cloud is Parallels Automation for Cloud Infrastructure, a module of the Parallels Automation billing and provisioning system. The product comes with an excellent RESTful API. We will not cite the entire listing with API teams - it can be viewed in the official documentation . Better show some examples of this way of managing virtual machines and containers.
')
Syntax and punctuation
Working with cloud resources is done by sending API requests to the PACI management server. Answers come in XML format, the code is as readable and user-oriented as possible, rather than processed by a soulless parser, so all fields have intelligible names. In addition, you can easily automate the management, and the XML itself can be parsed without any problems, if you suddenly need it.
You need to contact the API at the address of the PACI managing server (we will reduce it to baseURL in the future):
https://{ip_address | hostname}:port/paci/version If everything is more or less clear with the ip_address of the hostname and port, then the remaining two fields should focus. / paci / should always look like / paci /, and nothing else. And the version is specified in the v1.0 format (the numbers, respectively, may change in future versions of PACI).
Thus, the finished baseURL will look like this:
https://109.120.*.*:4465/paci/v1.0 Further communication with the virtual server is carried out using the baseURL extension “to the right” - we simply set / and add additional parameters to the baseURL. / ve - access to the virtual server, and since the server usually has its own identifier, after / ve the server name / my-server-01 is appended.
The baseURL string with two additional parameters takes the form:
https://109.120.*.*:4465/paci/v1.0/ve/my-server-01 Which is equivalent to the line:
baseURL/ve/my-server-01 Some queries allow the definition of additional parameters. Often the parameters are optional, but very useful. All additional parameters are listed after the question mark.
An example of such a request is the following line:
GET baseURL/ve?subscription=1000001 With the syntax, we more or less figured out, now move on to the possibilities.
What actions are available through the API?
The possibilities are quite wide. Innocent features are available:
- listing and monitoring existing virtualok
- creating new and managing already created servers
- image deployment
- cloning existing systems
- setting available resources to the server
And more serious things:
- creating new images
- management of already created server images
- creating, configuring, and, of course, removing the load balancer
- connecting and disconnecting servers from the balancer
Server management
As you already know, you can view the list of servers with the command
GET baseURL/ve/ In response, a simple XML will come:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ve-list> <ve-info subscription-id="1000001" name="Habr1" state="CREATED" description="Habr Example 1"/> <ve-info subscription-id="1000002" name="Habr2" state="CREATED" description="Habr Example 2"/> </ve-list> The description of the fields is in the documentation, but their names, in principle, speak for themselves.
You can stop or start a ready server by a simple request:
PUT baseURL/ve/{ve-name}/start|stop Instead of {ve-name} we insert the server name (the name field from the answer above), and after it we add a command to start or stop the server. Again, it’s easier than simple and there’s nothing to stop here.
Slightly more difficult is the creation of a new server from the console. This command has a lot of additional parameters, and restrictions on the use of certain resources will have to be remembered or peeped in the cheat sheet, since this is not a GUI with sliders. If the allowed parameters are exceeded, you will get error 406: “Subscription limit for VE number exceeded".
The team itself looks like this:
POST baseURL/ve/ But then all the magic begins. In addition to the request itself, it is also necessary to generate an XML body in which all the parameters of the required server will be written:
<?xml version="1.0" encoding="UTF-8"?> <ve> <name>HabrExample1</name> <description>VE Linux 40</description> <subscription-id>1000001</subscription-id> <cpu number="1" power="1500"/> <ram-size>256</ram-size> <bandwidth>100</bandwidth> <no-of-public-ip>1</no-of-public-ip> <no-of-public-ipv6>0</no-of-public-ipv6> <ve-disk local="true" size="20"/> <platform> <template-info name="centos-6-x86_64"/> <os-info technology="CT" type="linux-free"/> </platform> <backup-schedule name="daily"/> <admin login="root" password="152eyyBHO"/> </ve> If everything is correct, the answer will come about the successful creation of a new virtual machine:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <pwd-response> <message>VE create initiated</message> <password>152eyyBHO</password> </pwd-response> Image Management
The functionality embodied in this group of commands allows you to save great time and resources when deploying and scaling new systems.
The following examples imply that the images have already been prepared, and you have read their list with the team.
GET baseURL/image Suppose the server answered us that there is such an image:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <image-list> <image-info image-of="HabrExample3" active="true" load-balancer="true" subscriptionid="100001" created="2012-11-11 19:19:19.84091+04" size="3" name="lbimage"/> </image-list> Want to deploy another server out of it? Nothing is easier! Standard request:
POST baseURL/ve/{subscription-id}/{ve-name}/from/{image-name} in our case turns into
POST baseURL/ve/1000003/Habr3/from/HabrExample3 On this, in fact, work with creating a server from an image ends, but no one bothers to create a new server simply by cloning an existing one:
POST baseURL/ve/{ve-name}/clone-to/{new-server-name} Balancer Management
The list of available balancers is “ordered” in the same way as many other lists of available services, services and opportunities:
GET baseURL/load-balancer In response, a short XML comes with information about the load balances created:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <lb-list> <load-balancer state="STARTED" subscription-id="1" name="LB1"/> <load-balancer state="STARTED" subscription-id="1" name="LB2"/> </lb-list> It is easy to connect any existing server to the balancer already operating:
POST baseURL/load-balancer/{lb-name}/{ve-name} Yes, and disconnect no more difficult:
DELETE baseURL/load-balancer/{lb-name}/{ve-name} Utilities
So far, only functions have fallen into this part of the API. One of them is the list of available for use “pre-installed” server OS:
GET baseURL/template/{name} List of presets for automatic backup:
GET baseURL/schedule PHP code examples
GET request for a server list:
<?php $mainStr = "http://109.120.166.3:4465/paci/v1.0/"; $queryStr = 've'; $url = $mainStr.$queryStr; $process = curl_init(); curl_setopt($process, CURLOPT_URL, $url); curl_setopt($process, CURLOPT_HEADER, 1); curl_setopt($process, CURLOPT_USERPWD, '<login>:<password>'); curl_setopt($process, CURLOPT_RETURNTRANSFER, TRUE); $head = curl_exec($process); curl_close($process); ?> XML response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ve-list> <ve-info subscription-id="1000001" name="web1" state="CREATED" description="Web server 1"/> <ve-info subscription-id="1000002" name="web2" state="CREATED" description="Web server 2"/> </ve-list> PUT request to start / stop the server:
<?php $mainStr = "http://109.120.166.3:4465/paci/v1.0/"; $queryStr = 've/<ve-name>/<start | stop>'; $url = $mainStr.$queryStr; $process = curl_init(); curl_setopt($process, CURLOPT_URL, $url); curl_setopt($process, CURLOPT_HTTPHEADER, array('Content-Type: application/xml')); curl_setopt($process, CURLOPT_PUT, 1); curl_setopt($process, CURLOPT_HEADER, 1); curl_setopt($process, CURLOPT_USERPWD, '<login>:<password>'); curl_setopt($process, CURLOPT_RETURNTRANSFER, TRUE); $head = curl_exec($process); curl_close($process); ?> XML response:
* VE START initiated POST request for server creation:
<?php $mainStr = "http://109.120.166.3:4465/paci/v1.0/"; $queryStr = 've'; $serverInfo = '<?xml version="1.0" encoding="UTF-8"?> <ve> <name>Web40</name> <description>VE Linux 40</description> <subscription-id>1000001</subscription-id> <cpu number="2" power="1600"/> <ram-size>512</ram-size> <bandwidth>100</bandwidth> <no-of-public-ip>2</no-of-public-ip> <no-of-public-ipv6>2</no-of-public-ipv6> <ve-disk local="true" size="3"/> <platform> <template-info name="centos-6-x86_64"/> <os-info technology="CT" type="linux-free"/> </platform> <backup-schedule name="daily"/> <admin login="root" password="qwwqq45"/> </ve> '; $url = $mainStr.$queryStr; $process = curl_init(); curl_setopt($process, CURLOPT_URL, $url); curl_setopt($process, CURLOPT_HTTPHEADER, array('Content-Type: application/xml')); curl_setopt($process, CURLOPT_POST, 1); curl_setopt($process, CURLOPT_HEADER, 1); curl_setopt($process, CURLOPT_USERPWD, '<login>:<password>'); curl_setopt($process, CURLOPT_RETURNTRANSFER, TRUE); curl_setopt($process, CURLOPT_POSTFIELDS, $serverInfo); $head = curl_exec($process); curl_close($process); ?> XML response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <pwd-response> <message>VE create initiated</message> <password>152eyyBHO</password> </pwd-response> DELETE request to delete the server
<?php $mainStr = "http://109.120.166.3:4465/paci/v1.0/"; $queryStr = 've/<ve-name>'; $url = $mainStr.$queryStr; $process = curl_init(); curl_setopt($process, CURLOPT_URL, $url); curl_setopt($process, CURLOPT_CUSTOMREQUEST, "DELETE"); curl_setopt($process, CURLOPT_HEADER, 1); curl_setopt($process, CURLOPT_USERPWD, '<login>:<password>'); curl_setopt($process, CURLOPT_RETURNTRANSFER, TRUE); $head = curl_exec($process); curl_close($process); ?> XML response:
* VE DELETE initiated Non-commercial testing of Cloud Servers will continue until February 1, 2013. The development of the service largely depends on your feedback. Join now !
For authors of the best reviews of the service, we have prepared prizes .
Our previous posts on the topic
Cloud servers from Infobox
Links to materials mentioned
Official Documentation on Using APIs in Parallels Automation for Cloud Infrastructure (PDF)
Infobox blog
Source: https://habr.com/ru/post/160667/
All Articles