Options

vCloud Automation + UCS Manager + OS deployment

jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
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 ?
My own knowledge base made public: http://open902.com :p

Comments

  • Options
    UnixGuyUnixGuy Mod Posts: 4,567 Mod
    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 :)
    Certs: GSTRT, GPEN, GCFA, CISM, CRISC, RHCE

    Learn GRC! GRC Mastery : https://grcmastery.com 

  • Options
    jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
    Oh yea, vCAC / vCO seems to be picking up ..... fast ..
    My own knowledge base made public: http://open902.com :p
  • Options
    ZentraediZentraedi Member Posts: 150
    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?
    Current Study Track
    EMCCA, EMCCAe, EMCCE, VCIX-NV, Puppet Practitioner, ServiceNow
  • Options
    jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
    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.
    My own knowledge base made public: http://open902.com :p
  • Options
    jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
    * not just fire up
    My own knowledge base made public: http://open902.com :p
  • Options
    ZentraediZentraedi Member Posts: 150
    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?
    Current Study Track
    EMCCA, EMCCAe, EMCCE, VCIX-NV, Puppet Practitioner, ServiceNow
  • Options
    jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
    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.
    My own knowledge base made public: http://open902.com :p
  • Options
    ZentraediZentraedi Member Posts: 150
    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.
    Current Study Track
    EMCCA, EMCCAe, EMCCE, VCIX-NV, Puppet Practitioner, ServiceNow
  • Options
    jibbajabbajibbajabba Member Posts: 4,317 ■■■■■■■■□□
    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 ..
    My own knowledge base made public: http://open902.com :p
  • Options
    ZentraediZentraedi Member Posts: 150
    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.
    Current Study Track
    EMCCA, EMCCAe, EMCCE, VCIX-NV, Puppet Practitioner, ServiceNow
Sign In or Register to comment.