Przeczytałem dokumentację dotyczącą zakresu, ale nadal mam problemy z jej rozwiązaniem. Mam dwa środowiska, które są bardzo podobne - więc mam:
moduły / django-env / manifests / init.pp
class django-env {
package { "python26":
ensure => installed
}
# etc ...
}
import "er.pp"
moduły / django-env / manifests / er.pp
$venvname = "er"
$venvpath = "/home/django/virtualenvs"
class er {
file { "$venvpath/$venvname" :
ensure => directory
}
# etc ...
}
class er-dev {
include er
}
class er-bce-dev {
$venvname = "er-bce"
include er
}
manifests / modules.pp
import "django-env"
manifests / nodes.pp
node default {
# etc ...
}
node 'centos-dev' imports default {
include django-env
include er-bce-dev
include er-dev
}
Rezultat jest taki, że „dziedziczenie” działa - ale działa tylko pierwszy element „er-” w węźle „centos-dev”, albo dostaję er-bce-dev lub er-dev, ale nie oba. Musi tu być podstawowa rzecz, której nie rozumiem.
Czy to jest różnica między importem a dołączeniem ? (nie jestem pewien, czy to rozumiem)
Odpowiedzi:
Puppet nie obsługuje tego rodzaju konfiguracji, ale ograniczenie można łatwo ominąć. Powodem są dwie podstawowe „zasady” marionetek:
er-dev
ier-bce-dev
oba obejmują klasęer
. Ale klasa nie może być dołączona dwa razy, więcer
klasa jest wykonywana tylko z wartością domyślną$venvname = "er"
lub z przesłonięciem$venvname = "er-dev"
, ale nie z obydwoma.Rozwiązanie: zmień
er
klasę na definicję (patrz „Definicje” z samouczka języka kukiełkowego ( http://docs.puppetlabs.com/guides/language_tutorial.html )):moduły / django-env / manifests / er.pp
Nie potrzebujemy zmiennych
$venvname
i$venvpath
, są one określone jako wartości domyślne w definicji. Nazwadjango-env::er
dodaje definicję dodjango-env
przestrzeni nazw i umożliwia automatyczny import (patrz poniżej).Importuj i dołączaj
Różnica pomiędzy
import
iinclude
statemens jest:import
współpracuje z plikami i nie wykonuje klasinclude
wykonuje zajęciaUwaga: istnieje bardzo silny wyjątek od ostatniej reguły: wyszukiwanie modułu marionetek .
include
instrukcja wykonuje automatyczny import w wielu sytuacjach. Tutaj jest kilka z nich:include foo
próbuje zaimportować plikmodule_dir/foo/manifests/init.pp
include foo::bar
importmodule_dir/foo/manifests/bar.pp
Dzięki tym automatycznym importom i definicji zasobów możesz bardzo łatwo zdefiniować wiele środowisk wirtualnych. Zmień
node 'centos-dev'
:I możesz usunąć w zasadzie wszystkie
import
instrukcje dotyczącedjango-env
modułu.Happy Puppeting!
źródło
inherits
zamiastimports default
?inherits
jest również przestarzałe, ale przynajmniej jest to poprawna składnia.Składnia marionetek ewoluowała, od Puppet 3.7 pojawi się wiele ostrzeżeń o rezygnacji. Słowa kluczowe
import
iinherits
są przestarzałe. Zamiast używać układu takiego jak:Powinieneś użyć:
Zamiast używać tradycyjnej
site.pp
konfiguracji:powinieneś użyć standardowego
class
(ale nie możesz go nazwać,class default
ponieważ jest to słowo zastrzeżone ) plikumanifets/01_common.pp
:Pliki są ładowane w kolejności alfabetycznej, dlatego najpierw należy załadować „klasy podstawowe” (dobrym pomysłem może być numeracja).
Następnie zamiast definiować węzeł, taki jak:
użyj raczej (rozwiązuje klasyczny problem wielokrotnego dziedziczenia, tzw. problem diamentów ), np. zdefiniowany w
manifests/web.pp
źródło