Editing Ansible

Owned by Former user (Deleted)
Last updated: Aug 23, 2021 by Eddie Rubeiz
3 min read

Development Workflow

Take a look at

Variable Structure

Ansible looks at a number of different files when building or updating a box. When looking for a variable, use the following guide to decide where to check for a variable or where to place one. All variables are in the group_vars folder.

  1. all: Holds variables that are unlikely to ever change between production and staging, such as ssh accounts, project name, or AWS region. As per ansible documentation, any variable here will be overridden by the same variable in another folder.
  2. prod/stage: Holds variables that will differ between production and staging. This includes domain names, AWS key, or security groups.
  3. app/fedora/solr/jobs: Holds variables that will be consistent between all servers sharing the same role. The application variables, box name, and disks tend to be here. This is weighted equally with prod/stage, so duplicate variables will be resolved in alphabetical filename order. This is also where variables that are only needed for a specific role are placed.
  4. X_Y_override: Each combination (app_prod, app_stage, etc) has an override file. This overrides all other variables. This is where variables are added which don't fit the above pattern. For example, the security groups on app_prod and app_stage. All app boxes need extra security groups to allow http/https access for the website. This should not be in prod/stage since the other boxes of that service level do not need to be web accessible. It cannot be in app since the two app boxes will have different security groups for controlling access. Thus there needs to be an override to treat those boxes uniquely.

When checking for a variable, the above guide should help indicate where the variable is likely to be stored. When you add new variables, ask yourself where they are likely to differ and place it in the file that best fits.

All override notes assume you run the commands as described in the Ansible page or allow the cronjob update tasks to run them.


Editing templates

Editing an existing template file involves the following steps.

  1. Locate the file. Ansible files are pushed out from role/ROLENAME/templates or role/ROLENAME/file  files in templates have variables while files in the file directory are static.
    1. At the moment a role guide to help locate files isn't written, the usual name pattern for a template is file_name.extension.j2 where j2 is the jinja2 extension. Search for the file name to find it if you're not sure what role it might be in.
  2. Edit the file with the new value(s).
  3. Edit the group_var file(s) with the values you need.
  4. Commit your change and push it to the repository.

Editing tasks

Ansible tasks are the default way to accomplish an action. We are using the role structure when designing new actions for Ansible, so when making a new set of tasks you will want to

  1. Create a folder in the roles directory (names should use _ and lower case)
  2. In the new role folder, add a tasks folder.
  3. Create a file called main.yml

When editing existing tasks, please make sure to test any tasks on staging with manual runs before you push changes up to the main branch.

See Editing Templates for the process to update and push out changes.

Editing handlers

Ansible handlers are tasks which only run when notified by another task that it has changed something. This is the preferred method to handle restarting or modifying services. This avoids potential downtimes or restarts when changes are not made to the machine's state.

All handlers are located in role/role_name/handler

Tasks which send an alert to the handler use notify: handler name