Bestmögliche Dokumentation der Saltstack-Dokumentation
1252
trueCamelType
Um klar zu sein, frage ich nicht nach dem "besten Weg", um Saltstack zu verwenden. Ich verstehe, dass es viele Möglichkeiten gibt, Saltstack zu verwenden, und was für Sie funktioniert, funktioniert. Meine Frage bezieht sich speziell auf die Best Practices-Dokumentationsseite, die Sie hier finden .
Zuerst werde ich Ihnen zeigen, wie meine derzeitige Umgebung aussieht
(Dies ist nicht spezifisch für meine Umgebung. Ich habe diese Frage schon einmal gesehen, aber niemals auf stackexchange.com, normalerweise auf dem Saltstack irc. )
Nachdem ich die Saltstack-Dokumentation zum ersten Mal gelesen hatte, versuchte ich, meine eigene Umgebung zu implementieren, aber ich war verwirrt, wie ich mit mehreren Projekten, die alle mit unterschiedlichen Paketen bereitgestellt wurden, das erreichen würde, was ich wollte. So sieht mein erster Versuch aus.
Ich habe drei verschiedene Projekte, die bereitgestellt werden müssen
project1, project2 und project3 .
/ 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'
Wenn ich Projekte habe, die Pakete gemeinsam haben, beispielsweise alle drei Projekte Apache haben, muss ich für jedes Projekt ein Apache-Verzeichnis in ihrem Ordner haben. Das ist nicht so schlimm, da Apache nicht gleich konfiguriert ist, aber ich glaube nicht, dass ich die Organisation nehme, die Saltstack erlaubt.
nicht leicht lesbar
Wie Sie sehen, ist dieses Setup schwer lesbar. Ich muss mein group-projectx in den Knotengruppen in der /etc/salt/masterDatei jedes Mal bearbeiten, wenn ich einen Minion hinzufügen möchte, der einem bestimmten Projekt zugeordnet ist.
Saltstack-Best Practices
Meine Frage ist, wie ich die hier genannten Best Practices-Richtlinien in einer oben angegebenen Umgebung implementieren könnte . Ich weiß, dass es viele Möglichkeiten gibt, dies zu tun, aber ich möchte dies auf eine einfachere Art und Weise tun, bei der ich nicht jedes Mal ein neues Apache-Verzeichnis erstellen muss, wenn ich einen Server mit Apache habe.
Jede Hilfe wird geschätzt.
BEARBEITEN 1
Ein paar Vorschläge, die ich nicht erhalten habe, die nicht über superuser.com gingen, waren, alle Knotengruppen zu entfernen und einfach in der Datei top.sls anzugeben, welche Schergen zu welchem Status passen, wobei sie dasselbe Format verwenden, in dem ich verwendet habe die Datei / etc / salt / master (L @ dev-project1, qa-project1, prod-project1).
Außerdem wurde mir vorgeschlagen, dass ich vielleicht für jedes Projekt einen anderen Salzmeister verwenden sollte. Das macht Sinn und ich mag diese Antwort, aber ich denke, für Leute, die nicht viel Platz für VMs oder physische Maschinen haben, könnte es schwierig werden.
1 Antwort auf die Frage
2
Val F.
I'm dealing with different app configuration per server type directly at the top file.
If your minions naming doesn't allow you to classify them based on regex, you can do the same with grains.
# 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
Then I do the same thing for my pillar data, allowing me to assign different pillars to some hosts so that is the only duplicate data I have in Salt, with the same pillar keys but different values to configure my environment as I need. I have then let's say one apache state and anything that is environment specific in it is rendered with the value in my pillar.