What happened so far
In the last installment of this series we successfully deployed our demo app to the SUSE Cloud Application Platform Developer Sandbox.
Where should the application state be stored?
According to the point IV. of the Twelve-Factor App manifest we should treat backing services as attached resources. In our target environment, this is easy due to the fact SUSE Cloud Application Platform provides first-class tools to manage things like databases as resources.
We are going to build on the same example we used in the last blog post, but Cassperli has learned a new feature in the meantime. In its latest version it knows if it’s being deployed on CloudFoundry. If it is on Cloud Foundry and it also discovers a MongoDB database through the cfenv subsystem it will use the database to store a simple web page hit counter reminiscent of the page counters from times long gone.
How Cloudfoundry makes services accessible to applications
As part of the cfenv subsytem Cloud Foundry will set some VCAP_* environment variables that a Cloud Foundry native application may use to figure out if it is running on Cloudfoundry as well as to discover information regarding the services that have been bound to the app.
In the following example the existence of the VCAP_APPLICATION environment variable will help us figure out if we are running on Cloud Foundry and the VCAP_SERVICES environment variable will tell us what services are available to use.
These environment variables follow some simple rules and you can assume that the will follow the same basic structure on all major Cloud Foundry distros.
For most programming environments there are libraries that help you parse the variables in a consistent manner:
Using these helper libraries adds a programming environment-specific interface to the cfenv subsystem. Such libraries also isolate you from changes to the underlying cfenv spec.
Creating the backing store
You can create the MongoDB database through the web frontend of the SUSE Cloud Application Platform.
After logging into the sandbox you can create a service.
First you will navigate to “Services” in the application you deployed in the previous post.
Click the + button to create a marketplace service.
Choose the “mongodb” service and click “Next”.
Select the service plan needed by your application. In our case, we can use any recent MongoDB version that is available.
Since we started from the “Services” page on an application the app to bind to is already specified.
Call the service instance “mongodb” to the automatic configuration detection in Caasperli can discover the instance.
Wait for the service to be created and verify that it is bound to the app by looking at the service count on the application overview.
Deploying a new and improved Caasperli that uses the backing store
Next, we will update Caasperli to a version that supports using MongoDB and discovering a backing service on cloud foundry. Click on the three dots to the right of the firstmost commit in the list of commits and choose to Deploy from the menu.
Double check that the commit you are deploying is the given or a later one.
Press “Redeploy” to confirm that you want to roll out the next version of the Caasperli application.
After the service has been built by the buildpack and started. The logs will contain some output telling you that it is running on cloud foundry and that it detected the “mongodb” service.
You may now visit Caasperli at the route we deployed it to and find a happy new feature.
In the next installment of this blog series, we will be looking into other ways to deploy applications to the SUSE Cloud Application Platform.
