Task:
Add a script to the OneFuse appliance and include it in a vRA 8.x Cloud Template (Blueprint).
In this example, we will be adding an Ubuntu script for One Fuse.
Notes:
The Scripting Policy Name is the keyword/bubble gum that connects the script to the vRA Cloud Template (Blueprint).
Typically the Rocky or CentOS local user is "root". Typically the Windows local user is "Administrator". Ubuntu VMs will vary because of root not having SSH and the "first" username can be anything.
For MS Windows VMs, the format for PowerShell is: PowerShell -File {{scriptName}}.
Part A: One Fuse
Create the Script:
Modules (menu) --> Scripting (submenu option) --> +Create button
1. General tab:
Scripting Policy Name: ubuntu_ScriptTask
Description: Updates ubuntu performing scriptTask to solve scriptReason
Target Host: {{OneFuse_VmNic0.fqdn}}
Module Credential: Ubuntu_Admin
2. Provisioning tab:
Launch Command: /bin/bash/{{scriptName}}
Script Template: <paste in the contents of the script to run>
Replace any variables to be added like: {{someproperty}}.
Success Exit Code: 0
(0 is typically a success)
Click the Save button.
Part B: vRA - Update the Cloud Template (blueprint template)
Update the Cloud Template in Cloud Assembly:
1. Cloud Assembly --> Design (top menu) --> Click/select/open the cloud template under name (e.g. MW OS VM).
2. In the right window/frame, select Code.
3. Close the inputs twistie/category to collapse all that.
4. Under the resources twistie, look for:
resources:
vSphere Machine:
type: Cloud.vSphere.Machine
properties:
Under the properties add the OneFuse scripting policy:
OneFuse_ScriptingPolicy_Trigger_ComputeProvisionPostLate: 'true'
OneFuse_ScriptingPolicy_ComputeProvisionPostLate_001ubuntuScriptTask: '${input.propOS="ubuntu"? propgroup.oneFuse.endpoint + ":" + input.propOS + "_ScriptTask": null)'
Note:
There only needs to be one OneFuse_ScriptingPolicy_Trigger_ComputeProvisionPostLate true line. Only add it, if your cloud template doesn't already have it.
5. Save and Upload to Git
Click Version, to save the update.
In the Creating Version dialog:
Version: 1.2
(Do one higher than the "Last Version: 1.1" )
Description: Updated MW OS VM template to include new script to run after machine is cloned.
Release <check> Release this version to the catalog
Click Create.
---
Note:
If releasing a new cloud template version later:
Cloud Template Version:
Assembler --> Design --> Templates --> Locate the catalog item cloud template, click the >> beside the name. On the right, click the cloud template version(s) number. On the left, click RELEASE on the new/latest version being deployed, and optionally, UNRELEASE the old version if desired. Click the <- left arrow to return to the previous page.
Custom Form Version:
Service Broker --> Content & Policies --> Content --> Locate the catalog item cloud template, click the >> beside the name. On the right, click the cloud template version(s) number of the Custom Form, and confirm latest Enabled, and earlier version now Disabled.
---
Part C: vRA - Enable the update Cloud Template in Cloud Assembly
1. Service Broker --> Content & Policies (top menu) --> Content Sources (side menu) --> Click/select/open Machine Blueprints (source on right).
2. On the Content Source Details page, click Validate (button).
It should say something like 1 update found. Click Save & Import (button).
3. Return to the Catalog (top menu) and Request the blueprint.
______________
Additional Notes on Setting Up Git for First Sync from vRA 8 (Cloud Assembly --> Cloud Templates):
vRA 8.11 - Limitations on Cloud Templates/Blueprints from Broadcom (VMware):
(See Broadcom (VMware) tech doc "Using and Managing Cloud Assembly)
- Each cloud template is placed into its own folder. (The folder has the name of the blueprint/cloud template.)
- Each cloud template's name w/in the folder is blueprint.yaml.
- Each cloud template must contain its name and version fields.
- If template is found invalid, it cannot be imported into vRA 8.
- Drafts created (by viewing or editing in vRA --> Cloud Assembly) do not get updated in subsequent syncs. New versions must be created in Git, and then pulled after the final draft updates are made and tested in vRA.
Other practical limitations and considerations:
- Think of Git for Cloud Templates as more of back-up. They do not promote branch to branch because of the way they are stored/synced from Aria/vRA 8 Cloud Assembly.
- - Therefore, we carefully copy-and-paste from DEV vRA and use the Propose new file and Create pull request with a Commit Merge at the next branch up to promote branches.
- In case missed in the VMware list above, cloud templates/blueprints edited (that become drafts) in Cloud Assembly cannot be committed or synced back to Git.
- If custom resource or tool kit has been removed in vRA, the cloud template cannot be synced back into Cloud Assembly. It has to be removed from its blueprint.yaml before the next sync with vRA.
- If a custom template was pasted from vRA to the Git web UI, and then pulled, cloud template will be pulled into the Cloud Assembly as another (new) entry. It has a different UUID than the original one.
- If a custom template is promoted to another branch (copy-and-paste is easiest), and pulled into that respective vRA Cloud Assembly, the UUID of that one will be different than the UUID of the previous vRA. Each vRA has its own UUID of the synced template.
- The DEV branch is populated from the local Cloud tempaltes vRA DEV Cloud Assembly; updon making a new version, the template's code is copy-and-pasted to a new file in the Git web GUI DEV branch, and the name, version are verified at the top, with the code pasted underneath.
Setting up new Git repository for synching:
1. Create the new Git repository. (e.g. vRAvRO / CloudTemplates, where vRAvRO is the owner/category in Github.)
- Set-up desired user security.
- Set-up the service account that vRA/vRO will use with the repository. To authenticate, it will require username and token.
- - Create the Git token if using token by logging in as the service account, and then create the token. Copy the token to a safe place.
2. Create the Git endpoint configuration in vRA (cloud templates) or Orchestrator (vRO) for workflows and actions.
a. Add the new Integration:
- In the Git web UI, navigate to the repo, and select the branch for "this" vRA (e.g. Dev, QA, Prod) and copy the resulting URL to the clipboard. (e.g. https://mwgithub.mindwatering.com/vRAvRO/CloudTemplates/tree/DEV )
- In vRA --> Cloud Assembly --> Infrastructure (top menu) --> Integrations (left menu) --> + ADD INTEGRATION (button).
- - In the Integration Types screen, click the Github option.
- - In the New Integration screen ...
- - - Under the Summary heading, paste the clipboard into the Name field.
- - - Under the GitHub Credentials heading, in the Server URL field, enter the github server URL including https (e.g. https://mwgithub.mindwatering.com. which is called the FQDN or SCM)
- - - Under the GitHub Credentials heading, in the Token field, copy and paste the token from step 1 above.
- - - Under the GitHub Credentials heading, click the VALIDATE button.
- - - - If green/successful, click the ADD button.
- - - - If not successful, check the "Name" URL, the Github Server URL and the token pasted.
b. Update the new integration with additional configuration:
- Still in Cloud Assembly --> Infrastructure (top menu) --> Integrations (left menu) --> Open the new Github integration just completed.
- - Under the Projects tab, click + ADD PROJECT -->
- - - Select the applicable vRA project --> Click the NEXT button.
- - - For Type field: Cloud templates
- - - For Repository field: <enter repository> (e.g. /vRAvRO/CloudTemplates)
- - - For Branch: <enter branch> (e.g. DEV)
- - - Click ADD button.
c. Perform initial sync:
- Still on the Project tab, to kick-off the first sync, click the down arrow in the table now presented.
- Review the status on the far right of the table. It should have a checkmark and have green/successful status.
Note:
Where the green status is displayed, a SYNC button will be displayed for forcing future syncs.
d. Review the Sync History
- Click the History tab, and review the sync.
3. Publish the new cloud template.
if a cloud template was already added to the Git web UI or committed via a workstation Git Bash, the sync would have pulled in the new cloud template(s).
These new templates are unpublished.
a. Preform the following steps to use the new cloud template with an existing catalog item:
- Publish the template in Cloud Assembly
- - Cloud Assembly --> Design --> <locate this cloud template> --> <locate newest/current version>, click RELEASE (left version history) --> In the Release Version dialog, make no edits to the Description field, click RELEASE.
- Import the cloud template into Service Broker catalog item.
- Enable the new Service Broker item by applying the custom form to it, and enabling it.
b. If there was a local copy of the Cloud template, it should be unpublished or disabled as it is no longer in use.
---
If the catalog item is new, the steps are to:
a. Publish the template in Cloud Assembly
- Cloud Assembly --> Design --> <locate this cloud template> --> <locate newest/current version>, click RELEASE (left version history) --> In the Release Version dialog, make no edits to the Description field, click RELEASE.
b. Create the Catalog Item:
- Service Broker --> Content & Policies (top menu) --> Content Sources (left menu)
- Locate the latest/current cloud template, click its name to open it.
- - In the Content Source Details screen, click the VALIDATE button.
- - - A green status box with successful is presented.
- - Click the SAVE & IMPORT button.
c. Create or Use an Existing Custom Form:
- If a new custom form is needed, create it or, what we do more often, start with another custom form to export and then re-import.
- - Use another custom form:
- - - Service Broker --> Content & Policies (top menu) --> Content (left menu) --> <locate a similar catalog item's cloud template> and click the 3 vertical dots --> Choose Customize Form from the drop-down --> When the custom form appears, go to its ACTIONS button, select Export form. Note the location saved --> Click CANCEL (bottom left of custom form) to quit.
- - Afterwards, we can apply it/use it with the new template.
- - - Service Broker --> Content & Policies (top menu) --> Content (left menu) --> <locate this newest cloud template> and click the 3 vertical dots --> Choose Customize Form from the drop-down --> When the custom form appears, it should be empty/blank.
- - - - If we wanted to start with an empty form, we could build it now.
- - - - Instead, to start with the other custom form just exported, click ACTIONS button, select Import form. navigate to the exported file, and click the system Open button to import it. --> Make the changes desired to the custom form --> Click the ENABLE button --> Click SAVE (bottom left of custom form) to save and close.
d. Test the new catalog item:
- Service Broker --> Catalog (top menu) --> Under Catalog Items heading, locate the new catalog item, click REQUEST.
- - Complete the custom form fields, click SUBMIT to kick-off the deployment.
______________
Additional Notes on Setting Up Git for First Sync from vRA/vRO 8 Orchestrator (Workflow and Actions via Git Repository):
Limitations and Considerations:
- Deleted workflows are not always deleted from Git. They remain with a 0 size, that when promoted to the next branch break syncs (imports).
- vRO configuration elements often have passwords, which are stored as secure string in vRO, which Orchestrator, for security reasons, strips from the sync push to Git. This usually breaks the next branch during promotion. vRO REST endpoints (vCenter, REST hosts, etc.) have the CustomSDKObject data type UUIDs are assigned at creation so config elements based on them will not find them by their UUIDs. As configuration items may have different boundary systems, we exclude all of them. Use the .gitignore file to exclude config elements.
- System libraries from VMware (Broadcom), and toolkits (e.g. OneFuse or AAP) libraries tend to be updated by software upgrades for VMware and by package updates for the toolkit vendors, therefore use the .gitignore file to exclude these workflow folders and action folders.
- Similarly, packages being the old way of code versioning management, typically are unnecessary; therefore, use the .gitignore file to exclude them.
1. Create the new Git repository. (e.g. vRAvRO / Orchestrator, where vRAvRO is the owner/category in Github.)
- Set-up desired user security.
- Set-up the service account that vRA/vRO will use with the repository. To authenticate, it will require username and token.
- - Create the Git token if using token by logging in as the service account, and then create the token. Copy the token to a safe place.
2. BEFORE setting up vRO, create the .gitignore file. The example below ignores all configuration elements and packages. It syncs only workflows, actions, and resources in specific folders ignoring all others.
# sample vRO 8.x .gitignore
*
!*/
Configurations/**
Packages/**
!.o11n/links/**
!Workflows/MWNet/**
!Workflows/MWCom/**
!Actions/net.mindwatering/**
!Actions/com.mindwatering/**
!Resources/MWNet/**
!Resources/MWCom/**
3. Create the Git endpoint configuration in vRA (cloud templates) or Orchestrator (vRO) for workflows and actions.
a. Add the new Git repository:
- Aria/vRA/vRO --> Orchestrator --> Administration (left menu twistie) --> Git Repositories --> Click the ADD REPOSITORY button.
On the New Git Repository page, complete the fields:
Under the Credentials heading:
- Repository URL: <enter the full URL to the repo including the branch> (e.g. https://mwgithub.mindwatering.com/vRAvRO/Orchestrator/tree/DEV )
- Name: <enter the full URL to the repo including the branch>
- Description: MW vRAvRO Orchestator Repo
Under Configuration heading:
- Make active repository: enable.
Click SAVE.
previous page
|