Le petit coin de Nicolas - Commentaires

Lecture : High Performance MySQL - Nicolas Steinmetz

Nicolas Steinmetz — Fri, 19 Jun 2009 17:39:00 +0200

@Laotseu : Non pas en tant que tel. Postgres va faire son entrée pour un applicatif partiuclier (car il est utilisé historiquement avec postgres et étendu par la suite à Oracle, ce qui nous intéresse). Un de nos architectes a l'air un peu tenté par Postgres mais déjà qu'on a du mal avec MySQL alors je pense que ça va être plus compliqué avec Postgres

Déjà quand j'ai proposé à l'équipe Genie Logiciel de stocker de simples paramètres dans une base Sqlite au lieu de MySQL, ils ont fait les grands yeux, alors postgres...

Dommage car postgres me semble assez intéressant (mais je n'ai pas eu le temps de m'initier bcp à postgres, ni de lire bcp de choses à son sujet).

Lecture : High Performance MySQL - Laotseu

Laotseu — Fri, 19 Jun 2009 16:01:01 +0200

Avez vous considéré une solution Postgres ?

Lecture : High Performance MySQL - Nicolas Steinmetz

Nicolas Steinmetz — Wed, 17 Jun 2009 19:58:16 +0200

Je ne dis pas que MySQL ne peut pas être utilisé dans des systèmes critiques et/ou à forte charge dans l'absolu. C'est plus le contexte JCDecaux qui veut ça du fait du manque d'expérience / expertise sur MySQL (on doit être 2) et je parle même pas de notre infogéreur. On a quand même 2 (voir 3 en comptant l'intranet groupe) systèmes relativement critique sous MySQL et qui fonctionne globalement bien, voir très bien.

A la lecture du livre, je me rends surtout compte que pour bien optimiser MySQL, il faut savoir où on va et acquérir une certaine expérience / expertise. Cela va plus loin que le simple "apt-get install mysql-server et zou c'est parti" comme on le voit au niveau des équipes de dev ou par un hébergeur par ex (idem pour la conf Apache d'ailleurs ne tirant pas partie de la puissance de la machine...). On parle des DBA Oracle mais je crois qu'il faudrait reconnaître un statut équivalent pour MySQL.

Dans votre cas, vous maîtrisez toute la chaine (de la conception à l'hébergement). Il vous est du coup peut être plus "facile" que pour moi de faire marcher le tout aux petits oignons et atteindre un certain nombre de critères de performance / criticité / etc.

Ensuite, c'est comparativement à Oracle ou SQL Server, ce que je peux voir, c'est que ces deux produits sont plus aboutis en tant que tel ou bien sont mieux outillés. Pour résumé, par certains cotés, MySQL reste très "artisanal" et même si cela évolue dans le bon sens, elle a encore du chemin à faire. Dans ce cadre, je sais pas top ce que va donner le rachat de Sun par Oracle (qui en gérant innodb a déjà une prise sur MySQL de fait).

Pour répéter, c'est bien dans le contexte actuel à JCDecaux ou je suis sceptique sur MySQL que sur MySQL même si ce livre m'a éclairé sur pas mal de point qui sont à mon avis pas / peu pris en compte dans des projets traditionnels.

Lecture : High Performance MySQL - Mega

Mega — Wed, 17 Jun 2009 17:13:20 +0200

Chez nous ca tourne du feu de dieu, c'est optimisé aux petits oignons, et on ne peut pas dire qu'on ne tienne pas la charge ou la criticité

CouchDB - Premier tour d'horizon - Nicolas Steinmetz

Nicolas Steinmetz — Mon, 15 Jun 2009 09:41:16 +0200

@OncleTom : les échanges se font via JSON. Tu peux donc le faire autrement qu'en JS mais tu sors du cadre strict de CouchDB. Pour python, tu as par ex couchdbkit qui, si j'ai bien compris, te permet de t'interfacer à couchdb uniquement via du python. Sous réserve que ça existe ou que tu le crées tu dois donc pouvoir le faire en PHP par ex.

@benoitc : ok, j'y vois un peu plus clair, je crois qu'il faut que je me lance dans le concret pour me faire une idée.

CouchDB - Premier tour d'horizon - benoitc

benoitc — Mon, 15 Jun 2009 08:24:37 +0200

Je suis d'accord (j'allais te le dire via twitter quand j'ai vu l'autre tweet) MVC n'a rien à voir avce le système de stockage c'est juste une vision applicative.

En ce qui concerne les ajouts de champs, géneralement je fait dans un mappage de/des anciens vers les nouveaux si c'ets nécessaire avec les eventuelles conversions, snon evidemment je n'affiche que les nouveaux. Si tu dois gérer n versions de ton appli il peut etre interessant aussi de maintenir via les vues n versions de schema. en mappant les champs eventuelles. Les scenarios sont multipes.

Sortir du socle couchdb pour y insérer du django , tt depend. Tu es obligé d ele faire pour le moment quand tu veux chainer des vues ou lq tu as besoin de sql. Tu pourrais aussi ne valider tes données qu'au niveau couchdb (la prochaine version de couchdbkit l'autorisera). A voir. Evidemment tu peux (et là je parle de l'extension couchdbkit) aussi avir besoin d'accéder à des bases de données sql ou autres (redis, tc, memcached...) et là django t'es utile aussi.

CouchDB - Premier tour d'horizon - Oncle Tom

Oncle Tom — Mon, 15 Jun 2009 07:14:09 +0200

J'ai pas lu encore tous tes liens mais on peut pas y accéder autrement qu'en JS ? Parce contre ça fait une super base de stockage à dispo

Apache : mutualisation, inclusion et ordre - Nicolas Steinmetz

Nicolas Steinmetz — Wed, 20 May 2009 09:16:33 +0200

Tant mieux si j'ai pu répondre à ta question.

Sur l'histoire des comportement dynamiques, en y réflechissant de bon matin, je pense que c'est faisable en fait avec des directives comme SetEnvIf (comme présenté ici avec la gestion de source pour l'authentification) ou des variables prennent des valeurs en fonction de règles que tu définies... Mod_include doit aussi permettre des choses mais je n'ai jamais joué avec pour le moment.

Apache : mutualisation, inclusion et ordre - Oncle Tom

Oncle Tom — Wed, 20 May 2009 08:36:53 +0200

Non ben je pensais à ça (gestion dynamique des sous-domaines) donc pas besoin d'en dire plus.

Je trouve ça pratique pour mutualiser les règles au travers différents projets : les règles de réécriture sont à 90% identiques sur tous mes projets symfony ... un include ira plus vite que tout retaper à chaque fois.

Versionné, ça ira encore plus vite à déployer sur de nouveaux serveurs

Apache : mutualisation, inclusion et ordre - Nicolas Steinmetz

Nicolas Steinmetz — Wed, 20 May 2009 00:22:29 +0200

Pour les contextes, tu peux détailler un peu ?

Si tu penses à un truc genre la gestion dynamique des sous-domaines, je vois pas pourquoi cela ne serait pas possible (ou bien via d'autres directives apache). Quand Apache lis ton fichier de conf et inclus tes fichiers .txt (si on reprend mon exemple), alors c'est comme s'il voyait un fichier complet amha. Donc ce qui était valable dans un fichier unique doit être valable de la même façon avec les include.

Après dans le contenu de tes fichiers.txt, faut voir ce qui est vraiment générique et ce qui ne l'est pas - faut pas non plus transformer le binz en usine à gaz. Je m'en sers dans le cas présent pour gérer la conf de l'intranet groupe (basé sur eZ Publish) avec un vhosts avec une authentification SSO et un vhosts anonyme en fonction du routage réseau. En dehors de cet aspect authentification, les confs apache sont identiques en tout point (même dossier pour le DocumentRoot, etc).

Pour des machines mutualisées (avec des applicatifs divers), il faut voir dans quelle mesure c'est réalisable et ça ne complexifie pas la chose... Je me dis par ex que je vais pouvoir adopter cette logique pour la gestion des Reverse Proxy des sites web vélos. Par contre, pour d'autres RP reroutant tout et n'importe quoi, je suis pas sur que cela apporte grand chose ou que cela ne complexifie plus que cela ne simplifie les choses.

Apache : mutualisation, inclusion et ordre - Oncle Tom

Oncle Tom — Tue, 19 May 2009 23:06:51 +0200

Excellent cette mutualisation ! Je connaissais ça pour Nginx mais pas pour Apache ... que j'utilise depuis plus longtemps. Comme quoi ...

Par contre question, y'a des variables de contexte ou autre ? Ou moyen de passer des variables à des fichiers inclus ? Pour faire des directives utilisant des "Match" (DirectoryMatch entre autre) génériques pour des besoins spécifiques ?

Des choix techniques et d'infrastructure - Nicolas Steinmetz

Nicolas Steinmetz — Tue, 19 May 2009 17:28:14 +0200

@Olivier : je ne vois pas SAP/Oracle/... fournir du support sur du slackware Pour le BSD, perso j'ai jamais essayé et je pense pas qu'il y ait des compétences internes sur BSD.

@Benjamin : cf ma réponse à Oncle Tom

Des choix techniques et d'infrastructure - Benjamin

Benjamin — Tue, 19 May 2009 14:22:36 +0200

Pourquoi debian "c'est exclu" ?

Retour sur un an d'intégration à JCDecaux - Nicolas Steinmetz

Nicolas Steinmetz — Tue, 19 May 2009 10:02:38 +0200

Pour les outils de déploiement maison :

Il y a un existant en perl pour les applications dont je m'occupe Complété parfois à la marge par des scripts bash
L'outil cible est en java pour son coté multi-plateforme et de compétences internes sur le développement de l'outil pour un projet en question (et qu'on doit généraliser ensuite)

Retour sur un an d'intégration à JCDecaux - Benjamin

Benjamin — Mon, 18 May 2009 15:19:50 +0200

@Nicolas

oui en grande partie.

Ton retour d'expérience est intéressant :=)

Dernière question cependant, quelles technologies as-tu choisi pour tes outils de déploiement maison (et pourquoi) ?

Des choix techniques et d'infrastructure - olivier

olivier — Wed, 13 May 2009 19:33:40 +0200

Slackware à fond, par expérience, c'est plus simple de créer / maintenir des SlackBuilds. Par contre je ne pense pas qu'il existe des SlackBuild tout prêt pour Oracle. Peut être, qu'il faut voir du côté de Eric « Alien » Hameleers.

Sinon les BSD (du moins FreeBSD) supporte Oracle (via une émulation Linux).

Des choix techniques et d'infrastructure - Nicolas Steinmetz

Nicolas Steinmetz — Wed, 13 May 2009 10:34:46 +0200

@JB :

Oui, je suis d'accord, c'est bien pour cela que je parle d'adaptation raisonnable (par ex, dans mon cas, recompiler PHP à partir des SRPMS de FC me semble une bonne solution)
Je ne sais pas si c'est nous qui sommes consciencieux ou si RH nous questionne mais en tous cas, on essaie de respecter les licences. Sauf erreur, on ne fait pas appel au support et au RHN donc... Je ne sais pas dans quelles mesures tu peux te retourner contre RHEL en cas de pépin d'ailleurs...
Perso, j'ai du me mettre à la création de paquets et on doit être pas beaucoup à savoir en faire en effet . Dans mon cas, c'est pour ça que je suis parti des RPMs de Fedora Core pour minimiser les risques. Je ne me vois pas créer des paquets moi-même pour le moment de zéro. J'avais essayé une fois, le résultat n'a pas été très probant. Pour nous, c'est sur que c'est pas l'équipe de dev qui va les faire et pas plus la prod. Ca rentre amha dans le rôle de la cellule intégration (technique) à laquelle j'appartiens.

@Oncle Tom :

Pour Fedora, effectivement, c'est la question que je me pose - en même temps pour l'avoir testé à titre perso quand j'étais chez OVH/Gandi, ça marche bien et il y a beaucoup de paquets fournis. J'ai eu aussi de mauvaises expériences avec les premières versions de FC ; je trouve que cela s'est bien amélioré. Maintenant, pour en faire de la prod à JCDecaux, je pense qu'il faut encore y réfléchir...
Pour Debian, notre Resp. Sécurité s'y opposerait je pense (cf problème SSL/SSH) et parce que personne ici (hormis moi et quelques cas isolés) n'a de compétence sur Debian. Se poserait aussi le problème du fonctionnement de certaines applications sur Debian (je ne pense pas qu'Oracle, SAP, etc certifie leurs produits sur Debian - or dans un contexte d'informatique "industriel", ce genre d'éléments entre compte. On ne va pas non plus multiplier les distributions "à l'infini".

@YvesTan :

L'appstack n'a pas été pris pour des raisons budgétaires à l'époque (appremment PHP est à jour en 5.2.6, intéressant - https://rhn.redhat.com/errata/RHSA-2009-0350.html & https://rhn.redhat.com/errata/RHSA-2008-0505.html )
Effectivement, il y a le dépot "rémi" mais là (et même si Remi semble devenir de plus en plus un packageur officiel Fedora pour PHP), je trouve ça "encore" pire que d'utiilser les dépots de FC pour recompiler nos paquets. De mémoire, le paquet source de PHP pour FC11 est pourtant produit par Rémi il me semble... Si on en arrive là, le coté "Entreprise" perdrait encore plus de son sens amha.

Des choix techniques et d'infrastructure - YvesTan

YvesTan — Wed, 13 May 2009 10:08:05 +0200

Je trouve RHEL un peu pénible pour du serveur Web à moins de s'abonner au Red Hat Application Stack (http://www.redhat.com/appstack/) pour avoir des paquets officiels récents.

Sinon, on installe des paquets non-officiel (rpm remi) et le côté "entreprise" perd de sa substance comme tu le dis.

Du coup, moi je dirais tout en CentOS, même la prod

Des choix techniques et d'infrastructure - Oncle Tom

Oncle Tom — Wed, 13 May 2009 09:56:49 +0200

Intéressant : j'aurais jamais considéré Fedora sur du serveur à cause du rythme de mise à jour trop fréquent (et toujours pas top ? Du temps où j'utilisais Fedora (3, 4 et 5), c'était pas génial les mises à jour de version majeur....)

Sinon pour exclure Debian ? C'est pas un troll, je suis curieux

Des choix techniques et d'infrastructure - JB

JB — Wed, 13 May 2009 05:57:47 +0200

Billet intéressant !

Je suis confronté aux mêmes genres de problèmes au boulot, sachant que c'est un peu décalé car notre infrastructure Linux est complètement sous RHEL (3/4/5) et quelques petites choses sous AIX (bases Oracle notamment). Et je ne connais pas Slackware, donc parlons RedHat.

Mes réflexions et mon retour d'expérience :

"Passer à côté de solutions répondant aux problèmes des utilisateurs pour une histoire de version de composant me semble être une hérésie et symboliser l'échec de la mission d'une DSI à l'égard de ses utilisateurs" => oui, à condition d'évaluer correctement les gains attendus côté utilisateur et le nombre d'utilisateurs, à mettre en face de la peine à exploiter ou maintenir les outils côté production ; j'aime faire plaisir aux utilisateurs, leur rendre service, mais passer 50% de son temps pour satisfaire à peine 5 ou 10 personnes sur des centaines, c'est dommage!
"Pour faire des économies en ces temps de crise, est-il judicieux par ex de monter des environnements de VABF / PREPROD sur du CentOS et la PROD sur du RHEL" : à mon avis non. Pour une simple raison, RedHat n'est pas si regardant que ça sur les licences. Je "possède" 30 licences RHEL, j'ai 45 serveurs enregistrés sur leur site (RedHat Network), et aucune mise à jour n'a jamais été bloquée pour autant. En cas d'appel au support ils raleraient certainement. La seule chose importante j'imagine, c'est qu'en cas d'appel au support la machine soit enregistrée et à jour. Cela dépend aussi de ce qu'on met derrière RHEL ; chez moi, on ne prend pas de CentOS uniquement pour l'affichage, on peut raconter à nos décideurs qu'on a une boite contre laquelle se retourner en cas de pépin, et ça "fait pro" d'avoir du support, même si on ne s'en est jamais servi. Cas tout personnel bien entendu, ce n'est certainement pas pareil partout...
"Il serait intéressant de déterminer à partir de quand le coup de possession de Fedora est moindre que celui de RHEL + Paquets maison + contexte d'infogéreur (ah les complexités de système...)" => complètement ! Il faut aussi prendre en compte les compétences techniques en production cela dit ; chez nous, les dev ont leurs versions Windows et sont incapables de faire des rpm pour la plupart, et côté centre-serveur nous en sommes collectivement incapables aussi. Si l'on en fait, on reposera sur la compétence d'une personne unique ou deux, et vu le turn over, c'est un risque trop important de se retrouver avec des choses impossibles à maintenir. Donc c'est vite vu.