дык мне не грейнс нужны, а список нод

кога было тупо списком оно работало

добавил переменные в pillar  и на их основе генерю конфиг, в зависимости от id миньена .

salt-minion:
  allowed_ip: '10.233.60.135'
  env: 'prod'

master:
 - {{ salt['pillar.get'](grains.id~':allowed_ip', '10.233.60.114') }}
saltenv:  {{ salt['pillar.get'](grains.id~':env', 'base') }}


кумекаю как  переписать на match по ipcidr
что то вроде

10.233.60.0/24:
   - match: ipcidr
   allowed_ip: '10.233.60.135'
   env: 'prod'

servers:
   - server-01
   - server-02
   - server-03

а сейчас у меня группы формируются так:
servers: 'G@tags:multireplica-replica:*'

и не работает

mine

Это про rotate ключей master.pem, master.pub из salt-key -F master ... Local keys: ? Всмысле по умолчанию они постоянно ротейтяться ? А если миньон был недоступен тройку суток - он перестаёт работать с мастером из-за устаревания ключей ?

10.233.60.0/24:
   - match: ipcidr
   allowed_ip: '10.233.60.135'
   env: 'prod'

чет пока не понял как это сделать в pillar
сделал вот так  в jinja, при генерации конфига

{% set allowed_master = salt['match.filter_by']({
    'S@10.233.60.0/24': {
        'ip': '10.233.60.134',
        'env': 'prod',
    },
    'S@10.233.61.0/24': {
        'ip': '10.233.60.135',
        'env': 'dev',
    },
}) %}

master:
  - {{ allowed_master.ip}}
master_type: failover
master_alive_interval: 60
saltenv: {{allowed_master.env}}

норм ?

Всем привет. Вопрос про environments. Я если честно не понял до конца. Если top_file_merging_strategy по умолчанию (т.е. merge) и мы не укажем ни какого saltenv (это не указно по умолчанию у миньона) значит солт смержит всё что найдёт во всех env-ах на сервере для миньона. Если мы укажем foo или base или какоё либо ещё env то солт по умолчанию возьмёт стейты только из этого env ? Такое поведение обусловлено тем, чтобы по умолчанию хоть что то работало (по началу тот кто разбирается с солтом не думаю что сразу станет распихивать свою логику по разным env)?

> и мы не укажем ни какого saltenv (это не указно по умолчанию у миньона)
мне кажется base по умолчанию передается

подскажите.  
а можно сделать так что бы при авторизации на host машине, salt-minion отправлял в шину (zeromq) это событие(event) ,  и принть его в  logstash (elk)

логика  верна ?

@yazero Либо https://docs.saltstack.com/en/master/topics/engines/index.html

привет все. я так понимаю в салте  file.line BOF  и EOF не поддерживается?

Коллеги. Вопрос по пилларам и окружениям. Никак не могу понять как мне ограничить миньенов по разным окружениям. К примеру. Есть prod и есть dev. Есть репа с пилларами в которой 2 ветки: master - мапится на окружение prod и develop мапится на окружение dev. В обоих ветках одинаковый top.sls, к примеру:
{{ saltenv }}:
 'G@gitlab':
   - gitlab
У миньенов, соответственно, есть роли gitlab, но у одного миньена прописан pillarenv: prod, а у другого pillarenv:dev
Соответственно, если я буду применять формулу командой:
salt 'G@gitlab' state.apply gitlab
То формула пойдет раскатываться на миньена с пилларом из prod и на миньена с пилларов из dev.
Можно ли добиться что бы при такой команде формула раскатывалась только на миньена с pillarenv=prod?
Если разграничивать миньенов через роли и top.sls тогда вообще не ясно, зачем пилларам нужны окружения по веткам...

что ?

ну мне нужно проверять, если строка, и вставлять ее

но файл первоначально может быть пустой

и он (салт) мне ругается, то я не указываю befor или after