En pratique, non, les USAs ( je bosse pour une boite US depuis quelques années, la moitié de mon équipe est aux USAs ) ont des tonnes de prestas aussi dans les boites.
Et c'est visiblement courant de prendre les gens en prestation pour plusieurs années, malgré le fait de pouvoir virer les gens rapidement dans tout les cas.
Donc bon, pour l’honnêteté, on repasseras. Dire "tu meurs pas direct" quand au final, tu te retrouves à devoir virer les personnes sur qui tu as investit en formation, c'est bien joli, mais le salarié a perdu son taf dans tout les cas, et tu as perdu ton argent quand même.
La sécurité n'est pas l'objectif pour ce cas d'usage, ce qui
répond à ta dernière question
C'est pas tant la securité que "j'ai mon script d'init qui fait un killall mondemonamoid" et ça fuite hors du chroot. C'est déjà arrivé sur une ferme de compilation d'une distro francaise, avec sshd.
Si c'est une chose qui peut être prise en charge et mutualisée
par une ou des distributions, tant mieux et je trouve que ça
fait partie des choses qui justifie une distribution.
Mais pourquoi s’arrêter à la distribution et pas faire ça upstream ? Si tu as un truc de migration de la configuration de apache, pas de raison que le distributeur garde ça.
Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
L'un des défaut que je trouve à Ansible est la piètre
ré-utilisabilité effective des rôles.
D'un part peu de rôles offrent la possibilité de spécifier son
chemin de template de fichier de configuration, à la place
c'est souvent une liste très sommaire d'options
D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
Il n'est pas possible à ma connaissance de profiter des
fonctionnalités d'un rôles sans qu'il n'impose aussi
l'installation à sa manière.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Un autre problème est la duplication souvent d'apparence
inutile des modules Ansible.
Comme ?
Enfin l'approche role-based est intéressante, mais les choses
ne sont parfois pas aussi simples.
Par exemple une machine peut faire office de reverse-proxy
supportant le SSL dans certains cas, mais pas dans d'autres et
d'autres tâches et/ou variables en dépendront (monitoring,
chemins, …)
Je ne suis pas certain que Ansible se prête à se niveau de
flexibilité.
Sur l'aspect future-proof, une config' Ansible dépendant d'une
paire de modules est-elle plus pérenne qu'un paire de shell-
scripts… hum. On verra jusqu'où le support et la compatibilité
suivra au fil des années et des changements de version majeure.
Je peux pas répondre pour les autres, mais j'ai toujours vu fabric comme étant juste un gros wrapper autour de ssh, et pas trés "haut niveau"
Par exemple, y a pas d'emphase sur le fait d'avoir des actions idempotentes, c'est quasiment equivalent à un script shell, mais en python.
Ansible a une tonne de module, donc tu vois de suite ce que tu peux faire. Fabric semble laisser le fait de connaitre la ligne de commande à l'utilisateur, donc je peux comprendre que ça paraisse plus complexe et moins attrayant.
En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.
De manière amusante, il faut aussi que le financement augmente à la hauteur du nombre de paquet qui arrivent dans la distro. Si il y a 20% en plus à chaque release, ça implique d'avoir 20% de choses en plus à faire ( à la louche ), ce qui implique donc de réussir à suivre la cadence.
Perso, si j'étais eux, je commencerais par fixer un groupe restreint de paquets pour être supporté. Ensuite, revoir le groupe à chaque release, avec la possibilité pour les gens (qui payent pour le projet) de donner leur avis sur la liste de paquets.
Mais l'histoire semble donner raison aux devs de golang, vu qu'il y a pas non plus l'air d'avoir tant de souci que l'ASLR bloquerais sur les softs en go pour le moment.
J'ai pas utilisé le mot "avantage" dans mon texte, donc je vois pas ou tu va trouver que j'aurais pu dire ça.
Mon texte est la pour nuancer le fait que "les upgrades c'est trop génial", parce que c'est un contournement pour le souci de ne pas vouloir faire la maintenance longtemps et parce que le déploiement de logiciel est trop compliqué.
On mets à jour parce qu'on a pas le choix, et on upgrade parce tout réinstaller prends trop de temps.
Le 1 est une conséquence de plusieurs facteurs sociaux dans le libre:
- on célèbre les gens qui font des nouveaux trucs, pas ceux qui font marcher ce qui existe déjà.
- on s'excite sur les nouveautés pour montrer notre status de geek alpha ( "ouais, je fait tourner la version git de tel truc" )
Donc du coup, on trouve pas assez de bénévole pour faire la maintenance et les backports, par rapport à trouver des gens qui poussent sans arrêt des nouveaux trucs ( et encore, Debian est une des distros qui arrivent à trouver le plus de monde pour ça ).
Et le 2, bah, j'ai écrit tout mon commentaire sur pourquoi c'est pas une fatalité, et pourquoi le monde a évolué. Si tu va bien le lire, tu verra même que je nuance en disant que ça résouds des soucis et qu'il y a des raisons valables en pratique ( archi déjà en place, pas le temps d'améliorer, etc, etc ), mais qu'un hack reste un hack, et qu'on arrive aussi à ne pas avoir besoin d'upgrade de version majeur.
Ensuite, si tu veux vraiment aller sur ce terrain, c'est pas l'absence qui va être un avantage en soit, mais les conséquences de cette absence, à savoir que ça libere des ressources de ne pas supporter l'upgrade. Et donc qu'on peut avoir ce temps libre mis ailleurs. Genre un packageur avec moins de bugs sur l'upgrade, car sans obligation de le supporter, peut prendre plus de paquets, ou corriger d'autres bugs, par exemple.
Et la, on en reviens sur les débats de rolling releases, etc, etc, etc.
Kubernetes est un gestionnaire de cluster de containeurs, projet initié par Google et soutenu par une paire d'autres boites.
Ça se base sur les archis de micro services, que je vais tenter d'expliquer vite fait.
L'idée, c'est de décrire une archi ( par exemple, une appli web ) sous forme de différents services qui tourne chacun dans un espace séparé et qui communique via une API défini. Par exemple, un site de e-commerce va avoir le serveur web, qui va parler à php-fpm ( un php en dehors du process du serveur web ), un composant qui va se charger de donner les résultats de recherche via une API REST, un composant qui va enregistrer le caddie ( via REST aussi ), etc.
Avec Kubernetes, chaque composant tourne dans un containeur docker, ce qui permet de faire les updates indépendamment du composant du reste de la stack ( modulo le fait que le composant respecte l'API ), ce qui permet aussi de gérer la charge indépendamment de chaque composant ( genre si tout d'un coup, y a plus de recherche, tu rajoutes plus de composant "recherche" et tu t'arranges pour que le code fasse du load balancing ), etc.
Donc Kubernetes, un master prends en entré un fichier json ou yaml qui décrit plusieurs containeurs docker, les groupes dans ce que le projet appelle un pod et se charge de repartir le pod sur une ou plusieurs machines, en reliant les containeurs entre eux pour communiquer, en relancant ce qui sont en panne pour que le service fonctionne, etc, etc.
C'est basé sur les architectures utilisé par les géants du web ( google, facebook, twitter ) pour leur infra web ou de traitement par lots ( ie, les batchs de job ). C'est encore en rapide développement, écrit en go.
Origin, c'est la version 3 de l'architecture d'openshift, un logiciel de PaaS ( Platform as a service ) de Red Hat. Tout comme kubernetes, c'est écrit en go, et ça s'interface devant Kubernetes, en rajoutant des APIs et des services pour être directement utilisable par un développeur pour faire du hosting. Par exemple, il y a une interface web, ça gére les utilisateurs, il y a un workflow pour construire les containeurs docker et les déployer à partir de git, etc etc.
Pour prendre l'exemple du site de ecommerce, tu peux avoir un déploiement du composant de recherche à chaque fois qu'un developpeur fait un commit. Le logiciel va recevoir une notification ( par exemple, via un post-commit git ), va prendre le code, le compiler ( dans un containeur prévu pour ), lancer les tests ( encore dans un containeurs ) et si c'est bon, le déployer automatiquement sur ton cluster. Tout ceci est bien sur configurable ( à terme ) pour par exemple ne déployer que sur 10% pour faire des tests, ou ne déployer qu'à la main, etc, etc.
C'est aussi en rapide développement, et pour faciliter le déploiement, ça embarque tout kubernetes. Ce qui me fait crier dans ma tête, mais bon, c'est vrai que du coup, ça va vite à tester.
Les upgrades de versions majeurs sont non supportés. La solution est "tu réinstalles". Autant en Fedora, tu t'en tire avec fedup, autant rhel/centos, c'est niet.
Et l'emphase de nos jours est plus sur la séparation OS de base/ applications ( comme les BSD, mais au dela du code et de la compilation ), et des systémes de mises à jour atomiques ( ostree et snappy, par exemple ), et les containers ( docker, rocket ). Ce qui permet de mettre à jour, revenir en arrière, et de faire ( via des architectures de micro services ) bouger les pièces indépendamment.
Voir par exemple les videos et slides de la conférence "New directions in operating systems" qui a eu lieu il y a 6 mois à Londres.
J'arrive à vivre avec EPEL qui fait tout ce que tu aimes dans
les repos Debian.
Sans que ça soit la catastrophe, y a quand même plus de trucs chez Debian que dans EPEL 7. Mais EPEL étant mis à jour indépendamment de la version stable de la distro, il y as aussi plus de flexibilité, et ça se ressent. Et j'ai personnellement toujours pas compris pourquoi y a pas plus de mises à jours autre que sécurité sur Debian ( ou qu'il faille attendre des mois pour que ça soit dispo au lieu de faire ça au fil de l'eau car l'effort serait sensiblement le même ).
J'ai en effet pas cherché, j'ai juste vu le mail de Florian.
J'utilise pas Debian pour docker et je pense que docker est pas sec, pour reprendre les termes consacrés, mais je regarde un peu les choses de loin, et de mon point de vue de packageur, je sais que c'est une plaie pour la securité sur le long terme, principalement à cause de go.
Donc il y a:
- besoin du compilo go, avec l'upstream qui pousse vers la derniére release du language ( donc ça implique de backporter aussi un compilo ). Que je sache, ça tourne pas encore avec gcc-go.
( ou plutot, ça tourne avec gcc 5.0 et quelques crashs )
sans doute besoin des dernières libs (pareil, backports). Peut être des snapshots git des dites libs.
et ça compile tout en statique, ce qui rends le tracking des soucis de sécu un chouia plus compliqué.
Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.
Debian offre les aussi la possibilité d'installer un chroot de
n'importe quelle version de Debian sur le même serveur en une
seule ligne de commande, ce qui est très pratique pour faire
tourner de vieux programmes sur un serveur récent.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Les changements de version Debian sont simples.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
A long-running problem in Debian is that several of our core teams are severely under-staffed.
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
par contre aucuns de nos serveurs CentOS 5 n'a été migré en 6
ou en 7.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
De ce que j'ai vu, y a de tout dans la nature. Debian est très présent mais aussi du Centos/RHEL, et je vois de temps en temps de l'opensuse. j'ai plus rarement vu du *bsd, mais il me parait aussi évident que je vais pas en croiser vu que je fait surtout du linux :)
Mais je pense que tu as d'autres raisons que "tu as pas le choix" pour prendre autre chose que Debian. Par exemple, j'ai eu des surprises chez un client ( genre, du matos acheté sans vérifier la compatibilité, et donc qui ne marchait pas sans devoir bidouillé et mettre le serveur à moité en testing ). À minima, les certifs hardwares évitent ça et même si dans mon cas, c'était 2 serveurs internes d'infra, ça aurait pu être 40 sur internet. Et autant, 2 à 3 ans de support sécu, c'est déjà bien, autant, je comprends que plus, c'est aussi pas mal ( dit-il en pensant au serveur VPN en RHEL 5 de son taf ).
Il y a aussi des différences technologiques parfois assez importantes. Si tu veux déployer un truc comme freeipa ( qui est de la bombe, ça déchire de déployer kerberos/ldap/etc via 1 commande ), ou les choses produites par des communautés ou RH est un gros ou le seul sponsor important comme openshift, kubernetes, les trucs autour de docker ( surtout que le dit docker a été viré de jessie ), Debian est pas forcément le choix le plus probant ( Ubuntu à la rigueur, mais ils poussent aussi pas mal leur stack en priorité, genre lxc, maas, juju ).
À contrario, si tu veux des trucs un peu exotiques ou spécifiques, Debian propose sans doute un paquet ( genre dans le monde scientifique, ou j'ai le sentiment qu'il y a une tonne de paquets, de part l'attachement des scientifiques à ses idéaux non commerciaux ).
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
[^] # Re: Classique
Posté par Misc (site web personnel) . En réponse au journal sous-developpeurs-SSII. Évalué à 8.
En pratique, non, les USAs ( je bosse pour une boite US depuis quelques années, la moitié de mon équipe est aux USAs ) ont des tonnes de prestas aussi dans les boites.
Et c'est visiblement courant de prendre les gens en prestation pour plusieurs années, malgré le fait de pouvoir virer les gens rapidement dans tout les cas.
Donc bon, pour l’honnêteté, on repasseras. Dire "tu meurs pas direct" quand au final, tu te retrouves à devoir virer les personnes sur qui tu as investit en formation, c'est bien joli, mais le salarié a perdu son taf dans tout les cas, et tu as perdu ton argent quand même.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
C'est pas tant la securité que "j'ai mon script d'init qui fait un killall mondemonamoid" et ça fuite hors du chroot. C'est déjà arrivé sur une ferme de compilation d'une distro francaise, avec sshd.
Mais pourquoi s’arrêter à la distribution et pas faire ça upstream ? Si tu as un truc de migration de la configuration de apache, pas de raison que le distributeur garde ça.
[^] # Re: alt et p-
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 3.
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Comme ?
Bah, tu peux mettre passer des arguments à un rôle ou un include ( http://docs.ansible.com/playbooks_roles.html#task-include-files-and-encouraging-reuse et plus bas ). J'ai un role httpd qui le fait que j'utilise sur 3 projets indépendants, donc je vois pas en quoi ça serait pas faisable.
La, ça semble un peu du FUD…
[^] # Re: Ansible / Puppet
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 3.
Je peux pas répondre pour les autres, mais j'ai toujours vu fabric comme étant juste un gros wrapper autour de ssh, et pas trés "haut niveau"
Par exemple, y a pas d'emphase sur le fait d'avoir des actions idempotentes, c'est quasiment equivalent à un script shell, mais en python.
Ansible a une tonne de module, donc tu vois de suite ce que tu peux faire. Fabric semble laisser le fait de connaitre la ligne de commande à l'utilisateur, donc je peux comprendre que ça paraisse plus complexe et moins attrayant.
[^] # Re: Ansible / Puppet
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 10.
En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
De manière amusante, il faut aussi que le financement augmente à la hauteur du nombre de paquet qui arrivent dans la distro. Si il y a 20% en plus à chaque release, ça implique d'avoir 20% de choses en plus à faire ( à la louche ), ce qui implique donc de réussir à suivre la cadence.
Perso, si j'étais eux, je commencerais par fixer un groupe restreint de paquets pour être supporté. Ensuite, revoir le groupe à chaque release, avec la possibilité pour les gens (qui payent pour le projet) de donner leur avis sur la liste de paquets.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
Parce que jamais aucun employé ne va être mécontent, et parce que les bécanes vérolés qui servent de passerelles n'existent pas ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 3.
Théoriquement les gens se plaignent du fait que ça ne prenne pas en compte les mesures de sécurité comme ASLR et NX. Mais les devs du compilo disent que ç'est pas requis de part la présence d'autres protections ( https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/u1jlX12zVx8J ).
Mais l'histoire semble donner raison aux devs de golang, vu qu'il y a pas non plus l'air d'avoir tant de souci que l'ASLR bloquerais sur les softs en go pour le moment.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 5.
J'ai pas utilisé le mot "avantage" dans mon texte, donc je vois pas ou tu va trouver que j'aurais pu dire ça.
Mon texte est la pour nuancer le fait que "les upgrades c'est trop génial", parce que c'est un contournement pour le souci de ne pas vouloir faire la maintenance longtemps et parce que le déploiement de logiciel est trop compliqué.
On mets à jour parce qu'on a pas le choix, et on upgrade parce tout réinstaller prends trop de temps.
Le 1 est une conséquence de plusieurs facteurs sociaux dans le libre:
- on célèbre les gens qui font des nouveaux trucs, pas ceux qui font marcher ce qui existe déjà.
- on s'excite sur les nouveautés pour montrer notre status de geek alpha ( "ouais, je fait tourner la version git de tel truc" )
Donc du coup, on trouve pas assez de bénévole pour faire la maintenance et les backports, par rapport à trouver des gens qui poussent sans arrêt des nouveaux trucs ( et encore, Debian est une des distros qui arrivent à trouver le plus de monde pour ça ).
Et le 2, bah, j'ai écrit tout mon commentaire sur pourquoi c'est pas une fatalité, et pourquoi le monde a évolué. Si tu va bien le lire, tu verra même que je nuance en disant que ça résouds des soucis et qu'il y a des raisons valables en pratique ( archi déjà en place, pas le temps d'améliorer, etc, etc ), mais qu'un hack reste un hack, et qu'on arrive aussi à ne pas avoir besoin d'upgrade de version majeur.
Ensuite, si tu veux vraiment aller sur ce terrain, c'est pas l'absence qui va être un avantage en soit, mais les conséquences de cette absence, à savoir que ça libere des ressources de ne pas supporter l'upgrade. Et donc qu'on peut avoir ce temps libre mis ailleurs. Genre un packageur avec moins de bugs sur l'upgrade, car sans obligation de le supporter, peut prendre plus de paquets, ou corriger d'autres bugs, par exemple.
Et la, on en reviens sur les débats de rolling releases, etc, etc, etc.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 10.
Kubernetes est un gestionnaire de cluster de containeurs, projet initié par Google et soutenu par une paire d'autres boites.
Ça se base sur les archis de micro services, que je vais tenter d'expliquer vite fait.
L'idée, c'est de décrire une archi ( par exemple, une appli web ) sous forme de différents services qui tourne chacun dans un espace séparé et qui communique via une API défini. Par exemple, un site de e-commerce va avoir le serveur web, qui va parler à php-fpm ( un php en dehors du process du serveur web ), un composant qui va se charger de donner les résultats de recherche via une API REST, un composant qui va enregistrer le caddie ( via REST aussi ), etc.
Avec Kubernetes, chaque composant tourne dans un containeur docker, ce qui permet de faire les updates indépendamment du composant du reste de la stack ( modulo le fait que le composant respecte l'API ), ce qui permet aussi de gérer la charge indépendamment de chaque composant ( genre si tout d'un coup, y a plus de recherche, tu rajoutes plus de composant "recherche" et tu t'arranges pour que le code fasse du load balancing ), etc.
Donc Kubernetes, un master prends en entré un fichier json ou yaml qui décrit plusieurs containeurs docker, les groupes dans ce que le projet appelle un pod et se charge de repartir le pod sur une ou plusieurs machines, en reliant les containeurs entre eux pour communiquer, en relancant ce qui sont en panne pour que le service fonctionne, etc, etc.
C'est basé sur les architectures utilisé par les géants du web ( google, facebook, twitter ) pour leur infra web ou de traitement par lots ( ie, les batchs de job ). C'est encore en rapide développement, écrit en go.
Plus d'info sur :
http://kubernetes.io/
https://github.com/googlecloudplatform/kubernetes
http://kubernetesio.blogspot.ca/
Et une distrib qui embarque Kubernetes :
http://www.projectatomic.io/
Donc, ça, c'est Kubernetes.
Origin, c'est la version 3 de l'architecture d'openshift, un logiciel de PaaS ( Platform as a service ) de Red Hat. Tout comme kubernetes, c'est écrit en go, et ça s'interface devant Kubernetes, en rajoutant des APIs et des services pour être directement utilisable par un développeur pour faire du hosting. Par exemple, il y a une interface web, ça gére les utilisateurs, il y a un workflow pour construire les containeurs docker et les déployer à partir de git, etc etc.
Pour prendre l'exemple du site de ecommerce, tu peux avoir un déploiement du composant de recherche à chaque fois qu'un developpeur fait un commit. Le logiciel va recevoir une notification ( par exemple, via un post-commit git ), va prendre le code, le compiler ( dans un containeur prévu pour ), lancer les tests ( encore dans un containeurs ) et si c'est bon, le déployer automatiquement sur ton cluster. Tout ceci est bien sur configurable ( à terme ) pour par exemple ne déployer que sur 10% pour faire des tests, ou ne déployer qu'à la main, etc, etc.
C'est aussi en rapide développement, et pour faciliter le déploiement, ça embarque tout kubernetes. Ce qui me fait crier dans ma tête, mais bon, c'est vrai que du coup, ça va vite à tester.
Plus d'info :
http://www.openshift.org/#v3
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/welcome/index.html
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 9.
Les upgrades de versions majeurs sont non supportés. La solution est "tu réinstalles". Autant en Fedora, tu t'en tire avec fedup, autant rhel/centos, c'est niet.
C'est sur la roadmap d’après une présentation donnée lors du RH Summit l'année dernière ( https://rhsummit.files.wordpress.com/2014/04/cantrell_w_1650_migrating_and_upgrading_rhel.pdf ). Mais je miserais moins sur ça que sur les outils d'automatisations pour un redéploiement ( et encore, j'ai un serveur web à passer en 7, et j'ai la flemme ).
Et l'emphase de nos jours est plus sur la séparation OS de base/ applications ( comme les BSD, mais au dela du code et de la compilation ), et des systémes de mises à jour atomiques ( ostree et snappy, par exemple ), et les containers ( docker, rocket ). Ce qui permet de mettre à jour, revenir en arrière, et de faire ( via des architectures de micro services ) bouger les pièces indépendamment.
Voir par exemple les videos et slides de la conférence "New directions in operating systems" qui a eu lieu il y a 6 mois à Londres.
Sans que ça soit la catastrophe, y a quand même plus de trucs chez Debian que dans EPEL 7. Mais EPEL étant mis à jour indépendamment de la version stable de la distro, il y as aussi plus de flexibilité, et ça se ressent. Et j'ai personnellement toujours pas compris pourquoi y a pas plus de mises à jours autre que sécurité sur Debian ( ou qu'il faille attendre des mois pour que ça soit dispo au lieu de faire ça au fil de l'eau car l'effort serait sensiblement le même ).
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 6.
J'ai en effet pas cherché, j'ai juste vu le mail de Florian.
J'utilise pas Debian pour docker et je pense que docker est pas sec, pour reprendre les termes consacrés, mais je regarde un peu les choses de loin, et de mon point de vue de packageur, je sais que c'est une plaie pour la securité sur le long terme, principalement à cause de go.
Donc il y a:
- besoin du compilo go, avec l'upstream qui pousse vers la derniére release du language ( donc ça implique de backporter aussi un compilo ). Que je sache, ça tourne pas encore avec gcc-go.
( ou plutot, ça tourne avec gcc 5.0 et quelques crashs )
sans doute besoin des dernières libs (pareil, backports). Peut être des snapshots git des dites libs.
et ça compile tout en statique, ce qui rends le tracking des soucis de sécu un chouia plus compliqué.
Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 7.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Malgré ce qu'on croit, l'userspace est pas 100% indépendant du kernel http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
Mais voila, ça reste couteux en ressources. Le DPL dit d'ailleurs dans une interview ( http://www.itwire.com/business-it-news/open-source/67512-surviving-systemd-lucas-nussbaum-satisfied-with-init-system-outcome ) :
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 10.
De ce que j'ai vu, y a de tout dans la nature. Debian est très présent mais aussi du Centos/RHEL, et je vois de temps en temps de l'opensuse. j'ai plus rarement vu du *bsd, mais il me parait aussi évident que je vais pas en croiser vu que je fait surtout du linux :)
Mais je pense que tu as d'autres raisons que "tu as pas le choix" pour prendre autre chose que Debian. Par exemple, j'ai eu des surprises chez un client ( genre, du matos acheté sans vérifier la compatibilité, et donc qui ne marchait pas sans devoir bidouillé et mettre le serveur à moité en testing ). À minima, les certifs hardwares évitent ça et même si dans mon cas, c'était 2 serveurs internes d'infra, ça aurait pu être 40 sur internet. Et autant, 2 à 3 ans de support sécu, c'est déjà bien, autant, je comprends que plus, c'est aussi pas mal ( dit-il en pensant au serveur VPN en RHEL 5 de son taf ).
Il y a aussi des différences technologiques parfois assez importantes. Si tu veux déployer un truc comme freeipa ( qui est de la bombe, ça déchire de déployer kerberos/ldap/etc via 1 commande ), ou les choses produites par des communautés ou RH est un gros ou le seul sponsor important comme openshift, kubernetes, les trucs autour de docker ( surtout que le dit docker a été viré de jessie ), Debian est pas forcément le choix le plus probant ( Ubuntu à la rigueur, mais ils poussent aussi pas mal leur stack en priorité, genre lxc, maas, juju ).
À contrario, si tu veux des trucs un peu exotiques ou spécifiques, Debian propose sans doute un paquet ( genre dans le monde scientifique, ou j'ai le sentiment qu'il y a une tonne de paquets, de part l'attachement des scientifiques à ses idéaux non commerciaux ).
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Sauf que salt-ssh ne fait que du ssh.
Ansible propose ça :
https://github.com/ansible/ansible/tree/devel/lib/ansible/runner/connection_plugins
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 6.
Ça depend ou tu situes ton spectre.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
[^] # Re: Pour résumé / Point d'étape
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 10.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
[^] # Re: Je confirme
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 6.
C'est pas parce que c'est un bug que tu va réussir à le déclencher à coup sur. C'est un bug, par définition, c'est un comportement inattendu :)
[^] # Re: C'est le jeu ma pauvre lucette!
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 7.
Sans doute ça :
http://www.wired.com/2013/08/20-percent-time-will-never-die/
ou ça :
http://www.businessinsider.com/mayer-google-20-time-does-not-exist-2015-1
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Azure a fait 1 milliard de chiffres d'affaire en 2013.
http://www.journaldunet.com/solutions/cloud-computing/chiffre-d-affaires-azure-en-2013.shtml
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Pour donner une comparaison de la croissance, l'Appstore d'Apple a fait ça en 2 ans ( http://www.macworld.com/article/1157957/app_store_market_share.html , ouvrture en 2008, chiffre d'affaire en en 2009 de 800 millions ).
Donc bon, pour une boite moribonde, ils ont visiblement réussi à faire un peu d'affaire, face à la concurrence de Amazon et d'une tonne d'acteurs.
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
[^] # Re: Certes
Posté par Misc (site web personnel) . En réponse au journal L'autohébergement, c'est pas gagné. Évalué à 5.
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
[^] # Re: Des usages à cerner
Posté par Misc (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 4.
Alors parmi les cas d'usage, c'est deja le fait d'avoir un truc self contained à déployer. IE, ce que tu testes est exactement ce que tu déploies.
Ça, c'est globalement la théorie, la pratique est plus compliqué car la platforme est pas correctement isolé :
http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
[^] # Re: TU
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.