VMware vFabric Application Director is a tool for automating application deployments to infrastructure clouds – it basically automates the provisioning of infrastructure, install, and configuration processes. Once an application has been designed inside Application Director, it can also be deployed to multiple cloud environments without redesigning the application.
This blog post (and a very helpful accompanying video embedded below) will explain how Application Director’s Command Line Interface (CLI) can be used alongside VMware’s cloud stack to support a self-service portal for provisioning cloud applications. A future blog post will outline a second key use case with Application Director – it’s use in a continuous integration development lifecycle to automate builds and migrations.
VMware software used in this Use Case:
- VMware Service Manager Cloud Provisioning (VSM CP)
- VMware vCenter Orchestrator (vCO)
- VMware vFabric Application Director (AppD)
- VMware vCloud Director (vCD)
Steps in this Use Case:
- End User orders a service from VSM CP
- Admin/Manager approves request in VSM CP
- VSM CP calls to vCO to feed Application Director
- vCO captures status and updates VSM CP
- Application Director deploys the app with vCD
- vCD receives a registered vApp
- VSM CP notifies the user
1. End User orders a Service via VSM CP
From a user’s perspective, the process is quick, easy, and completely self-service. They simply browse the service catalog, where they can drill down to look at the details of each application on offer to them, and then select the version they want to deploy.
Once the user finds the application they want, they click on the order button and are asked to fill out a request form, the deployment profile dropdown determines the cloud environment it can be deployed into, for example development, test or production infrastructure, in private or public clouds. This can also determine who approves the request, as there may be more approvals required before deploying an application into a production or public cloud.
2. Admin/Manager approves Request in VSM CP
Once the user submits the order, the relevant person gets an approval request. In this example the development environment was selected so it is the development manager only who approves the request, although in many cases an approval wouldn’t be necessary for dev/test environments.
The development manager reviews the details of the request and approves the request by entering their password.
3. VSM CP calls to vCO to feed Application Director
This triggers the workflow in VSM CP to call out to vCO in order to invoke the Application Director CLI. Note: the Production Manager approval was skipped in this workflow because this request was to deploy into a development environment.
The vCO workflow then builds a Spring Roo script to feed into the Application Director CLI based on the inputs provided by the user, which essentially involve the application name, the version and the deployment profile. The deployment profile determines which cloud to deploy into, and the mapping of the logical templates and networks defined in the application blueprint to the templates and networks in that cloud. Once this script is compiled, it starts the Application Director CLI and runs the script.
4. vCO captures Status and Updates VSM CP
The CLI reports that the application was successfully scheduled in Application Director and vCO searches the output in the command line to find the deployment name and provides it as a workflow output to VSM CP. This means that VSM CP is aware of which vApp in vCloud Director this request relates to, and allows the end user to see and manage this new vApp in the cloud portal once provisioning is complete.
5. Application Director deploys the App in vCloud Director
Application Director then automatically deploys the application based on the application blueprint we have created. Application Director fully supports dependency management, so it knows which order to install the middleware and application components. In this example Application Director first installs, configures and starts MySQL as a database server and JBoss as an application server. Once MySQL is installed and the database is initialized, and the JBoss server is installed and running, the Duke’s Bank application .jar and .ear files are deployed. Finally, the Apache Load Balancer is installed and started up. The steps are visible in the below execution plan.
6. vCD gets a registered vApp
The end result is a multi-tiered vApp in vCloud Director (either a private or public cloud), with the application installed and running.
7. VSM CP notifies the User
Once deployment is complete, the VSM CP workflow finishes and emails the user, notifying them of the successful deployment. The user can view and manage the vApp and its VMs in the VSM CP portal as well as launch the VM console directly via the web.
The result is a fully operational application, running in the cloud, in less than 15 minutes from the moment the request is approved to the delivery of the working application.
If you want to see the video, click here.