Utilizando o Resource Elements em workflows do vRealize Orchestrator 8.x – parte 1
Com o Resource Elements do vRealize Orchestrator é possível utilizar os objetos criados como atributos nos workflows. É suportado vários tipos de arquivos, como scripts, modelos XML, HTML, além de arquivos de imagem. Aqui vou demonstrar rapidamente como usar um Resource Elements para instalar e configurar um web server no Ubuntu.
No Orchestrator, navegue até Assets > Resources e importe o seu script. O meu recurso irá se chamar apache-ubuntu.
apt-get -y install apache2 echo -e '<html>\n<head>\n<title>'$HOSTNAME'</title>\n</head>\n<body align=center bgcolor=gray>\n<h1>Caverna Labs</h1>\n<h2>'$HOSTNAME'</h2>\n</body>\n</html>' > /var/www/html/index.html service apache2 restart
Agora que o script já está dentro do vRO, vamos criar um novo workflow. Adicione InputProperties como input (mais detalhes aqui) e crie uma nova variável chamada resourceFile do tipo ResourceElement e associe com o recurso criado anteriormente.
Vamos criar um scriptable task chamado de “get properties” e adicionar as variáveis que criamos anteriormente como inputs.
Ainda no scriptable task “get properties”, é hora de escrever o código. Tá fácil, só usar o modelo que criei abaixo.
// get VM from vCenter
vcUuid = inputProperties.customProperties.vcUuid
externalIds = inputProperties.externalIds[0]
vcVmName = System.getModule("com.vmware.vra.xaas").findVcVmByVcAndVmUuid(vcUuid,externalIds)
vm = vcVmName
// get content from resource element
getFile = resourceFile.getContentAsMimeAttachment()
script = getFile.content
// set variables
vcVmObject = vcVmName
vmName = inputProperties.resourceNames[0]
ip = inputProperties.addresses[0]
image = inputProperties.customProperties.image
os = inputProperties.customProperties.softwareName
osType = inputProperties.customProperties.osType
flavor = inputProperties.customProperties.flavor
project = inputProperties.customProperties.infoProject
blueprint = inputProperties.customProperties.infoBlueprint
userName = System.getContext().getParameter('__metadata_userName')
eventTopicId = System.getContext().getParameter('__metadata_eventTopicId')
// log
System.log("#-----------------------------------------#")
System.log("------> VM VC NAME: " + vcVmName.name)
System.log("------> NAME: " + vmName)
System.log("------> IP: " + ip)
System.log("------> IMAGE: " + image)
System.log("------> OS: " + os)
System.log("------> OS TYPE: " + osType)
System.log("------> FLAVOR: " + flavor)
System.log("------> PROJECT: " + project)
System.log("------> BLUEPRINT: " + blueprint)
System.log("------> USER: " + userName)
System.log("------> EVENT TOPIC: " + eventTopicId)
System.log("#-----------------------------------------#")
Vamos usar o workflow element para adicionar um novo workflow, para isso basta arrastar o componente e no campo workflow encontrar um cara chamado Run Script in Guest. Promova tudo deste workflow para variáveis. Isso é tudo que precisamos fazer com este workflow.
O workflow Run Script in Guest precisa apenas de duas informações para funcionar: o nome da VM e o script que será executado nela. Por isso, precisamos configurar os outputs do scriptable task “get properties” com as variáveis script e vm.
Em variáveis, garanta que você definiu as credenciais (variáveis username e password) e que alterou o scriptType (no meu caso será bash, mas poderia ser bat ou powershell também).
Agora é só criar uma subscription (Cloud Assembly > Extensibility > Subscription) para que o workflow que acabamos de criar seja acionado no event topic compute post provision, ou seja, após o provisonamento com sucesso do recurso.
Peguei um blueprint simples apenas para testar. Lembre-se de adicionar estas linhas no seu blueprint para poder usar as informações sobre o projeto, blueprint e deployment no vRO caso necessário.
infoProject: ${env.projectName}
infoBlueprint: ${env.blueprintName}
infoDeployment: ${env.deploymentName}
Após solicitar o blueprint, vejo nos logs que as variáveis funcionaram perfeitamente e o servidor está com o web server (apache) instalado e com as configurações que realizamos no script.
É só ficar atendo aos inputs e outputs que o sucesso é garantido.
Apenas para esclarecer: VMware Aria Automation é o novo nome do vRealize Automation, o mesmo vale para o antigo vRealize Orchestrator, que agora se chama VMware Aria Automation Orchestrator. Aqui, para fins didáticos, continuo utilizando os termos vRA e vRO.
É isso aí, pessoal. Até a próxima.