Ansible: Difference between revisions

From Leo's Notes
This page was last edited on 14 September 2020, at 06:06.
dumping notes in, a WIP
Added see also links
Line 1: Line 1:
== Quick Overview ==
==Quick Overview==
Ansible is an open source application that automates configuration management and software/application deployment. It manages remote hosts via SSH or PowerShell. Tasks can be executed on one or more machines which can be on different networks. Hosts can be targeted specifically or by groups defined in an inventory file.
Ansible is an open source application that automates configuration management and software/application deployment. It manages remote hosts via SSH or PowerShell. Tasks can be executed on one or more machines which can be on different networks. Hosts can be targeted specifically or by groups defined in an inventory file.


Line 10: Line 10:
Ansible uses Jinja as its template engine and can be used to render configuration files.  
Ansible uses Jinja as its template engine and can be used to render configuration files.  


== Getting Started ==
==Getting Started==
The quickest way to get your toes wet with Ansible is to try it out with a small set of Docker containers.  
The quickest way to get your toes wet with Ansible is to try it out with a small set of Docker containers.  
{{Highlight
{{Highlight
Line 202: Line 202:
         enabled: yes
         enabled: yes
| lang = yaml
| lang = yaml
}}<br />
}}
 
== See Also ==
There are lots of resources online to help you get started. Some guides I've stumbled across which I found helpful were:
 
* https://coyote.systems/blog/devops/learning-ansible-with-docker
* https://www.digitalocean.com/community/cheatsheets/how-to-use-ansible-cheat-sheet-guide
 
To set up the initial user, use something like the following. Use --ask-pass when running the playbook so that you log in using a password first, then this playbook will set up the SSH keys.
 
* https://medium.com/@khandelwal12nidhi/setup-ssh-key-and-initial-user-using-ansible-playbook-61eabbb0dba4

Revision as of 06:06, 14 September 2020

Quick Overview

Ansible is an open source application that automates configuration management and software/application deployment. It manages remote hosts via SSH or PowerShell. Tasks can be executed on one or more machines which can be on different networks. Hosts can be targeted specifically or by groups defined in an inventory file.

Commands are executed through modules. Modules can take in any number of variables. Modules can also return data back to Ansible which can be used later on by other modules. Common modules that are in use are shell, for running shell commands. A single module can be executed via the ansible command. Multiple modules can be executed through the use of a playbook which describes the list of tasks to perform.

Inventory contains a list of hosts managed by Ansible. By default, it uses the hosts file at /etc/ansible/hosts. However, this can be changed to something else such as a static .ini file, a .yaml file using the -i parameter or to some dynamic method of obtaining hosts.

Tasks are used by playbooks to execute a module with a specific set of arguments. Ansible goes through a playbook in sequential order as it executes tasks that match the host pattern that is given.

Ansible uses Jinja as its template engine and can be used to render configuration files.

Getting Started

The quickest way to get your toes wet with Ansible is to try it out with a small set of Docker containers.

# docker run -d -P -v ansible:/opt/ansible --name ansible --hostname ansible ansible
# docker run -d -p :22 --name nodea --hostname nodea node
# docker run -d -p :22 --name nodeb --hostname nodeb node
# docker run -d -p :22 --name nodec --hostname nodec node

You may want to turn off SSH host key checking by creating an ansible.cfg file:

[defaults]
host_key_checking = false

You can then ping all the nodes by running:

# ansible -i inventory.ini all -m shell -a 'hostname'


ansible -m shell -a 'whoami' all


ansible -b -K -m user -a 'name=testuser' all

-b for sudo

-K to ask for sudo password

-a to specify a variable, such as a user.


roles is a list of actions to run on a target machine in a given order

playbooks determine which roles to run


mkdir roles/basic/tasks

vi roles/basic/tasks/main.yaml

-name: 'install vim'

apt: pkg=vim state=installed


playbook.yaml

- hosts: all

become: true

roles:

- basic


ansible-playbook playbook.yaml

pass in -K to run as sudo as well


roles can be passed lists

-name: 'install item'

apt: pkg={{item }} state = installed

with_items:

- asdf


copy files over

-name: 'add file'

copy: src=./pwd/files/bash.bashrc dest=/etc/bashrc owner=root group=root mode=0644

files are copied from the role's sub directory.

mkdirroles/basic/files/bash.bashrc


run shell command with the shell module

-name: 'run something'

shell: creates=/asdfasdf mv /etc/bashrc /home/bash.rc

Runs command if the creates file does not exist.



Inventory

Either static (.ini or .yaml) or dynamic. Located at /etc/ansible/hosts and each host may define specific parameters.

[webservers]
web1.example.com ansible_user=bob
web2.example.com  ansible_host=192.168.81.142 ansible_port=3333

[apservers]
ap1.example.com
ap2.example.com

[dbservers]
db[01:10].example.com

Can be grouped (webserers, apservers), or left ungrouped at the very top (for .ini files only). The 'all' group captures everything too. Groups can be nested. Use the ':' in group names for .ini files to represent hierarchy. Ranges can also be specified with brackets.

ansible -i /path/to/inventory all -m shell -a 'echo hello world' -f 5

Additional variables can be set as well. Variables can either be set to each host, or to a group. Since groups can be nested, the most immediate group variable takes presidence.

Playbooks

A series of tasks to configure something can be bundled into a playbook. Playbooks can be applied with the ansible-playbook command.

When applying a playbook, the recap will output the following:

  • ok - task ran successfully with no changes being made
  • changed - task ran successfully with changes being made
  • failed - task failed to run
  • unreachable - host was unreachable
  • skipped - task was skipped
  • ignored - task was ignored
  • rescued - ?

playbooks look like this:

---
- name: Handler demo 1
  hosts: frt01.example.com
  gather_facts: no
  become: yes

  tasks:
    - name: Update Apache configuration
      template:
        src: template.j2
        dest: /etc/httpd/httpd.conf
      notify: Restart Apache

    - name: restart all services
      command: echo "this task will restart all services"
      notify: "restart all services"

  handlers:
    - name: Restart Apache
      service:
        name: httpd
        state: restarted
      listen: "restart all services"

Handlers can be called with notify. Handlers can also listen for a specific event with the listen directive.

Loops can be done by specifying a list of items:

---
- name: Install Apache
  hosts: frt01.example.com
  gather_facts: no
  become: yes

  tasks:
    - name: Install Apache package
      yum:
        name: httpd
        state: latest
    - name: Open firewall for Apache
      firewalld:
        service: "[[:Template:Item]]"
        permanent: yes
        state: enabled
        immediate: yes
      loop:
        - "http"
        - "https"
    - name: Restart and enable the service
      service:
        name: httpd
        state: restarted
        enabled: yes

See Also

There are lots of resources online to help you get started. Some guides I've stumbled across which I found helpful were:

To set up the initial user, use something like the following. Use --ask-pass when running the playbook so that you log in using a password first, then this playbook will set up the SSH keys.