To be clear, I am not asking for the "best way" to use saltstack. I understand that there are tons of ways to use saltstack, and what works for you, works. My question is specifically about the best practices documentation page found here.
First I'm going to show you what my current environment looks like
(This isn't specific to my environment. I've seen this question before, but never on stackexchange.com, normally on the saltstack irc)
After reading the saltstack documentation for the first time, I tried to implement my own environment, but I was confused as to how to do accomplish what I wanted with multiple projects all being deployed with different packages. Here is what my first attempt looks like.
I have three different projects that need to be deployed called
project1, project2, and project3.
file_roots: base: - /srv/salt project1: - /srv/salt/project1 project2: - /srv/salt/project2 project3: - /srv/salt/project3 #I have three projects that I need to deploy to, and each has a dev, qa, and prod machine. nodegroups: group-project1: 'L@dev-project1,qa-project1,prod-project1' group-project2: 'L@dev-project2,qa-project2,prod-project2' group-project3: 'L@dev-project3,qa-project3,prod-project3'
project1: 'group-project1': - match: nodegroup - oraclejava - tomcat - iptables-persistent - postgresql - apache project2: 'group-project2': - snort - pulledpork - barnyard - snorby - apache - mysql project3: 'group-project3': - match: nodegroup - oraclejava - tomcat - iptables-persistent - postgresql - apache
File structure inside of /srv/salt
contents of /srv/salt
/srv/salt/project1, project2, project3, top.sls
contents of /srv/salt/project1
/srv/salt/project1/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
contents of /srv/salt/project2
/srv/salt/project2/snort, pulledpork, barnyard, snorby, apache, mysql
contents of /srv/salt/project3
/srv/salt/project3/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
What I don't like about this setup
- duplicate files
If I have projects that have packages in common, for example all three projects have apache, then I have to have an apache directory for each project inside of their folder. That's not terrible since apache isn't configured the same, but I don't think I'm taking advantage of the organization that saltstack allows.
- not easily readable
As you can see, this setup is kind of difficult to read. I have to edit my group-projectx in the nodegroups in
/etc/salt/master file every time I want to add a minion associated with a specific project.
Saltstack best practices
My question is, how would I implement the best practices policies mentioned here, in an environment specified above. I know there's a lot of ways to do it, but I really want to do this in a way that is easier to understand and doesn't involve me making a new apache directory every time I have a server with apache on it.
Any help is appreciated.
A couple of suggestions I've received, that weren't through superuser.com were to get rid of nodegroups all together, and just specify in the top.sls file which minions go with which state, using the same format that I used in the /etc/salt/master file (L@dev-project1,qa-project1,prod-project1).
Also, it was suggested to me that maybe I should just use a different salt-master for each project. That makes sense, and I like that answer, but I think for people who don't have tons of space for VM's or physical machines, it might be difficult.