The YAML schema for LinuxVMDeploy native step is as follows:
An alphanumeric string (underscores are permitted) that identifies the step.
LinuxVMDeploy for this step type.
Description of usage
|Must specify a VmCluster resource.||Required|
In addition, these tags can be defined to support the step's native operation:
Description of usage
|The ssh user used to connect to target VMs.||Required|
Path of the directory where the deploy artifacts will be uploaded. The directory will be created if it does not exist.
Default directory is
|These variables will be exported on target VMs.||Optional|
Time in seconds to wait between deploys.
The release strategy to be used. It can be either
User-defined commands to run on a given context.
The following environment variables are available for user-defined scripts written in the LinuxVMDeploy step.
|Name||Description of usage|
|The name of the VM cluster being deployed to.|
The name of the VM cluster that was last deployed to.
|The name of the command that was running when the step exited. This should be blank if no user-defined command was running.|
Declares collections of shell command sequences to perform for pre- and post-execution phases:
|Tag||Description of usage||Required/Optional|
|Commands to execute in advance of the native operation||Optional|
|Commands to execute on successful completion||Optional|
|Commands to execute on failed completion||Optional|
|Commands to execute on any completion||Optional|
The actions performed for the
onExecute phase are inherent to this step type and may not be overridden.
The following examples show a few ways in which a LinuxVMDeploy step can be configured.
Uploading an App in a FileSpec Resource to VMs and Running It
The most basic form of LinuxVMDeploy. Uses all default values. The step will upload files to the default
targetDirectory and run a deploy command.
Uploading an App in a BuildInfo Resource to VMs, Running postDeploy command, and Handling Rollback.
Upload a BuildInfo resource and try to run
postDeploy commands. If
deployCommand succeeds, then postDeploy will run. If there is a failure on a VM (in case a command or
postDeploy did not succeed), then
rollbackCommand will run on any VM that deployed successfully.
Overriding VmCluster Targets
In this example, a VmCluster resource is supplied alongside
deploy_targets_override environment variable. Artifacts will be deployed to the targets specified in
deploy_targets_override. The ssh keys from the VmCluster resource will still be used.
Passing Environment Variables to Commands Run on the VM
In this example, a VmCluster resource is supplied with
vmEnvironmentVariables. These variables will be available to user-defined commands running on the
Setting up a blueGreen Deploy Strategy
In this example, two VmCluster resources are supplied and a strategy of
blueGreen is specified. Each time the step runs,
currentCluster swap between the two supplied VmCluster resources.
How it Works
When you use the LinuxVMDeploy native step in a pipeline, it performs the following functions in the background:
- jfrog rt download (download files from FileSpec, BuildInfo or ReleaseBundle)
- tar (compress all files to be uploaded to VMs)
- scp (upload compressed artifacts to VMs)
- ssh "mkdir -p" (create the targetDirectory if it does not exist)
- Script commands run on target VMs via ssh or on the build node itself if context is "buildNode".
- Commands run in the order they were written in the yaml.
- Commands running on the target cluster will have access to variables defined in vmEnvironmentVariables.
- A rollback archive is created on the targetCluster (only happens when entire step succeeds)
- Rollback directory location: /home/$ssh_user/LinuxVMDeploy/rollback
- mkdir -p (create rollback directory if it does not exist).
- rm -rf $rollbackDirectory/* (remove any old rollback artifacts)
- cp -r $targetDirectory/* $rollbackDirectory (copy all uploaded artifacts to rollback archive)