Vagrant peut-il pointer vers un répertoire de manifestes Puppet pour exécution?


9

J'utilise Vagrant pour démarrer une configuration initiale de marionnettes et je ne sais pas comment inclure / exécuter plusieurs manifestes (autres que juste site.pp) dans le flux de travail d'exécution de marionnettes sans transformer les manifestes supplémentaires en modules et les inclure de cette façon.

Dans le répertoire des manifestes de marionnettes vers lequel je pointe Vagrant (voir ci-dessous), j'ai deux manifestes que je veux exécuter: site.pp et hierasetup.pp.

config.vm.provision "puppet" do |puppet|
  puppet.manifests_path = "puppet_files/manifests"
  puppet.module_path    = "puppet_files/modules"
  puppet.manifest_file  = "site.pp"
  puppet.options = "--verbose --debug"
end 

Actuellement, j'ai site.pp être le manifeste qui appelle hierasetup.pp. Mon site.pp ressemble à ceci:

File {
  owner => 'root',
  group => 'root',
  mode  => '0644',
}

import "hierasetup.pp"

include jboss

Mais je reçois cette erreur sur la dépréciation de "importer":

Avertissement: L'utilisation de 'import' est déconseillée dans /tmp/vagrant-puppet-1/manifests/site.pp:33. Voir http://links.puppetlabs.com/puppet-import-deprecation (sur grammar.ra: 610: dans `_reduce_190 ')

Selon l'URL référencée sous "À essayer à la place", il est indiqué " Pour conserver vos définitions de nœuds dans des fichiers séparés, spécifiez un répertoire comme manifeste principal ".

En outre, ce doc fantoche sur les manifestes principaux dit:

" Recommandé: si vous utilisez fortement le manifeste principal au lieu de vous fier à une ENC, envisagez de changer le paramètre du manifeste en $ confdir / manifestes. Cela vous permet de diviser votre code de niveau supérieur en plusieurs fichiers tout en évitant le mot-clé d'importation. Il correspondra également au comportement des environnements simples. "

Il semble que Puppet puisse référencer un répertoire entier au lieu d'un simple fichier manifeste, de sorte que je m'attendrais à ce que Vagrant prenne des dispositions pour cela et me permette de supprimer la ligne " puppet.manifest_file =" site.pp "et de pointer vers le répertoire parent à la place dans lequel tous les fichiers * .pp seront exécutés. Cependant, la suppression de cette ligne dans Vagrant ne fait que générer une plainte concernant un "default.pp" attendu à sa place:

provisionneur de marionnettes: * Le manifeste de marionnettes configuré est manquant. Veuillez spécifier un chemin vers un manifeste existant: /some/path/puppet_files/manifests/default.pp

Donc:

  1. Premièrement, est-ce que je comprends la "nouvelle" façon (non-importée) d'appeler correctement plusieurs manifestes, en ce sens qu'un répertoire doit être pointé vers lequel tous les fichiers * .pp qu'il contient seront exécutés?
  2. Et deuxièmement, Vagrant a-t-il «rattrapé» ce nouveau changement pour tenir compte du référencement des répertoires conjointement avec la dépréciation de Puppet de «l'importation»?

Mise à jour: Grâce à Shane, le problème avec # 2 (le code de Vagrant n'est pas rattrapé pour permettre de pointer vers les répertoires de manifestes de marionnettes) a été signalé sur le site de suivi des problèmes GitHub de Vagrant et a depuis été corrigé: https://github.com/mitchellh/vagrant / numéros / 4169

Réponses:


6

Premièrement, est-ce que je comprends la "nouvelle" façon (non-importée) d'appeler correctement plusieurs manifestes, en ce sens qu'un répertoire doit être pointé vers lequel tous les fichiers * .pp qu'il contient seront exécutés?

Oui. Voir ici :

Si vous utilisez fortement le manifeste principal au lieu de vous fier à une ENC, envisagez de changer le paramètre du manifeste en $ confdir / manifestes. Cela vous permet de diviser votre code de niveau supérieur en plusieurs fichiers tout en évitant le mot-clé d'importation.

De plus, manifestet modulepathsont également obsolètes en faveur des environnements de répertoire et du comportement du répertoire manifeste, voir ici :

Maintenant que les environnements de répertoire sont terminés, les environnements de fichier de configuration sont obsolètes. La définition de blocs d'environnement dans puppet.conf provoquera un avertissement de dépréciation, de même que toute utilisation des paramètres modulepath, manifest et config_version dans puppet.conf.

Il s'agit d'un changement assez important pour de nombreux déploiements, mais devrait être une bonne amélioration à long terme.


Et deuxièmement, Vagrant a-t-il «rattrapé» ce nouveau changement pour tenir compte du référencement des répertoires conjointement avec la dépréciation de Puppet de «l'importation»?

Non, il n'a pas; de leurs documents:

manifest_file (string) - Le nom du fichier manifeste qui servira de point d'entrée pour l'exécution de Puppet. Ce fichier manifeste devrait exister dans le chemin de manifestes configuré

Pour une utilisation avec Vagrant, vous êtes coincé avec les avertissements de dépréciation pour l'instant, ce qui est regrettable. Mais l'importation n'est pas prévue pour être supprimée avant 4.x, ce qui donne à Vagrant un certain temps pour rattraper son retard.


Eh bien, c'est bon de savoir que je ne deviens pas fou parce que j'essaie de comprendre quel était l'accord depuis plus d'une heure maintenant. Les développeurs de Vagrant sont-ils conscients de la nécessité de cette fonctionnalité, ou sinon, existe-t-il un endroit pour suggérer de tels ajouts?
SeligkeitIstInGott

On dirait que cela ne leur a pas encore été demandé - voir ici . Déposez un problème pour l'aligner mieux avec une marionnette moderne (ou je le ferai si vous n'avez pas de compte github)!
Shane Madden

Je pense que mes collègues de développement ont tous des comptes Github, mais si j'en ai un, je ne sais même pas quelle serait ma connexion. Je n'en ai pas besoin depuis que je suis IT et pas codeur. Ça vous dérangerait terriblement de faire ça?
SeligkeitIstInGott

1
@SeligkeitIstInGott Bien sûr, je vais déposer quelque chose!
Shane Madden

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.