☰

Erläuterung der Dokumentation zu Best Practices für Saltstack

tag-icon • tag-icon linux ubuntu deployment yaml
Erläuterung der Dokumentation zu Best Practices für Saltstack

Um es klarzustellen: Ich frage nicht nach der „besten Art“, Saltstack zu verwenden. Ich verstehe, dass es unzählige Möglichkeiten gibt, Saltstack zu verwenden, und was für Sie funktioniert, funktioniert. Meine Frage bezieht sich speziell auf die Dokumentationsseite zu bewährten Methoden, die Sie findenHier.

Zuerst zeige ich Ihnen, wie meine aktuelle Umgebung aussieht

(Das ist nicht spezifisch für meine Umgebung. Ich habe diese Frage schon einmal gesehen, aber nie auf stackexchange.com, normalerweise auf derSaltstack-IRC)

Nachdem ich die Saltstack-Dokumentation zum ersten Mal gelesen hatte, versuchte ich, meine eigene Umgebung zu implementieren, war mir jedoch nicht sicher, wie ich das gewünschte Ergebnis erzielen sollte, wenn mehrere Projekte mit unterschiedlichen Paketen bereitgestellt werden. So sieht mein erster Versuch aus.

Ich habe drei verschiedene Projekte, die bereitgestellt werden müssen:

Projekt 1,Projekt2, UndProjekt3.

/etc/salt/master

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

Dateistruktur innerhalb von /srv/salt

Inhalt von /srv/salt

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

Inhalt von /srv/salt/project1

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

Inhalt von /srv/salt/project2

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

Inhalt von /srv/salt/project3

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

Was mir an diesem Setup nicht gefällt

  1. doppelte Dateien

Wenn ich Projekte habe, die gemeinsame Pakete haben, z. B. alle drei Projekte Apache haben, muss ich für jedes Projekt ein Apache-Verzeichnis in ihrem Ordner haben. Das ist nicht schlimm, da Apache nicht gleich konfiguriert ist, aber ich glaube nicht, dass ich die Organisation ausnutze, die Saltstack ermöglicht.

  1. nicht leicht lesbar

Wie Sie sehen, ist dieses Setup etwas schwer zu lesen. Ich muss meine Gruppen-Projektx in der /etc/salt/masterDatei „Knotengruppen“ jedes Mal bearbeiten, wenn ich einen Minion hinzufügen möchte, der einem bestimmten Projekt zugeordnet ist.

Bewährte Methoden für Saltstack

Meine Frage ist, wie ich die genannten Best Practices-Richtlinien umsetzen würdeHier, in einer oben angegebenen Umgebung. Ich weiß, dass es viele Möglichkeiten gibt, dies zu tun, aber ich möchte dies wirklich auf eine Weise tun, die einfacher zu verstehen ist und bei der ich nicht jedes Mal ein neues Apache-Verzeichnis erstellen muss, wenn ich einen Server mit Apache darauf habe.

Jede Hilfe wird geschätzt.

BEARBEITEN 1

Ein paar Vorschläge, die ich erhalten habe und die nicht über superuser.com kamen, bestanden darin, Knotengruppen ganz zu entfernen und in der Datei top.sls einfach anzugeben, welche Minions zu welchem ​​Status gehören. Dabei sollte dasselbe Format verwendet werden, das ich in der Datei /etc/salt/master verwendet habe (L@dev-project1,qa-project1,prod-project1).

Außerdem wurde mir vorgeschlagen, dass ich vielleicht einfach für jedes Projekt einen anderen Salt-Master verwenden sollte. Das macht Sinn, und mir gefällt diese Antwort, aber ich denke, für Leute, die nicht viel Platz für VMs oder physische Maschinen haben, könnte es schwierig werden.

Antwort1

Ich beschäftige mich mit unterschiedlichen App-Konfigurationen pro Servertyp direkt in der obersten Datei.

# per server hostname : ie. 

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

Wenn Sie die Benennung Ihrer Minions nicht anhand von regulären Ausdrücken klassifizieren können, können Sie dasselbe mit Grains tun.

# 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

Dann mache ich dasselbe mit meinen Säulendaten, was es mir ermöglicht, einigen Hosts verschiedene Säulen zuzuweisen, sodass dies die einzigen doppelten Daten sind, die ich in Salt habe, mit denselben Säulenschlüsseln, aber unterschiedlichen Werten, um meine Umgebung nach Bedarf zu konfigurieren. Ich habe dann beispielsweise einen Apache-Status und alles, was darin umgebungsspezifisch ist, wird mit dem Wert in meiner Säule gerendert.

In Ihrer Säule könnten Sie zum Beispiel haben:

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

verwandte Informationen