Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Testing

When you want to make changes, make sure to commit them to staging or a new branch which you merge to staging.

Check that the staging branch automatically deploys properly.

If staging encounters no errors, merge staging with master. Do not delete the staging branch.

A box, manage_prod updates its copy of the repository every 2 minutes

  • Staging boxes are updated on 11, 22, 33, 44, and 55 every hour as a cronjob.
  • Production boxes are updated on 45 every hour as a cronjob

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
  5. Push your change to Bitbucket
  6. If you need to run the update sooner, manually run the update command in the main Ansible page.

If you need to test in something in staging which absolutely cannot run in production, such as a potentially destructive password edit turn off the cronjob in manage_prod.


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.

If you need to test in something in staging which absolutely cannot run in production, such as a potentially destructive password edit turn off the cronjob in manage_prod.

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

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

If you need to test in something in staging which absolutely cannot run in production, such as a potentially destructive password edit turn off the cronjob in manage_prod.



  • No labels