In this blog post we are going to look at how to use an ABX action to enable synchronization of blueprints and blueprint changes from VMware Cloud Assembly to a Gitlab repository. Also how to use AWS Secrets Manager to securely store secrets for our ABX Action.

• Introduction
• Using Blueprint Options in the Blueprint
• Using the ABX Action Inputs
• Testing the ABX Action
• Final Step

 

Update Log:

Introduction

Assembly does not offer the ability to synchronize blueprint changes to external git repositories like Gitlab or Github. In this blog we are going to show how we can use an ABX action performs the following tasks:

• Syncs blueprints to git when they are versioned or deleted in Assembly.
• Upon Assembly deletion blueprints can be deleted in git or preserved by setting blueprint option blueprint option blueprintOptionGitDelete
• All blueprints can be synchronized or only selected once by setting blueprint option blueprintOptionGitSync. You may want to synchronize only particular blueprints from your projects.
• Renaming a blueprint in Assembly creates a new blueprint in Git

Furthermore the action also shows how to use AWS Secrets Manager to securely store secrets (password/credentials/tokens/ect..) . By using the actionOptionUseAwsSecretsManagerIn action option It allows us to choose between:

• Providing secrets via AWS Secrets Manager
• Providing secrets via Action Inputs

I am going to speak more about Blueprint Options and Action Options in a bit.
The action can be found on VMware Sample Exchange or following Gitlab Repo bit.ly/The-Gitlab

Special thanks goes to Dana Gertsch for his work with ABX and AWS Systems Manager which gave me the idea to use AWS Secrets Manager

We are going to look at the following use case:

• We have Assembly development Project A where we actively develop our blueprint
• We have Assembly production Project B where we want all versioned blueprints from Project A to be synchronized. This can also be used to synchronize blueprints between two distinct VMware Cloud Assembly or vRealize Cloud Assembly instances .
• In this example Project B (or instance B) is connected to the git repo where we store the blueprints.

 

Using Blueprint Options in the Blueprint

I mentioned Blueprint Options earlier. Our ABX Action uses a couple of blueprint properties that have to be set in blueprints that we want to sync to git:

• gitlabSyncEnable (Boolean)
• true: Blueprint will be synchronized with git.
• false: Blueprint will not be synchronized with git. You can turn synchronization on and off to skip some changes to be replicated to git.
• gitlabSyncDelete (Boolean)
• true: If blueprint is deleted from Assembly, it will be deleted in git.
• false: If a blueprint is deleted from Assembly, it will not be deleted in git.

These Blueprint Options are top level properties in the blueprint yaml. Here an example blueprint yaml:

Upon synchronization the ABX action will override the version and name properties to match the Assembly blueprint name and the version of the blueprint. In git this will result to e.g.:
…

…

This is all for the blueprint. The Blueprint Options can be set for any existing blueprints that need to start synchronizing to git.

Using the ABX Action Inputs

This is all for the blueprint. The Blueprint Options can be set for any existing blueprints that need to start synchronizing to git.

Lets take a look at some of the ABX Action inputs. Similar to the Blueprint Options we have here Action Options we can activate or deactivate:

• actionOptionAcceptPayloadInputIn (Boolean): Can be used to turn off payload inputs and use action inputs to speed up ABX action testing.
• True: Accept payload inputs.
• False: Accept only action inputs. Mainly for ABX testing only
• runOnBlueprintOptionMatchABXIn: see below
• runOnCustomPorpertyMatchABXIn: see below
• blueprintIdABXIn (String): Id of the blueprint to be synchronized with Git.
• blueprintNameABXIn (String): Name of the blueprint to be synchronized with Git.
• blueprintVersionABXIn (String): Blueprint release version to be synchronized with Git.
• actionOptionRunOnCustomPropertyIn (Boolean): RunOn custom property condition
• True: Check for runOn condition
• runOnCustomPropertyIn (String): Custom property key/value to match for when
• runOnCustomPorpertyMatchABXIn (String): Custom property key/value to match actionOptionRunOnCustomPropertyIn=True and actionOptionAcceptPayloadInputIn=False. For ABX testing. ( e.g. cloudZoneProp: cas.cloud.zone.type:aws )
• False: Do not check for runOn condition
• actionOptionRunOnBlueprintOptionIn (Boolean): RunOn blueprint option condition
• True: Check for runOn condition
• runOnBlueprintOptionIn (String): Blueprint property key/value to match for when actionOptionRunOnBlueprintOptionIn=True (e.g. blueprintOptionsGitSync: true)
• runOnBlueprintOptionMatchABXIn (String): Blueprint property key/value to match for when actionOptionRunOnBlueprintOptionIn=True and actionOptionAcceptPayloadInputIn=False. For ABX testing. (e.g. blueprintOptionsGitSync: true)
• False: Do not check for runOn condition
• actionOptionUseAwsSecretsManagerIn (Boolean): Allows use of AWS Secrets Manager for secrets retrieval
• True: Use AWS Secrets Manager for secrets
• awsSmRegionNameIn (String): AWS Secrets Manager Region Name e.g. us-west-2
• awsSmCspTokenSecretIdIn (String): AWS Secrets Manager CSP Token Secret ID
• awsSmGitTokenSecretIdIn (String): AWS Secrets Manager Git Token Secret ID
• False: Use action inputs for secrets
• cspRefreshTokenIn (String): CSP Token
• gitPrivateTokenIn (String): Git Token

The Accept Payload Input Action Option (actionOptionAcceptPayloadInputIn) allows us to switch between blueprint payload as source for some of the inputs or use the action inputs as inputs source. Usually this will always be set to True so that we can read the payload data once we’ve subscribed the action to an event topic. Whereas if we are still developing the ABX action and want to provide the inputs which are supposed to come from the deployment, via action inputs we can set it to False. When wet to False we have to set all action inputs that have *ABXIn in their name . Again if set to False all those inputs will be taken from the payload.

The Run On Custom Property Action Option (actionOptionRunOnCustomPropertyIn) allows us only run the action only if a given custom property is found in the deployment payload. If set to True the property name/value pair specified in runOnCustomPropertyIn has to be present in the deployment payload action otherwise the action will not perform any operations.

The Run On Blueprint Options Action Option (actionOptionRunOnBlueprintOptionIn) similar to the Run On Custom Property Action Option runs the action only if a given blueprint option is set. If set to True the property name/value pair specified in runOnBlueprintOptionIn For example if we use here the blueprint option blueprintOptionGitSync: true the action will only run and sync if the option property is found in the blueprint yaml

The Use AWS Secrets Manager Action Option (actionOptionUseAwsSecretsManagerIn) allows us to choose whether to use AWS Secrets Manager to store and retrieve secrets or action inputs. If set to True AWS Secrets Manager is used. If this is the case we will also need to specify the AWS Secrets Manager Secret ID’s for both the VMware Cloud Services portal token (awsSmCspTokenSecretIdIn) and the Git API token (awsSmGitTokenSecretIdIn). If set to False we will have to provide both again via the action inputs: cspRefreshTokenIn and gitPrivateTokenIn

The rest of the inputs are self-explanatory .

Testing the ABX Action

Let’s run an example test of the action. Here are inputs we’ve had set for the action.

As you can see I’ve specified my Gitlab repo folder where I want to synchronize my blueprints as well as the repo Project ID.
I’ve said that I want to run the action and synchronize only blueprints that have the blueprintOptionGitSync: true Blueprint Option and enabling the Run On Blueprint Option Action Option
I’ve selected to accept payload input. And I’ve also selected to accept AWS Secrets Manager secrets. Therefore I’ve also specified my AWS Secrets Manager Secret ID’s for both my tokens.
This action is subscribed to two Event topics:

• blueprint.configuration: Subscribe here for blueprint configuration events like create / delete. > Only delete enabled
• blueprint.version.configuration: Subscribe here for blueprint versioning events like create / release / un-release / restore > Only create version enabled.

I’m developing my blueprints in a project called dev-tito which is my development project. I also have a prod-tito which is my production project. Dev-tito has not been configured with any Assembly Gitlab Integration. Prod-Tito has been configured to sync blueprints from the aforementioned repo folder.
My blueprint looks like this:

Now if we version this blueprint . In this example I’ve created version 28. This will sync it in git

Now if I delete the Assembly Blueprint it will not delete the git because I’ve used blueprintOptionGitDelete: false

Let’s say I don’t want next versions to be synched with git for a while. I can set the blueprintOptionGitSync: false blueprint option. Now if I create a blueprint version it will not sync it in git. If I turn it back to true it will start sync again.

Now that we have synced the Assembly blueprint version to git. We can synchronize the Assembly Gitlab Integration which is configured for the prod-tito project, or wait about 15 minutes, and the git-synchronized blueprint should appear in the prod-tito project.

You can note the blueprint version which was synchronized and the project in which it was .

 

 

 

Final Step

If all went well, go grab a beer.

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.