CODEWITHSUNDEEP
rundeck
Bibelo
Bibelo

Reputation: 229

Define configuration file for a workflow

Say I need to handle some projects of various types on various VMs

Before running a workflow, I would like to define a list of those projects to go through

If it was a bash script, I would just create a file like this:

hostname1:projectA:type1
hostname2:projectA:type2
hostname3:projectB:type1
hostname4:projectC:type2
etc.

Then I'd just go through each line of this file, and then of each field, something like (in a very simplistic way):

for i in $(cat file); do $hostname=$(awk -F':' '{print $1}; ssh $hostname "do something on $project;done
That command would basically enumerate through the whole file

I can't seem to find a way to do that.

Of course, there's the Workflow Data Step, where you can put some variable, but there's zero documentation on how to use it and how to include it in a script.

What if I want to know the number of variable defined? What if I don't want a list of variable, but rather a comma-separated list of strings, like the above?

And what is the properties format anyway?

The idea would be to manually update this list with the newest project and have rundeck manage the task.

I went through 6 pages of Stack Overflow rundeck topics. The closest I found was Is it possible to enumerate Rundeck input variables in script?

Upvotes: 0

Views: 269

Answers (1)

MegaDrive68k
MegaDrive68k

Reputation: 4325

A good way to do that is get the project list from Rundeck API in an inline script, this is a basic example which list all projects:

#!/bin/sh

# protocol
protocol="http"

# basic rundeck info
rdeck_host="localhost"
rdeck_port="4440"
rdeck_api="39"
rdeck_token="G90XOPrPqT9dyuuySADVg5GcS8jNNrGV"

# api call
curl -s --location --request GET "$protocol://$rdeck_host:$rdeck_port/api/$rdeck_api/projects" \
  --header "Accept: application/json" \
  --header "X-Rundeck-Auth-Token: $rdeck_token" \
  --header "Content-Type: application/json" | jq -r .[].name

The example uses jq to filter by name, also, you can play with the output to save to a file, do a wc -l to enumerates the elements (filtered or not using grep or another tool), etc.

So, regarding the Data Step (check this if you like to test in your environment), the example just creates two data values using the Data Step and later print it on a command step/script step, in that way you can generate your config file.

- defaultTab: nodes
  description: ''
  executionEnabled: true
  id: c955e3f5-732e-41dd-b837-726efb2a73dd
  loglevel: INFO
  name: HelloWorld
  nodeFilterEditable: false
  plugins:
    ExecutionLifecycle: {}
  scheduleEnabled: true
  schedules: []
  sequence:
    commands:
    - configuration:
        data: |-
          brand=fiat
          type=citycar
        format: properties
      nodeStep: false
      type: stub-data-step
    - description: Command Step Example
      exec: echo "the car is an ${stub.brand} ${stub.type}"
    - description: Script step example
      fileExtension: .sh
      interpreterArgsQuoted: false
      script: echo "the car is an @stub.brand@ @stub.type@"
      scriptInterpreter: /bin/bash
    keepgoing: false
    strategy: node-first
  uuid: c955e3f5-732e-41dd-b837-726efb2a73dd
  1. The "properties" format it's just a key=value format to generate any data, for example: country=italy.
  2. The "trick" is to catch the value in this way: stub.country (${stub.country} for the command step, and @stub.country@ for inline-script step) which meaans the documentation needs an update.

Here the result.

Upvotes: 1

Related Questions