Jan 21

Dynamic install of the app authoring agent

Today in our next Event Broker introduction piece we are going to walk through configuring it to dynamically install the agent needed for Application Authoring (ie our Software components option in the enterprise editions).

So what does that really mean? Two things in my opinion… First it means you can have a pristine template that is used for simple IaaS as well as for all application component. For you, that’s less templates to manage, and for the consumer it means they are alway identical. Second it’s an illustration of how you might deploy ANY agent using the Event Broker and a few custom properties.

I would also like to make sure you understand this is something I have been trying for some time and due to limitations the only it could be done before v.7 (event broker) was to exploit some of the CDK or make the product do unnatural things. THIS WALK THROUGH IS 100% OUT OF THE BOX!

I do have a couple of pre-reqs that I will make assumptions you are capable of…

  1. You know how to Entitle a Catalog item.
  2. You know how to and have created an app authoring Software Component.
  3. You already have vRA setup and at least one Linux template or linked clone catalog item available.
  4. Downloaded and imported the vRO Package below.

Without further ado, here is the vRO Package you can import. There is a single setting you will need to adjust in your environment.

In the Extendingclouds Run SSH command you will need to edit this workflow.01

 

In the General tab, look through the attributes and make sure you have password authentication set to yes and set your root password that you want to use.02

 

Next we’ll do the rest of the configuration in your vRA web console. Log in and go to Administration -> Property Dictionary03

 

Property Groups -> +New04

 

Create a name for your property group, the ID will automatically populate, and then +New to create a new property within this grouping.05

 

Name needs to be custom.appliance.fqdn This will be used in the workflow to create the command line install of your App Agent

Value should be the fqdn of your vRA Appliance

Uncheck the Overridable option06

 

Name needs to be custom.iaas.fqdn This will be used in the workflow to create the command line install of your App Agent

Value should be the fqdn of your Model Manager (ie Windows server)

Uncheck the Overridable option07

 

Name needs to be

Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.BuildingMachine

This actually tells vRA to pass properties to vRO at this particular state change.

Value should be * This will provide ALL of the values to vRO for use

Uncheck the Overridable option09

 

Go to Design -> Blueprints, select your Linux blueprint and click copy10

 

Now we rename the copy to something including App in it. I am using MySQL in this example. You will see later why App must be in the name.11

 

Now select the newly created blueprint.21

 

Click the vSphere Machine in the canvas Properties -> Property Groups -> +Add22

 

Check the Property Group you created.23

 

Click on the Software Components, drag the MySQL install onto your vSphere Machine in the canvas. COMING SOON -> MySQL quick tutorial24

 

The blueprint is now ready to be published (this is where I assume you can entitle that item).25

 

Go to Administration -> Events26

 

Subscriptions -> +New27

 

Select Machine provisioning
28

 

Select the Run based on conditions radio button

All of the following in the dropdown

Expand the +Data

Expand the +Lifecycle state

Select the Lifecycle state name29

 

Set to Equals

Scroll down to VMPSMasterWorkflow32.BuildingMachine

This means that we are going to run the workflow we choose at BuildingMachine. If we were to move on here it would run at all 3 phases on every machine request30

 

In order to have this run only at POST we go through the same steps.

Expand the +Data

Expand the +Lifecycle state

Select the State phase31

 

Set to Equals

Set to POST

This means that we are going to run the workflow we choose at BuildingMachine but only at the phase of POST. If we were to move on from here it would run against every request during the POST – BuildingMachine.32

 

So to narrow it down even more we want to select ONLY requests that contain the word App in them.

Expand the +Data

Select the Blueprint name33

 

Set to Contains

Enter App in the text field35

 

This is how your final subscription should appear

As I’m sure you’re putting it together now when we step forward we will actually only be running this on blueprints that have App in the name, at BuildingMachine state, during the POST phase. (Tada, you see the power in subscriptions yet???)36

 

Select the Install App Authoring Agent workflow that was included in the vRO package.37

 

Check the Blocking box, this means it won’t go to the next step till this one completes

Set a timeout of 15 minutes38

 

Publish the subscription39

Now go to request your catalog item!

7 comments

2 pings

Skip to comment form

    • Ventsyslav Raikov on February 1, 2016 at 9:27 am
    • Reply

    Great post again, Gary !
    I would not use BuildingMachine.POST here – when the lifecycle enters into BuildingMachine.PRE the actual provisioning of the machine starts. Depending on the result on of the two events – onBuildFailure or OnBuildSuccess will be raised.
    In both cases the BuildingMachine.POST will execute as we’ll be going out of the BuildingMachine state, but in case of onBuildFailure the next state is Disposing and it doesn’t make much sense to try to install software.
    So it will be more resilient solution if you subscribe to the OnBuildSuccess event here.

    1. Ventsyslav, great suggestion! Quite honestly the reason I’m still using BuildingMachine.Post is lingering from the 6 major state changes. Since EB elevates the number of places you can execute these workflow then there may be better places to these workflows. I will test for my next post (windows) If all works out I’ll come back and update this accordingly. Thanks again!

    • Eric on February 25, 2016 at 12:15 am
    • Reply

    This is a great help. I think this can also be applied to Amazon EC2 machines, but that would require inserting the initial bootstrap script into the EC2 Instance metadata “UserData” property. Is there a way to do this?

    1. Eric, yes this methodology could also be used for AMIs. That said you must make sure that you have connectivity and DNS configured to allow the AWS instances to communicate back with the VRA components during the provisioning process.

    • Amir A. on April 4, 2016 at 5:34 pm
    • Reply

    Hi Gary – the download link for the vRO package doesn’t work. Would you please update the link.

    Thanks a lot as always!

    1. Amir, the package should lead you to https://developercenter.vmware.com/web/dp/samples?id=921 that address. I just tested it and it went there with no issue. Can you verify? Also one thing that may still be an issue is if this is for windows then the script to pull the installer will fail if you’re using it against vRA 7.0.1. You need to update the reference in the script to my new windows installer script. https://gist.githubusercontent.com/vmwaredevcenter/fdded0536435cc1546ea/raw/01d58f576c26476ba36392a66ba8754029717531/snippet.ps1

    2. Additionally food for thought since the limitation is that it registers with a single VA you may want to consider my post https://extendingclouds.com/due-to-high-demand-heres-the-combined-aaa-deployment/ which defines the agent at deployment time so you can change that default VA to the fail over node if needed.

  1. […] Components in vRA 7? Don’t we already have a prepare_vra_template available? Didn’t you just post an automated way to use that at provisioning […]

  2. […] I say I can improve that with the Event Broker and create the Dynamic install which calls the previous […]

Leave a Reply

Your email address will not be published.

%d bloggers like this: