Under the hood

Overview

As stated in the installation instruction, HADeploy use Ansible under the hood to perform operation on the remote hosts. As such Ansible is defined as a dependency for HADeploy installation.

The main steps of an HADeploy run are the following:

  1. Load the application description by appending all --src files provided on the command line to build a single deployment file.

  2. Check syntax of this deployment file, based on a YAML schema.

  3. Build a data model in memory representing this file content.

  4. For all objects, Check when: clause and remove it if False.

  5. Check this data model for consistency, enrich it, or transform some data to ease the next stages.

  6. Generate a Jinja2 template by concatenating all template snippets provided by the plugins.

  7. Render this template with the model to generate an Ansible playbook

  8. Launch Ansible on this playbook.

Variables

When using HADeploy in an advanced way (i.e using the ansible module, or developing your own plugin), you may be disturbed by different variable notation. There is in fact 3 kinds of variables involved in HADeploy

${my_variable}

Or <<my_variable>>

This is the only variable notation you should be aware of for standard usage of HADeploy.

Such variables are resolved during step 1 (Building of the deployment file).

Refer to alternate notation for the motivation of using <<my_variable>>.

{{{my_variable}}}

This is the variable notation used during the rendering of step 6. This will allow all snippets provided by the plugin to access variables of the model.

{{my_variable}}

This is the standard variable notation used by Ansible. HADeploy will not resolve such variables, passing them as is to Ansible playbook. So they will be resolved by Ansible in step 7.

This form need generaly to be quoted ("{{my_variable}}"). It must also be used for encrypted values

Variable relationship

Although this variables act at different level, there is some mechanism to propagate user's value (The one with ${..} notation) to lower level.

The working folder

In case of problem, it could be useful to have a look on the generated Ansible playbook. This playbook is generated in a temporary folder, called the working folder. It is named as the action provided as parameter.

This folder is automatically created in /tmp, under a random name. To ease debugging, one can force this working folder to a specific location, using the --workingFolder command line option.

Warning: In such case, the full content of the working folder will be deleted on each run...

But, this working folder not only contains the playbook. Here is a brief description of the files you may found in it:

Name Description
ansible.cfg
inventory
group_vars folder
HAdeploy create a complete Ansible context to run Ansible inside.
<action>.yml.jj2 This is the Jinja2 source template, result of step 5 above, which will be merged with the data model to produce the file below.
<action>.yml The playbook for targeted action, generated on step 6. i.e deploy.yml or remove.yml.
model_src.json This is the part of the data model built from the sources file.
model_data.json This is a the part of the data model where HADeploy store some intermediate structure.
model_helper.json This is a part of the data model hosting some configuration information.
schema.yml This is the YAML schema used to validate source input files. Will use pykwalify tool for validation.
desc_xxxx.yml.j2 Some helper files, specific to some plugins.

Note: If you launch HADeploy with --action none then it will generate ansible playbooks for all action it is aware off. But, it will not launch ansible. This is intended to validate description for all action.

Plugins

A plugin is a component which may be involved in all phases described at the befinning of this page. It is typically made of:

All theses are optional. A plugin can also host:

Currently, HADeploy is provided with the following internal plugin:

Embedded Ansible roles

Embedded Helpers

Hive

HBase

Kafka