Bonjour
Je rebondis sur ce sujet... il n'est pas rare de trouver une image
Docker pour une application/service dont l'image de base n'a pas été
mise à jour. Désespérant. Et pour la "portabilité" on pourra repasser
(bref linux >= 5 amd64) mais les systèmes ARM vont se généraliser...
Personnellement, je me repose sur le flux d'annonce de vulnérabilité de
Debian, et c'est pour cela que j'insiste auprès de mes équipes pour
installer leurs dépendances applicatives (openjdk, postgresql...) sous
forme de package Debian, même quand le fournisseur d'un produit nous
fournit une image Docker. (j'ai en tête un exemple où les "known bugs"
du produit sont déclarés très en retard - genre après que nous avons
fait l'upgrade, alors je n'imagine pas ce qui doit en être des
vulnérabilités)
L'avantage d'une image Docker "pourrait être" (mais c'est rarement le
cas) que le système ne contient que le strict nécessaire au
service/application et donc limite la surface d'attaque. Ce qui est
toujours mieux qu'un site web déployé sur un Ubuntu avec serveur X.
Pour en revenir au Python, je proposerai une mixte des points suivants,
découvert pour la création de paquet DSM pour lequel la cross-
compilation des wheels et leur mise en package est "sportive"
https://github.com/SynoCommunity/spksrc/wiki/Using-wheels-to-distribute-Python-packages
- monter un venv et lister les versions exactes des dépendances qui
sortent de pip freeze
- installer les packages Debian disponibles pour les "requirements"
- refaire un venv pour confirmer que les versions Debian sont
compatibles avec les autres dépendances réclamées
- si ce n'est pas dans vos objectifs de compléter les paquets Debian
pour vos dépendances "manquantes", le venv avec les "requirements"
issus du "freeze" est reproductible mais en espérant que les
dépendances sont disponibles en binaire pour éviter d'installer une
chaîne de compilation complète en production
[ comme l'exige d'ailleurs la version "communautaire" de Docker
https://docs.docker.com/engine/install/debian/ à fuire, 1 GiB de disque
supplémentaire comparé au package Docker original de Debian "docker.io"
]
Et pour étendre le débat, Python est quand même au point concernant les
dépendances et le suivi des vulnérabilités, parce que les dernières
"nouveautés" comme le Go me semble encore loin derrière...
Exemple: la compilation de MinIO depuis les sources est effrayante, on
peut y voir passer des versions multiples d'une même dépendances,
j'imagine que le binaire résultant contient finalement plusieurs
versions des mêmes méthodes... allez suivre les vulnérabilités d'un
"monstre" pareil à la sortie. Mais oui, l'image Docker ne contient plus
qu'un seul gros binaire.
Bon week-end
Yves
On Fri, 2022-06-03 at 11:12 +0200, Jérôme Kieffer wrote:
> Salut Patrice,
>
> oui docker ou conda c'est le même probleme de taille de la sur-couche
> installée, mais j'ai l'impression que docker permet moins de savoir
> où
> on en est coté patchs de sécurité, peut être que c'est parce que je
> le
> maitrise moins que conda.
>
> Pour ce qui est de la portablilité, oui, on souhaite faire tourner du
> code prévu pour ubuntu sur des machines redhat ou centos, alors
> docker
> leur parait attrayant pour la portabilité (pas besoin de re-
> packager).
>
> Conda-forge, c'est tout fait sur des machines d'integration continue,
> "offerte" sur le cloud. C'est génial, mais niveau sécurité ... faut
> mieux passer son chemin.
>
> A++
>
> Jerome
>
> On Fri, 3 Jun 2022 09:12:12 +0200
> Patrice Karatchentzeff <patrice.karatchentzeff@???> wrote:
>
> > Salut Jérôme,
> >
> > Merci de ton retour.
> >
> > Je n'avais qu'une crainte, c'est qu'on me parle de docker : c'est
> > fait :)
> >
> > Pour moi, Docker va exactement dans le même sens que mes problèmes,
> > avec beaucoup plus de dépendances en plus !!! J'ai l'impression que
> > conda va dans le même sens...
> >
> > Pour la portabilité d'un paquet, tu parles de changer de distrib ou
> > de
> > version de distrb ? Parce que, de toute façon, ça passe par une
> > qualif
> > en pré-prod avant, donc pas un souci à ce stade. Je parle vraiment
> > de
> > pouvoir suivre la sécu de ce qui est installé en prod, sans « trop
> > se
> > prendre la tête » (c'est-à-dire, cas idéal, le rétroportage des
> > patches de sécu de l'équipe sécu de Debian).
> >
> > PK
> >
> > Le ven. 3 juin 2022 à 08:31, Jérôme Kieffer
> > <jerome.kieffer@???> a écrit :
> > >
> > > Salut,
> > >
> > > Je suis dev' python depuis 10 ans et l'ecosystem de packaging de
> > > python
> > > s'est grandement amélioré depuis... par contre c'est vrai que
> > > c'est
> > > redondant avec le packaging systeme et que cela reste une "moving
> > > target":
> > > par exemple avec la PEP517-518 qui déprécie l'usage de
> > > setuptools, tout
> > > notre systeme de compilation va s'effondrer d'ici à python 3.12
> > > et il
> > > va falloir tout refaire mais on a pas encore les outils pour le
> > > faire.
> > > Stressant un peu pour nous deroutant pour beaucoup: je comprends
> > > ton point de vue.
> > >
> > > 1. je suis tout a fait d'accord avec toi que le top pour une mise
> > > en
> > > prod' de code, c'est les paquets systeme (deb, rpm). Tu déploies
> > > et ca
> > > marche, par contre personne ne fait de paquets (troll inside). Un
> > > autre
> > > probleme c'est que les paquets ne sont pas portables d'une
> > > distrib à
> > > l'autre.
> > >
> > > 2. en tant que dev', je suis content de pouvoir avoir plusieurs
> > > environnement distincts pour tester, donc oui pip et venv,
> > > j'utilise
> > > tout le temps pour mon travail, mais je respecte mes utilisateurs
> > > en ne
> > > leur imposant pas "ma methode de travail".
> > >
> > > 3. la limite de pip et des venv se rencontre quand on veut
> > > plusieurs
> > > python installés (on supporte 3.6 - 3.10) ou alors qu'on veut
> > > changer
> > > les librairies systeme. C'est là qu'entre conda en jeu: des
> > > environnement virtuels mais version "lourd" 5G/environnement.
> > > Un point positif, il y a du packaging automatique dans conda-
> > > forge:
> > > j'ai taggué une release hier et ce matin, j'ai la PR de prete
> > > pour
> > > inclusion dans la distrib. Ca tombe bien, j'en ai besoin la
> > > semaine
> > > prochaine. Pas forcément possible avec Debian.
> > > https://github.com/conda-forge/fabio-feedstock/pull/44
> > >
> > > 4. Comme les sysadmin veulent avoir le même environnement sur les
> > > systemes centos, ubuntu et debian, il préfèreraient qu'on leur
> > > fournisse des image docker (ou singularity dans mon cas precis)
> > >
> > > En conclusion, tu avais un dilemme à 2 choix, maintenant tu en as
> > > 4. Désolé.
> > >
> > > Bon Trolldi
> > >
> > > Jérôme
> > >
> > > On Fri, 3 Jun 2022 07:38:06 +0200
> > > Patrice Karatchentzeff <patrice.karatchentzeff@???> wrote:
> > >
> > > > Salut,
> > > >
> > > > De plus en plus de projets sont gérés à base de pip (ou nm)
> > > > pour la
> > > > facilité que cela occasionne aux développeurs. Je comprends
> > > > parfaitement leur point de vue... Je ne cherche pas à
> > > > introduire un
> > > > débat sur l'éco-système ^Wbord^Wde mer^W de Python :)
> > > >
> > > > Cependant, d'un point de vue système, et donc déploiement en
> > > > prod,
> > > > c'est très largement discutable.
> > > >
> > > > Je n'ai pas trouvé de solution qui satisfasse les deux mondes.
> > > >
> > > > Est-ce que quelqu'un a une idée ou une expérience à partager ?
> > > >
> > > > Merci de vos retours,
> > > >
> > > > PK
> > > >
> > > > --
> > > > |\ _,,,---,,_ Patrice KARATCHENTZEFF
> > > > ZZZzz /,`.-'`' -. ;-;;,_
> > > > mailto:patrice.karatchentzeff@gmail.com
> > > > |,4- ) )-,_. ,\ ( `'-'
> > > > '---''(_/--' `-'\_)
> > > >
> > >
> >
> >
> > --
> > |\ _,,,---,,_ Patrice KARATCHENTZEFF
> > ZZZzz /,`.-'`' -. ;-;;,_
> > mailto:patrice.karatchentzeff@gmail.com
> > |,4- ) )-,_. ,\ ( `'-'
> > '---''(_/--' `-'\_)
> >
>
