-
Notifications
You must be signed in to change notification settings - Fork 1
/
notes
72 lines (41 loc) · 3.57 KB
/
notes
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
Initial vagrant-salt setup
http://cnygaard.quora.com/Using-Vagrant-and-Salt-stack-together
salt states reference:
http://docs.saltstack.com/en/latest/ref/states/index.html
Repo with examples:
https://github.com/saltstack/salty-vagrant
it is deprecated. for use only as examples
grains is that system used to derive informations about the undelying system (like ohai and facter)
had issues with vagrant salt and centos 7.0. there seem to be some bugs in the dependency management
of bootstrap script.
in the configuration file of the minion we must not use a master line. If we do that the minion will try to connect to the master and eventually timeout. we only need to define file_client: local
mind the spaces after the colon
the first run does a yum update so takes some time.
in an sls directory
one sls file can include others creatign that way a tree structure of state files
there is a templating engine that can be used for sls files, called jinja
saltstack best practices here:
http://docs.saltstack.com/en/latest/topics/best_practices.html
salt formulas here:
http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
According to the documentation it is enough to include the official formulas in the top sls and they will be retrieved from the default formula repo
in order to do that we need to set up gitfs. this can be used with any git repo. it seems that this is not supported in the masterless mode: https://groups.google.com/forum/#!topic/salt-users/FL0rTKouA9I
example formula with kitchen-salt support is postgres formula: https://github.com/saltstack-formulas/postgres-formula
update seems to be a standard operation no matter which platform is used. same thing happens with ubuntu too
salt file layout:
Directory structure
Before diving onto how exactly we target minions, we must learn how Salt normally stores its states and Pillar information on the master.
The configuration files for the master are in /etc/salt/, the main one being /etc/salt/master. However the state files (sls files) are usually stored in /srv/salt. Pillar files are usually stored in /srv/pillar. Each of these directories has a file called top.sls that indicates which minions are subject to which states/Pillar files. The configuration files for the minion are in /etc/salt also, the main one being /etc/salt/minion.
Salt has support for a multienvironment setup that allows for a minion to use a different set of aggregated directories from which to pull states/Pillar based on this grains and Pillar data, but for the purposes of this tutorial and the sake of simplicity, we'll assume that there are no shenanigans, so all sls files are stored directly under /srv/salt and all Pillar files are stored under /srv/pillar, following a plain directory structure.
---------
if there is any error with an sls file, then it fails silently without any errors. If there is one failure in the sls files then none is executed
according to the docs, using salt in master/minion mode, works out of the box, the only thing needed with keys, is for master to accept the keys of the minions
nice article: http://dev.mlsdigital.net/posts/IntroToSaltStack/
saltstack modules are the equivalent of chef resources.
they provide the idepontence:
there are execution modules and state modules
Salt execution modules are different from state modules and cannot be called directly within state files. You must use the module state module to call execution modules within state runs.
state modules:
http://docs.saltstack.com/en/latest/ref/states/all/
execution modules:
http://docs.saltstack.com/en/latest/ref/modules/all/