[Howto] Adding SSH Keys To Ansible Tower Via Tower-cli [Update]
Ania Cozzolino
My workaround right now is to store the ssh_key_file inside AWX container and when launching the job we set the ansible_private_key_file to /tmp/test.pem. But we actually want to select the name of the credentials from AWX tower instead of storing the keys inside the container.
While Tower is commercially licensed software, tower-cli is an open source project. Specifically, this project is licensed under the Apache 2.0 license. Pull requests, contributions, and tickets filed in GitHub are warmly welcomed.
By issuing the tower-cli config command without arguments, you can view a full list of configuration options and where they are set. The default behavior allows environment variables to override your tower-cli.cfg settings, but they will not override configuration values that are passed in on the command line at runtime. The available environment variables and their corresponding Tower configuration keys are as follows:
The resource is a type of object within Tower (a noun), such as user, organization, job_template, etc.; resource names are always singular in Tower CLI (use tower-cli user, never tower-cli users).
By default, tower-cli raises an error if the SSL certificate of the Tower server cannot be verified. To allow unverified SSL connections, set the config variable, verify_ssl = false. To allow it for a single command to override verify_ssl if set to true, add the --insecure flag:
The tool tower-cli is often used to pre-configure Ansible Tower in a scripted way. It provides a convenient way to boot-strap a Tower configuration, be it for testing environments or to deploy multiple Towers with the same configuration. But adding SSH keys as machine credentials is far from easy.
The tool tower-cli is often used to pre-configure Ansible Tower in a scripted way. It provides a convenient way to boot-strap a Tower configuration. But adding SSH keys as machine credentials is far from easy.
Note that as part of a credential like this, we can also specify how this key will be used with privelege escalation - with su, sudo, or other mechanisms. In the above example, we choose to use sudo, to root, with a particular password.
As with all parts of Tower, credentials can be created and edited via Tower's REST API. Here are examples, using the tower-cli commandline wrapper.
License keys purchased on different dates must be co-termed in order to be combined. The earliest of the license key expiration dates will be used. If you need your license keys merged, please reach out to ansible...@redhat.com.
As I understand, this would have been straight forward when using Docker by simply adding the SSH keys ahead of time. But with Kubernetes this gets a little more complicated due to the lack of persistence.
This is somewhat different from awx predecessor tower-cli and cannot simplybe done in a single atomic command. Rather you to first modify the job_templatewith the new extra-vars and then execute the command.
Over time, I found that many playbooks benefitted from having all role dependencies managed independently. That meant adding a requirements.yml file for that playbook, (usually, but not always) defining each role's version or Git commit hash, and adding an ansible.cfg file in the playbook project's root directory so Ansible would know to only load roles from that playbook's roles directory.
The first thing to do is setup tower-cli. This is a much better tool than curl to trigger Ansible Tower. From the webhook we will use tower-cli to update projects in Ansible Tower and launch workflows.
In Dialog, select the service dialog you created previously (in this example, ansible_tower_job). To ask the user to enter extra information when running the task, Service Dialog must be selected. A dialog is required if Display in Catalog is chosen.
Ansible has a default inventory file (/etc/ansible/hosts) used to define which remote servers it will be managing. Our public SSH key should be located in authorized_keys on remote systems.
SSH keys have already been created and distributed in your lab environment and sudo has been setup on the managed hosts to allow password-less login. When you SSH into a host as user student from ansible-1 you will become user ec2-user on the host you logged in.
aa06259810