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

Posté par  . Édité par claudex. Modéré par rootix.
Étiquettes :
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.

Aller plus loin

  • # Commentaire supprimé

    Posté par  . Évalué à -6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: puppet vs. ruby

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

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

        • [^] # Re: puppet vs. ruby

          Posté par  . É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  (site web personnel) . Évalué à 4.

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

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: puppet vs. ruby

                Posté par  (site web personnel) . Évalué à 6. Dernière modification le 22 mai 2013 à 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…

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 0.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: puppet vs. ruby

                    Posté par  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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.

                      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

              • [^] # Re: puppet vs. ruby

                Posté par  (site web personnel) . É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  (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 :)

  • # 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  (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  . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.