Overview
========

Directory Structure
-------------------------

- data  - see next topic "Dynamic Data Structure"
- doc   - sphinx documentation
- inventory/dyn   - python code to generate inventory from data
- filter_plugins  - filter to modify content (python)
- roles           - roles used by playbooks including
  templates and files to be copied to systems and
  additional .yml and .py code
- playbooks       - older playbooks not migrated to dynamic datadir

On the top level, there are playbooks (prefixed with ``playbook_``).
See :ref:`chapter_playbooks`.


Dynamic Data Structure
-------------------------
The ``data`` directory contains a hierarchies ("users" and "hosts") of YAML
dictionaries.
They control which hosts are deployed and how.

A __defaults file can contain a set of values that are applied to all
dictionaries in or below the current directory.
A __transforms file can contain hooks used during the loading process.
Currently, there's only a ``on_load`` transform.


Hosts
~~~~~~~~~~~~~~~~~~~~~~~~
Host are stored in folders below ``./data/hosts/``. Sub-folders are used for
departments and customers.

Users
~~~~~~~~~~~~~~~~~~~~~~~~
Users are stored in separate files in ``./data/users/``. These contain the
ssh-keys for accessing the systems, the department for which the user is
working.


Targeting Systems
-----------------------------------
You can target systems by name, and by ansible_groups. You can use wildcards
like ``hlc*``.

Following ansible_groups are actually defined: project_realization,
peterlackegroup, internal, internal_prod, internalit


How SSH-Keys are deployed
-------------------------

General permission are granted by giving a user access for a departement.
Example: ``data/users/mmustermann``

.. code-block:: yaml

  departments:
    - project_realization
    - internal
    - internalit
    - internal-prod
    - key_account



We also manage the ssh-keys for froneri-customers. They get the department
via the default file in ``data/users/froneri/__defaults``

Additional permissions can be granted for each single system. This is normally
only the case on internal perfact systems.
Example: ``data/hosts/internalit/tyke``

.. code-block:: yaml

  ssh_allow_user_access:
    - lars
    - fscheja
    - draeder
    - rstock
    - maren
    - holger


Finally ssh-keys can be added that don't belong to any user.
Example: ``data/hosts/internal/perfact-ema-2020-devel``

.. code-block:: yaml

  extra_ssh_keys:
    # Allow source-system access
    - 'from="192.168.51.20" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCwGpxuNam0l4l28mICDt016obYDrU4sfwbjq/t7SAfxHGzrwX2UkkMqynz3pIh2+M5ME2hozLYaYnBbiWueMn60R+ihwic8E1miDjEoY5WYpo5rrHvZuCISHPkP7SnSilMVSNrpYX+Nefvc85t6wpKYHMNrCU6JEU+qaYzosonwtM/8tQlozbmgd4wk1yihbGm7GAhlnAufRg77gje2vf71QiGT9TreWWQhmS8KKkWhqFzHsbHWQzTGhbjFciGW93RH9+zx66XTW+tlfFF65Rd21BQGuN+Q9rvoJFW7aBauEpHLDaKAaPrdHPjk8rrwWe1qQce7/vnESwmok9JeuOFumJSVL8k5Kumd8rgtFfT8r5Tq1Rh7C4K7/E1nNNI1Jz1ppDohjo5xgjotaR8FjpeAV4jne1oSn/7rUZ8iPV3bYenN1AizY2qt+XunzkUWhp0rQb3RDYn3qCxWO/knClO5Q1cqiww4at13NKTUnmrOudrc49BuOSSrMcXgYehnCs= perfact@perfact-ema-2020-devel'