Advanced Ansible CLILast updated: 15 October 2020

Considering Ansible Vault

When starting off with Ansible Vault, it’s important to understand why someone would choose to use this.
Whilst it’s not recommended for your run-of-the-mill quick test lab. The moment you want to take your Ansible use to the next level there will be some confidential information you might not want to share or have someone take advantage of in case the project gets leaked.
Therefore, Ansible created Ansible VAULT: This is a tool that enables their users to encrypt their playbooks and password-protect them as its main feature. The other notable feature is encrypting specific variables inside your YAML files.

Using Ansible Vault

To start/enable this feature it is required to type the following command inside of your command line window: ansible-vault.
Followed by one of its uses directly after prompting for a password (or the password file location).

• Encrypt example.yml - This encrypts an already existing file.
• Decrypt example.yml - This decrypts an already existing file.
• Create example.yml - Creates an encrypted file.
• Edit example.yml - Only way to edit a file which has been encrypted by Ansible vault – see above TIP for inline editor change.
• Rekey example.yml - To change the original password – you will be prompted first for the original before the new one.
• Encrypt_string - This encrypts a specific variable.
• View example.yml - To view an encrypted file.

If everything went correctly, and you’d like to use an encrypted playbook instead of using Ansible-playbook example.yaml. To run the file, you will now have to provide the ansible with a password or a password location to be able to run the playbook and this would be done by adding --ask vault pass at the end of your command forming ansible-playbook example.yml --ask-vault-pass for the password prompt version.
And --vault-password-file pass.txt at the end of your command forming ansible-playbook --vault-password-file pass.txt for the password file version which doesn’t require any further actions from the user. However, doing so will leave the password file unencrypted so at the very least it is recommended to change the user rights on it with chmod 400 pass.txt so that only the file owner has read only access to it.

Lastly there is one more option to store and retrieve your vault passwords assuming you run Ansible version 2.4 or higher; Vault ID’s.
Before I continue with the explanation on how to set them up, I’ll describe how to use the password to finish of the quick overview. To use an ansible vault id password you must type in the following: --vault-id passfile1@vault1 at the end of your command forming ansible-playbook example.yml –vault-id pass1@vault_pass_file.txt for the vault id version. Do note that using vault id you can have multiple passwords inside of 1 file. The needed password is specified with “pass1” In this case from the “vault_pass_file.txt” file. In case you’d like to enter the password manually you can also use –vault-id pass1@prompt to be prompted for the file.

And now for the actual explanation of Vault IDs:
Simply Vault IDs provide a way to identify passwords from a source thanks to a label.

[defaults]
inventory = inventory
remote_user = root
vault_identity_list = inline@~/ansible/.inline_pass , files@~/ansible/.files_pass

--vault-id label@source in this case ansible vault would look for a password labeled “label” in a file called “source”. Alternatively, you can use --vault-id label@prompt to have Ansible prompt you for the password.
However, it is not enough to type in the above code snippets as Vault IDs need to be preconfigured in your ansible.cfg file before use. As an example, we have 2 password files declared here: inline and files at their corresponding locations. Both contain an unencrypted passphrase with the password and will have to be called using inline@prompt or inline@file_source (~/ansible/.inline_pass)

Encrypt_string output breakdown

Seeing as the encrypt_string output might be confusing at first, we will also explain what all the visible variables mean from the initial code snippet to the output.

 ansible-vault encrypt_string --vault-password-file pass.txt 'testing' --name 'secret_password'

Secret_password: !vault | 
  $ANSIBLE_VAULT;1.1;AES256 
  62313365396662343061393464336163383764373764613633653634306231386433626436623361 
  6134333665353966363534333632666535333761666131620a663537646436643839616531643561 
  63396265333966386166373632626539326166353965363262633030333630313338646335303630 
  3438626666666137650a353638643435666633633964366338633066623234616432373231333331 
  6564

• The variable name secret_password, followed by !vault |, indicates that the vault is encrypted.
• The vault version that supports the vault ID is 1.1.
• The AES cipher in 256 bits is represented by AES256.

--vault-id example

ansible-vault encrypt_string --vault-id test@source 'testing' --name 'secret_password'

Secret_password: !vault | 
  $ANSIBLE_VAULT;1.2;AES256;test 
  30613233633461343837653833666333643061636561303338373661313838333565653635353162 
  3263363434623733343538653462613064333634333464660a663633623939393439316636633863 
  61636237636537333938306331383339353265363239643939666639386530626330633337633833 
  6664656334373166630a363736393262666465663432613932613036303963343263623137386239 
  6330

• The variable name secret_password, followed by !vault |, indicates that the vault is encrypted.
• The vault version that supports the vault ID is 1.2.
• The AES cipher in 256 bits is represented by AES256.
• The vault ID in use is test.

Considering Ansible Galaxy

As promised at the beginning of this chapter we will also look at something that might help you speed up the process of automation. we're talking about Ansible Galaxy of course. Ansible Galaxy is a community driven tool. Or rather a repository of community made roles and collections for all your automation needs.
The reason you may want to consider using the resources provided by Ansible Galaxy is quite simple: Time.

Every time we come up with the need to automate we tend to be either short on time or not knowledgeable enough of the subject to be efficient in the process. That’s where something like a community made resource can come in handy as a reference or a quick and dirty way to see how far along you are with your test environments without the need to start from ground up.

Finding content on Ansible Galaxy

There are 2 main ways to search for content available on Ansible Galaxy:

• Using the Command Line Interface
• Using the Web Interface

Using the Command Line Interface

Following that you’d type in the following in your CLI:
ansible-galaxy info xxxx (Substituting xxxx for the name of your search – bennojoy.ntp for out example).


And by repeating these 2 steps you can get to know what your search is all about and on which versions it works.

Using the Web Interface

• Type - e.g Development, Networking etc.
• Keywords - Through plain search
• Community authors - For your trusted authors and their commits
• Partners - Not a standardized option but available through the Partner Website

As with every previous theme around Ansible Galaxy installation and usage is simple and fast. Ansible Galaxy is installed by default with your Ansible installation and to install a role you’ve found you simply need to type in the following in your CLI:

ansible-galaxy install contributor_name.role

ansible-galaxy install --roles-path ~/ansible-roles contributor_name.role

• Installing a specific version by adding a coma and the version number as stated below

ansible-galaxy install geerlingguy.apache,v1.0.0

• Installing a specific GIT commit by following install with git+branch name orgit+commit hash

ansible-galaxy install git+https://github.com/geerlingguy/ansible-role-apache.git,0b7cd353c0250e87a26e0499e59e7fd265cc2f25

• Installing multiple roles from one or multiple files
To do this you’d make a file named requirements.yml with .yml or .yaml extension. And execute the following command:


ansible-galaxy install -r requirements.yml

Below you can find an example requirements.yml file referenced from the Galaxy documentation.

# from Galaxy 
- src: yatesr.timezone 
	
# from GitHub 
- src: https://github.com/bennojoy/nginx 
	
# from GitHub, overriding the name and specifying a specific tag 
- src: https://github.com/bennojoy/nginx 
	version: master 
	name: nginx_role 
	
# from a webserver, where the role is packaged in a tar.gz 
- src: https://some.webserver.example.com/files/master.tar.gz 
	name: http-role 
	
# from Bitbucket 
- src: git+http://bitbucket.org/willthames/git-ansible-galaxy 
	version: v1.4 
	
# from Bitbucket, alternative syntax and caveats 
- src: http://bitbucket.org/willthames/hg-ansible-galaxy 
	scm: hg 
	
# from GitLab or other git-based scm 
- src: git@gitlab.company.com:mygroup/ansible-base.git 
	scm: git 
	version: "0.1" # quoted, so YAML doesn't parse this as a floating-point value

Now seeing as this block has multiple variables added to the roles we will now go through them:

• Src - Source of the role and its required attribute.
• Scm - If the src field is a URL it needs to be specified with either git or hg. The default is set to git.
• Version - Version of the role. The following options are possible: tag value, commit hash or branch name. The default is set to master.
• Name - To override the name with which the role is installed.

ansible-galaxy install -r requirements.yml

Contributing content

The last topic around Ansible-Galaxy that we’re going to explore is the creation and contribution of content. Which will also introduce the last of the most common commands used with Ansible Galaxy init. For example, if you’d decide to create a new role the command, you’d be looking for is:

ansible-galaxy init my_new_role

|.travis.yml 
|README.md 
|defaults 
| | main.yml 
|files 
|handlers 
| | main.yml 
|meta 
| | main.yml 
|tasks 
| | main.yml 
|templates 
|tests 
| | inventory 
| | test.yml 
|vars 
| | main.yml

Once you populate your role with the desired configurations the next step you will need to take is to populate the metadata of your role. Seeing as Galaxy takes a look into your metadata file for all its content information it is important to populate it as fully and concise as possible. You can find the default metadata file created by init command below.

galaxy_info: 
 role_name: foo 
 author: your name 
 description: your description 
 company: your company (optional) 

 # If the issue tracker for your role is not on github, uncomment the 
 # next line and provide a value 
 # issue_tracker_url: http://example.com/issue/tracker 

 # Some suggested licenses: 
 # - BSD (default) 
 # - MIT 
 # - GPLv2 
 # - GPLv3 
 # - Apache 
 # - CC-BY 
 license: license (GPLv2, CC-BY, etc) 

 min_ansible_version: 1.2 

 # If this a Container Enabled role, provide the minimum Ansible Container 
 # version. 
 # min_ansible_container_version: 

 # Optionally specify the branch Galaxy will use when accessing the GitHub 
 # repo for this role. During role install, if no tags are available, 
 # Galaxy will use this branch. During import Galaxy will access files on 
 # this branch. If Travis integration is configured, only notifications for   
 # this branch will be accepted. Otherwise, in all cases,
 # the repo's default branch (usually master) will be used. 
 # github_branch: 
 # 
 # platforms is a list of platforms, and each platform has a name and a 
 # list of versions. 
 # 
 # platforms: 
 # - name: Fedora 
 #   versions: 
 #   - all 
 #   - 25 
 # - name: SomePlatform 
 #   versions: 
 #   - all 
 #   - 1.0 
 #   - 7 
 #   - 99.99 

 galaxy_tags: [] 
  # List tags for your role here, one per line. A tag is a keyword 
  # that describes and categorizes the role. Users find roles by searching 
  # for tags. Be sure to remove the '[]' above, if you 
  # add tags to this list. 
  # 
  # NOTE: A tag is limited to a single word comprised of 
  # alphanumeric characters. 
  #       Maximum 20 tags per role. 

 dependencies: [] 
  # List your role dependencies here, one per line. Be sure to remove the '[]'  # above,if you add dependencies to this list.

Whilst most of the information in your metadata file is optional the only required field is Platforms. In which you need to provide the platform that is compatible with your role and the versions you’ve tested on. All the other fields are optional. After which you can upload your file to GitHub or Travis and from there import it to your Ansible Galaxy account.

The other “thing” you can create and share is your Playbook bundle. The principle is mostly the same with the command changing slightly to:

ansible-galaxy init –type apb my_new_apb

|.travis.yml 
|Dockerfile 
|Makefile 
|README.md 
|apb.yml 
|defaults 
| |main.yml 
|files
|handlers
| |main.yml 
|meta
| |main.yml 
|playbooks
| |deprovision.yml 
|provision.yml 
|tasks
| |main.yml 
|templates
|tests
| |ansible.cfg 
| |inventory 
| |test.yml 
|vars
| |main.yml