Enabling the developer self service with Jenkins and the Cloudclient

What is it that our developers are truly asking for from their IT? The DevOps monicker is getting more and more flooded by companies coining their “tools” around it. SD-WAN is allowing the network to play an equal part in DevOps . If you want to learn more about SD-WAN, then you may want to click here now for more info.

Ask any one person what they believe DevOps means and you will likely get a multitude of answers… Well the one thing that I continue to hear from my customers, and my enterprise developer friends is that the desire is to simply check code in and the rest of the process just spins up their new environment without any additional interaction. To see an example of this exact use case feel free to check the video below.

If you would rather watch the video guide I have uploaded it here as an alternative to this step by step guide. I believe when you complete this guide you will be able to offer your developers a ‘platform’ which will deploy automatically based on when Jenkins initiates a build. This is NOT a tutorial to help build an application, check into Git, or setup Jenkins from scratch. It also has not yet been tested at scale so depending on your build requests the sizing of your cloud client may vary.

There are a couple expectations for this to work, I’m expecting you have the following already setup.

• vRA with Application Services setup
• Application blueprint defined, published, and entitled into the self service catalog (this is something your application team, architect, and developers will help define)
• Linux server
• Jenkins setup ready for some configuration (typically developers will have the ownership of this)
• Git code repository (typically developers will have the ownership of this)

As with all my examples I’ll use our VMworld session (search for HBC2609) that focuses on the Motorcloud Bass Search Application which represents a 3 tier enterprise application consisting of Web Load Balancer, Application Servers, and Database server. You will notice the highlighted field that contains the application war file location this is where Jenkins will deliver the completed build.

This is an example of what the self service catalog entry appears like during the request phase. Later you will see a command line that we issue that requests this catalog item but takes the default parameters. You can choose to include any of the items in this to alter based on the command line and Jenkins request.

Now we start getting the real work done, first and foremost we need to download and extract the vRealize Cloudclient. Create the /opt/vmware/cloudclient directory on your linux server and copy the extracted files directly into that directory.

Log into your linux server and make the cloudclient direcotry executable
chmod -R 777 /opt/vmware/cloudclient

Download the JRE client which is required for the cloud client to work.
wget http://applicationServices.FQDN/agent/jre-1.7.0_51-lin32.zip (64 bit version is jre-1.7.0_51-lin64.zip)

Create the vmware-jre directory
mkdir -p /opt/vmware-jre

Unzip the jre file into your vmware-jre directory
unzip jre-1.7.0_51-lin32.zip -d /opt/vmware-jre

Set the default path to include the newly created java directory
export PATH=$PATH:/opt/vmware-jre/bin

Enter the cloud client directory and launch the cloud client
cd /opt/vmware/cloudclient
./cloudclient.sh

First run will parse through the eula and accept

Create the automated login file
login autologinfile

Exit the client and edit the newly created Cloudclient.properties
exit
vi Cloudclient.properties

Edit each of the lines in the file to meet your specific environment
One thing to note is vra_username must use the the full login name. Example – my tenant is set to use the alias of bbr, I often login with vcacservice@bbr with this tool you need to use the full domain login which in my case is vcacservice@biteback.records
*****If you don’t do this you will get a forbidden 403 error!

Complete the editing for the iaas and vco server components

Launch the cloudclient again, this will then automatically login and you can start to run commands
./cloudclient.sh

Verify the sign by running a catalog list
vra catalog list

This is an example list, you will see the group, id and other valuable information about catalog items

Now exit the client and go to the root directory
cd /root
vi catalogRequest.sh

With this file we build out the commands you need to call the cloud client and pass it the proper parameters to automate the call to the application we highlighted above. To break down the script we are building here.

export PATH=$PATH:/opt/vmware-jre/bin -> We do this to make sure that java is defined for the cloudclient to work
cd /opt/vmware/cloudclient/ -> This is required because issuing the command out of that directory has some challenges
./cloudclient.sh vra catalog request submit -> Breaking down the command, this will issue the request
–groupid ‘”YOUR BUSINESS GROUP”‘ -> Define the business group
–id ‘”YOUR APPLICATION AS PUBLISHED”‘ -> Define the application by name (in my example you notice the Bass Player Search which is the same as the screenshot earlier
–description -> This is a required field for an application service request
–reason -> Why you want this request
–export -> Export results to a file (this is optional)
–properties -> Optional but this is where you would add specific variables that you may want to pass to the application the format is provider-OPTION, example would be –properties provider-global_conf=,provider-JAVA_HOME=

Save the file and make it executable
chmod 777 catalogRequest.sh

Now with all that configured we will setup the Jenkins to copy the application files to my ftp share and ssh to the cloud client for automated deployment. The following steps may be something you rely on your developers to either consult or utilize something they already have setup just needs a few of these settings configured.

In Jenkins select to manage and configure systems

Scroll down to the ftp server settings and enter the data needed to connect your ftp server and test connection

Do the same with your SSH server, this will be the linux server we just configured

Save the configuration and go into the project list. Select  the project you will be automating

Select to configure your project

Example of when to build your project, this is when a change is committed to Git but could easily be just something scheduled to run nightly. Either way once it is configured will automatically create the environment

Configure the ftp server to accept and deploy the files directly to ftp

Configure the ssh server to launch the catalogRequest.sh and then save the configuration

As an example if you log into application services and click on deployments you will see that nothing has been deployed

Now you can check in code to Git or simply kick off the Build Now

If you look into the console output you will see the successful build, ftp, and ssh kickoff success

Now you can log back into application services and check on the deployments to see the application is in process