Pour les administrateurs systèmes sous Linux, Puppet s’impose comme la solution Open Source par excellence pour automatiser la gestion d’un parc de serveurs, de quelques-uns à plusieurs milliers.
Fort de sa longue expérience avec Puppet depuis 2007, Camptocamp propose désormais un cursus complet de formation en France et en Suisse :
- Formation Puppet : les fondamentaux (3 jours) ;
- Formation Puppet : utilisation avancée (3 jours) ;
- Formation Puppet : étendre Puppet avec Ruby (4 jours) ;
Destinées à découvrir, implémenter et adapter Puppet à son infrastructure informatique, ces formations sont dispensées par un expert reconnu dans la communauté.
Outre contribuer activement au projet Puppet (GitHub), les experts de Camptocamp s'impliquent également dans des projets Open Source connexes tels que Augeas et Mcollective.
En résumé, pour garantir disponibilité, robustesse et reproductibilité des applications métier que vous déployez, utilisez Puppet et facilitez-vous la vie !
NdM : Le tarif est de 1950 € par participant pour les formations de 3 jours et 2450 € pour la formation de 4 jours.
Aller plus loin
- Plus de détails sur la formation Puppet : les fondamentaux (476 clics)
- Plus de détails sur la formation Puppet : utilisation avancée (166 clics)
- Plus de détails sur la formation Puppet : étendre Puppet avec Ruby (102 clics)
- www.camptocamp.com (162 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: puppet vs. ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 9.
Ton argumentaire sans faille m'a convaincu ! Merci de m'avoir ouvert les yeux.
[^] # Re: puppet vs. ruby
Posté par Anonyme . Évalué à 1.
En même temps, comparer Ruby/Python/Perl/, c'est très, très
conmarketing, pardon.[^] # Re: puppet vs. ruby
Posté par Anonyme . Évalué à 0. Dernière modification le 21 mai 2013 à 21:44.
Il manque un bout.
Je disais donc, comparer Ruby/Python/Perl/*autre langage de script* au C […].
[^] # Re: puppet vs. ruby
Posté par Atem18 (site web personnel) . Évalué à 4.
Vous lui reprochez quoi au Ruby au juste à part d'être un langage pour hipsters ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: puppet vs. ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6. Dernière modification le 22 mai 2013 à 11:47.
Je marche dedans !
Tu n'aimes pas non plus les décorateurs en python ?
Il va falloir que tu détailles un peu plus, parce que je n'ai pas bien compris que ce que tu veux dire.
C'est au contraire tout ce qu'il y a de plus logique. En quoi 0 ou "" devraient être faux ?
Je te concède que a=a qui renvoie nil est une aberration. Le deuxième exemple n'est plus valide.
Ce qui est très amusant, c'est que ce bouquin est la traduction de Learn Python The Hard Way. Je te laisse lire ici : http://learnpythonthehardway.org/book/ex36.html
Ensuite, prendre _why en exemple représentatif de la communauté ruby, n'est-ce pas un peu de la mauvaise foi ? Ce serait comme dire que que la communauté linuxfr t'a dégoûté parce que tu as lu un commentaire de Zenitram…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: puppet vs. ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Il n'y a pas de différence syntaxique parce que dans les deux cas tu fais un appel de méthode. Cela a à mon sens de nombreux avantages (facilite la compatibilité arrière, permet de fournir une API qui est sémantique et non pas imposée par la manière de stocker les données dans ta classe).
Je comprends que ce choix ne te plaise pas, mais de la à dire que ça fait de ruby une « bouse » (car il me semble que c'est le seul argument qui te reste comparé à Python que tu sembles apprécier), n'est-ce pas un peu trollesque ?
Note que c'est décrit comme :
On ne peut pas vraiment dire que c'est décrit comme une ressource sérieuse et officielle…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: puppet vs. ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Alors qu'en python, pas du tout :
Passons sur le message d'erreur pas du tout explicite, la règle « une méthode dont le nom commence par __ est privée sauf si le nom se termine aussi par __ » est quand même sacrément tordue…
[^] # Re: puppet vs. ruby
Posté par lolop (site web personnel) . Évalué à 3.
Ça devrait le faire:
Sinon, les doubles tiret bas au début et à la fin d'un identificateur sont normalement réservés pour le langage, tu ne devrais pas les utiliser pour tes propres identificateurs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: puppet vs. ruby
Posté par Atem18 (site web personnel) . Évalué à 2.
Techniquement, c'est aussi le cas en python.
En Python aussi, on a des "easters eggs". Importe le module "this" et ceci apparaîtra :
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea—let's do more of those!
[^] # Re: puppet vs. ruby
Posté par HSimpson . Évalué à 3.
Bin si! Tout simplement parce que tu n'a jamais accès directement aux attributs, tu passes obligatoirement par des setter/getter:
un
est juste équivalent à
Et je trouve ça super pratique (bien que pas optimale niveau vitesse, mais ruby n'est pas connu pour être rapide…)
# puppet vs codeur
Posté par fcartegnie . Évalué à 4.
Et dans les jours de formations, y'a combien de temps prévu pour corriger les fausses pistes lancées par les incohérences du langage ?
- Des ressources appelées classes parce que probablement issue de la vue "héritage" du codeur, sans remise en question pour l'utilisateur final.
- L'utilisation d' "include" qui n'a pas le même sens pour un programmeur et qui ici déclare l'utilisation (donc ~ l'instance) des classes.
- Des syntaxes différentes pour la déclaration des ressources, parce que les "include" ne marchent pas avec les classes paramétriques (probablement pas prévues non plus au départ).
- …
# la solution open source par excellence
Posté par Grégoire Seux (site web personnel) . Évalué à 4.
Il me semble un peu biaisé de présenter puppet comme la solution de référence pour la gestion de conf d'un parc de machine; chef est le challenger qui gagne le plus de momentum (parmi les personnes ayant un background de developpeur il est vrai).
Quant au troll sur ruby, bien joué mais il est un peu tôt dans la semaine pour ce genre de commentaire :)
[^] # Re: la solution open source par excellence
Posté par CamilleM . Évalué à 2.
Ou Ansible (http://ansible.cc/ )
[^] # Re: la solution open source par excellence
Posté par GeneralZod . Évalué à 3.
Ansible a été développé par un ancien Product Manager de Puppet Labs par ailleurs (et également l'auteur original de Cobbler et Func). ;)
# c2c c'est de la balle
Posté par hugoL . Évalué à -2.
Voilà c'est dit.
Je parle du .org bien sur, pour le reste je ne peux pas juger.
# Et par rapport à Fabric ?
Posté par kadalka . Évalué à -7.
Et par rapport à Fabric ?
C'est comment ?
[^] # Re: Et par rapport à Fabric ?
Posté par lolop (site web personnel) . Évalué à 2.
De ce que j'en ai vu (présenté par un collègue qui utilise puppet), Fabric serait au mieux une couche basse de puppet pour faciliter les communications.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# CFEngine
Posté par AsM0DeUz . Évalué à 3.
Ne pas oublier CFEngine qui est plus orienté administrateurs système que Puppet ou Chef. Puppet et Chef se basent sur CFEngine 1 qui n'était pas bien terrible mais depuis la v2 c'est le jour et la nuit.
Puppet a le très gros désavantage de bouffer énormement de mémoire aussi bien sur les serveurs administrés que sur le serveur qui gère le parc. Il est rapidement submergé sur un parc assez grand. Tout le contraire de CFEngine qui a une faible empreinte mémoire et peut sans soucis gérer des parcs immenses.
Je ne comprends pas vraiment l'engouement pour Puppet … peut être le partenariat avec VMWare … ca doit aider :)
[^] # Re: CFEngine
Posté par Joff54 . Évalué à 3.
Sans oublier les dépendances qui sont pharaoniques pour les produits Ruby contrairement à CFEngine ou il y a 1 ou 2 dépendances. Ca, pour moi, c'est vraiment un + pour CFEngine.
Personnellement, j'ai eut la flemme d'apprendre Ruby. J'ai trouvé plus facile d'apprendre le "langage" de CFE qu'un langage complet comme Ruby.
# Rudder
Posté par Christophe Bliard . Évalué à 7.
Il existe aussi Rudder. Il se base sur CFEngine et FusionInventory et propose une interface web d'administration et de supervision du parc. Il se veut simple à administrer et complet.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.