software components_blueprint_vRA

[jvm2016]

Hi all,

we are in process of devoloping blueprint and for which we need to install some agents on windows machine blueprint.

for installtion of agents and addtional software we are using additional server and giving the path of that server using custom properties tab in blueprint.

can the above process be  avoided by importing additional software components using cloud client and dragged it to blueprint.

Thanks in advance.

[daphnissov]

Not entirely sure what you're saying you're doing here, but Cloud Client would have no part of this design. If you're not using software components (requiring an Enterprise license), that would be the way to go.

[jvm2016]

thanks for replying .

i can see software components tab  under design .

i want to use cloud client to import content(in this case all the agents or additional  software required for application ) is this not the way to import??

[daphnissov]

The import ability in the Cloud Client does not import software packages or binaries; it imports blueprints. Those blueprints (which can be software blueprints) are what get dragged-and-dropped onto the design canvas.

[hejgard · Accepted solution]

If I understand you correct you have designed in the blueprint to map a file share on an external server where you have media files and maybe installation scripts and at provisioning time the software (agents) are then installed over the network on the provisioned server. This method is very often used and is allowing you to have a generic template to use every where and via blueprint 'commands' or SoftwareComponent scripts install the agents and maybe other software.

Less flexible you could copy your media files and software to the template and keep the provisioning of the new server with agents and software independent of connecting to a network share using blueprint commande or SoftwareComponent scripts, after installation then clean up the software binaries on the new server.

My experience is that Guest OS management agents can follow the template, as this is the lowest denominator of what should be on a any provisioned server, but middle ware stack should be installed via a mapped file share, otherwise you will end up with too many templates impossible to manage.

[daphnissov]

Less flexible you could copy your media files and software to the template and keep the provisioning of the new server with agents and software independent of connecting to a network share using blueprint commande or SoftwareComponent scripts, after installation then clean up the software binaries on the new server.

However, this would still require a scripted approach to install and possibly configure those applications, then remove the binaries. That script could be a software component itself or a guest agent script (i.e., custom properties), but would still require management. In my opinion, I try not to do this and prefer to have a centralized software repo for a few reasons:

1. Storing software binaries on a template inflates the size of the template and elongates cloning time.
2. Updating software requires updating it on every single template. Not a fun process when you may have 6 different Windows templates and 4 variants of Linux.
3. Managing settings template files for said software increases management overhead (see #2).
4. Not all management agents/software get installed on all templates even of the same type. This produces fragmentation which increases manageability (see #2 again) and sometimes confusion as to which templates have which binaries staged. If staging all, then inefficiencies result in cloning a template with 15+ software packages yet installing 2 (see #1).

By comparison, it's rather simple to have a dedicated software repo as an NFS mount or SMB share and call that as the first few lines of every software component you have. When using PowerShell, for example, there's even a cmdlet to remotely mount an ISO file to avoid copying it to the guest. Once all tasks are complete, simply unmount the share. No package cleanup necessary. And since there's one centralized place, all updates and changes made to software binaries, settings manifests, and bootstrap scripts are made in one place and outside of vRA or vSphere. Simply add/remove what you want, update from source control, whatever your processes are, and continue your deployments without messing with anything else.