Comment les petits gars peuvent-ils apprendre et utiliser efficacement Puppet? [fermé]


109

Il y a six mois, dans le cadre de notre projet à but non lucratif, nous avons décidé de commencer à migrer la gestion de nos systèmes vers un environnement contrôlé par Puppet, car nous nous attendons à ce que notre nombre de serveurs augmente considérablement d'ici à un an.

Depuis que la décision a été prise, nos informaticiens sont devenus un peu trop énervés, un peu trop souvent. Leurs plus grandes objections sont:

  • "Nous ne sommes pas des programmeurs, nous sommes des administrateurs système";
  • Les modules sont disponibles en ligne mais beaucoup diffèrent les uns des autres; On réinvente trop souvent les roues, comment décider laquelle convient le mieux?
  • Le code dans notre référentiel n'est pas assez transparent pour trouver comment fonctionne quelque chose, ils doivent récidiver à travers des manifestes et des modules qu'ils auraient même écrits eux-mêmes il y a quelque temps;
  • Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires à celles des autres modules, ce qui est un processus difficile.
  • "Lançons-le et voyons comment ça marche"
  • Des tonnes d'extensions à peine connues dans les modules de la communauté: 'trocla', 'augeas', 'hiera' ... comment nos administrateurs système peuvent-ils garder la trace?

Je peux voir pourquoi une grande organisation enverrait ses administrateurs système à des cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les plus petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s’ils ne suivent pas de cours et ne l’apprennent pas en gros via leur navigateur et leur éditeur?

Réponses:


101

J'ai commencé à utiliser Puppet avant de déployer une nouvelle infrastructure et j'ai simplement acheté un livre ( bien considéré ) sur le sujet. Je ne pense pas que la plupart des gens obtiennent une formation professionnelle en marionnettes. J'ai travaillé sur des exemples jusqu'à ce que je puisse adapter le processus à mon environnement. C'était en décembre 2011, alors en quelques semaines, j'ai été capable de comprendre les bases et de mettre en place un cadre de production. Je ne connaissais pas bien la gestion de la configuration, je connais bien CFEngine , mais bon nombre des préoccupations de vos administrateurs système résonnent. J'ai fait des erreurs et j'ai dû refacturer plusieurs fois, mais j'ai réussi à faire fonctionner les choses de manière satisfaisante.

Quelques notes sur vos points ...

  • Le rôle traditionnel de l'administration des systèmes est en train de changer. Adapter ou être laissé pour compte. Je suis un ingénieur système performant, mais je dois également me réoutiller (apprendre Python, par exemple). L'accent mis sur les serveurs individuels est réduit au fur et à mesure que l'abstraction matérielle via la virtualisation et les services de cloud public et privé gagnent en popularité. Cela implique une automatisation des tâches du système et l’utilisation de la gestion de la configuration pour contrôler un plus grand nombre de serveurs. Ajoutez des concepts DevOps à la combinaison et vous verrez que les attentes et les exigences du client / utilisateur final changent.

  • Les modules de marionnettes disponibles en ligne diffèrent par leur style et leur structure et, oui, j’ai constaté de nombreux chevauchements, redondances et redondances. Un développeur avec lequel j'ai travaillé a déclaré: "Vous auriez pu développer vos propres outils en passant du temps à chercher en ligne quelque chose qui fonctionne!" Cela me donna une pause lorsque je réalisai que Puppet semblait intéresser davantage les développeurs que les administrateurs cherchant des pratiques optimales ou la bonne approche.

  • Documenter beaucoup afin d'avoir une idée de la façon dont les choses sont connectées. Compte tenu des définitions incertaines et de l’absence de méthode standard , votre structure de gestion de la configuration est vraiment unique pour votre environnement. Cette transparence devra être développée au sein de.

  • Je dirais qu'il est relativement facile de dupliquer un module pour accueillir un nouveau démon ou ajouter un service à un manifeste existant, en fonction de la manière dont vous avez organisé vos serveurs et vos rôles.

  • J'ai passé beaucoup de temps à tester une seule cible avant de transmettre les modifications à des groupes de serveurs plus importants. Faire fonctionner puppetd à la main sur un serveur représentatif m'a permis de déboguer les modifications et d'évaluer leur impact. C'est peut-être un peu conservateur, mais c'était nécessaire.

  • Je ne sais pas à quel point je dépends de modules communautaires. J'ai dû commencer à utiliser Augeas pour certains travaux et j'ai déploré le fait que c'était une fonctionnalité que je prenais pour acquise dans CFEngine.

Dans l’ensemble, j’ai le sentiment qu’il n’existe pas de norme bien définie en matière de marionnettes. J'ai eu du mal à comprendre comment organiser la structure de répertoires sur mon maître Puppet , comprendre comment gérer la signature de certificat, mettre en place le bon DNS inversé partout, faire en sorte que Puppet s'adapte correctement à l'environnement et comprenne quand exploiter les modules de la communauté plutôt que de construire le mien. C'est un changement de mentalité et je vois comment une telle panique se produirait. Cependant, c'était aussi une solution construite à partir de zéro, j'ai donc eu le luxe d'évaluer des outils. La décision d’aller dans cette direction était basée sur l’esprit partagé et sur l’élan derrière Puppet. Cela valait la peine d'apprendre quelque chose de nouveau.

N'oubliez pas que ce site est également une bonne ressource.


20
Je suis passé d'aucune expérience sur Puppet à la gestion complète de mon environnement en deux semaines. Je suis responsable d'environ 40 machines virtuelles, bien que toutes exécutent Ubuntu. Cela simplifie un peu les choses. Je suis développeur de profession. "Adaptez-vous ou laissez-vous derrière" - je suis maintenant devops + sysadmin + architecte. Excellente réponse!
François Beausoleil

Je leur recommanderais de commencer à déployer de petits services, d'abord en mode autonome, puis de commencer à bricoler avec plus de serveurs. Je n'ai pas à travailler avec Puppet, mais j'ai un petit VPS et j'ai récemment créé mes propres modules Puppet. S'ils veulent suivre le reste des administrateurs système du siècle en cours, ils feraient mieux de rester ouverts. Je le fais parce que j'aime bien, et je suppose que tout le monde n'aime pas apprendre de nouvelles choses, mais une chose est sûre, de nos jours, les administrateurs système sont plus proches des développeurs que jamais.
Sergio Galvan

2
Je travaille dans une petite entreprise et je cours également puppetd -tpour tester sur quelques boîtes avant de transmettre à tous les serveurs. Il est toujours vrai qu'un couple a quelque chose d'unique qui provoque l'échec de ses mises à jour. La marionnette est beaucoup plus facile lorsque vous avez un environnement contrôlé et cohérent pour le début.
Jordan

1
@ewwhite, j'ai parcouru le didacticiel de Puppet dans leur documentation, mais je me demandais quel livre vous avez utilisé pour apprendre? J'ai un peu l'impression que le didacticiel fourni dans la documentation manquait de quelque chose qui empêche tout de cliquer avec moi, car je travaille avec Puppet sur des hôtes tests pour apprendre ce que je fais. EDIT: Ou toute autre ressource que vous pouvez recommander. Merci.
Mike Keller

1
@MikeKeller J'aimais ça dans mon post ... Mais c'est disponible ici .
ewwhite

29

Dans un emploi précédent, on m'avait confié la tâche de faire une implémentation pilote de Puppet. Maintenant, j'ai des connaissances en programmation, mais pas Ruby, donc je n'ai pas autant de problèmes que les autres.

Cependant, il est intéressant de noter que les programmeurs sans expérience des paradigmes non traditionnels ont également un problème avec Puppet, car Puppet est déclaratif et non impératif. En ce sens, Puppet fonctionne à peu près comme n'importe quel fichier de configuration: vous dites comment les choses devraient se passer et Puppet se charge du reste.

Après le pilote, j’ai eu l’occasion de former une douzaine d’administrateurs avec Puppet et de faire des présentations à ce sujet lors de deux événements. Ce que je retiens de cette expérience, c’est que certains administrateurs l’ont prise, d’autres non. C'étaient tous des administrateurs traditionnels, sans compétences en programmation et avec différents niveaux d'expertise.

Une chose que j'ai remarquée, c'est que Puppet nécessite une pratique constante . Les personnes formées ont écrit des modules, puis passé un mois ou deux à faire autre chose, sont revenues à Puppet avec peu de compétences utiles. Les gens qui continuaient à faire de petites choses chaque semaine n'y perdaient jamais cette possibilité.

Sur la base de ces deux observations, je vous recommande de vous assurer que tout le monde continue d’ajouter une classe, une définition ou un module de marionnettes chaque semaine (de préférence au moins deux ou trois fois). Ceux qui ne peuvent toujours pas s'y habituer pourraient ne pas avoir les compétences nécessaires pour le faire.

Encore une fois, si Puppet leur était imposée d'en haut, ils pourraient simplement réagir à ce qu'ils perçoivent comme une gestion empiétant sur la façon dont ils effectuent leur travail - ce qui serait assez vrai, en fait. Il pourrait être le cas que les laisser choisir qui système de gestion de configuration à utiliser améliorerait les choses. Voici quelques alternatives:

  • ANSIBLE : Ceci est nouveau, mais il est basé sur des commandes shell et ssh, ce qui pourrait l’attirer chez les administrateurs systèmes traditionnels.
  • Chef : Peut-être que leur problème est un style déclaratif, auquel cas Chef serait mieux s’ils avaient l’expérience Ruby.
  • SaltStack : basé sur Python et open-source
  • CFEngine : vieux, rapide, traditionnel - il pourrait les convaincre pour ces raisons.

12
La bonne chose à propos d'ANSIBLE est qu'il fonctionne sur des distances galactiques sans aucun délai dans la transmission de données!
Kalamane

1
Merci pour la mention ANSIBLE. Je n'étais pas au courant jusqu'à maintenant.
ewwhite

@ewwhite De rien. Je l’ai moi-même découvert récemment, mais beaucoup de choses ont attiré mon attention. Si nous n'avions pas déjà autant dans Puppet, je l'essayerais certainement.
Daniel C. Sobral

11

J'utilise Puppet depuis un peu plus de deux ans dans de petits magasins où j'étais le seul administrateur système. Le plus gros obstacle que j'ai eu à apprendre est d'apprendre à développer des logiciels correctement. Il ne s’est pas passé une semaine au cours de laquelle je n’ai pas foiré quelque chose que j’avais dit aux développeurs de ne pas faire douze fois. J'ai enregistré trop de code, je n'ai pas cassé les checkins, je n'ai pas tagué, je n'ai pas créé de branche, je n'ai pas exécuté de vérificateur de syntaxe, je n'ai pas utilisé de norme, etc. Si vous venez juste de commencer sur je recommanderais certaines des choses suivantes.

  1. Réalisez que vous développez un logiciel que vous ne savez pas faire ou que vous faites mal. Ceci est attendu parce que c'est nouveau.
  2. L'infrastructure en tant que code est la réalité et une fois que vous avez surmonté la bosse, c'est assez puissant. J'inviterais certains développeurs, leur montrerais votre processus de développement actuel (ou leur absence), ne vous fâchez pas lorsqu'ils lèvent les sourcils et prenez leurs suggestions au sérieux. Je recommanderais d'utiliser le système et le processus que vos développeurs utilisent, à moins que cela ne soit complètement inapproprié.
  3. Les modules tiers de Puppet sont sucés 90% du temps. Je les lisais. Je leur volais des idées. Je ne les attirerais pas dans mon système sans modifications majeures. Cependant, je tirerais la marionnette stdlib qui ajoute quelques fonctionnalités intéressantes.
  4. augeas et hiera. Apprenez ces deux. Le premier permet l'édition complexe de fichiers existants en place. Le second est un magasin de données externe.
  5. Séparez le code des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs codées en dur, telles que la surveillance des hôtes dans le code de votre module, sont mauvaises. Les placer dans un magasin de données (db, yaml (que Hiera utilise par défaut), csv, peu importe) que vos modules peuvent consommer est bon. Un exemple est une application Web qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela simplifie votre processus de développement.
  6. analyseur de marionnettes valider et puppet-lint dans le cadre de votre processus d’archivage avant ou après le code. Des tests rspec peuvent également être une bonne idée une fois que vous êtes au courant.
  7. écrivez un code / guide de style et utilisez-le. "où est le code qui installe Apache" est un problème courant. Si vos modules sont généralement les mêmes, cela devrait être facile.

En résumé, j'ai rencontré tous ces problèmes, de même que la plupart de mes amis administrateurs système. Il faudra un certain temps pour bien utiliser un système de gestion de configuration. Une fois que vous avez fait, vous vous demanderez comment vous avez vécu sans un. "Connectez-vous à un serveur et effectuez les modifications manuellement? Ick."


Merci pour vos suggestions, en particulier augeas et hiera sont deux composants que nous avons commencé à mettre en œuvre et cela nous a rendu beaucoup plus conscients, même confiants, des capacités de Puppet. Alors merci :-)
drumfire

7

Il y a six mois, dans le cadre de notre projet à but non lucratif, nous avons décidé de commencer à migrer la gestion de nos systèmes vers un environnement contrôlé par Puppet, car nous nous attendons à ce que notre nombre de serveurs augmente considérablement d'ici à un an.

Cela semble être une très bonne idée de commencer tôt - Puppet est plus qu'une simple gestion de configuration, c'est une forme de documentation.

Depuis que la décision a été prise, nos informaticiens sont devenus un peu trop énervés, un peu trop souvent.

Ils ont besoin d'un ajustement d'attitude.

"We're not programmers, we're sysadmins";

Encore une fois, attitude. Vous pouvez créer un fichier de configuration pour un serveur, n'est-ce pas? Vous pouvez vous familiariser avec les modèles et les "programmeurs" à mesure que vos besoins et votre complexité évoluent .

Les modules sont disponibles en ligne mais beaucoup diffèrent les uns des autres; On réinvente trop souvent les roues, comment décider laquelle convient le mieux?

Difficile à répondre - je préfère toujours les modules puppetlabs à la plupart - et même à cela, je n'en utilise pas beaucoup. Jugement à coup sûr. À mon avis, certains modules sont «trop volumineux».

Le code dans notre référentiel n'est pas assez transparent pour trouver comment fonctionne quelque chose, ils doivent récidiver à travers des manifestes et des modules qu'ils auraient même écrits eux-mêmes il y a quelque temps;

Cela ne ressemble pas à un problème de marionnette, mais plutôt à un problème d’organisation ou de documentation?

Un nouveau démon nécessite l'écriture d'un nouveau module, les conventions doivent être similaires à celles des autres modules, ce qui est un processus difficile.

Ce démon pourrait être une classe s'il est assez simple à gérer. Je ne suis pas sûr de ce que vous entendez par conventions, marionnette vous impose assez bien les conventions, n'est-ce pas? Ou sommes-nous en train de parler de la mise en forme du code?

"Let's just run it and see how it works"

Ce n’est pas une si mauvaise idée si vous le prenez lentement et en sécurité. Je commencerais toujours par une machine virtuelle pour comprendre l'essentiel.

Des tonnes d'extensions à peine connues dans les modules de la communauté: 'trocla', 'augeas', 'hiera' ... comment nos administrateurs système peuvent-ils garder la trace?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, modules perl .. Choisissez ce que vous voulez et utilisez-le? Je suppose que cela sonne plus comme une chose d'attitude à nouveau ...

Je peux voir pourquoi une grande organisation enverrait ses administrateurs système à des cours de marionnettes pour devenir des maîtres de marionnettes. Mais comment les plus petits joueurs pourraient-ils apprendre Puppet à un niveau professionnel s’ils ne suivent pas de cours et ne l’apprennent pas en gros via leur navigateur et leur éditeur?

Je n'ai suivi aucun cours - bien que je sois programmeur plus qu'un administrateur système, j'ai constaté qu'il ne nécessitait pas beaucoup de compétences en programmation pour que quelque chose soit accompli.

La documentation de Puppet, lorsqu'elle est suivie, est assez complète. Faites juste attention aux types intégrés et passez un peu de temps à regarder comment les autres modules sont assemblés. Je ne dirais pas que c'est super facile, mais ce n'est pas dur non plus. Préparer votre infrastructure pour la création de marionnettes prend un peu de temps, mais il est certain que le temps investi sera bien dépensé lorsque vous développerez votre infrastructure.


Pour info, cela vient de quelqu'un qui vient juste de finir de préparer son infrastructure. J'ai donc une nouvelle expérience et je ne peux pas dire que c'était du temps perdu.
thinice

En tant que membre récent, je me reconnais entièrement dans votre commentaire.
Martijn Heemels

1
Dans mon cas, un changement d'attitude était en effet nécessaire. Ops adore l’automatisation et utilise souvent des scripts, c’est donc essentiellement une question d’utilisation de différents outils. C'est un sentiment génial de voir votre manifeste de marionnettes configurer une machine complète ou un nouveau service à partir de zéro. Le fait qu'une erreur puisse avoir un impact sur plusieurs machines à la fois nécessite de s'habituer à des tests plus rigoureux, ce qui peut être agaçant, mais c'est évidemment une bonne chose. Expérimentez avec Vagrant, rspec-puppet, puppet-lint, Geppetto, Git branch et d'autres outils gratuits et vous découvrirez bientôt votre flux de travail préféré.
Martijn Heemels

1
Travailler avec Puppet m’a également aidé à apprendre Ruby, qui est venu remplacer Bash comme langage par défaut pour mes outils système.
Martijn Heemels

5

KISS (Keep it simple stupid) - N'utilisez pas les nouvelles technologies juste parce qu'elles existent, mais parce que vous en avez besoin, utilisez le strict minimum requis par votre déploiement, mettez à jour au besoin, n'essayez pas de suivre le rythme. bord. Si vous commencez avec une configuration de base et que vous vous appuyez sur cette dernière, il est plus facile de la récupérer au fur et à mesure, et ils ne devraient pas avoir besoin d'un cours (sont-ils même disponibles?).

Les autres domaines que vous pouvez regarder sont vos administrateurs système. S'ils ne peuvent pas également programmer, sont-ils suffisamment avancés pour un déploiement de grande envergure, où la majeure partie du travail doit être écrite avec les outils que vous utilisez?


4
... parce que nous nous attendons à ce que notre nombre de serveurs augmente considérablement d'ici un an. Exigence?
Jeff Ferland

1
Cela dépend vraiment de la certitude de cette attente et de la pertinence de ce que vous mettez en place au moment où le besoin se fait sentir.
JamesRyan

+1 pour "utiliser le strict minimum requis par votre déploiement" - Bon nombre des problèmes de marionnettes que j'ai rencontrés proviennent de la volonté de faire en sorte que les marionnettes contrôlent tout le système.
Sirex

5

Je travaille également pour un but non lucratif et j'étais responsable de la mise en place initiale des machines Linux, puis de la gestion de Puppet peu de temps après. Nous avons pris des mesures spécifiques qui ont vraiment contribué à faire avancer les choses.

Tout d’abord, j’ai essayé de rester à l’écart des modules tiers. Les outils intégrés gèrent 90% de notre gestion. Le plus gros utilitaire tiers que j'utilise est le module pare-feu. Tous les faits personnalisés, etc. sont développés avec toute l’équipe impliquée. Nous avons développé un module de gabarit et avons normalisé la gestion des fichiers, les packages, les services, etc.

Deuxièmement, après avoir normalisé l'utilisation des modules intégrés, nous avons commencé à utiliser Git et Atlassian's Crucible, gratuits pour les sociétés à but non lucratif, pour effectuer des analyses de toutes les modifications de configuration. Cela fournit la transparence souhaitée.

Troisièmement, j'ai automatisé la configuration de Puppet afin que de nouveaux hôtes puissent être ajoutés automatiquement avec un ensemble d'options par défaut. Il y a plusieurs façons de résoudre ce problème. Comme je disposais déjà d’un environnement complet Kickstart, j’ai choisi d’y ajouter un script.


4

"Nous ne sommes pas des programmeurs, nous sommes des administrateurs système"

La façon dont les temps ont changé a été pire: on s'attendait à ce qu'un gris comme moi soit un meilleur programmeur que les programmeurs professionnels, sans quoi il n'aurait jamais pu passer pour un administrateur système .

Nous avons maintenant des «administrateurs système», qui sont essentiellement des utilisateurs de bureau Windows qui ont été convertis à un moment donné sous Linux et qui ne peuvent pas programmer, et qui ne trouvent absolument aucun problème avec cela.

L’éléphant dans la pièce est la raison pour laquelle la direction tolère une telle attitude destructrice. Destructif à qui ou quoi? Pour l'entreprise et l'infrastructure.

Revenons à l’objet Puppet [, CFEngine, Chef]: dès que l’on installe une solution comme celle-ci, on perd. Tout le monde perd. Pourquoi? Parce que quiconque a eu cette idée n’est pas capable de concevoir une gestion de la configuration encapsulée sous forme de packages de système d’exploitation agréables et propres, Kickstart [, JumpStart, Installation automatisée, AutoYaST, Ignite-UX, NIM]. Lorsque vous devez utiliser un outil de piratage automatisé tel que Puppet (ou Chef ou CFEngine), vous ne disposez pas des moyens nécessaires pour concevoir et mettre en œuvre un processus qui, par cette même conception, imposerait des systèmes totalement gérés de manière totalement vierge et illimitée. automatisé et complètement non interactif.

Un autre point important est, si vous devez avoir des marionnettes ou d' une telle solution pour corriger quelqu'un de piratage du système ou la configuration de l' application à la main, qui remonte aussi à ne pas avoir l'expérience pour concevoir un processus, et dans ce processus un cadre dans lequel la configuration est emballé en composants discrets. En effet, quiconque implémente Puppet ou autre, n'a aucun concept de propriétaires de composants, de versions, de gestion de la configuration, de modèle de maturité de capacité. Cela devient rapidement un problème très grave dans l'industrie.

Travailler avec Puppet m'a également aidé à apprendre Ruby, qui est venu remplacer Bash comme langage par défaut pour mes outils système. "

Pourquoi Ruby est-il nécessaire, alors qu'une gestion complète de la configuration de bout en bout peut être encapsulée dans les sections preinstall, postinstall, preremove et posttremove des packages du système d'exploitation, en utilisant simplement les programmes Bourne Shell, AWK et sed? Il est absolument inutile que quelqu'un approfondisse l'apprentissage d'une langue ésotérique de Ruby et de son dialecte dans le contexte de Puppet. Le problème de la gestion de la configuration est facilement résolu (et a été résolu) avec les programmes shell et AWK, et un peu sed (1) ici et là comme une colle.

C'est un sentiment génial de voir votre manifeste de marionnettes configurer une machine complète ou un nouveau service à partir de zéro.

C’est encore plus cool de le faire avec Kickstart, AutoYaST ou JumpStart, sans une seule ligne de code , et d’interroger le système d’exploitation à l’aide d’outils intégrés, sans avoir besoin de logiciel ésotérique ou supplémentaire , sans client-serveur. l’architecture requise (SSH, c’est plus que bien, beaucoup plus que bien) et de voir votre système d’exploitation connaître chaque modification apportée.

5. code séparé des données. C'est l'un des concepts les plus difficiles à apprendre. Les valeurs codées en dur, telles que la surveillance des hôtes dans le code de votre module, sont mauvaises. Les placer dans un magasin de données (db, yaml (que Hiera utilise par défaut), csv, peu importe) que vos modules peuvent consommer est bon. Un exemple est une application Web qui utilise Mysql. Cela permet de pousser le code et les données séparément. Cela simplifie votre processus de développement.

... Ou vous pouvez simplement modéliser vos fichiers de configuration avec des variables shell, même des cotes en arrière (par exemple ls -1 ...) et écrire un script shell qui utilise AWK pour appeler eval (1) et développer toutes les variables du modèle, exploitant ainsi la même puissance puissante. analyseur dont les coquilles ont intégré. Pourquoi le rendre complexe, alors que cela peut être vraiment, vraiment simple? Où allez-vous stocker les valeurs de configuration? Pourquoi, n’importe où, par exemple des fichiers pkginfo (4), ou une base de données telle que Oracle, ou à peu près n’importe où . Pas besoin de solutions ultracomplexes. La bibliothèque que je mentionne ci-dessus pourrait simplement provenir des sections de pré-installation ou de post-installation des packages du système d'exploitation, supprimant ainsi la duplication et exploitant un élément de code central ...

Mais avant tout, je trouve que la citation ci-dessus est un exemple de la prochaine génération d’administrateurs système ayant besoin d’un tutorat, non pas d’administrateurs système, mais d’ ingénieurs système . Trouvez-vous un barbe et ouvrez une session en tant qu'apprenti.


1
Vous semblez avoir oublié votre réponse à la question des auteurs.
M. Glatki

Cette réponse semble être principalement une discussion sur les opinions, les attitudes et les outils, et ne répond pas vraiment à la question posée.
JonathanDavidArndt
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.