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

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

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

То, чего я в конечном счете пытаюсь достигнуть, должно дать соль, осваивают список configfiles как это

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

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

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

затем я мог просто позволить основному нажатию целая вещь к нашему серверу мерзавца и иметь все имеющие версию конфигурации.

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

Существует названная команда

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

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

У кого-либо есть идея, как сделать это с солью?

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

2
задан 23 April 2014 в 12:56
1 ответ

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

Итак, вот простой пример того, как это сделать (так получилось, что для git'а используется битбекет):

1) Настройте salt master /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) Создайте простое ядро/иннит. sls файл:

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

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

6) Создайте специальный minion-специфический ssh_config под серверами/minion01/ssh_config

7) Фиксируйте и перемещайте изменения обратно в ваш git-репозиторий (bitbucket).

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

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

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

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

.
5
ответ дан 3 December 2019 в 09:36

Теги

Похожие вопросы