Skip to content

Latest commit

 

History

History
113 lines (103 loc) · 3.48 KB

hosts.adoc

File metadata and controls

113 lines (103 loc) · 3.48 KB
Raw

qDup hosts

The hosts section in qDup is a YAML mapping that assigns an alias for a username + host combination.

hosts:
  alias: [email protected] #logs in with ssh key using default port
  container: quay.io/example/container #starts a container using podman
  local: LOCAL #reserved name for a local connection

The roles then refer to host connections by the alias.

roles:
  one:
    hosts:
    - alias
  two:
    hosts:
    - container
  ...

Hosts can be a string or mapping but in either case it must contain the information necessary to connect to the target host. There are 3 classes of target hosts:

  1. shh connections to any host accepting an ssh connection

  2. local connection using a local terminal process

  3. connection to a container using a supported container platform (default is podman)

SSH Connection

The previous alias used ssh keys with the default ssh port but a password and port number can be added to the configuration.

hosts:
  alias: me:[email protected]:22

There is also a move verbose mapping format for those who like to write more YAML.

hosts:
  alias:
   username: me
   hostname: myserver.com
   port: 22
   password: 12345

qDup supports passwords in the hosts definition because it can make testing easier but ssh keys are the recommended login method. If you cannot use ssh keys and must include the password you should use a state variable and pass the value as a secret through the command line

qdup.yaml
hosts:
  alias: me:${{password}}@myserver.com:2222

Then run the script reading the password from a tmp file so it is not in the bash history

java -jar qdup-uber.jar -b /tmp/ -S _password="$(cat /tmp/secret.txt)" qdup.yaml

-S _password sets the state variable password and the _ prefix tells qDup to treat the value as a secret and replace it with **** in the logs.

Local Connection

qDup can also connect to the local computer. Local connections use the LOCAL reserved hostname or set local: true when defining the host as a mapping.

hosts:
  example1: LOCAL
  example2:
    local: true

A local connection is helpful when testing scripts or deploying qdup inside a container.

Container Connection

qDup can start a container on a local or remote container platform. Containerized hosts help isolate changes and control the test environment. A local container can be specified as just the image name

hosts:
  example: quay.io/fedora/fedora

or LOCAL with the image name separated by //

hosts:
  example: LOCAL//quay.io/fedora/fedora

qDup also supports specifying an existing image by the containerId

hosts:
  example: LOCAL//deadbeef #where deadbeef is the platform containerId

Using a container Id requires us to explicitly use LOCAL or a remote host reference. Remote host references use the same syntax as their container-less counterpart.

hosts:
  example: me@myserver:2222//quay.io/fedora/fedora

The above examples all use the single line notation for a host defintion. qDup also supports a mapping definition

hosts:
  example:
    local: true
    container: quay.io/fedora/fedora
    platform: docker
  remote:
    username: me
    hostname: myserver
    port: 2222
    container: quay.io/fedora/fedora
    platform: podman

The mapping definition is the only way to specify the container platform. The default platform is podman but docker is also supported.