Назад | Перейти на главную страницу

имя хоста миньона в солевой команде

Я новичок в соли, поэтому возможно, я что-то пропустил, но я не могу этого понять.

Я использую соль как инструмент выполнения команд (пока без управления конфигурацией). Я не мог найти способ получить конфигурации от миньонов с солью и поместить их в репозиторий git.

В конечном итоге я пытаюсь дать мастеру соли список файлов конфигурации, подобных этому

/etc/ssh/ssh_config
/etc/vim/vimrc
etc.

и заставьте salt-master запустить выборку этих файлов, поместите их в такие папки, как

/srv/salt/minions/configs/minion01/etc/ssh/ssh_config
/srv/salt/minions/configs/minion02/etc/ssh/ssh_config

тогда я мог бы просто позволить мастеру отправить все это на наш git-сервер и установить версии для всех конфигураций.

Я знаю, что соль может обрабатывать состояния, но все, что я нахожу, касается передачи файла от мастера к миньону, чтобы сохранить состояние таким, каким оно должно быть, но я просто хочу собрать все конфигурации обновлений со всех серверов и автоматически их версия .

Есть команда под названием

salt \* cp.push /etc/ssh/ssh_config

который помещает файл конфигурации в / var / cache / salt / minion / minion01 / files / etc / ssh / ssh_config, что кажется идеальным, но я не знаю, как сообщить соли, чтобы это происходило при каждом изменении файла (у нас есть довольно несколько серверов и множество конфигураций для версии ...) и получать его только в том случае, если он изменился, поэтому мне не нужно загружать все файлы каждые пять минут или около того (через cron).

Кто-нибудь знает, как это сделать с солью?

С уважением, Mohrphium

Вы неправильно думаете об этом, Salt не предназначен для того, чтобы предоставить вам историю изменений, которые вы сделали на машине, но вместо этого, чтобы диктовать «высокое» состояние, в котором должна находиться машина. Etckeeper отслеживает изменения, сделанные локально , регистрируя изменения, сделанные локально, в git, в то время как соль заставляет ваши ящики следовать любым изменениям в репозитории git. Если у миньона есть какие-либо локальные изменения, он покажет вам, когда вы сделаете высокое состояние. Вы можете угадать, какой весит?

Итак, вот простой пример того, как это сделать (это происходит с использованием bitbucket для git):

1) Настройте свой солевой мастер / etc / salt / master с помощью:

file_roots:
  base:
    - /srv/salt

fileserver_backend:
  - git
  - roots

gitfs_remotes:
  - git@bitbucket.org:user/your-salt-repo.git

pillar_roots:
  base:
    - /srv/pillar

2) В корне репозитория git создайте простой файл top.sls:

base:
  '*.domain.com':
    - core

3) Создайте несколько дополнительных каталогов внутри репозитория git:

mkdir core
mkdir servers
mkdir servers/default
mkdir servers/minion01

4) Создайте простой файл core / init.sls:

/etc/ssh/ssh_config:
  file.managed:
    - source:
      - salt://servers/{{ grains['id'] }}/ssh_config
      - salt://servers/default/ssh_config

5) Создайте ssh_config по умолчанию в server / default / ssh_config.

6) Создайте специальный ssh_config для миньонов в server / minion01 / ssh_config

7) Зафиксируйте и отправьте изменения обратно в репозиторий git (битбакет).

8) Из солевого мастера выполните: sudo salt '*' state.highstate test=true чтобы увидеть, какие изменения будут применены.

Когда minion01 свяжется с мастером соли, он получит серверы / minion01 / ssh_config, но любой другой миньон (например, minion02), у которого нет файла ssh_config в /servers/minion.id.whatever/, и переместится вниз по списку к следующему источнику (серверам /дефолт). Вместо того, чтобы делать это с помощью minion_id, вы также можете сделать это на основе других зерен, таких как os, fqdn, domain и т. Д. (См. Список зерен на миньоне с salt 'minion-id' grains.items).

После того, как вы зафиксировали начальное состояние этих файлов, вы можете внести изменения в центральном месте (репозиторий git), а затем запустить state.highstate для внесения дальнейших изменений. Эта первоначальная боль стоит усилий. Вы можете автоматизировать некоторые из них, но на самом деле вы хотите найти выбросы, которые по определению потребуют некоторого ручного вмешательства для выявления. Я рекомендую вам начать с чего-то вроде ssd_config и запустить state.highstate test=true по одному миньону за раз. Если есть изменения от значения по умолчанию, он покажет вам разницу, и вы сможете судить, оправдывает ли это исключение из значения по умолчанию.

Примечание. Вам необходимо настроить ssh-ключи для пользователя root на мастере соли, чтобы иметь разрешение на чтение вашего репозитория git (bitbucket вызывает эти ключи развертывания).