This repository contains excercises with Ansible - Configuration Automation Tool.
To change the default inventory to hosts-dev and not use -i option all time: create ansible.cfg
Setup for AWS: upload setup-env.yml with changed to recent AMI ids, and your regions to CloudFormation
Checking the inventory configuration: ansible --list-hosts
NOTE: This also supports regular expressions and other types of calls, eg. ansible --list-hosts app*, ansible --list-hosts webservers:loadbalancers, ansible --list-hosts \!control, ansible --list-hosts webservers[0]
Installation comes on UNIX machines with python via pip/pipx.
Configuration on nodes must provide generally accesible SSH key (ssh-keygen) and copied to hosts (ssh-copy-id). Additionally ansible user can be created on control and host node, with visudo -> ansible_user ALL=(ALL) NOPASSWD: ALL premission.
- Basic building blocks of ansible execution.
- Oneliers for checking host status.
- They retrive return status of executed commands
- Tasks can be defined in playbooks
eg. ansible -m ping all
^ use module ping for inventory
Recepie for certain host groups, ordered from first to last.
They are composed from plays (map of host-tasks). In plays modules are used (eg. copy, service, etc.)
eg. ansible-playbook playbooks/ping.yml
Listeners for service config change. If change is made - service action is performed. Othervise service action is skipped
Compose playbooks for one system in single playboook file. This happens via importing subsequent playbooks
Ansible provides ANSIBLE_FACTS variable with all metadata about host.
Status module provides view into gathered information, eg. ansible -m setup app1
Jinja2 templating is used to evaluate variables.
Local variables are created with vars:as key-value pairs.
Variables can be registered from tasks by register: *name_of_variable*. They will contain outputs from it's task
Debug module displays variables contents and playbook information.
Used to group tasks together. Clean directory structure. Break configuration into files. Reuse code in similar configurations. Easy to modify and reduce syntax errors.
Initalize directory structure ansible-galaxy role init roles/webservers
It's a great way to write configuration in modular way.
Roles Ansible Galaxy - repository with jump starts for projects
Dry-run does not make cnhanges on remote systems, rather than this it return status check if configuration could make any changes.
eg. ansible-playbook playbooks/setup-webapp --check
Some modules might return non zero exit code and its okay (eg. command: /basg/false), or they might return change status when change was NOT made (eg. command: service httpd status)
In this scenarios one can use ignore_errors: yes and changed_when: false
Add them to specific tasks, so one can use specyfic parts of playbook.
Can be added to any resource.
Specify tags one want to run.
eg. ansible-playbook playbooks/setup-webapp.yml --tags upload
or skip specyfic tasks:
eg. ansible-playbook playbooks/setup-webapp.yml --skip-tags upload
Encrypts stored vault files. Vault can be shared via SCM. Vault can encrypt any data structure used by Ansible. Password protected. Default cipher is AES.
- create vault:
ansible-vault create vars/secret-variables.yml - edit vault file:
ansible-vault edit vars/secret-variables.yml - prompt for password:
ansible-playbook setup-app.yml --ask-vault-pass
Can be stored as ariables, run conditions based on them, ask for sensitive data.
To ask user a prompt, in a playbook file specify:
vars_prompt:
- name: "upload_var"
prompt: "Upload index.php file?"
tasks:
- name: Upload application file
copy:
src: ../index.php
dest: "{{ path_to_app }}"
when: upload_vars == 'yes'
tags: uploadAbove yml has a conditional based on user input in upload task (when: ...). When input is 'yes' it will proceed with task, otherwise it is omited.