Question Différences entre «application de marionnette» locale et «agent de marionnette» pour un marionnettiste


Nous sommes en train de migrer d'un référentiel de marionnettes monolithique qui contient toute la configuration. Ce référentiel contient des éléments qui ne devraient pas figurer sur tous les nœuds. Un système basé sur les maîtres de marionnettes semble donc le meilleur moyen de séparer les éléments de manière appropriée.

Le problème que j'ai est que le même repo fonctionne très bien lorsqu'il est copié sur les nœuds locaux et puppet apply /etc/puppet/manifests/site.pp courir dessus. Nos installations fonctionnent très proprement.

Lorsque je pose le repo de marionnettes sur le maître des marionnettes et que je signe l'agent, il ne semble rien faire d'autre que signaler son catalogue local au maître des marionnettes.

Pendant un certain temps là-bas, et je n’ai pas été capable de reproduire la configuration qui l’a fait, un de nos modules construit par nous-mêmes a généré une erreur suggérant qu’il essayait de copier un fichier à partir de la machine locale. modules répertoire, plutôt que le maître de marionnettes comme il se doit.

Ce qui suggère qu'il peut exister des différences de syntaxe entre le module et le manifeste lors de la création d'un référentiel pour une utilisation locale et via puppetmaster.

S'il y a des différences, quelles sont-elles ou quels sont les principaux points de déclenchement des efforts de conversion?


le /etc/puppet/puppet.conf fichier sur le maître:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

# Set up Environments
## Each environment has a dedicated 'modules' directory under /environments/ from
## which puppet will preferentially pull. Otherwise, it'll use the top level  
## 'modules' directory. That is where common code goes.
[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules
  ssl_client_header= SSL_CLIENT_S_DN
  ssl_client_verify_header = SSL_CLIENT_VERIFY
[production]
  manifest=$confdir/manifests/site_prod.pp
[integration]
  manifest=$confdir/manifests/site_integ.pp
[development]
  manifest=$confdir/manifests/site_dev.pp
[operations]
  manifest=$confdir/manifests/site_ops.pp

Pour le moment, le site_prod.pp fichier et ilk sont des liens symboliques vers site.pp.

Les classes définies dans le fichier site.pp fonctionnent en dehors du nom d'hôte. Comme je l'ai mentionné, lors de l'exécution via puppet apply les choses fonctionnent bien. Si le pire venait à se dégrader, je peux faire ce dont j'ai besoin en installant une installation temporaire NFS, mais je préfère ne pas le faire.


site.pp Pour votre plaisir:

filebucket { "main": server => $server; }
File { backup => "main" }

Exec { path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }

import "stages.pp"
import "int_setup.pp"
import "nodes.pp"

Les fichiers .pp importés se trouvent dans le même répertoire que site.pp. nodes.pp est où la viande est, mais contient également la sauce secrète. Quelques extraits:

node /clunod\-wk\d+\.sub\.example\.local/ {

  class { "int_setup": stage => "setup"; }
  include base
  include curl
  include custommodule
  [...]
}

Qui peut et correspond aux nœuds nommés clunod-wk01234.sub.example.local quand exécuter via marionnette appliquer.

[int-setup.pp]

class int_setup {
  file { "/var/cluebat":
    ensure => directory,
    mode => "755",
    owner => "root",
    group => "root";
  }

  group{"puppet":
    ensure => present
  }

}

4
2018-01-08 20:53


origine




Réponses:


La seule difficulté que je connaisse est dans le file type de ressource.

La sauvegarde des fichiers remplacés se comporte différemment, en utilisant par défaut le plateau de fichiers du serveur au lieu du plateau de fichiers local.

La chose la plus importante à prendre en compte est la source paramètre.


source => '/tmp/somepath/sshd_config',

Avec un chemin de fichier brut, il essaiera toujours le chemin local.


source => 'puppet://puppetmaster1/modules/sshd/sshd_config',

Avec un puppet://server/ chemin, ça va toujours essayer le chemin distant.


source => 'puppet:///modules/sshd/sshd_config',

Avec une spécification de serveur vide, cela devient intéressant.

Appliqué localement, le chemin du module de marionnettes local est utilisé pour rechercher le fichier.

Lors du rapport à un maître de marionnettes, le serveur qui lui a donné le manifeste est traité comme le serveur.


En outre, si vous devez faire preuve de créativité quant à la source d’un fichier, vous pouvez indiquer au source paramétrer une liste:

source => [ '/tmp/somepath/sshd_config', 'puppet:///modules/sshd/sshd_config'],

Le premier emplacement où quelque chose a été trouvé sera utilisé.


5
2018-01-08 23:40



Oh, et sur les problèmes liés à l’obtention des nœuds pour appliquer les manifestes à partir du serveur, obtenez-vous quelque chose d’intéressant d’un puppet agent --test? - Shane Madden♦
Non, bien que je commence à avoir des indications que mon node les déclarations se comportent mal d'une manière ou d'une autre. Changer un en 'nœud par défaut' au lieu de cette expression rationnelle a changé les choses de manière intéressante. - sysadmin1138♦


Le problème a fini par être une différence dans la façon dont les nœuds ont été sélectionnés. Le code dans l'original nodes.pp fichier:

node /clunod\-wk\d+\.sub\.example\.local/ { )

Qui correspond correctement à un nœud nommé clunod-wk01234.sub.example.local. Cela fonctionnait très bien quand puppet apply a été exécuté contre un manifeste de marionnettes local. Mais n'était pas à distance.

La question était de savoir comment localhost la ligne a été définie dans /etc/hosts.

Ne fonctionne pas:

127.0.0.1  localhost clunod-wk01234 clunod-wk01234.sub.example.local

Travail:

127.0.0.1  localhost clunod-wk01234.sub.example.local clunod-wk01234

Le premier formulaire signalait un nom de nœud "clunod-wk01234" au maître des marionnettes, le deuxième formulaire signalait le nom de domaine complet. La seconde forme satisfait le node delcaration, où le premier ne le fait pas. Cela a été résolu en changeant les lignes de nœud pour ne pas inclure le nom de domaine complet, auquel cas tout fonctionnait parfaitement.

Les machines avec la marionnette distante étaient une image mise à jour, il y avait donc de légères différences avec celles qui exécutent marionnette locale. L’un de ces changements a fini par concerner la façon dont cette ligne /etc/hosts a été déclaré. Maintenant nous savons.

J'ai ensuite trouvé que deux appels de fichiers étaient écrits en utilisant des chemins d'accès durs, les autres étant utilisés syntaxe correcte puppet: ///.


4
2018-01-09 18:50





Il n'y a pas de différence entre les règles de marionnettes "locales" et "distantes".

Pouvez-vous poster votre site.pp afin que nous puissions vérifier les erreurs?

Le serveur et les clients utilisent-ils le même serveur DNS? Est-ce que leurs fichiers /etc/resolv.conf diffèrent dans les lignes 'search' ou 'domain'?

Vous pouvez également exécuter des marionnettes avec --debug --verbose --no-daemonize options et obtenir plus de sortie.


1
2018-01-08 21:00



J'utilise le truc --debug --verbose --no-daemonize pour obtenir ce que je peux. Ils utilisent tous les mêmes résolveurs DNS. Heck, coder en dur les deux dans / etc / hosts ne change rien. Je soupçonne que certaines différences dans la détermination de l'appartenance à une classe sont en cause, mais je ne sais pas quoi. - sysadmin1138♦
Essayez de simplifier votre configuration. N'utilisez pas d'environnements et de modules. n'incluez qu'une simple classe "test". Ensuite, créez des fonctionnalités à partir de là. - hayalci