vCloud Automation + UCS Manager + OS deployment

I cannot find anything online. Google seem to have let me down so far.

1. You can create Blueprints to deploy a UCS Blade from the UCS Manager
2. The blade will then take a service profile from the UCSM and does "its thing"

It seems that PXE is the only way to deploy the OS.

Anyone done anything like that before ? Are there any ways to create (Service)Blueprints to deploy agents in Physical servers ?

Find more posts tagged with

Comments

UnixGuy

I don't know the answer to your question, but the title of your post sums up the new buzzwords that I see on many new job ads

jibbajabba

Oh yea, vCAC / vCO seems to be picking up ..... fast ..

Zentraedi

It seems that PXE is the only way to deploy the OS.

Pretty much... We had a bespoke vCO solution and that's the conclusion we came to. If you look at what the other converged infra managers like UIM and UCSD, they're doing the same thing with their bare metal deployment agents.

I suppose you could stage an isolated starter boot LUN, clone and have it reconfigure itself upon boot. Still, at that point you're talking more trouble than a straightforward PXE setup.

Are there any ways to create (Service)Blueprints to deploy agents in Physical servers ?[/QUOTE]

What exactly do you mean here? Deploying to any bare metal blades? 'Physical' as in rackmount as opposed to blades?

jibbajabba

Physical = Blades. I mean when building Blueprints for Virtual Machines you can pass custom properties through using the default stubs. But you probably don't have the option when using Blueprints for physical servers.

What I am looking for is a way to deploy a physical UCS Blade using a Blueprint but not sure fire up a PXE boot deployment but also configuration items.

For example the image may have backup agents embedded but they need later be configured.

So I am just not sure it is possible to configure any custom properties which could be used to fire up any scripts after deployment.

I think it only supports Powershell scripts executed upon deployment.

So yes, long story short, I am looking for a way to create workflows to installs apps inside the OS of a physical deployed server and also to fire up scripts to configure them (from r example installing the Avamar backup agent and then configure the server so it ends up in the right group).

I cannot find anything online that people done that before.

jibbajabba

* not just fire up

Zentraedi

jibbajabba wrote: »

Physical = Blades. I mean when building Blueprints for Virtual Machines you can pass custom properties through using the default stubs. But you probably don't have the option when using Blueprints for physical servers.

What I am looking for is a way to deploy a physical UCS Blade using a Blueprint but not sure fire up a PXE boot deployment but also configuration items.

Well, there are many ways of doing that.... could embed post install scripts into the image, chain another workflow in vCO, GPO in Windows boxes, install Puppet/Chef via your kickstart and push configs via that etc....

jibbajabba wrote: »

For example the image may have backup agents embedded but they need later be configured.

Why not create a script pushed via GPO or have a workflow make a ps-remoting call to register the agent via cli?

jibbajabba wrote: »

So yes, long story short, I am looking for a way to create workflows to installs apps inside the OS of a physical deployed server and also to fire up scripts to configure them (from r example installing the Avamar backup agent and then configure the server so it ends up in the right group).

Seems pretty straight forward. Any reason why the options above might be proving to be a challenge in your case?

jibbajabba

Not 100% sure how to do this really. AD .. Not sure it is an option as I don't know if the environment in question has it. Post install script : suggested that, not sure if they will agree (yet).

As far as I understand the preferred method is vCO by and I am struggling to understand how this can be used on physical servers. Especially since most workflows seem to require VMware. Which makes sense as most require VMware Tools to get the on-status back to vCO.

So I guess the cleanest way would really be using PS or just embedding the scripts into the images.

Automated upon deployment is probably only possible via the latter.

Zentraedi

jibbajabba wrote: »

Not 100% sure how to do this really. AD .. Not sure it is an option as I don't know if the environment in question has it. Post install script : suggested that, not sure if they will agree (yet).

As long as the script and verification is part of the image or workflow, I'm not sure why they would be opposed...

jibbajabba wrote: »

As far as I understand the preferred method is vCO by and I am struggling to understand how this can be used on physical servers. Especially since most workflows seem to require VMware. Which makes sense as most require VMware Tools to get the on-status back to vCO.

Perhaps you should step back and just think of vCO as a general purpose orchestration engine with some nice add on integration for VMware. Just have a sub workflow that checks for a newly deployed physical install to come online. That really depends on how you deploy though. For example, you might have a staging VLAN, so after sub-workflow triggers the deployment, you can have another that monitors DHCP or pings on the staging VLAN. From there, trigger a ps-remoting session to connect to the server and push whatever command line configs you need.

jibbajabba wrote: »

So I guess the cleanest way would really be using PS or just embedding the scripts into the images.

Nothing wrong with that. If it works, it works. However, it's usually a good idea to keep most of your automation in one place, i.e. the orchestration engine so that you can re-utilize it later.

jibbajabba wrote: »

Automated upon deployment is probably only possible via the latter.

Could setup your deployment images to allow ps-remoting, then push PS actions or DSC remotely. Once the desired config state has been accomplished, if your environment requires, you could then lock that down as a final step in the workflow.

jibbajabba

Thank you very much - still a lot of head spinning going on here ...

Assuming you can create workflows to talk to backup software to create settings etc., the main issue will probably be to find out how you would kick them off. Automatically anyway .. Because the physical server deployment is done via PXE, I just fail to see how a workflow can autoatically be kicked off to perform certain actions once the OS has been deployed via Puppet ..

Sorry, I am probably a bit thick here ..

Zentraedi

Well, I guess it depends on your processes and how you want to approach it.

I would assume that the PXE deployment is part of a larger workflow where you would allocate the UCS service profile, create storage LUNs, implement zoning/masking, and then power on the service profile. If that's the case, you want your workflow to sleep/poll for the physical server to come after it's deployment and then go head with the rest of the work. The key here is that the deployment isn't kicking off another workflow. The larger workflow is just sitting around, waiting and check for the PXE deployment to complete before proceeding.

If you're expecting the service profiles to be powered on manually at any time and just start PXE booting, I would just create a workflow to finish up the rest of the configuration/deployment and trigger it manually.