totof2000 a écrit 1788 commentaires

Je me suis posé la question, mais quand je vois le nombre de liens de propagande politique orientée ici même, je me suis dit que je pouvais quand même poster. On reste dans le sujet global de Linuxfr, et l'article en soi est intéressant.

Avoir un outil qui les vérifie globalement c'est un peu compliqué. Il faut être vigilant je pense sur tous les trucs qui peuvent exécuter des actions : je pense aux documents de bureautique avec macros ( word, excel, access, powerpoint, libreoffice, etc …), potentiellement les documents postscripts et pdf. Le seul outil je pense qui puisse scanner tout ça devrait être un bon antivirus. Mais pour les autres documents je ne vois pas comment faire pour détecter la corruption de ceux-ci.

Et pour les gens qui sont allergiques au mot « syndicat », il y a aussi le code d'éthique de l'ACM.

Pour ma part je ne suis pas allergique au mot "syndicat" mais je suis allergique à ce que sont devenus les syndicats en France aujourd'hui (tout comme je ne suis pas allergique à la gauche, mais à ce qu'est la gauche aujourd'hui en France). Mais bon, je ne sais pas si c'est le lieu ou le moment pour débattre du sujet.

Allez poster ça sur des sites spécialisés. J'essaie de m'éloigner ces temps-ci de toutes ces polémiques à la c**, et les retrouver ici commence sérieusement à me gaver.

Bien souvent ce ne sont pas les admins qui mettent un nginx, mais les architectes ou les devs ( dans un contexte devops …).

Ça vaut VRAIMENT le coût d’aller voir des services mesh ou de simplement installer un vpn quand tu as ce genre de contraintes.

Je ne dis pas le contraire, mais dans certains cas la mise en place du service mesh est tellement complexe (parce qu'il faut commencer à expliquer ce que c'est, ce que ça fait, etc …) que mettre un nginx est bien plus pratique (en tout cas dans l'immédiat).

installer un vpn

Euh … pas sûr que mettre en place un VPN entre conteneurs soit plus simple que de mettre en place un nginx pour communication https. Mais bon, j'ai fait le même constat que toi : on parle de UUOC lorsqu'on fait du shell, et j'ai l'impression qu'on a souvent un UUON (Useless Use of NGINX) lorsqu'on met en place du docker …

Les cartons de vins, ça dépend lesquels : j'en ai déjà eu, ils ont eu tendance à se déformer. Mais je vais voir ce que kje peux trouver de ce côté.

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 ?