Bowe Strickland
2020-03-09 cb0b2619b9e8271f5a9b2f9b1a6b8d66ced3af9a
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
= Galaxy and external roles
 
To use galaxy roles in your config, just do the following:
 
. Create `requirements.yml` file in the config directory, for example:
+
.`ansible/configs/{{env_type}}/requirements.yml`
[source,yaml]
----
---
- src: geerlingguy.docker
  name: docker
  version: '2.5.1'
----
. Use the role in the playbooks
+
.`ansible/configs/{{env_type}}/pre_software.yml`
[source,yaml]
----
- name: Some play
  hosts:
    - myhosts
  become: true
  gather_facts: False
  tasks:
    - name: install docker
      include_role:
        name: docker
----
 
[NOTE]
====
Note that in the previous example, we use `include_role` which is *dynamic*. If you try to use the role with `role` or `import_role` it will fail because the role is dynamically downloaded at runtime.
====
 
[IMPORTANT]
====
Please use a pinned `version` in the `requirements.yml` file so the success of the deployment of your config does not depend on the stability of upstream galaxy roles.
 
[source,yaml]
.Make sure you use version pinning in `requirements.yml`
----
- src: geerlingguy.docker
  name: docker
  version: '2.5.1'
----
====
 
 
When you run Ansible Agnostic Deployer, it will automatically fetch and create the role in your config directory: `ansible/configs/{{env_type}}/roles/docker` for example.
 
== Non-Galaxy external roles
 
Roles in `requirements.yml` don't have to be in Galaxy, you can use any git repo.
 
[source,yaml]
.Another example of `requirements.yml` with git repo
----
---
# External role to setup grader host virtualenv and FTL grading infra
 
- src: https://github.com/redhat-gpte-devopsautomation/ftl-injector
  name: ftl-injector
  version: v0.7
----
 
== Development workflow
 
During development, the roles will be deployed and get in your way git-wise. To avoid that, there is a rule in the top-level link:../.gitignore[`.gitignore`] to ignore those dynamic roles:
 
.gitignore
----
ansible/configs/*/roles
----
The convention is:
 
> the "static" roles, those versioned in this repository, must live in link:../ansible/roles[`ansible/roles`] and the "dynamic" roles in your config directory `ansible/configs/{{env_type}}/roles`.
 
NOTE: Dynamic roles are not pushed in git, only the `requirements.yml` file is versioned.
 
 
== Multiple requirement files
 
Sometimes, for the same config, we need several `requirements.yml`. For example, one for PROD, one for DEV, etc.
 
You can create as many files as you want. When calling the playbook just override the `requirements_path` variable:
 
[source, bash]
----
ansible-playbook main.yml -e requirements_path=ansible/configs/{{env_type}}/requirements-prod.yml [...]
----