Re: [FRsAG] [MISC] Re: Cherche DevOPSs poilus pour relever un défi industriel
Bonjour, Je vais répondre dans le message... Le 23/08/2016 à 15:09, Christophe Dezé a écrit : salut, sans vouloir troller, il y a que moi que ca gène que l'on parle de "DEVOPS" comme un rôle ? Devops c'est un mouvement ou une culture, ... Comme pour beaucoup de choses en informatique on met en place de nouveaux termes et de nouveaux corps de métiers pour le business, on (ré)invente parfois des choses, il faut s'adapter, cependant (...) On peut etre "expert Devops" pour mettre en place des pratiques, ou "dev" ou "ops", mais etre "un devops" ca me pique un peu les yeux. La vieille séparation fait de la résistance :) si je suis le seul à penser cela: désolé du dérangement . enfin si vous cherchez un peu sur le net, vous verrez que pas mal d'experts pensent comme moi, mais peut-etre que les temps changent ;-) Effectivement, pour moi, c'est tout à fait normal, ça s'appelle la convergence des métiers et ça ne me pique pas du tout les yeux. Quand on gère toute son infrastructure avec du code en python, on ne peux pas se dire complètement développeur, mais on ne peut non plus se considérer à 100% comme sysadmin... Pourtant, ce type de job existe bel et bien, en particulier dans le monde du cloud, pour les sysadmins qui gère des centaines de machines... Ça veut dire qu'il faut absolument bien s'y connaître dans les deux branches de métier. Je suis un ancien sysadmin; il m'arrive encore de me considérer comme tel, mais je me vois désormais plutôt comme un "devops". Par ailleurs, quand on voit le "SDN" dans le monde du réseau, on se dit que la convergence ne touche pas que les sysadmins. Ne pas voir ça, c'est faire l'autruche. On peut toujours travailler dans son coin et faire un travail de sysadmins "old school", mais quand votre PDG se rendra compte que l'entreprise d'à côté fait aussi bien (ou presque, l'accompagnement en moins) avec 5 fois moins de personnel... Quand on a une équipe suffisante, "devops" peut également signifier une équipe qui travaille main dans la main pour faire à la fois le "dev" et le "ops"; mais, même si les tâches sont bien séparées (avec les séparations avec les corps de métier d'avant), les gens travaillent vraiment ensemble, afin cette fois, de développer, tester, mettre en production, développer, tester, mettre en production (petit bout par petit bout). En partie grâce à l'apport des containers. Il peut s'agir d'une seule personne qui fait tout ce travail, il paraît alors logique d'utiliser le terme "devops"; là aussi. Ce qui me gène de mon côté, c'est plutôt la définition qu'essaient de mettre certains développeurs java derrière cette étiquette grâce à tout leur écosystème, à commencer par jenkins. Attention, je ne suis pas contre jenkins, c'est très pratique, c'est juste le fait de s'accaparer le terme qui me gène, afin de vendre toujours plus de développeurs java. C'est comme pour le terme "Big data". Chacun en a une définition différente (taille, technologies à utiliser) Bref, vaste sujet... Le 07/08/2016 à 19:04, Cyril Feraudet a écrit : Bonjour à tous, Petit disclaimer: - Cette recherche ne s’adresse PAS aux SSII et autres vendeurs de poisson: Commerciaux vous pouvez arrêter de lire ce message. - Je ne représente pas une SSII, je suis un DevOPS et la proposition suivante est de venir travailler à mes côtés. - Je me chargerai personnellement de pourrir toutes SSII qui répondront à cette demande. J’ai une équipe d’Ingénieurs de Production à constituer, les technologies sont cools mais parfois pas très sèches. Pour ce faire je recherche 4 à 5 DevOPSs poilus, si tu ne sais pas développer c’est rater, si ton niveau en système laisse à désirer c’est aussi raté. Les technologies sont, entres autres, les suivantes : - Ubuntu Precise, Trusty et Xenial - OpenStack - Kubernetes - Docker - KVM - SDN (Calico, Contrail) - Chef - Ansible - Chef - Ceph - Swift (pas le language d’Apple) - Foreman - Consul - Vault - Nagios - Collectd - Graphite - InfluxDB - Prometeus - Bash - Python - Ruby - Node - C - Go - HTML / CSS / Javascript - Jenkins - GitLab - ... Ces technologies ne sont pas toutes à connaitre, vous aurez tout le loisir de monter sur celles qui vous intéressent. Il y a 3 à 4 postes en salarié (65k€ n’est pas un gros mot pour nous) et 1 à 2 poste en freelance (600€HT/j n’est pas non plus insultant) Les Polytechniciens comme les autodidactes sont recherchés, seules les compétences importent. Conditions de travail: - Issy les Boulogne - Baby-Foot Bonzini - Locaux spacieux flambants neufs - Terrasse gigantesque - Embuscades de geeks armées de Nerfs quasi quotidiennes - Horaires souples - Remote quand vous en avez besoin - Poste de travail sous votre distribution préférée N’hésitez pas à me contacter si vous êtes intéressé. Cyril ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de d
Re: [FRsAG] Outils de gestion de planning d'astreinte
Bonjour, Juste une petite parenthèse à ce sujet. Il y a aussi PHP congés. J'avais contribué à PHP congés lorsqu'il était hébergé sur google code. Créé à l'origine par Cédric Chauvineau (http://www.ced.univ-montp2.fr/php_conges/), il y a désormais un fork nommé "libertempo" : https://github.com/wouldsmina/Libertempo Je ne crois pas que Cédric soit impliqué dans ce fork et je ne sais pas ce que vaut ce fork, mais j'imagine qu'il correspond à votre besoin. Concernant GRR, j'ai une instance ici et c'est bourré de bug. Pour faire ce que je fais ce n'est pas dérangeant, je l'ai même modifié à volonté pour rajouter quelques fonctionnalités, mais bon; Maintenant qu'il est sur github, il faudrait que je trouve le temps pour le forker et corriger les bugs... Rémy Le 31/08/2016 à 12:54, BEF a écrit : Bonjour, j'utilise l'outil GRR au quotidien. Tout ce fait par interface web, possible de le rattacher au ldap https://grr.devome.com/fr/ Le 31/08/2016 à 09:56, Nono a écrit : Bonjour la liste, Je dois gèrer le planning d'astreinte de mon équipe (3 personnes) manuellement. C'est assez fastidieux surtout pour toute les petites modification dû aux absences/maladies etc ... La durée d'une astreinte "normale" est de 1 semaines complête (Lundi au Dimanche). L'idée étant d'avoir le même compte de semaine d'astreinte à la fin de l'année pour tout le monde, auriez-vous un outils (de préférence libre) qui sait faire ca ? Nono ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] service de rachat de domaine à expiration
Je ne sais pas si ça fonctionne sur de "vieux domaines", mais : http://park.io/ A+ Le 10/10/2016 à 15:02, Sylvain Viart a écrit : Salut, Vous connaissez des services performants pour une "OPA" (option pour (R)Achat) sur des domaines expirés ? ;-) Sylvain. -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] [Systemd] Un installer lamp automatique pour Debian 8
Bonjour, On va éviter de lancer le troll, même si c'est 'dredi, mais personnellement, même si je trouve que la couche de gestion apportées par systemd est pratique, on se retrouve souvent à démêler des problèmes qu'on avait pas avant, et surtout, souvent plus complexes (ça me rappelle d'ailleurs un peu le passage de LILO à GRUB à l'époque (*)). Bref, notre ami Lennart Poettering a juste oublié que sous Linux, il fallait faire KISS (https://fr.wikipedia.org/wiki/Principe_KISS). Même si du point de vue utilisateur, oui, c'est plus simple... My 2 cts, Rémy (*) plus de capacité, gestion simplifiée, mais du point de vue du cœur du système et de son fonctionnement, c'est en réalité bcp plus complexe. Le 08/12/2016 à 19:21, Mrjk a écrit : Salut, Loin de moi de vouloir relancer un troll qui devient vieux comme le monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le point de vue de l'admin qui fait de la prod qui m’intéresse (je ne sais pas si tu es dans ce cas). En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté un grand confort, surtout quand on utilise des outils du type Ansible/Puppet sur différentes plateforme. Une interface pour tous les masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher a systemd. Note; C'est le point de vue qui m’intéresse, je cherche pas à démontrer que systemd est le meilleur. -- MrJK GPG: https://jeznet.org/jez.asc Le 8 décembre 2016 à 01:16, Guillaume Tournat a écrit : J'ai développé une allergie à systemd Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur debian8 ;-) Le 7 déc. 2016 à 23:40, Bruno Pagani a écrit : Le 07/12/2016 à 21:40, Christophe Casalegno (DN) a écrit : Bon pour le coup, on va voir si ça passionne : https://twitter.com/Brain0verride/status/806598323830456320 une install ntpd est de toute manière plus rapide que taper dans la cron, ça c'est sur :) amicalement, systemd-timesyncd :p Bruno ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Team Password Manager
Bonjour, A noter un fork de KeePass, KeePassXC sur lequel je suis tombé récemment (pas testé), cross-platform, qui permet de merger des bases : https://keepassxreboot.github.io/project Rémy Le 09/01/2017 à 07:50, Brenas Emmanuel a écrit : Salut, si cela arrive qu'avec KeePassX on ait une concurrence d'accès en écriture au fichier mais bon à 5 dans l'équipe avec des bureaux qui se touchent il suffit de brailler pour trouver le coupable et arranger ça ;-) Et pour répondre à Simon, oui avec KeePassX tout le monde à accès à tous les mots de passe. Là encore c'est adapté car l'équipe et l'organisation est toute petite. Bonne semaine à tous, Manu. *De :* FRsAG de la part de Wallace *Envoyé :* dimanche 8 janvier 2017 17:17 *À :* frsag@frsag.org *Objet :* Re: [FRsAG] Team Password Manager Salut, On était avec KeePassX aussi v1 puis v2 mais à force d'être nombreux on arrivait à avoir besoin d'éditer en même temps les fichiers. On a découpé en différentes logiques clients / interne ... mais ça n'a fait que repousser le problème d'édition multiple. Du coup on est passé sous TeamPass et on s'en sort mieux même si on a perdu en rapidité pour aller chercher un pass. Tu n'as pas rencontré ce problème d'édition multiple? Le 07/01/2017 à 12:30, Brenas Emmanuel a écrit : Bonjour à tous, on fait un peu dans l'artisanal dans ma petite équipe sur ce sujet: un fichier KeePassX partagé sur un lecteur réseau. Le petit logiciel est succinct, mais ça fonction de recherche fait qu'on trouve ce que l'on cherche rapidement. Manu. *De :* FRsAG de la part de Christophe TAVERNE *Envoyé :* samedi 7 janvier 2017 11:19 *À :* frsag@frsag.org *Objet :* Re: [FRsAG] Team Password Manager Bonjour à tous Pour ma part j'ai un peu testé teampass. Ça marche mais je trouve encore pas mal de bugs, un peu brouillon et pas intuitif. C'est un peu l'usine. J'ai en projet de tester passbolt qui me paraît prometteur dans sa version auto hébergée. Cdlt, -- Christophe TAVERNE christophetave...@fastmail.com Clé publique: 241857C7[http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA903BFF0241857C7] Le Sam 07 janv 2017, à 11:13, Jonathan Leroy a écrit : > Le 7 janvier 2017 à 00:20, Olivier Calzi a écrit : > > En bref, comment vous faites ? > > Salut, > > J'utilise 1Password for Teams, et j'en suis très satisfait : > https://1password.com/teams/ > > > -- > Jonathan Leroy. > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Centralisation de logs
Le 06/02/2017 à 16:27, Stéphane Cottin a écrit : fluentd est une alternative possible à logstash, beaucoup + léger. Intéressant ! Un peu HS aussi, mais petit retour d'EX ELK : Après avoir utilisé pendant pas mal de temps ELK, on en est revenu car la base devenait énorme. Je l'ai sûrement mal configuré, mais attention au remplissage de disque... ! Je pense que j'avais mal configuré la taille de mes shards, mais je trouve que ce n'est pas forcément très bien expliqué au départ (impossible de redimensionner après coup... Ou alors, j'avais pas compris comment faire ?...). Si tu peux rajouter facilement des machines (scale horizontal), ça va, sinon, je serai toi, soit je prévois très large en taille, soit je trace mon chemin. https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index Pour l'utilisation, effectivement, ELK, ce n'était que du bonheur par rapport à un serveur de logs sql classique. J'ai utilisé loganalyzer couplé à rsyslog pendant des années, et pareil, je pense que je logue trop de choses/trop longtemps, mais c'était devenu inutilisable. La capacité à trouver une info dans ES est impressionnante, par rapport à un SGBD relationnel classique. Je n'ai pas trouvé que le client bouffait tant de ressource que ça, mais je n'ai plus les valeurs en tête. Rémy Chez nous on envoi tout ce qui est applicatif directement à fluentd en json et au format natif lorsque c'est possible, et sinon au format syslog pour les apps legacy. De même pour nginx , haproxy, etc ... qui supportent syslog en natif. Et bien sur rsyslog pour attraper tout ce qui tombe dans /dev/log A l'étape suivante on ne fait aucun traitement, nous voulons rester le + léger possible en input. On pousse tout en raw dans kafka, en séparant juste en plusieurs topics en fonction des sources/types de logs ( système, http, ...). Nous utilisons ensuite d'autres instances de fluentd comme consumers kafka, pour parser / filter / pousser dans ES. A ce niveau les traitements peuvent être longs ou lourds, ça n'impacte pas l'input. Tu peux aussi utiliser logstash, riemann ou autre en // pour consommer les topics depuis kafka. Seul inconvénient à mon avis, cette chaine ne permet pas de "temps réel", tu as un empilement de buffers, et en fonction de ta volumétrie et de tes réglages, cela peut prendre plusieurs grosses secondes avant qu'une ligne soit indexée dans ES. Les points positifs: scalable et souple. On 6 Feb 2017, at 14:44, Alexandre wrote: Bonjour à tous, je pense que se sujet a été abordés plusieurs fois mais je n'ai pas trouvé d'informations. Nous souhaitons centraliser nos logs (applicatifs, systèmes ...). Nous avons maquetté une solution standard avec Elasticsearh + Logstash + Kibana. Le trio fonctionne très bien, nous créons des custom logs et en y applique via logstash un template pour sortir tous les champs intéressant. Cependant si nous devons mettre en production cette solution comme nous l'avons maquetté, il faut que nous installation un logstash sur toutes les machines. Le déploiement pose aucun problème, mais mettre du java sur toutes mes machines sachant que le process mange du CPU et la RAM, cela me plaît très moyennement. Mon idée serait d'utiliser un outils centralisant les logs sur un cluster et d'y paramétrer un logstash qui injecterait les données venant des différents log. Il y a quelques années je m'étais bien amusé avec syslog-ng, et en production c'était pas mal. Je me permets de vous demander si syslog-ng est toujours un outils utilisé ? ou plutôt dépassé. J'ai vu qu'il était possible de centraliser les log directement via rsyslog, pensez-vous que cela soit une bonne solution ? Il y a t'il d'autres solutions mieux que syslog-ng ou rsyslog pour centraliser les logs ? Par avance, merci pour vos réponses. Alexandre. ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] WannaCry / WannaKey
Bonjour, Pour information, au cas où ça pourrait servir : https://github.com/aguinet/wannakey Pas testé. Il faut que la machine infectée n'ait pas rebooté. Cordialement, Rémy. -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Recherche ordonnanceur libre
Le 07/06/2017 à 22:30, Jonathan Leroy a écrit : "Le 7 juin 2017 à 21:03, Guillaume Tournat a écrit : Je n'ai pas du tout accroche Salt. FAKE NEWS ! ;) Les packages Debian sont nuls (ils ne se mettent pas à jour par apt-cron), Tu utilises bien le dépôt "latest" ? il faut 50 dépendances, qui changent à chaque version. Plutôt entre 10 et 15 chez moi, à vue d'oeil. Après c'est du Python, donc pour bien packager ça il faut faire un package par module... Et on ne sait jamais trop ce qu'il fait ou pas. SaltStack fait tout. TOUT ! +1 https://docs.saltstack.com/en/latest/ref/states/all/salt.states.cron.html Il pourrait presque faire le café ;) -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Outils de déploiement
Le 09/06/2017 à 16:36, Jonathan Leroy a écrit : Le 9 juin 2017 à 16:17, Cyrille Verger a écrit : Bonjour à tous, Salut, Je suis actuellement en train de regarder des outils d'automatisation de déploiement de VM ou de machine physique. Je souhaiterais avoir votre retour d'expérience sur les différents outils que vous pouvez utiliser sachant que je souhaiterais si possible avoir : - Déploiement d'OS en VM sous VMware comme de Machine Physique - Déploiement en "masse" simplifié https://www.terraform.io/ (pas testé) Ça me fait penser, de la même boîte, il y a : https://www.packer.io/intro/index.html (Jamais testé). Mais une fois de plus, c'est vraiment orienté cloud/VM. - Déploiement d'application en fonction d'un catalogue https://saltstack.com/ (c'est bien) - Interface Web de gestion et de déploiement sécurisé - Gestion potentiel d'un framework de validation - Gestion des updates etc etc... Pour ça je ne sais pas trop. Mais si tu cherches *une* solution pour faire tout ça, ça risque d'être compliqué. -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Outils de déploiement
Le 09/06/2017 à 16:36, Jonathan Leroy a écrit : Le 9 juin 2017 à 16:17, Cyrille Verger a écrit : Bonjour à tous, Salut, Bonjour, Je suis actuellement en train de regarder des outils d'automatisation de déploiement de VM ou de machine physique. Je souhaiterais avoir votre retour d'expérience sur les différents outils que vous pouvez utiliser sachant que je souhaiterais si possible avoir : - Déploiement d'OS en VM sous VMware comme de Machine Physique Avec VMware, je sais qu'il y a un converter pour faire du p2v, mais dans l'autre sens ...? - Déploiement en "masse" simplifié https://www.terraform.io/ (pas testé) - Déploiement d'application en fonction d'un catalogue https://saltstack.com/ (c'est bien) Pour les images: Je déploie des OS (Linux) aussi avec SaltStack + FAI (http://fai-project.org/); et j'en connais aussi qui font ça avec Kickstart ou preseed (http://github.com/oxedions/banquise). Pour faire du déploiement sans info sur l'OS, c'est effectivement compliqué, sauf à déployer des images disques (clonezilla ? Avec sysprep pour Windows ?)... Mes infos windows étant un peu outdated, je me rappelle qu'on faisait ça avec Norton Ghost à une époque aussi (il y a + de 10 ans de ça...), après nettoiement de l'image (suppression de toutes les caratéristiques spécifiques aux machines (hostname, ip...). Pour les softs : Tu as aussi des outils de déploiement via une application tierce (OCS packager, peut-être avec Landesk aussi http://landesk.avocent.com/os-deployment.aspx ?). A une époque, Mandrive proposait "Pulse", mais bon, comme c'est mort... (dommage...; Pour les curieux : http://linuxfr.org/news/mandriva-pulse-3-0-faites-le-plein-de-fonctionnalites-pour-votre-si) - Interface Web de gestion et de déploiement sécurisé Les pros rundeck/ansible n'ont pas un truc pour ça ? - Gestion potentiel d'un framework de validation Je sais que Chef a un système de gestion de contrôle des recettes déployées. Salt aussi mais c'est une contrib, basé sur les "dry runs" qui date un peu ( https://bitbucket.org/arthurlogilab/salt-highstate-stats ) - Gestion des updates etc etc... J'ai peur que ça soit impossible d'avoir tout dans un seul produit là... Du côté pur Windows, il y a déjà des outils très bien qui font ça, mais c'est du pur Windows (AD+GPO, WSUS, MDT, WAPT, WPKG)... Mais une fois de plus un outil de gestion de conf multi OS. Dans Salt, je crains que la gestion des Windows soit pour le moins instable, même si certains font ça... Tu dois pouvoir coder toi-même les parties manquantes, ce qui ne sera pas évident avec un autre outil de gestion de conf que Salt, où généralement, le pouvoir d'expression est moindre, mais l'apprentissage sera plus long... J'attends les levées de bouclier :) Sinon, il y a effectivement des outils clouds pour ça, mais généralement, ça déploie des VMs, pas des OS sur bare-metal... Tu peux quand même regarder de ce côté là si ça t'intéresse (à base de OpenStack) : https://cloudbase.it/windows-with-juju-and-maas/ A+ Rémy. Pour ça je ne sais pas trop. Mais si tu cherches *une* solution pour faire tout ça, ça risque d'être compliqué. -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Outils de déploiement
Le 12/06/2017 à 09:36, Remy Dernat a écrit : Le 09/06/2017 à 16:36, Jonathan Leroy a écrit : Le 9 juin 2017 à 16:17, Cyrille Verger a écrit : Bonjour à tous, Salut, Bonjour, Je suis actuellement en train de regarder des outils d'automatisation de déploiement de VM ou de machine physique. Je souhaiterais avoir votre retour d'expérience sur les différents outils que vous pouvez utiliser sachant que je souhaiterais si possible avoir : - Déploiement d'OS en VM sous VMware comme de Machine Physique Avec VMware, je sais qu'il y a un converter pour faire du p2v, mais dans l'autre sens ...? - Déploiement en "masse" simplifié https://www.terraform.io/ (pas testé) - Déploiement d'application en fonction d'un catalogue https://saltstack.com/ (c'est bien) Pour les images: Je déploie des OS (Linux) aussi avec SaltStack + FAI (http://fai-project.org/); et j'en connais aussi qui font ça avec Kickstart ou preseed (http://github.com/oxedions/banquise). Pour faire du déploiement sans info sur l'OS, c'est effectivement compliqué, sauf à déployer des images disques (clonezilla ? Avec sysprep pour Windows ?)... Mes infos windows étant un peu outdated, je me rappelle qu'on faisait ça avec Norton Ghost à une époque aussi (il y a + de 10 ans de ça...), après nettoiement de l'image (suppression de toutes les caratéristiques spécifiques aux machines (hostname, ip...). Pour les softs : Tu as aussi des outils de déploiement via une application tierce (OCS packager, peut-être avec Landesk aussi http://landesk.avocent.com/os-deployment.aspx ?). A une époque, Mandrive proposait "Pulse", mais bon, comme c'est mort... (dommage...; Pour les curieux : http://linuxfr.org/news/mandriva-pulse-3-0-faites-le-plein-de-fonctionnalites-pour-votre-si) Désolé pour les mails multiples, mais à la réflexion, et après une petite recherche, pulse existe toujours : http://www.siveo.net/pulse/ Donc à ta place, si tu me manques de temps, je me pencherai sur ça ou LANdesk. Si tu as plus de temps, terraform.io/packer.io, SaltStack + FAI/ Clonezilla, OpenStack, Ubuntu Juju/MAAS... A+ Rémy - Interface Web de gestion et de déploiement sécurisé Les pros rundeck/ansible n'ont pas un truc pour ça ? - Gestion potentiel d'un framework de validation Je sais que Chef a un système de gestion de contrôle des recettes déployées. Salt aussi mais c'est une contrib, basé sur les "dry runs" qui date un peu ( https://bitbucket.org/arthurlogilab/salt-highstate-stats ) - Gestion des updates etc etc... J'ai peur que ça soit impossible d'avoir tout dans un seul produit là... Du côté pur Windows, il y a déjà des outils très bien qui font ça, mais c'est du pur Windows (AD+GPO, WSUS, MDT, WAPT, WPKG)... Mais une fois de plus un outil de gestion de conf multi OS. Dans Salt, je crains que la gestion des Windows soit pour le moins instable, même si certains font ça... Tu dois pouvoir coder toi-même les parties manquantes, ce qui ne sera pas évident avec un autre outil de gestion de conf que Salt, où généralement, le pouvoir d'expression est moindre, mais l'apprentissage sera plus long... J'attends les levées de bouclier :) Sinon, il y a effectivement des outils clouds pour ça, mais généralement, ça déploie des VMs, pas des OS sur bare-metal... Tu peux quand même regarder de ce côté là si ça t'intéresse (à base de OpenStack) : https://cloudbase.it/windows-with-juju-and-maas/ A+ Rémy. Pour ça je ne sais pas trop. Mais si tu cherches *une* solution pour faire tout ça, ça risque d'être compliqué. -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] ISCSI vs NFS
Le 24/06/2017 à 20:26, Raphael Mazelier a écrit : Il est quand même important de bien faire le distinguo entre une techno d'exposition de block device (SAN donc, ou pourrait citer FC, FCoe, iscsi, atoe, etc...) et une techno de FS réseau sans block device partagé (NFS, Smb ?). Vraiment ? Avec un FS distribué construit sur le dev block exporté par iSCSI, tu peux faire tout ce que fait NFS, non ? C'est franchement différent. Tu penses j'image à OCFS2, GFS2 ? Le problème de ces FS c'est la gestion du lock (NFS s'en sort mieux à ce niveau même si ça reste un gros soucis). Je ne les conseillerais vraiment pas. iSCSI t’expose un blockdevice, donc il faut ajouter un FS dessus pour l’utiliser. Depuis une VM où le but c’est juste de pousser un backup ailleurs, ça peut être bien d’écrire directement sur un NFS. Sur une VM où c’est le /, j’aurais plutôt tendance à partir sur de l’iSCSI par contre, mais ça reste du feeling :p Pour le stockage de VMs cela parait intuitivement plus logique d'utiliser du block. Le problème c'est que par définition tu vas avoir beaucoup de vm(s) et donc potentiellement autant de target que de vm(s). Ça se fait c'est du SAN à l'ancienne on va dire. On utilise en général une approche différente, on utilise un ou plusieurs gros block device avec un FS distribué ou chaque vm(s) est stocké dans des fichiers (qui sont des images disques). Par exemple VMFS over FC, over iscsi ; ou directement NFS pour vmware. Sous XEN je connais des gens qui ont la même approche, export d'un gros share NFS ou on stocke des images disques des vm(s). Ça se passe globalement bien, car en général une vm n’accède qu'une seule ou fois à son fichier d'image disque, du coup pas de problème d'accès concurrent au fichiers, lock unique au démarage de la vm. Et après il faut bien regarder l'implémentation coté server aussi. Exemple assez connu, Netapp a avant tout été construit pour faire du NFS/Smb avec un FS interne (WAFL) prévu pour. L'implémentation d'isci au début était moche (un fichier image over WAFL). Du coup NFS était beaucoup plus performant sur Netapp qu'iscsi. En tout cas malgré tout le mal que je pense de NFS c'est certainement plus simple et adapté pour du stockage de VMs. L'immense problème de NFS (mais iscsi aussi) c'est la redondance et le scaling (vertical only). Alors on peut être tenté d'utiliser un vrai block device partagé (Ceph avec RDB). On règle les deux problèmes au prix d'une certaine complexité. Pour du container alors la par contre je dirais ni l'un ni l'autre ; un container ne devrait pas avoir besoin de stockage persistent, ou alors du stockage objet (S3 like). Heu... ? Un container c'est pas forcément du stateless hein... Il y a d'autres technos que Docker (ou rkt) dans la vie. Rémy -- Raphael Mazelier ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] ISCSI vs NFS
Le 30/06/2017 à 10:51, Julien Escario a écrit : Le 24/06/2017 à 17:57, Fabien a écrit : Bonjour la liste, J'ai une question théorique concernant le stockage Y a-t-il une réelle différence de performance entre le NFS et l'ISCSI ? Certaines situations nécessitent elle l'utilisation de l'une ou l'autre techno ? Alors, même si ces deux technos ont l'avantage de la simplicité, à ta place, pour un cluster Proxmox 'moderne', je regarderais plutôt du côté de Ceph ou DRBD. Ma préférence va, pour le moment, à DRBD même si son support est plus léger dans Proxmox (erreur de calcul de l'espace disque). Pour info, on peut aussi faire un cluster glusterfs aussi maintenant dans Proxmox. Moi je fais du ZFS en local. Mais on peut aussi faire du ZFS over iSCSI + tout ce qui a déjà été cité. Concernant le stockage sur du NFS distant, je m'en sers pour faire mes dumps, mais pour les grosses VMs ou les gros containers, ça arrive que je me prenne des timeouts (malheureusement pas réglables)... Rémy Le soucis de Ceph, c'est qu'il faut 4 machines pour démarrer et je ne suis pas certain que tu puisses utiliser ces machines pour faire tourner tes hyperviseurs. DRBD9 (avec drbdmanage), c'est deux machines pour démarrer et elles peuvent être à la fois noeud de stockage et hyperviseurs. Ca fait de belles économies pour démarrer. Tu devrais pouvoir monter jusqu'à 32 nœuds sans trop de soucis. Attention : c'est de le techno plus ou moins beta, attends toi à mettre les mains dans le cambouis quand il va y avoir un soucis. Jusqu'à présent, j'ai toujours réussi à repartir et retrouver une redondance suite à un incident avec un downtime minimal (quelques minutes le jour où j'ai dû faire un reboot d'un hyperviseur). Autre astuce : utiliser un export NFS en plus du DRBD. Avec la fonctionnalité de déplacement du stockage à chaud dans Proxmox, tu peux basculer de NFS (lent) à DRBD (plutôt rapide, dépend de la latence et des disques) et les migrer sans shuter tes VMs le jour où ça commence à merdoyer (par exemple, si ta synchro DRBD est H.S. sur un noeud). My 2 cts, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] ISCSI vs NFS
Le 30/06/2017 à 12:06, lemonni...@ulrar.net a écrit : Pour info, on peut aussi faire un cluster glusterfs aussi maintenant dans Proxmox. Ça fait un moment. Ça marche plutôt bien d'ailleurs, on l'utilise beaucoup, mais il y a depuis plus d'un an un bug qui fait qu'on ne peut pas augmenter un volume shardé (un volume pour stoquer des VM en gros) sans corrompre tous les disques. Bref, c'est cool et ça marche bien, mais pour de la VM considérez que le l'ajout de brick est impossible pour l'instant. À noter qu'ils ont (enfin) réussi à le reproduire de leur coté, donc ça devrait être fix soon j'espère. Cool ! Super nouvelle. Effectivement, je trouve que GlusterFS est un super produit, c'est dommage qu'il soit si souvent délaissé au profit d'autres solutions. Ceci dit, il nécessite quand même un bon réseau pour l'échange des métadonnées... ___ Liste de diffusion du FRsAG http://www.frsag.org/ -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] [Couplage monitoring et cmdb - SaltStack & co] remplacer ce bon vieux nagios
Bonjour, J'ai changé le titre, car désolé, mais ça risque de partir en troll. Je m'en excuse par avance. Voici mon petit retour d'xp sur la question... J'ai toujours détesté nagios (trop usine à gaz, en perl, dont le développement est clairement parti dans tous les sens). Du coup, comme certains d'entre vous, j'ai essayé d'autres outils de monitoring (pas tous (je n'ai notamment pas testé icinga2 et shinken, car je les trouvais trop jeune à l'époque, mais qui sont très appréciés semble t-il)), mais ils avaient toujours un défaut à mes yeux (ex. zabbix grosse usine à gaz par exemple dont la GUI est souvent bordélique). D'autres, plus simples, m'ont donné une satisfaction partielle (collectl, collectd, ganglia, munnin)... Souvent, ce que je reproche, c'est le stockage de la donnée en base RRD. Ce type de base, selon la définition de la base au départ, peu s'avérer pratique quand on manque d'espace, comme sur un raspPI, ne permet pas souvent de revenir suffisamment en arrière sur l'historique pour retracer un problème (pour info, j'ai d'ailleurs trouvé de petits outils sympas en js qui permettent d'afficher plus de détails sur une représentation graphique d'une base rrd). Car, en général, on arrive facilement à rectifier un problème, mais il est bien plus intéressant d'en trouver l'origine. Et si les données qu'on a ne sont pas assez précises pour avoir le timestamp exact, alors il est difficile de le corréler à des logs. D'où l'intérêt des bases de données temporelles, InfluxDB, elasticsearch, and co., voir éventuellement de se faire aussi son propre système, si la solution choisie ne permet pas de définir un stockage différent du RRD. Mais ces bases grossissent, et beaucoup. Ceci dit, quand on a de l'espace, pourquoi s'en priver. Pour ceux qui ne connaissent pas, il y a d'ailleurs plein d'outils "cloud" qui font ce type de job magnifiquement bien (voir par exemple "sysdig cloud" pour vous faire une idée, mais il en existe plein d'autres, si on reste peu regardant sur la confidentialité/le stockage de ces informations). Je me suis alors mis à faire de la métrologie comme certains ici, avec, pour le rendu, de pauvres tableaux html qui me disent quand tout va bien (vert) ou pas (rouge) et qui me suffisent amplement. La métrologie est faite avec SaltStack qui me remonte plein d'information sur mes machines. Cependant, c'est pour du petit/moyen parc, et je suis d'accord pour dire que c'est loin d'être aussi complet qu'un nagios qui vous remontera des infos par snmp sur tout un tas d'équipements réseau, que pour l'instant, je suis dans l'incapacité de monitorer, étant donné qu'il faudrait pouvoir y déployer à minima, le client Salt (salt-minion) ou un client SSH. L'intérêt, c'est que je ne rajoute que rarement un outil de monitoring à mon système de gestion de conf (sauf pour monitorer la température, l'électricité, le trafic réseau, ou bien l'activité de mes clusters de calcul), et je ne suis pas débordé par un trop plein d'informations (intérêt des métriques et des seuils d'alerte). Car de mon point, la problématique à vouloir absolument tout monitorer, c'est qu'au final, on se retrouve avec trop d'infos, et comme le dit l'adage trop d'informations tue l'information. Pour ceux qui utilisent Salt et souhaite approfondir la question, vous pouvez regarder la doc des beacons : https://docs.saltstack.com/en/latest/topics/beacons/ @+ Rémy Le 29/08/2017 à 09:57, Benoit Poulet a écrit : Le 24/08/2017 à 22:14, L.M.J a écrit : Et pour les autres : - Centreon : énième nagios repackagé/refondu... What's the point ? Vous avez une vue faussée de Centreon, je vais vous en parler un peu car je l'utilise au quotidien Quand vous parlez de Centreon, vous parlez généralement de la WEBUI, cette interface est assez bien foutue, complète, bien pour les gens ayant besoin de gérer des droits finement (Auth LDAP/AD), on peut par exemple filtrer les actions possible par un utilisateur. Pour mon besoin, on a des utilisateurs qui vont du commercial au technicien en passant par des clients, l'ergonomie de l'outil est un vrai plus Mais Centreon, la société française (cocorico) a fait bien plus : - Centreon peut être managé en CLI, l'outils s'appelle «clapi». Mais aussi via une API Rest. - Nagios à été forké depuis longtemps et fortement optimisé => Centreon-Engine - Ils ont développé un broker (connexion entre un satellite et le central pour la remontée de données) codé en C++, performant et avec des mécanismes intégrés de rétention de données en cas de coupure réseau. Broker est modulaire, on le configure avec des inputs/outputs, c'est lui qui écrit les RRD, et peux même sortir les métrics dans InfluxDB => Centreon-Broker - Il ont dev un mega plugin modulaire compatible Nagios, qui permet de vérifier un nom de choses incroyable et d'une façon standardisée : https://github.com/centreon/centreon-plugins - il y a une gestion native des trap
