Formation Puppet : lancement d'un cursus complet en France et en Suisse par Camptocamp

Posté par . Édité par Xavier Claude. Modéré par Christophe Guilloux.
Tags :
8
21
mai
2013
Technologie

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.

  • # puppet vs. ruby

    Posté par . Évalué à -6.

    Ave,

    J'ai découvert puppet récemment, et je dois dire que je suis impressionné par la simplicité de l'outils. Très pythonique :-)

    Son vrai défaut, c'est vraiment ruby. Ce langage est une bouse pour développeur narcissique, et je pèse mes mots :-). C'est dommage car l'extensibilité de puppet est une fonctionnalité clef. J'ai été découragé de faire une extension. Peut-être parce que j'avais une main occupée à me boucher le nez.

    Bref, vivement une implémentation python de puppet :-P

    • [^] # Re: puppet vs. ruby

      Posté par . Évalué à -4.

      Pour étayer mon troll sur ruby, voici la page de documentation de ruby http://www.ruby-lang.org/fr/documentation/ . Morceaux choisis :

      Les Koans vous emmènent le long du chemin de l’illumination pour vous apprendre Ruby. […] Il vous enseignera aussi quelques points « culturels » (bonnes pratiques, état d’esprit du programmeur Ruby…)

      http://www.ruby-lang.org/fr/documentation/quickstart/4/

      La plupart des autres langages utilisent un itérateur célèbre, la « boucle for », ce qui donne par exemple en C :

      for (i=0; i<number_of_elements; i++)
      {
      do_something_with(element[i]);
      }
      Ce qui fonctionne parfaitement, mais n’est pas spécialement élégant.

      Mais le plus dégradant, c'est Poignant guide. Heureusement, le site est down à l'heure où j'écris ce commentaire. http://mislav.uniqpath.com/poignant-guide/ . Ça vaut son pesant de LSD.

      Et dire que linuxfr tourne avec ruby :'(

      • [^] # Re: puppet vs. ruby

        Posté par (page perso) . Évalué à 9.

        Ton argumentaire sans faille m'a convaincu ! Merci de m'avoir ouvert les yeux.

      • [^] # Re: puppet vs. ruby

        Posté par (page perso) . Évalué à 1.

        En même temps, comparer Ruby/Python/Perl/, c'est très, très con marketing, pardon.

        Love, bépo.

        • [^] # Re: puppet vs. ruby

          Posté par (page perso) . Évalué à 0. Dernière modification le 21/05/13 à 21:44.

          Il manque un bout.

          Je disais donc, comparer Ruby/Python/Perl/*autre langage de script* au C […].

          Love, bépo.

          • [^] # Re: puppet vs. ruby

            Posté par (page perso) . Évalué à 4.

            Vous lui reprochez quoi au Ruby au juste à part d'être un langage pour hipsters ?

            • [^] # Re: puppet vs. ruby

              Posté par . Évalué à 2.

              • Utilise des ponctuations dans les identifieurs et comme «mot clef» du langage. C'est difficile à mémoriser, et encore plus à chercher dans la doc. J'ai dû lire des dizaines de pages de docs, juste pour trouver la doc de la notation « :var »…
              • Pas de distinction sémantique entre accès à un attribut et appel d'une méthode.
              • Des tas de trucs bizarres, comme par exemple 0 évalue à vrai. Seuls nil et false évaluent à faux…
              • Et puis : https://www.destroyallsoftware.com/talks/wat … C'est de l'humour, voir de l’auto-dérision, mais il y a quelque chose de vrai :-)

              Ensuite, effectivement, il y a la communauté. Et là, ça fleur le LSD à plein nez. L'élégance est un objectif suprême.

              Les docs fondamentales pour apprendre le langage déconseillent le débogueur, pourtant présent dans ruby au profits de printf (ici puts) (http://ruby.learncodethehardway.org/book/ex36.html#tips-for-debugging)

              Les phrases pseudo philosophiques forment parfois le cœur de la documentation Poignant Guide en est le sommet :

              Creative skills, people. Deduction. Reason. Nodding intelligently. The language will become a tool for you to better connect your mind to the world.

              Bref, le langage a quelques bizarreries auquel il faut s'habituer, qui ne le rende pas si lisible que ça. Mais le pire reste quand même la communauté. Il y a certainement d'autre choses, mais j'ai été suffisamment dégoûté :x

              • [^] # Re: puppet vs. ruby

                Posté par (page perso) . Évalué à 6. Dernière modification le 22/05/13 à 11:47.

                Je marche dedans !

                Utilise des ponctuations dans les identifieurs et comme «mot clef» du langage. C'est difficile à mémoriser, et encore plus à chercher dans la doc. J'ai dû lire des dizaines de pages de docs, juste pour trouver la doc de la notation « :var »…

                Tu n'aimes pas non plus les décorateurs en python ?

                Pas de distinction sémantique entre accès à un attribut et appel d'une méthode.

                Il va falloir que tu détailles un peu plus, parce que je n'ai pas bien compris que ce que tu veux dire.

                Des tas de trucs bizarres, comme par exemple 0 évalue à vrai. Seuls nil et false évaluent à faux…

                C'est au contraire tout ce qu'il y a de plus logique. En quoi 0 ou "" devraient être faux ?

                Et puis : https://www.destroyallsoftware.com/talks/wat … C'est de l'humour, voir de l’auto-dérision, mais il y a quelque chose de vrai :-)

                Je te concède que a=a qui renvoie nil est une aberration. Le deuxième exemple n'est plus valide.

                Les docs fondamentales pour apprendre le langage déconseillent le débogueur, pourtant présent dans ruby au profits de printf (ici puts) (http://ruby.learncodethehardway.org/book/ex36.html#tips-for-debugging)

                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…

                • [^] # Re: puppet vs. ruby

                  Posté par . Évalué à 0.

                  Pas de distinction sémantique entre accès à un attribut et appel d'une méthode.
                  Il va falloir que tu détailles un peu plus, parce que je n'ai pas bien compris que ce que tu veux dire.

                  Pardon, j'ai écrit « sémantique » au lieu de « syntaxique » :x. Le fait de mélanger des syntaxes d'appel de fonction avec ou sans parenthèses.

                  MaClass.new.method.attr=mavar.autre_attr
                  
                  

                  Le = n'est pas un opérateur, mais l'identifiant d'une fonction… C'est troublant.

                  Ce qui est très amusant, c'est que ce bouquin est la traduction de Learn Python The Hard Way.

                  Autant pour moi ! Ça me rassure sur la communauté ruby ! :-)

                  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…

                  Bah, c'est quand même mis en avant sur le site officiel du langage :/

                  Bref, il y a des choses que j'aime bien dans ruby, mais il y a des ambiguïté du langage et un état d'esprit de la communauté auxquels je suis rétifs.

                  • [^] # Re: puppet vs. ruby

                    Posté par (page perso) . Évalué à 2.

                    Pardon, j'ai écrit « sémantique » au lieu de « syntaxique » :x. Le fait de mélanger des syntaxes d'appel de fonction avec ou sans parenthèses.

                    MaClass.new.method.attr=mavar.autre_attr
                    
                    

                    Le = n'est pas un opérateur, mais l'identifiant d'une fonction… C'est troublant.

                    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 ?

                    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…

                    Bah, c'est quand même mis en avant sur le site officiel du langage :/

                    Note que c'est décrit comme :

                    Ce livre, à la frontière entre tutoriel, roman et œuvre d’art, vous propose une manière non conventionnelle mais intéressante d’apprendre Ruby au travers d’histoires, de mots d’esprit et de dessins.

                    On ne peut pas vraiment dire que c'est décrit comme une ressource sérieuse et officielle…

                    • [^] # Re: puppet vs. ruby

                      Posté par . Évalué à 2.

                      Je trouve ça séduisant sur le fond, de n'avoir que des méthodes. Mais de les appeler sans faire exprès, ça me choque. J'ai du mal à m'y faire en pratique.

                      Il y a aussi le return implicite, et d'autres trucs qui me font éviter ruby. J'en ai suffisament vu pour ne pas vouloir tout retenir :-)

                  • [^] # Re: puppet vs. ruby

                    Posté par (page perso) . Évalué à 1.

                    Bref, il y a des choses que j'aime bien dans ruby, mais il y a des ambiguïté du langage

                    Alors qu'en python, pas du tout :

                     ○ python
                    Python 3.3.1 (default, Apr  6 2013, 19:03:55) 
                    [GCC 4.8.0] on linux
                    Type "help", "copyright", "credits" or "license" for more information.
                    >>> class toto:
                    ...   def __toto1__(self):
                    ...     print('toto')
                    ...   def __toto2(self):
                    ...     print('toto')
                    ... 
                    >>> t = toto()
                    >>> t.__toto1__()
                    toto
                    >>> t.__toto2()
                    Traceback (most recent call last):
                      File "<stdin>", line 1, in <module>
                    AttributeError: 'toto' object has no attribute '__toto2'
                    
                    

                    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 (page perso) . Évalué à 3.

                      Ça devrait le faire:

                      t._toto__toto2() 
                      
                      

                      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.

                      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

              • [^] # Re: puppet vs. ruby

                Posté par (page perso) . Évalué à 2.

                L'élégance est un objectif suprême.

                Techniquement, c'est aussi le cas en python.

                Les phrases pseudo philosophiques forment parfois le cœur de la documentation

                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 . Évalué à 3.

                Pas de distinction sémantique entre accès à un attribut et appel d'une méthode.

                Bin si! Tout simplement parce que tu n'a jamais accès directement aux attributs, tu passes obligatoirement par des setter/getter:

                un

                attr_accessor :toto
                
                

                est juste équivalent à

                def toto
                  @toto
                end
                def toto=(value)
                  @toto=value
                end
                
                

                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 . É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 (page perso) . É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 :)

  • # c2c c'est de la balle

    Posté par . É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 . Évalué à -7.

    Et par rapport à Fabric ?
    C'est comment ?

    • [^] # Re: Et par rapport à Fabric ?

      Posté par (page perso) . É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.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # CFEngine

    Posté par . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.