☰

Разъяснение документации по лучшим практикам Saltstack

tag-icon • tag-icon linux ubuntu deployment yaml
Разъяснение документации по лучшим практикам Saltstack

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

Сначала я покажу вам, как выглядит мое нынешнее окружение.

(Это не относится к моей среде. Я уже видел этот вопрос, но никогда на stackexchange.com, обычно насольстек irc)

После первого прочтения документации saltstack я попытался реализовать собственную среду, но я был в замешательстве относительно того, как достичь того, что я хотел, с несколькими проектами, развернутыми с разными пакетами. Вот как выглядит моя первая попытка.

У меня есть три разных проекта, которые нужно развернуть, они называются

проект1,проект2, ипроект3.

/etc/соль/мастер

file_roots:
  base:
    - /srv/salt
  project1:
    - /srv/salt/project1
  project2:
    - /srv/salt/project2
  project3:
    - /srv/salt/project3

#I have three projects that I need to deploy to, and each has a dev, qa, and prod machine.
nodegroups:
  group-project1: 'L@dev-project1,qa-project1,prod-project1'
  group-project2: 'L@dev-project2,qa-project2,prod-project2'
  group-project3: 'L@dev-project3,qa-project3,prod-project3'

/srv/salt/top.sls

project1:
  'group-project1':
    - match: nodegroup
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
project2:
  'group-project2':
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql
project3:
  'group-project3':
    - match: nodegroup
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache

Структура файла внутри /srv/salt

содержимое /srv/salt

/srv/salt/project1, project2, project3, top.sls

содержимое /srv/salt/project1

/srv/salt/project1/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache

содержимое /srv/salt/project2

/srv/salt/project2/snort, pulledpork, barnyard, snorby, apache, mysql

содержимое /srv/salt/project3

/srv/salt/project3/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache

Что мне не нравится в этой установке

  1. дубликаты файлов

Если у меня есть проекты, которые имеют общие пакеты, например, все три проекта имеют apache, то мне нужно иметь каталог apache для каждого проекта внутри их папки. Это не страшно, так как apache не настроен одинаково, но я не думаю, что я использую преимущества организации, которую позволяет saltstack.

  1. не легко читается

Как видите, эту настройку довольно сложно читать. Мне приходится редактировать group-projectx в /etc/salt/masterфайле nodegroups каждый раз, когда я хочу добавить миньона, связанного с определенным проектом.

Лучшие практики Saltstack

Мой вопрос заключается в том, как мне реализовать упомянутые политики передовой практики?здесь, в среде, указанной выше. Я знаю, что есть много способов сделать это, но я действительно хочу сделать это так, чтобы было проще понять и не требовалось создавать новый каталог apache каждый раз, когда у меня есть сервер с apache.

Любая помощь будет оценена по достоинству.

ПРАВКА 1

Несколько предложений, которые я получил (не через superuser.com), заключались в том, чтобы вообще избавиться от nodegroups и просто указать в файле top.sls, какие миньоны соответствуют какому состоянию, используя тот же формат, который я использовал в файле /etc/salt/master (L@dev-project1,qa-project1,prod-project1).

Также мне предложили, что, возможно, мне следует использовать отдельный salt-master для каждого проекта. Это имеет смысл, и мне нравится этот ответ, но я думаю, что для людей, у которых нет тонн места для виртуальных машин или физических машин, это может быть сложно.

решение1

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

# per server hostname : ie. 

base:
  'websrv*':
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
  'monsrv*':
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql

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

# per server grains : ie. 

base:
  'G@role:websrv': # or even a custom grain like 'G@project:1'
    - oraclejava
    - tomcat
    - iptables-persistent
    - postgresql
    - apache
  'G@role:monitoring': # or even a custom grain like 'G@project:1'
    - snort
    - pulledpork
    - barnyard
    - snorby
    - apache
    - mysql

Затем я делаю то же самое для своих данных о столбах, что позволяет мне назначать разные столбы некоторым хостам, так что это единственные дублирующие данные, которые у меня есть в Salt, с теми же ключами столбов, но разными значениями для настройки моей среды по мере необходимости. У меня есть, скажем, одно состояние Apache, и все, что в нем относится к среде, отображается со значением в моем столбе.

В вашем столпе вы могли бы иметь, например:

/top.sls
/apache /
        | init.sls
        | project1.sls
        | project2.sls
        | project3.sls

Связанный контент