This repository has been archived by the owner on Nov 12, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathConventions
94 lines (64 loc) · 3.5 KB
/
Conventions
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
92
93
94
This file describes some conventions we are going to try and use
to keep things organized and everyone on the same page.
If you find you need to diverge from this document for something,
please discuss it on the infrastructure list and see if we can
adjust this document for that use case.
Playbook naming
===============
The top level playbooks directory should contain:
* Playbooks that are generic and used by several groups/hosts playbooks
* Playbooks used for utility purposes from command line
* Groups and Hosts subdirs.
Generic playbooks are included in other playbooks and perform
basic setup that is used by other groups/hosts.
Examples: cloud setup, collectd, webserver, iptables, etc
Utility playbooks are used by sysadmins command line to perform some
specific function. Examples: host update, vhost update, vhost reboot.
The playbooks/groups/ directory should contain one playbook per
group. This should be used in the case of multiple machines/instances
in a group. MUST include a hosts entry that describes the hosts in the group.
Examples: packages, proxy, unbound, virthost, etc.
Try and be descriptive with the name here.
The playbooks/hosts/ directory should contain one playbook per 'host'
for when a role is handled by only one host. Hosts playbooks
MUST be FQDN.yml, MUST contain Hosts: the host or ip.
Examples: persistent cloud images, special hosts.
Where possible groups should be used. Hosts playbooks should only
be used in specific cases where a generic group playbook would not work.
Play naming
===========
Plays in playbooks should be a short readable description of what the play
is doing. This will be displayed to the user and/or mailed out, so think
about what you would like to see if the play you are writing failed that
would be descriptive to the reader to help fix it.
Inventory
=========
The inventory file should add all hosts to one (or more) groups.
*FIXME: need to elaborate here quite a bit more.*
Production vs Development
====================================
In the meanwhile we should be careful to leverage --check, and thoroughly vetting plays as they merge up to master.
Requirements:
1. shouldn't touch prod playbook by default
2. should be easy to merge changes back to prod
3. should not require people to 'remember' to do a bunch of steps. ideally, a playbook should be able to run with no added options or user input required.
4. should be easy to see exactly if and what changes are made.
*FIXME: We need to establish some standards for how things can be considered "production ready"*
Cron job/automatic execution
============================
FIXME: I am keeping this block in for now but I don't see this[cron executed plays] as being a practice we adopt soon. We would first need proper roles and master.yml
We would like to get ansible running over hosts in an automated way.
A git hook could do this.
* On commit:
If we have a way to determine exactly what hosts are affected by a
change we could simply run only on those hosts.
We might want a short delay (10m) to allow someone to see a problem
or others to note one from the commit.
* Once a day: (more often? less often?)
We may want to re-run on all hosts once a day and yell loudly
if anything changed.
FIXME: perhaps we want a tag of items to run at this time?
FIXME: alternately we could have a util playbook that runs a
bunch of checks for us?
FIXME: establish tags
> Written with [StackEdit](https://stackedit.io/).