4 votes

Comment puis-je dire à Puppet "Si je déclare la classe X, appliquer ses ressources avant la classe Y" ?

Dans ma configuration Puppet, je veux dire "Si je déclare la classe X, appliquer ses ressources avant la classe Y". En d'autres termes, je veux déclarer un ordre, mais rester silencieux sur l'application ou non de la classe X.

Si je comprends bien le métaparamètre "avant", dire :

class X {
    ...
    before => Class['Y'],
}

class Y {
    ...
}

node N {
    include Y
}

node M {
    include X
    include Y
}

inclura les ressources de X et de Y sur les nœuds M et N. Au lieu de cela, ce que je veux, c'est exprimer séparément, "Appliquez juste Y," ou "Appliquez X et Y, et appliquez X avant Y".

Pour le contexte, ce que je veux faire plus concrètement, c'est m'assurer que mes dépôts Yum sont configurés avant que Puppet n'applique les ressources des paquets. Je veux omettre certains dépôts sur certains nœuds. Je veux que mes définitions de ressources de paquets restent naïves par rapport aux dépôts correspondants ; je ne veux pas encombrer mes définitions de ressources de paquets avec des dépendances sur des dépôts spécifiques.

J'ai essayé d'utiliser les Run Stages, mais au-delà de la configuration la plus simple, ils semblent provoquer des cycles de dépendances. Par exemple, ceci pourrait fonctionner :

stage { 'first': before => Stage['main'] }

class X {
    ...
    before => Class['Y'],
}

class Y {
    ...
}

node N {
    include Y
}

node M {
    class { "X": stage => first }
    include Y
}

Mais ce ne serait pas le cas :

stage { 'first': before => Stage['main'] }

class X {
    ...
    class { "Z": stage => first } # to avoid Z "floating off"
    before => Class['Y'],
}

class Y {
    ...
    include Z
}

class Z { ... }

node N {
    include Y
}

node M {
    class { "X": stage => first }
    include Y
}

Dans ce dernier cas, Puppet pense qu'il y a un cycle de dépendance. Je présume que cela est dû au fait que Z est déclaré et que ses ressources sont gérées en deux étapes différentes. Je pourrais potentiellement simplifier les classes dont j'ai besoin dans l'étape "première" pour éviter les problèmes de cycle de dépendance que je vois en pratique, mais la documentation de Puppet étale FUD sur les étapes de la course.

Voici la partie spécifique de la configuration qui rend Run Stages vraiment peu attrayante pour moi. Dans les VM de développement, je démarre un serveur Yum localement via un "devrepo".

class yum::devrepo {

    # Ensures httpd is running as a Yum server before anything else
    # tries to install packages from it.
    exec { 'httpd-for-yum':
        command => '/sbin/service httpd restart',
        require => Class['yum::server'],
    }

    yumrepo {
        "devrepo":
            require    => [Exec['httpd-for-yum'],],
            descr      => "Local Dev YUM Repo",
            baseurl    => "http://localhost/repos/redhat/5/x86_64/",
            gpgcheck   => "0",
            enabled    => "1",
    }
}

class yum::server {

    include httpd

    package { ['createrepo']:
        ensure => present;
    }

    exec { 'update-repo-metadata':
        require => [ Package['createrepo']],
        cwd => '/var/www/html/yum',
        command => '/usr/bin/createrepo --update -d repos/redhat/5/x86_64/',
        creates => '/var/www/html/yum/repos/redhat/5/x86_64/repodata/repomd.xml',
    }

    file {'/etc/httpd/conf.d/yum.conf':
        ensure  => file,
        mode    => 0644,
        source  => "puppet:///modules/yum/yum_httpd.conf",
        require => Package['httpd'],
        notify  => Service['httpd'],
    }
}

Je veux inclure mon repo Yum de production sur certains nœuds et le repo dev sur d'autres.

Si je mets yum::server y yum::devrepo dans l'étape "première", puis plus tard les déclarations httpd dans d'autres classes causent des problèmes plus tard, parce que les autres classes mettent httpd dans l'étape principale.

Si Puppet peut exprimer "Si je déclare la classe X, appliquer ses ressources avant la classe Y", comment ? Sinon, comment puis-je obtenir l'ordre que je veux sans cycles de dépendance et sans inclure les ressources du référentiel Yum que je veux omettre ?

2voto

golja Points 1591

Je ne sais pas si cela fonctionnera, mais vous pourriez peut-être essayer de définir les dépendances au niveau des nœuds. Par exemple :

class X {
    ...
}

class Y {
    ...
}

node N {
   include Y
}

node M {
    Class['X'] -> Class['Y']
    include X
    include Y
}

1voto

Matt McClure Points 347

On dirait que réponse de golja pourrait fonctionner. Voici le modèle sur lequel je me suis arrêté. Il semble fonctionner jusqu'à présent.

class yum::reposareready {

    # The sole and critical purpose of this class is to act as an
    # intermediary between various repositories and the package
    # resources. It lets us do things like:

    # class yum::repofoo { ... }

    # class applicationbar {
    #     package { 'bazfromtherightrepo': ..., require => yum::reposareready, }
    # }

    # node n {
    #     class { 'yum::repofoo': before => Class['yum::reposareready'] }
    # }

    # With this pattern:

    # 1. The repository resource doesn't need to know about its ordering.

    # 2. Nodes can mix in repository resources, including and excluding
    #    repositories as needed.

    # 3. Classes that declare package resources need only require a
    #    generic "repos are ready" class rather than the knowing the
    #    specific repository from which to get a package.

    # DO NOT DO THIS:

    # class yum::repofoo { before => Class['yum::reposareready'] }
    # class yum::repobar { before => Class['yum::reposareready'] }
    #
    # node n {
    #     include yum::repofoo
    # }
    #
    # node m {
    #     include yum::repobar
    # }

    # The former scopes the ordering dependency to the node, whereas the
    # latter does not. The latter would make Puppet apply yum::repofoo
    # to both nodes n and m, whereas the former only applies
    # yum::repofoo to node n.

}

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X