CloudControl is a cloud platform much like Heroku. Creating a cloudControl add-on is very similar to creating a Heroku add-on but there are some differences. This article explains those differences.
Introduction
GroupDocs’ add-on for cloudControl is a web tool that can be installed on any web application to provide GroupDocs functionality:
- Create a new GroupDocs user with a free plan and get the user ID and private key for this user. This is done automatically when the add-on is installed.
- The user can change the payment plan using the add-on’s change plan function.
- Access to any methods from the GroupDocs API using the client ID and private key (which you can get from the add-on). We created this example which shows how to use add-on and GroupDocs Python SDK for some basic actions.
Requirements
- Kensa tool
- cloudControl tool
- Python 2.7
- cloudControl aplication
Creating the Add-on
The process for creating a cloudControl add-on is the same as for creating a Heroku add-on, but, as I said earlier, with a couple of differences. We will not go into how to create the add-on because Heroku has a lot of documentation for this and you decide how you build it. I will only show what exactly the differences are. Lets assume that we already have a cool Heroku add-on and we want to rebuild it for cloudControl:
- Install the Kensa and cloudControl tools. They help you manage add-on and cloudControl applications. Find out how to install the cloudControl tool.
- After installing the tools, change the addon-manifest.json file. This contains all the basics information for add-on installation, such as which environment variables will be created and from where to download and install add-on files.
- Before you upload the edited addon-manifest.json file, set the environment variable ADDONS_URL=https://api.cloudcontrol.com:.
- Specify the production server. Heroku required you to specify the production server, and then constructed the URL used to provision your add-on by appending “/heroku/resources” to it. Now, provide a hash instead of a string and change “/heroku/resources” to “/cloudcontrol/resources”.
- Add “sso_salt”:“PASSWORD” and “production”: {“base_url”:“https://your.add-on.com/cloudcontrol/resources", “sso_url”:“https://your.add-on.com/cloudcontrol/resources"}.
- Change “heroku_id” to “cloudcontrol_id” in the add-on files.
- When the changes have been made, test the add-on with Kensa tests by running it in the console: kensa test provision and kensa deprovision test. [caption id=“attachment_3488” align=“alignnone” width=“600” caption=“Kensa tests”]
- If the tests pass, push addon-manifest.json to cloudControl with kensa push -f addon-manifest.json. [caption id=“attachment_3489” align=“alignnone” width=“600” caption=“Kensa push”]
- Install the add-on to your cloudControl application: cctrlapp YOUR_APP_NAME addon.add YOUR_ADDON_NAME.PLANE
Now we have published a cloudControl add-on and installed it. So far, so good. How do we get the environment variables that the add-on creates? Let’s find out.
How to Get Environment Variables
In Heroku, this is easy. For example, in Python we can do this with the line os.environ[‘VARIABLE NAME’]. If you try this in cloudControl, you get only a few basics Python properties and not your add-on variables. In cloudControl, all environment variables created by the add-on are written to the json file which we can get by usingCRED_FILE. This is the name of a system property that contains the path to the JSON file with environment variables. To get our data, all we need is to read this JSON file and decode the JSON string. In Python, we can do this with this code:
credentialsFile = os.getenv('CRED\_FILE')
credentials = open(credentialsFile)
data = json.load(credentials)
credentials.close()
clientId = data\['GROUPDOCS'\]\['GROUPDOCS\_CID'\]
privateKey = data\['GROUPDOCS'\]\['GROUPDOCS\_PKEY'\]
That’s how we get the client ID and private key of the GroupDocs add-on user. And that’s all. You now know what the difference is between Heroku and cloudControl add-ons.