Saltstack best practices documentation clarification

Question

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.

/etc/salt/master

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'

/srv/salt/top.sls

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

1. 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.

2. 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.

EDIT 1

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.

Answer 1

I'm dealing with different app configuration per server type directly at the top file.

# per server hostname : ie. 

base:
  'websrv*':
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
  'monsrv*':
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql

If your minions naming doesn't allow you to classify them based on regex, you can do the same with grains.

# per server grains : ie. 

base:
  'G@role:websrv': # or even a custom grain like 'G@project:1'
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
  'G@role:monitoring': # or even a custom grain like 'G@project:1'
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql

Then I do the same thing for my pillar data, allowing me to assign different pillars to some hosts so that is the only duplicate data I have in Salt, with the same pillar keys but different values to configure my environment as I need. I have then let's say one apache state and anything that is environment specific in it is rendered with the value in my pillar.

In your pillar, you could have for example :

/top.sls
/apache /
        | init.sls
        | project1.sls
        | project2.sls
        | project3.sls