totof2000 a écrit 1856 commentaires

Pas quand tu as tes microservices qui sont sur des noeuds différents et que tu ne veux pas de communication en clair sur ton réseau Dans ce cas tu dois multiplier les serveurs en frontal. Le deuxième use case que j'ai vu, c'est mettre un nginx en sidecar dans un pod avec un microservice pour envoyer les logs vers un elasticsearch.

Il y a plein de raisons pour ne pas mettre de nginx en sidecar avec un microservice, mais il y a aussi des raisons de le faire dans certains contextes.

Certes c'est pas très rapide mais on peut facilement avec k8s en faire tourner plein.

Gros gaspillage de ressources …

Oui, donc une application un peu grosse, codée n'importe comment, c'est difficile à maintenir … Que ce soit en python ou dans n'importe quoi ça ne change rien.

C'est bien plus facile à faire en python que dans d'autres langages.

Notre cicd ne pardonne rien et on traque tout dans sonar.

Ca c'est une bonne idée.

Mais je pense que ça doit être le cas quel que soit le langage. Ce n'est en rien spécifique au python.

Vu le profil de beaucoup de personnes qui font du python (des gens qui ne sont pas devs mais qui se sont mis au dev parce qu'en python "c'est facile", je pense que c'est encore plus important de le faire en python (là ou je bosse, on a intégré il y a un an une appli python qui a été développée par un gars qui n'est pas dev : son appli a fait exploser les alertes sonar - c'est moins souvent le cas avec d'autres langages ou le niveau des développeurs est mailleur, même s'il y a parfois de mauvaises surprises).

Python c'est bien, c'est simple, ça fait tout.

Ouais bof … comme beaucoup de trucs qui font tout, ça fait baucoup de choses mal.

le but n'est pas, bien sur de vider les tiroirs pour le transport :). Je souhaiterais pouvoir juste les regrouper par 2/3ou 4 pour pouvoir les caser dans le camion.

Lors du précédent déménagement j'avais mis ces tiroirs dans des cartons, mais le format de ceux(-ci est tel que je n'aui pas pu optimiser le remplissage : j'ai mis des trucs pas cohérents dans les cartons, et après, pour déballer c'est un peu compliqué de s'y retrouver. Mais j'avais du faire les choses à la rache. La j'ai un peu de temps pour m'y préparer, du coup j'essaie d'éviter les erreurs précédentes.
( pour infos, mes blocs de tiroirs c'est ça : https://www.leboncoin.fr/ad/ameublement/2002452957 )

Effectivement, maintenant que tu le dis … je me souviens avoir un carton de bananes à la cave ou sont emball"s des composants de modelisme ferroviaire : cc'est vrai que c'est très solide … Il me reste à trouver un endroit ou je pourrai m'en procurer.

Pourquoi tu ne scotches pas tes tiroirs pour ne pas avoir à les vider ?

pour plusieurs raisons :
- le scotch est difficile à enlever après
- certains composants (résistances, vis) passent quand même.
- les boites telles quelles dans le fourgon de déménagement risquent de souffrir. J'aimerais les protéger une peu
- j'ai envie de les regrouper par 2, 3 ou 4 pour raison pratique.

Il y a vraiment de toutes les tailles et c'est gratuit.

Le problème de toutes les tailles c'est de trouver des tailles cohérentes. Mais j'essaierai d'aller voir quand même on ne sait jamais …

Bon, maintenant ça suffit. Cessez de faire les pythres.

Je ne sais pas comment. J'ai positionné la police par défaut a serif, et c'est mieux …

pythié, non !!!

J'aurais écrit pythoyable dans ce contexte :)

What !? Ce n'est pas du tout une contrainte docker et je ne comprends même pas le besoin.

*Le besoin de porter les certificats par exemple ? Ca se fait beaucoup quand tu déploies un microservice accessible en HTTPS.

Je suis curieux de comment ils gèrent ces cas. systemd leur suffit ? Ils déploient beaucoup de services mais une seule machine ?

Il est parfois plus judicieux d'avoir un service sur une VM et de multiplier les VMs plutôt que d'avoir une VM avec plein de docker dessus, et utiliser Ansible et/ou terraform pour l'instanciation. Ca ne veut pas dire qu'il faut le faire partout et tout le temps, mais de mon point de vue, mettre d u docker systématiquement ne sert pas forcément à grand chose. Exemple : pour les serveurs de base de données, avoir une surcouche docker n'apporte pas forcément grand chose. Et mettre de la base de données style postgres dans un K8S pour de la prod, c'est pas forcément la meilleure chose à faire : pour une petite base "technique" qui stocke des données de configuration d'un produit par exeple, ça peut le faire, mais pour des données applicatives j'ai beaucop de doutes sur la pertinence.

Mais on a eu la même chose avec les machines virtualles : à l'époque ou je faisais du hadoop, avant l'arrivée de Spark, il y a des gens qui avaient proposé de remplacer la quinzaine de serveurs bare-metal par une bonne centaine de VMS ….

Merci pour le lien : Cet article explique bien plus précisément ce que je voulais dire dans mon commentaire. Je partage à 100% le constat. Après ça ne veut pas dire que Docker ou les orchestrateurs sont une mauvaise chose, il faut juste éviter de le faire pouyr tout et n'importe quoi (un peu comme on mettait du XML partout à une époque même là ou ça n'était pas approprié).

L'utilisation de docker prendra plus de place disque car tu auras besoin de dupliquer un tas de truc dans tes images qui sont traditionellement partagés. Après certains font leurs images comme des gorets et ne se posent pas de question sur la taille de leurs images. Après en terme de ressources cpu/ram, je ne pense pas que Docker fasse utiliser plus de ressources que ça : il ne faut pas oublier que Docker, et la conteneurisation en général, c'est surtout du chroot amélioré. Le service de gestion docker ne doit pas prendre tant de ressources que ça. Eventuellement tu prendras plus de ressources si pour chaque service qui tourne sur ton host, tu instancies le processus qui va fournir le service + d'autres processus en side-car (supervision, gestion des logs) plutôt que d'en avoir un seul qui centralise tout sur ta machine.

Je ne suis pas fan de docker (enfin … pas fan de 100% docker, ni de la façon dont c'est utilisé - ça complique les choses dans beaucoup de cas pour un gain faible ), mais il faut rester objectif : côté ressources, mis à part l'espace disque, quand on fait les chsoses correctement, c'est pas là qu'on peut faire des reproches à Docker.

Note : en pratique, quand je peux, je lui préfère podman.

C'est pour ça que je l'appelle le "visual Basic" du libre. Certains trouvent ça un peu dénigrant mais sur le fond, le BASIC c'était un peu lamême chose à l'époque : un langage simple permettant d'apprendre à programmer.

Comme je disais plus haut, cette façon de faire te permet de t'affranchir de l'environnement d'installation : tu peux autant l'installer sur une VM, un conteneur docker, un virtualenv, ou n'importe quoi via un pip install (jango par exemple, ou ansible s'installent ainsi), en plus d'être cohérent avec les méthodes de packaging de ton environnement/framework de développement.

Je n'ai jamais vu quelqu'un copier les dépendances comme ça, je ne suis pas sûr que ce soit une excellente idée

Moi je le vois tous les jours … et je suis convaincu que c'est une très mauvaise idée.

Mais utiliser pip a l'intérieur d'un container docker, c'est un peu absurdement compliqué alors qu'on a juste besoin de copier des fichiers.

C'est là ou je ne suis pas d'accord : l'avantage de créer un package pip, c'est de rendre completement indépendant l'outil du mode de déploiement: que tu l'installes sur une vM, sur un serveur bare metal, dans une image docker, dans un virtualenv, ou n'importe ou, l'installation se résume à un pip install. Et dire que c'est compliqué je n'y crois pas trop (ou alors c'est que Python est encore plus pourri que je ne le pensais) : certes tu prends un peu de temps au début pour initialiser la créaton du package, mais ensuite tu mets ça en chaine de CI et on n'en parle quasiment plus.

Et pourqui ne sert-elle à rien ?

Vu mes expériences avec Python ces 15 dernières années, je ne peux qu'être d'accord avec l'article (et bien sûr en désaccord avec toi).

Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus.

Est-ce à cause du langage et du runtime python ? En partie je pense. Mais je pense aussi que le problème de python,c'est que la plupart de ceux qui en font ne sont pas formés à ça et se retrouvent à développer du code pourri, qui certes a lair de fonctionner, mais qui est difficile à maintenir ou se trouve lent à l'exécution parce que les gens qui ont développés ne se sont pas posés de questions.

J'ai vu ce genre de choses à chaque fois que j'ai du intervenir sur du code python. Des gros bloats avec des fonctions de plusieurs pages, avec du code sans cohérence (un bout de code pour faire un truc, suivi d'un bout de code pour faire autre chose, suivi d"'un autre bou de code pour continuer à faire ce qui avait été commencé précédemment, …). Puis bien sûr comme il n'y a pas de tests unitaires, c'est la galère pour tout reprendre …

Je ne parle pas des problèmes de dépendances, car l'article en a parlé (c'est d'ailleurs 90% des problèmes que je rencontre lorsque je veux installer un truc développé en python, mais on a parfois les mêmes soucis avec Ruby et ses gems).

Dernier détail : est-ce si difficile que ça de faire du packaging en python ? Parce que dernièrement je discutais d'un truc avec un dev : comme beaucoup de devs aujourd'hui, quand il package une appli, il la package dans une image docker, et moi ça me gène. En effet, l'appli devrait être, de mon point de vue, empaqueté dans un paquet python, avant d'être installée dans l'image via pip ( comme une appli Java est empaqueté dans un fichier Jar par exemple… mais il me dit que c'est se générer beaucoup de travail et des complexités pour rien. Pour beaucoup de langages modernes que je connais (Rust, Go, Java par exemple), c'est pas si compliqué que ça. En Ruby c'est un peu plus compliqué mais pas impossible. Et pour d'autres langages tels que C, on a des outils qui permettent de le faire facilement (dans l'absolu je pense qu'on pourrait même utiliser Maven pour faire un tgz, mais les outils de build couramment utilisés doivent permettre de le faire).

Pour moi les réelles applications de prises de notes sont les applications de style "post-it".

Alors, oui, à force on risque de s'y perdre mais pas plus que le truc qu'on a écrit dans un carnet il y a six mois et dont on ne se souvient plus ….

Il me faudrait ce genre d'appli mais sous Linux/xBSD/Androïd avec possibilité de synchro des notes.

Ouch !!! Le prix, ça pique !!!

Un adaptateur USB Ethernet coute moins de 10 euros et un cable ethernet rj45 de 50 cm coute moins de 5 euros. Ca fait presque moitié moins cher pour la solution ethernet.

Ce que tu dis ne fait que confirmer ce que je pense : un gros projet relativement récent, qui est toujours vivan et développé activement aura tout intérêt à ne pas être réécrit. Un vieux code qui n'est plus maintenu, écrit malproprement vaudra peut-être le coup d'être réécrit (on peut aussi vouloir changer la façon de faire comme par exemple le passage vers devfs puis vers udev, ou le passage de gnome2 à gnome3 qui a été une grosse rupture).

Lumineux, devoir, pour protéger les données, isoler une machine parce qu'elle est sous Windows, magnifique. Bel aveu.

Euh, attends : c'est valable tant pour les OS libres que les OS non libres : parce que même libre, les OS peuvent être distribués par des sociétés, ou des organisations étrangères. Et même si ce n'est pas le cas, libre ou non libre, une faille de sécurité peut compromettre ton SI et faire fuiter des données sensibles.

Certaines sociétés avec données sensibles (défense,etc …) ont es réseaux bien séparés non connectés sur internet. Et ça n'a rien à voir avec les logiciels libres. C'est aussi un moyen de se préserver de la fuite de données par acte de malveillance interne (un peu comme la fuite de données chez Free il y a quelques mois par exemple).

La question si j'ai bien compris, est de patcher le C/C++ pour qu'il puisse gérer la mémoire de manière pluis sûre, parce que ce serait moins compliqué d'adapter le code existant à une nouvelle gestion mémoire que tout réécrire en rust … Ca se défend, mais je ne suis pas convaincu : ça dépendra surtout je pense de la façon dont le code a été écrit initialement. Pour du code écrit relativement récemment avec un respect de bonnes pratiques de dev, je pense que ça se tient. Pour du code plus ancien, je ne suis pas sûr que l'on y perde beaucoup à tout réécrire. Je pense que c'est du cas par cas.

Sinon je réagis à ceci :

With subsets it is too easy to create an unsafe hole where memory usage goes unchecked in what is supposedly memory safe code. Rust is not immune, is also vulnerable. Rust programs may open a hole using the Rust 'unsafe' keyword, and widely do so to access notoriously unsafe C pointers."

Je pense que même les plus fervents défenseurs de Rust n'ont jamais prétendu que Rust était invulnérable. Par contre le fait que du code potentielement vulnérable soit dans des blcs "unsafe" spécifiquements déclarés permet de bien localiser ce code. En ne limitant les blocs unsafe qu'au strict nécessaire, on évite des erreurs d'inattention dans tout le reste du code.

Je n'ai pas compris en détail les solutions memory save envisagées pour C++ (j'ai laché le C++ depuis (trop) longtemps). Si quelqu'un pouvait expliquer ici les principes je lui serais très reconnaissant.

Pas dans le cas ou tu mets un lien avec de la "valeur ajoutée" (commentaire, questions, contextualisation, etc …).