Non, car ça n’a pas de sens, un conteneur contient un environnement d’exécution, donc ce n’est pas une bibliothèque qu’on conteneurise mais éventuellement les programmes qui l’utilisent. Si veux conteneuriser, à coût nul, un seul programme, LXC le permet (« lxc-execute »). Si tu veux pseudo-virtualiser tout le système, tu peux avec LXC (« lxc-start ») ou Docker.
Ah, des explications claires, merci.
Après je me suis mal exprimé en parlant de "bibliothèques" conteneurisées. Je veux bien sûr parler d'un programme qui doit pouvoir tourner avec ses dépendances en mode "container".
Or dans mes essais, ce n'est pas le cas. J'ai un programme sous Docker qui télécharge toutes ses dépendances, ce qui explique ces 2,6 Go d'occupation disque. OK, les programmeurs n'ont rien optimisé sans doute, mais quand ils s'expliquent, il y a de quoi se poser des questions...
Je n'ai absolument rien contre LXC (c'est une évolution quasi obligatoire, et c'est tant mieux pour toutes les raisons évoquées), mais la manière dont c'est exploité...
[^] # Re: Docker...
Posté par AlexTérieur . En réponse au journal L'Écosystème containeurs. Évalué à 1.
Ah, des explications claires, merci.
Après je me suis mal exprimé en parlant de "bibliothèques" conteneurisées. Je veux bien sûr parler d'un programme qui doit pouvoir tourner avec ses dépendances en mode "container".
Or dans mes essais, ce n'est pas le cas. J'ai un programme sous Docker qui télécharge toutes ses dépendances, ce qui explique ces 2,6 Go d'occupation disque. OK, les programmeurs n'ont rien optimisé sans doute, mais quand ils s'expliquent, il y a de quoi se poser des questions...
Je n'ai absolument rien contre LXC (c'est une évolution quasi obligatoire, et c'est tant mieux pour toutes les raisons évoquées), mais la manière dont c'est exploité...