David Boshton
David Boshton

Reputation: 2765

How do I manage minion roles with salt-stack pillars?

I'm trying to understand how to use Salt with roles like Chef can be used, but I have some holes in my understanding that reading lots of docs has failed to fill at this point.

The principle issue is that I'm trying to manage roles with Salt, like Chef does, but I don't know how to appropriately set the pillar value. What I want to do is assign, either by script or by hand, a role to a vagrant box and then have the machine install the appropriate files on it.

What I don't understand is how I can set something that will tell salt-master what to install on the box given the particular role I want it to be. I tried setting a

salt.pillar('site' => 'my_site1') 

in the Vagrantfile and then checking it in the salt state top.sls file with

{{ pillar.get('site') == 'my_site1'
  -<do some stuff>

But this doesn't work. What's the correct way to do this?

Upvotes: 2

Views: 8510

Answers (2)

Dan Garthwaite
Dan Garthwaite

Reputation: 3526

How to implement and utilize roles is intentionally vague in the salt documentation. Every permutation of how to implement, and then how to use, roles carries with it trade-offs -- so it is up to you to decide how to do it.

In your scenario I can assume that you want rather singular 'roles' or purposes associated with a virtualbox VM, and then have state.highstate run the states associated with that role.

If the above is correct, I would go with grains rather than pillars while learning salt for the sake of simplicity.

On each minion

Just add role: webserver to /etc/salt/grains and restart the salt-minion.

On the master

Update /srv/state/top.sls file to then associate state .sls files with that grain.

base:
  '*':
    - fail2ban

  role:webserver:
    - match: grain
    - nginx

  role:dbserver:
    - match: grain
    - mysql

Upvotes: 2

David Boshton
David Boshton

Reputation: 2765

So, it becomes easier when matching ids in pillars. First, set the minion_id to be something identifiable, for example test-mysite1-db (and above all unique. Hence the username initials at the end as an example. in the top.sls in /srv/pillar do

base:
 '<regex_matching_id1>':
   - webserver.mysite1
 '<regex_matching_id2>':
   - webserver.mysite2

And then in webserver.mysite1 put

role : mysiteid1

for example.

Then in /srv/state/top.sls you can then match with jinja or just with

base:
 'role:mysiteid1':
   - match: pillar
   - state
   - state2

Hence, roles derived from the ids. Works for me.

Upvotes: 4

Related Questions