Ansible role - ghdrako/doc_snipets GitHub Wiki

Roles provide a framework for fully independent, or interdependent collections of variables, tasks, files, templates, and modules.

<playbook>.yaml
roles/
  <role>/
  tasks/
  handlers/
  library/
  files/
  templates/
  vars/
  defaults/
  meta/
  • tasks: This directory contains a list of tasks' yaml files. It should contain a file called main.yaml (or main.yml or main), containing the entire list of tasks or importing tasks from other files within the directory.
  • handlers: This directory contains a list of handlers associated with the role within a file called main.yaml.
  • library: This directory contains Python modules that can be used with the role.
  • files: This directory contains all files that we require for our configuration.
  • templates: This directory contains the Jinja2 templates that the role deploys.
  • vars: This directory contains a main.yaml file with a list of variables associated with the role.
  • defaults: This directory contains a main.yaml file containing the default variables associated with the role that can be easily overridden by any other variable that includes inventory variables.
  • meta: This directory contains the metadata and dependencies associated with the role within a main.yaml file.

Tip

While choosing between the vars and defaults directories, the thumb rule is to put variables that will not change within the vars directory. Put the variables that are likely to change within the defaults directory.

Tip

Think about the full life cycle of a specific service while designing roles rather than building the entire stack, in other words, instead of using lamp as a role, use apache and mysql roles instead.

Tip

Use specific roles, such as apache or mysql, instead of using webserver or dbserver. Typical enterprises have a mix and match of multiple web server and database technologies. Therefore, giving a generic name to a role will confuse things.

In Ansible, the role is the primary mechanism for breaking a playbook into multiple files. This simplifies writing complex playbooks, and it makes them easier to reuse. The breaking of playbook allows you to logically break the playbook into reusable components.

Roles are not playbooks. Roles are small functionality which can be independently used but have to be used within playbooks. There is no way to directly execute a role. Roles have no explicit setting for which host the role will apply to.

Top-level playbooks are the bridge holding the hosts from your inventory file to roles that should be applied to those hosts.

Role Structure

Roles have a structured layout on the file system. Each role is a directory tree in itself. The role name is the directory name within the /roles directory.

$ ansible-galaxy -h 
ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...

Rola to zbiór zadań (tasks), uchwytów (handlers), plików (files), metainformacji (meta), szablonów (templates) i zmiennych (vars).

mkdir ­p roles/web_server/{files,handlers,meta,templates,tasks,vars}

Create Role Directory

ansible-galaxy init --force --offline vivekrole
Meta

Meta zawiera metainformację – np. zależność od innych ról, minimalną wersję ansible, nazwę autora dla ansible-galaxy itp.

meta/main.yml:
dependencies: []
Files

Do files wrzucamy statyczne pliki, które umieszczamy na serwerze. Mogą być to gotowe konfiguracje niewymagające od nas szablonowania. Np configuracje nginxa , definicje serwisy systemd itd

Vars

W naszych zmiennych będziemy trzymać nazwę domenową projektu, jego położenie, środowisko virtualne i nazwę aplikacji i adres repozytorium gitowego.

­­­--- vars/main.yml: domain: helloworld.local virtenv_dir: /var/app/hello_virt_env app_dir: /var/app/hello uwsgi_ini_name: hello_uwsgi.ini app_name: hello git_repo: https://github.com/EuroLinux/hello_world_django2.git




#### Utilizing Roles in Playbook
  • hosts: tomcat-node roles:
    • {role: install-tomcat}
    • {role: start-tomcat}
⚠️ **GitHub.com Fallback** ⚠️