Answers: <p>SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. </p>
  
  <p>For example:
  1. add grains to the minion config. Note, simply include the grains key here:</p>
  
  <blockquote>
  <pre><code>id: minion-07
  grains:
    roles:
      - production
    region: nl-amsterdam
  </code></pre>
  </blockquote>
  
  <ol start="2">
  <li>add custom grains within the /etc/salt/grains file. Note, add grains without prefacing them with grains:</li>
  </ol>
  
  <blockquote>
  <pre><code>   roles:
         - production
       region: nl-amsterdam
  </code></pre>
  </blockquote>
  
  <ol start="3">
  <li>Alternatively you may set roles via command line shell from master or from salt minion: </li>
  </ol>
  
  <blockquote>
    <p><code>salt 'your minion' grains.setval roles [production, dev, qa]</code></p>
    
    <p><code>salt-call grains.setval roles [production, dev, qa]</code></p>
  </blockquote>
  
  <p>For matching grains I usually use Jinja2. Or you may refer to commandline/config file approaches: </p>
  
  <blockquote>
    <p><code>salt -C 'G@roles:production' test.ping</code></p>
  </blockquote>
  
  <p>By using sytnax in the top.sls file:</p>
  
  <blockquote>
  <pre><code>base:
    'roles:production':
      - match: grain
      - salt.master
    'roles:dev':
      - match: grain
      - api-dev
  </code></pre>
  </blockquote>
  
  <p>Alternatively you may consider using environments in SaltStack, see here for more details: <a href="https://docs.saltstack.com/en/latest/ref/states/top.html#environments" rel="nofollow noreferrer">https://docs.saltstack.com/en/latest/ref/states/top.html#environments</a></p>
  
  <p>However, roles are more suitable for running specific states, at least We use them in our our company. So up to you what is the best ;) </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-14T09:22:24.293Z
Answers: Thank you for the answer @user54 - This is exactly what I was looking for, we used this method at my old workplace, except it was already implemented before my arrival so I've never had any experience configuring it myself!
Answers: jto
Answers: CC BY-SA 3.0
Answers: 2017-08-15T14:33:18.280Z
Answers: Always glad to help 
Answers: user54
Answers: CC BY-SA 3.0
Answers: 2017-08-12T22:40:49.677Z
Answers: 2017-08-12T23:02:37.800Z
Answers: 2017-08-12T23:02:37.800Z
Answers: user54
Body: <p>I have been tasked with using Salt Stack to find out what files/services exist in each of our environments (Test, UAT, Production).</p>
  
  <p>The Salt master can speak to all servers in Test and UAT (Production Salt master is yet to be configured) so I was thinking of creating a state in 'base' which can target all minions just doing simple file.exist queries. However I quickly came to the realisation that certain files won't exist on certain servers due to the different nature of them. E.g. Our API server has a lot of specific scripts and configs which won't exist on our LDAP server.</p>
  
  <p>What is the most efficient and scalable way of implementing this? Could I define roles for each type of server (e.g. webserver, ldap server, api server) and therefore a specific state for each role?</p>
  
Tags: <linux><configuration-management><salt><scalability>
Title: Best method of retrieving environment information via Salt Stack?
UserDisplayName: jto
ThreadText: # Best method of retrieving environment information via Salt Stack?
  
  (Asked by: username_0 on 2017-08-11)
  
  I have been tasked with using Salt Stack to find out what files/services exist in each of our environments (Test, UAT, Production).
  
  The Salt master can speak to all servers in Test and UAT (Production Salt master is yet to be configured) so I was thinking of creating a state in 'base' which can target all minions just doing simple file.exist queries. However I quickly came to the realisation that certain files won't exist on certain servers due to the different nature of them. E.g. Our API server has a lot of specific scripts and configs which won't exist on our LDAP server.
  
  What is the most efficient and scalable way of implementing this? Could I define roles for each type of server (e.g. webserver, ldap server, api server) and therefore a specific state for each role?
  
  **Tags:** linux, configuration-management, salt, scalability
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-08-12. Score: 3 | Accepted answer
  
  SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file.
  
  For example:
  1. add grains to the minion config. Note, simply include the grains key here:
  
  > ```
  > id: minion-07
  > grains:
  >   roles:
  >     - production
  >   region: nl-amsterdam
  >
  > ```
  
  2. add custom grains within the /etc/salt/grains file. Note, add grains without prefacing them with grains:
  
  > ```
  >    roles:
  >        - production
  >      region: nl-amsterdam
  >
  > ```
  
  3. Alternatively you may set roles via command line shell from master or from salt minion:
  
  > `salt 'your minion' grains.setval roles [production, dev, qa]`
  >
  > `salt-call grains.setval roles [production, dev, qa]`
  
  For matching grains I usually use Jinja2. Or you may refer to commandline/config file approaches:
  
  > `salt -C 'G@roles:production' test.ping`
  
  By using sytnax in the top.sls file:
  
  > ```
  > base:
  >   'roles:production':
  >     - match: grain
  >     - salt.master
  >   'roles:dev':
  >     - match: grain
  >     - api-dev
  >
  > ```
  
  Alternatively you may consider using environments in SaltStack, see here for more details: <https://docs.saltstack.com/en/latest/ref/states/top.html#environments>
  
  However, roles are more suitable for running specific states, at least We use them in our our company. So up to you what is the best ;)
  
  > **Comments:**
  > **username_0**: Thank you for the answer @username_1 - This is exactly what I was looking for, we used this method at my old workplace, except it was already implemented before my arrival so I've never had any experience configuring it myself!  
  > **username_1**: Always glad to help   
  
  ---
  
  