Jonathan Clarke a écrit 22 commentaires

  • [^] # Re: Objectif du logiciel

    Posté par  . En réponse à la dépêche RUDDER 4.3 : une nouvelle version qui consolide les fonctionnalités majeures. Évalué à 7.

    Pas vraiment. Rudder remplit une fonction similaire à Ansible, dans le sens où il gère des configurations, mais le fonctionnement est très différent : pour commencer, Rudder fonctionne avec des agents locaux à chaque machine gérée (agent léger et très performant, écrit en C), là où Ansible se connecte en SSH ou similaire pour exécuter des commandes distantes. Il en résulte une panoplie de différences, la décentralisation et l'autonomie de chaque machine notamment, la charge réseau, la capacité de passer à l'échelle sur des dizaines de milliers de noeuds, etc.

    Le mode "dry-run", Rudder l'a aussi (tout comme Ansible d'ailleurs) mais Rudder va bien plus loin en remontant une vraie conformité sur chaque item. Là où un mode dry-run "essaie" tout mais ne fait rien, la conformité dans Rudder va remonter un rapport propre à chaque configuration avec un status (OK, réparé, erreur, sommairement), donc beaucoup plus fin qu'un mode dry-run. Sur une machine, ca ne change pas grand chose, certes, la puissance réside en la capacité d'agréger ces rapports pour avoir une vision d'ensemble sur un parc.

    Un cas d'exemple : on veut savoir si un élément de sa politique de sécurité, disons l'auto-logout du terminal, est bien appliqué sur un parc, on crée la config dans Rudder en mode "audit", il vérifie sur tous les noeuds, dit qqch comme "OK à 96%", et là 1) on sait où on en est, et 2) on peut décider de forcer la config (passage en mode "enforce") sur les 4% restants si c'est des machines où on accepte le risque, et ainsi l'appliquer partout. Ensuite, la config est vérifiée en continu, et on a une alerte dès qu'une machine n'est pas OK.

    Le paramétrage peut être graphique, oui, il peut aussi être fait en CLI ou via l'API REST complète. En pratique, on a tendance à écrire les modules plutôt en dehors de l'interface graphique, puis on assemble des modules avec leurs paramètres dans l'interface graphique. L'idée fondamentale étant de faire des modules très génériques (contenu d'un fichier, état d'installation d'un paquet, existence d'un utilisateur, etc - comme les modules d'Ansible, et oui il y en a moins, mais ca suffit dans beaucoup de cas :-) ) et de batir avec ces briques les configurations plus complexes.

    Une vidéo vaut peut être mieux qu'un long discours, c'est une démo sur la version précédente, mais ca montre les concepts qui sont les mêmes : https://www.youtube.com/watch?v=_N_Xbs_yRaw

  • [^] # Re: Conférences podcastées ?

    Posté par  . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 5.

    On retrouve les talks de l'année dernière sur YouTube (https://www.youtube.com/playlist?list=PL7l-zOgt89E6tVRpa3O0j-Vl6Xu0l_0D1), si l'organisation le permet, ca sera pareil cette année.

  • [^] # Re: Prix...

    Posté par  . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 1.

    PS : Maintenant que l'agilité a dévoilé un autre code de réduction, rien n'empêche de l'utiliser hein :)

  • [^] # Re: Prix...

    Posté par  . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 4.

    Aha, bien joué l'agilité ! ;-)

    Le pourcentage de réduction accordé dépend simplement de la visibilité donné en échange pour l'événement. "Les autres", c'est plutôt toolinux.com, programmez.com, FrenchWeb, etc, qui ont exactement la même offre à 15% de réduction parce qu'en échange ils diffusent un bandeau de pub sur leur page d'accueil.

    Le meetup Paris Devops a fait beaucoup de publicité pour l'événement (distribution de flyers, messages d'info lors des meetups, etc). En échange, ils ont une réduction plus forte. C'est comme pour les sponsors, les sponsors Platinum ont une réduction plus forte que les Gold, puis Silver, puis Bronze…

    Désolé si la logique commerciale choque, mais ce n'est certainement pas de la discrimination anti-LinuxFR. D'ailleurs c'est l'exact inverse, puisque seul LinuxFR a un code de réduction sans afficher une bannière ou similaire sur le site. Et je me suis bougé moi même pour le faire, parce que sinon on n'en parlait juste pas ici, et j'aurais trouvé ca dommage.

  • [^] # Re: Prix...

    Posté par  . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 3.

    Oui, c'est pas donné, je te l'accorde.

    Maintenant ce prix comprend pas mal de choses :

    • l'accueil et petit-déj
    • café et jus de fruits bio toute la journée
    • un festin aka "buffet dinatoire" le midi avec un traiteur bio et éco-responsable
    • un social event le soir avec de la limonade artisanale et de la bière artisanale locale (Bapbap) et des animations
    • plein de goodies gratuits (la "fameuse" peluche devops REX, et plein d'autres)

    Le fait que ca se fait dans la grande salle du Grand Rex, qui est ultra luxueuse coute pas mal d'argent, ce qui se reflète sur le prix, mais qui se ressent aussi dans le confort au long de la journée.

    Mais avec la réduction LinuxFR.org c'est moins cher ;-)

  • [^] # Re: Joli logo !

    Posté par  . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 5.

    Héhé, merci pour le logo ! C'est une oeuvre de Nicolas Léonard.

    Concernant la notion de devops, c'est l'occasion idéale pour venir découvrir ;-)

    Sinon, un résumé de la vision définie par l'acronyme "CAMP" :

    • CULTURE : rassembler les équipes autour d'un objectif commun et raccourcir les cycles développement-feedback.
    • AUTOMATISATION : adopter les outils et méthodes qui permettent d'industrialiser les infrastructures informatiques (infra as code, intégration continue, déploiement continu, etc.), afin de gagner en fiabilité et libérer du temps pour l'amélioration continue.
    • MESURE : évaluer et quantifier ses avancées pour pouvoir réagir vite, optimiser et valider ses choix, et ainsi maîtriser son développement.
    • PARTAGE : faire circuler librement l'information et favoriser l'empathie entre les équipes.

    Moi quand on m'en a parlé la première fois, j'ai dit quelque chose du genre "ah ouais, travailler avec du bon sens quoi ?". Bon, vive l'humilité hein ;-) Mais avec le recul, d'avoir un nom là dessus, et des gens qui s'y intéressent, et des managers qui peuvent pousser pour ca parce que c'est à la mode et ce que le patron veut, ca permet d'avoir un milieu de travail qui bouge et de bosser mieux au final. Mais ce n'est que mon avis :)

  • # La licence open source pour graines

    Posté par  . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 1.

    Intéressant, les restrictions par catalogue en France, en effet. Mais à la base ce que je trouvais intéressant ici c'était l'idée d'avoir une licence open source (et c'en est une vraie, bien réfléchie) pour des graines :)

  • # Merci et quelques précisions

    Posté par  . En réponse au message [Tuto/HowTo] Installer et configurer Rudder sur Ubuntu/Debian. Évalué à 4.

    Merci pour ce joli tuto !

    Deux petites remarques :

    Attention : ils n'utilisent pas un dépôts "latest", en suivant ce tutoriel pensez donc a vérifier la version dans l'

    Il existe des dépôts latest, cf http://www.rudder-project.org/site/get-rudder/downloads/#current_releases. En l'occurrence c'est http://www.rudder-project.org/apt-latest/.

    Dans la première partie :

    Lancez l'installation de l'agent rudder

    C'est le serveur Rudder du coup :)

  • [^] # Re: Retour premier essai

    Posté par  . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 1.

    Possible que le hostname de la machine soit à l'origine du problème. Si c'est "localhost" ça peut causer l'erreur. Essaye de mettre un autre hostname avec 'hostname' ou dans /etc/hosts.

  • [^] # Re: Bien joué!

    Posté par  . En réponse à la dépêche Rudder 4 — nouvelle version de la solution de Continuous Configuration. Évalué à 5.

    Comme d'habitude avec les gens exceptionnels de Normation : c'est une équipe optimiste et visionnaire, et pas que, ils livrent ! Rudder a de vrais différentiateurs par rapport à la concurrence, et je regrette toujours que Rudder ne soit pas connu à la hauteur de ce qu'il devrait… La visualisation et vérification de la conformité sont clé.

    Wow. Que de compliments ! Merci infiniment pour cette confiance !!!

    Mais LinuxFR aide à ce qu'il soit mieux connu, alors merci LinuxFR :)

  • [^] # Re: Différence avec de la conf management ?

    Posté par  . En réponse à la dépêche Journée de découverte de Rudder à Aix‐Les Milles le 6 avril 2017. Évalué à 2.

    Rudder est aussi un outil de config management (cf le schedule au Config Management Camp, l'événement dédié à ces outils, le mois dernier : http://cfgmgmtcamp.eu/schedule/rudder.html).

    Rudder a ceci de différent qu'en plus d'appliquer des configs, il va les vérifier en continu (toutes les 5 minutes par défaut, avec un agent léger écrit en C). Techniquement, ca ressemble aux outils de config management standard, sauf que Rudder va remonter l'état de chaque config vérifiée, et les agréger pour en sortir une vision "conformité / compliance", qui permet de dire à son RSSI "la politique de sécurité est à 100% là" ou alors d'aller très vite à trouver la config qui n'est pas OK, donc à trouver plus vite la cause racine d'un problème.

    Par extension (bis), Rudder sait aussi ne pas appliquer les configurations, mais juste les vérifier, avec le mode audit (cf http://www.rudder-project.org/doc-4.1/_policy_mode_audit_enforce.html#_policy_mode_audit_enforce). Du coup, il ne gère plus les configs, il les audite juste.

    Bref, c'est du 3 en 1 : config management + conformité des configs + audit des configs.

  • # Autres villes ?

    Posté par  . En réponse à la dépêche Journée de découverte de Rudder à Aix‐Les Milles le 6 avril 2017. Évalué à 4.

    Merci LinuxFR pour la publication de l'info ! :)

    On parle de tournée hors Paris… Là le début est à Aix/Marseille parce que Maxime Longuet de Itika s'est généreusement proposé pour héberger. Est-ce qu'il y a des lecteurs ici qui auraient envie de voir une journée comme ca dans une autre ville ?

  • [^] # Re: Et on laisse publier ça ?

    Posté par  . En réponse à la dépêche L'UGAP accueille son premier projet open source de gestion de configuration : Rudder. Évalué à 9.

    Le fait de passer par l'UGAP amène simplement Normation à faire de son logiciel libre un logiciel propriétaire dans le cadre de l'UGAP CLAP CLAP bien joué; car de fait ce n'est pas la solution qui est référencée mais le prestataire.

    Que tu ne sois pas convaincu par le modèle de l'UGAP, je peux comprendre. Les arguments dans ce commentaire et les autres sont en effet pertinents. Mais de là à dire que l'action de Normation de s'inscrire à l'UGAP vise à "faire de Rudder un logiciel propriétaire" … !

    Le fait de vendre un service à travers l'UGAP ne change strictement en rien ni la licence ni les libertés des utilisateurs sur le logiciel couvert par ce service. L'idée que ça revienne à présenter un service sur un logiciel libre comme un logiciel propriétaire me laisse sans voix…

    Si quelqu'un dans une administration veut utiliser un logiciel libre et a besoin d'un accompagnement pour le mettre en prod, mais dont l'entité ne peut acheter que par l'UGAP (peu importe pourquoi il ne peut acheter que par l'UGAP - peut-être que son chef n'aime pas les marchés publics, peut-être que c'est la consigne du chef du chef etc - non, c'est pas normal, et non c'est pas idéal, on est d'accord, mais c'est comme ça), ça veut dire qu'on doit donc répondre qu'on est désolé, mais qu'il faut qu'il s'oriente vers un logiciel propriétaire ? Désolé, mais pour moi, promouvoir le libre, c'est pas ça.

    Et dénigrer un projet libre et une boite du libre ici comme tu le fais, ca ne va pas non plus aider à promouvoir le libre.

    Aucun de nous ne pourra faire du support Rudder pour l'état désormais (moi personnellement je n'avais pas envie, mais vous peut-être).

    Bien sûr que si. Apparemment, ta société est déjà référencée à l'UGAP en plus, alors tu n'as qu'un pas à faire pour le faire aussi.

  • [^] # Re: C'est vachement cher je trouve

    Posté par  . En réponse à la dépêche Devops Days Paris — 18/19 avril 2013. Évalué à 1.

    C'est maintenant possible de s'inscrire à une seule journée au lieu des deux, ce qui peut aider un peu : http://devopsdays.org/events/2013-paris/registration/

  • [^] # Re: infos complémentaires

    Posté par  . En réponse à la dépêche Devops Days Paris — 18/19 avril 2013. Évalué à 1.

    Juste pour information, le code de promotion est expiré.

    C'est corrigé, le code est de nouveau valide. Désolé pour la confusion !

  • [^] # Re: infos complémentaires

    Posté par  . En réponse à la dépêche Devops Days Paris — 18/19 avril 2013. Évalué à 1.

    Juste pour information, le code de promotion est expiré.

    Ah zut, je me renseigne pour le faire étendre. Bizarre…

    Sinon quel est le public visé par ces conférences ? novice, expert, maître Jedi chef/puppet?

    Toutes les sessions ne sont pas techniques, nombre d'entre elles vont parler de la culture devops, de l'organisation d'équipes, de bonnes pratiques… Elle peuvent donc s'adresser à tout le monde qui travaille dans l'informatique (dev, ops, responsable d'équipe…). Pas besoin d'un niveau particulier, au contraire, étant participant à des éditions précédentes, je trouve que c'est un excellent moyen de découvrir de nouvelles pratiques et de nouveaux outils.

    Le sujet de la conférence n'est clairement pas que les outils d'automatisation CFEngine/Puppet/Chef/etc. Même si nombre d'open spaces ou discussions porteront dessus, on peut tout à fait participer à la conférence et ne pas en parler. Souvent, nombre d'autres types d'outils sont abordés : métriques, monitoring, intégration continue, packaging…

  • [^] # Re: Ma veille techno

    Posté par  . En réponse à la dépêche Méthode et outils pour la veille technologique. Évalué à 1.

    Pour suivre des mots clés sur twitter, http://twilert.com est très utile : il surveille tout twitter pour toi et t'envoie un mail tous les jours avec les tweets qui contiennent tes mots clés.

    C'est très utile mais un peu trop verbeux, par exemple il ne détecte pas les retweets, et met plein de fois le même tweet s'il a beaucoup été relayé. C'est gratuit (mais pas libre).

  • [^] # Re: LDAP ?

    Posté par  . En réponse à la dépêche Rudder 2.4 - Gestion de configuration dans une UI. Évalué à 3.

    Ce n'est pas précisé dans la dépêche mais Rudder semble s'appuyer sur un annuaire LDAP (schémas spécifiques ?) pour stocker sa (ou partie de) configuration.
    A-t-il déjà été envisagé de se rapprocher des projets GOsa² ou OpenDirectory ?

    Effectivement, Rudder utilise des schémas LDAP pour stocker deux choses : 1) les données d'inventaire sur une machine (matériel, logiciel, réseau, etc), et 2) la configuration de Rudder elle-même (règles de configuration, groupes, etc).

    Pour le 1, Rudder et le projet FusionDirectory (fork de GOsa) collaborent pour trouver un schéma commun.

  • [^] # Re: Question ?

    Posté par  . En réponse à la dépêche Rudder 2.4 - Gestion de configuration dans une UI. Évalué à 1.

    Donc si je comprend bien il faut deux agents sur les clients : l'agent CFEngine et celui de fusion inventory ?

    Oui mais il n'y a que l'agent CFEngine qui tourne en permanence, après ça peut etre aussi le cas pour FusionInventory si vous l'utilisez avec un GLPI (l'agent FusionInventory peut communiquer avec plusieurs serveurs)

    Effectivement et le projet Rudder fournit un paquet unique (nommé rudder-agent) qui intègre les deux, ainsi que les configurations pour "bootstrapper" une machine à gérer, pour rendre le déploiement plus simple.

  • [^] # Re: Question ?

    Posté par  . En réponse à la dépêche Rudder 2.4 - Gestion de configuration dans une UI. Évalué à 2.

    J'imagine que le moteur est basé sur CFEngine mais je ne vois pas trop le rapport avec fusioninventory si votre agent est en C ?

    Rudder utilise CFEngine pour appliquer les configurations: c'est lui qui est en C, et qui est le seul bout qui tourne régulièrement, donc qui est vraiment impactant pour l'utilisation de RAM. Mais il fait aussi un inventaire de chaque serveur (matériel, CPU, RAM, version d'OS, réseau, logiciels installés…) qui est visible dans l'interface web de Rudder, et ca c'est FusionInventory qui le fournit.

    Sinon vous sortez une version 2.4 d'un logiciel qui se base sur deux projets très jeunes (pour CFEngine je ne dit seulement que la version 3 est jeune) : Vous avez sorti la première version de votre logiciel en 2.2 ? Le projet à combien d'année d'existence ?

    C'est un projet démarré dans l'entreprise Normation mi-2010. Les premières versions (0.1, 0.2… 1.0…) étaient du prototypage, beaucoup de code qui n'a pas été gardé (ou du moins qui ne devait pas l'être). Ensuite une grosse réécriture a fait passer Rudder en version 2.0 (puis 2.1, 2.2) mais ces versions n'ont jamais été publiées. On a mis les repos git en ligne avec la version 2.3 en octobre dernier. C'était sûrement pas la meilleure approche (on le voit avec le recul), cf "release early release often", mais on apprend de ses erreurs…

    Sinon je vois que ce projet proviens d'une entreprise (ce qui peut apporter un gage de confiance pour des décideurs pressés), mais question communauté : avez vous beaucoup de contributeurs externes à l'entreprise ?

    Actuellement il y a 6 contributeurs (ayant soumis des patchs pour la documentation, le packaging, les techniques, etc mais peu sur le code de l'appli web) et une petite vingtaine de "bug reporters" (n'ayant pas soumis de patch), en plus des développeurs chez Normation.

  • [^] # Re: Cfengine, et pourquoi pas Spacewalk

    Posté par  . En réponse au journal Jouer au ptit chef ou à la poupée ?. Évalué à 0.

    À l'époque où j'avais testé Puppet sur CentOS 5, il tirait des dizaines de dépendances, là où un seul paquet suffisait pour Cfengine.

    J'ai aussi choisi CFEngine pour cette raison, et quelques autres liées :
    - Consommation de ressources (RAM surtout mais aussi CPU) très bas par rapport à Puppet et Chef (CFEngine est écrit en C, très efficace)
    - Rapidité d'application des configurations (par défaut CFEngine tourne toutes les 5 minutes et est facile à scaler même à cette fréquence, Puppet/Chef c'est toutes les 30 minutes, et difficile à scaler même à cette fréquence ;) - voir https://t.co/kBQqRKzP)
    - Historique de sécurité - je sais pas pour Chef, mais chez Puppet il pleut les CVE ces temps ci (cf http://puppetlabs.com/security/), CFEngine n'a eu que 4 failles de sécurité en 19 ans (dont aucune considérée exploitable)
    - Ca peut paraître un détail, mais Chef et Puppet ne savent pas éditer le contenu de fichiers textes, seulement copier des templates en remplacant des variables dedans. CFEngine lui a plein d'approches pour éditer finement des fichiers (ajouter des lignes, remplacer des patterns, trouver des sections style .ini [section] etc).

    Petit disclaimer : je travaille sur le projet Rudder (un outil pour aider à propager l'utilisation de la gestion de configuration dans une boite en le rendant plus simple grace à une interface web, des configs toutes faites, du reporting automatique…) qui se base sur CFEngine, donc j'ai maintenant un parti pris, même si j'en avais pas à l'époque où j'ai fait ce choix (2009)

  • # Apache Lotus Symphony ?

    Posté par  . En réponse à la dépêche La fondation Apache donne des nouvelles d'OpenOffice.org. Évalué à 1.

    On connaît Apache OpenOffice.org. Mais si je comprends bien, le code de Lotus Symphony à aussi été donné à la fondation Apache ?!

    Je suis surpris, ça voudrait dire que la fondation a deux suites bureautiques ???