Marionette - Umwelt

Im Softwareentwicklungs- und Bereitstellungsmodell gibt es verschiedene Arten von Testumgebungen, die zum Testen eines bestimmten Produkts oder einer bestimmten Dienstleistung verwendet werden. Standardmäßig gibt es hauptsächlich drei Arten von Umgebungen wie Entwicklung, Test und Produktion, in denen jede ihre eigene Set-Konfiguration hat.

Puppet unterstützt die Verwaltung mehrerer Umgebungen in derselben Richtung wie Ruby on Rails. Der Schlüsselfaktor für die Erstellung dieser Umgebungen ist die Bereitstellung eines einfachen Mechanismus für die Verwaltung auf verschiedenen Ebenen der SLA-Vereinbarung. In einigen Fällen muss die Maschine immer ohne Toleranz und Verwendung alter Software betriebsbereit sein. Wobei andere Umgebungen aktuell sind und zu Testzwecken verwendet werden. Sie werden für Upgrades für wichtigere Maschinen verwendet.

Puppet empfiehlt, sich an die Standardkonfiguration für Produktions-, Test- und Entwicklungsumgebungen zu halten. Hier bietet es dem Benutzer jedoch sogar die Möglichkeit, benutzerdefinierte Umgebungen gemäß den Anforderungen zu erstellen.

Umweltziel

Das Hauptziel des durch eine Umgebung aufgeteilten Setups besteht darin, dass Puppet unterschiedliche Quellen für Module und Manifeste haben kann. Anschließend können die Konfigurationsänderungen in der Testumgebung getestet werden, ohne dass dies Auswirkungen auf die Produktionsknoten hat. Diese Umgebungen können auch zum Bereitstellen der Infrastruktur in verschiedenen Netzwerkquellen verwendet werden.

Verwenden der Umgebung auf Puppet Master

In einer Umgebung muss getestet werden, welches Manifest, Modul und welche Vorlage der Datei an den Client gesendet werden muss. Daher muss Puppet so konfiguriert werden, dass es eine umgebungsspezifische Quelle für diese Informationen bereitstellt.

Puppet-Umgebungen werden einfach implementiert, indem die Vorumgebungsabschnitte zur Puppet.conf des Servers hinzugefügt und für jede Umgebung eine andere Konfigurationsquelle ausgewählt wird. Diese Vorumgebungsabschnitte werden dann dem Hauptabschnitt vorgezogen.

[main] 
manifest = /usr/testing/puppet/site.pp 
modulepath = /usr/testing/puppet/modules 
[development] 
manifest = /usr/testing/puppet/development/site.pp 
modulepath = /usr/testing/puppet/development/modules

Im obigen Code verwendet jeder Client in der Entwicklungsumgebung die Manifestdatei site.pp, die sich im Verzeichnis befindet /usr/share/puppet/development und Puppet sucht nach einem beliebigen Modul in /usr/share/puppet/development/modules directory.

Wenn Sie Puppet mit oder ohne Umgebung ausführen, wird standardmäßig die Datei site.pp und das Verzeichnis verwendet, das in den Werten für Manifest und Modulpfad im Hauptkonfigurationsabschnitt angegeben ist.

Es gibt nur wenige Konfigurationen, deren Konfiguration in der Vorumgebung tatsächlich sinnvoll ist. Bei all diesen Parametern geht es darum, anzugeben, welche Dateien zum Kompilieren der Clientkonfiguration verwendet werden sollen.

Es folgen die Parameter.

Modulepath- In Puppet ist es als Standardstandardmodus am besten, ein Standardmodulverzeichnis zu haben, das alle Umgebungen gemeinsam nutzen, und dann ein Vorumgebungsverzeichnis, in dem das benutzerdefinierte Modul gespeichert werden kann. Der Modulpfad ist der Speicherort, an dem Puppet nach allen umgebungsbezogenen Konfigurationsdateien sucht.
Templatedir- Das Vorlagenverzeichnis ist der Speicherort, an dem alle Versionen der zugehörigen Vorlagen gespeichert werden. Das Modul sollte diesen Einstellungen vorgezogen werden, es ermöglicht jedoch, in jeder Umgebung unterschiedliche Versionen einer bestimmten Vorlage zu haben.
Manifest - Hiermit wird festgelegt, welche Konfiguration als Einstiegspunktskript verwendet werden soll.

Mit mehreren Modulen helfen Puppen dabei, die Modularität für Konfigurationen zu erhalten. In Puppet kann man mehrere Umgebungen verwenden, was viel besser funktioniert, wenn man sich weitgehend auf Module verlässt. Es ist einfacher, Änderungen in Umgebungen zu migrieren, indem Änderungen im Modul gekapselt werden. Der Dateiserver verwendet einen umgebungsspezifischen Modulpfad. Wenn eine Datei aus Modulen bereitgestellt wird, kann diese Umgebung anstelle von separat bereitgestellten Verzeichnissen umgebungsspezifische Dateien abrufen, und schließlich ist die aktuelle Umgebung auch in der Umgebungsvariablen $ in der Manifestdatei verfügbar.

Festlegen der Client-Umgebung

Alle Konfigurationen in Bezug auf die Umgebungskonfiguration werden in der Datei puppet.conf vorgenommen. Um anzugeben, welche Umgebung der Puppet-Client verwenden soll, können Sie einen Wert für die Umgebungskonfigurationsvariable in der Datei puppet.conf des Clients angeben.

[puppetd] 
environment = Testing

Die obige Definition in der Konfigurationsdatei definiert, in welcher Umgebung sich die Konfigurationsdatei in unserem Fall befindet.

Sie können dies auch in der Befehlszeile mit - angeben

#puppetd -–environment = testing

Alternativ unterstützt Puppet auch die Verwendung dynamischer Werte in der Umgebungskonfiguration. Anstatt die statischen Werte zu definieren, kann der Entwickler benutzerdefinierte Fakten erstellen, die eine Clientumgebung basierend auf einigen anderen Clientattributen oder einer externen Datenquelle erstellen. Die bevorzugte Methode ist die Verwendung eines benutzerdefinierten Tools. Diese Tools können die Umgebung eines Knotens angeben und sind im Allgemeinen viel besser in der Angabe von Knoteninformationen.

Puppensuchpfad

Puppet verwendet einen einfachen Suchpfad, um zu bestimmen, welche Konfiguration auf dem Zielcomputer angewendet werden muss. Ebenso ist der Suchpfad in Puppet sehr nützlich, wenn versucht wird, geeignete Werte zu ermitteln, die angewendet werden müssen. Wie unten aufgeführt, gibt es mehrere Stellen, an denen Puppet nach den Werten sucht, die angewendet werden müssen.

In der Befehlszeile angegebener Wert
In einem umgebungsspezifischen Abschnitt angegebene Werte
In einem ausführbaren Abschnitt angegebene Werte
Im Hauptabschnitt angegebene Werte