Linux (debian) + Docker + Linux App <= Où est la colle ?

Bonjour,

Ça fait un bon moment que je cherche en vain ...


Si j'ai bien compris (à confirmer) l'avantage des conteneurs sur les VMs,
c'est qu'ils permettent l'économie de l'OS.

L'application dans le conteneur doit "voir" l'OS de l'hôte et donc pouvoir utiliser les services qu'il fournit (l'OS).

Or, jusqu'à présent (je débute) je ne trouve que des exemples / tutoriels dans lesquels réside un OS fut-il rudimentaire.

En suivant et en adaptant un peu le Tutoriel pour apprendre à utilisation Docker - VII-A-3. Créons une image de base
je suis parvenu à créer une image debian "FROM scratch",
c'est déjà une petite victoire ;-)

Mais nulle part je ne trouve ni l'info, ni exemples sur :

Comment construire une image pour isoler une application "native" du même OS ?

Voici un exemple concret :

Sur un hôte Debian + Env Graphique X11 :

Créer un conteneur (jetable) dans lequel est installé Firefox.

Le but étant la sécurisation de l'hôte, on pourrait peut-être envisager 2 approches :

1. l'hôte ne fournit pas les dépendances du navigateur

2. l'hôte fournit les dépendances qui peuvent (pour certaines) servir à d'autres applications

Selon le schéma suivant :

https://xataz.developpez.com/tutorie...es/image-1.png
(partie droite) :mrgreen:

http://pix.toile-libre.org/upload/img/1611341440.png

cela me semble la base même du concept de conteneur que de contenir un logiciel (sans OS)
et
pourtant je ne trouve rien sur le sujet,
ou
je passe à côté parce que j'ai une idée fausse sur la question. :koi:


Merci pour les pistes et suggestions de lecture.

Un conteneur utilise le noyau de l'hôte, pas forcément ces bibliothèques, binaires, etc. C'est pour ça que sous Docker tu a avoir un "OS" minimal dans le conteneur: en fait les fichiers de la structure Linux (/usr /lib /etc ). Le conteneur accède au noyau

Si tu connais la notion de chroot sous Linux. en chroot, le dossier dans lequel tu fais celui-ci est ta racine, tu ne vois pas les fichiers hors de celui-ci.

Avec la virtualisation, tu vas pouvoir faire tourner sur le même hôte un Linux et un Windows. Avec la conteneurisation, tu vas pouvoir faire tourner sur un hôte un conteneur basé sur Fedora, un autre sur Debian, un autre sur Alpine Linux : des distributions différentes mais utilisant le même noyau. Tout cela sur le même système de fichiers. Tu vas pouvoir aussi faire tourner un conteneur tout fait contenant une application.

L’intérêt n'est pas là, mais plutôt d'avoir un conteneur faisant tourner Apache/PHP, un autre faisant tourner MySQL, le conteneur Apache pouvant communiquer avec le conteneur MySQL, un autre conteneur avec un serveur FTP qui ne peut pas communiquer avec les autres. Tu pourrais le faire avec des VM mais ça te demanderait plus de ressources.

Autre avantage : Tu peux récupérer un conteneur contenant Apache, y intégrer MySQL pour générer un nouveau conteneur s’appuyant sur le premier. C'est géré en couches.
Avec les Dockerfile, tu vas créer un fichier de script qui va générer ton conteneur selon tes besoins. C'est plus souple que de cloner une VM.

Tu peux voir ça comme de la virtualisation plus légère (virtualisation d'applications/de services plutôt qu'un OS), mais sur le principe l'isolation est moindre qu'avec la virtualisation. Ca reste suffisamment étanche sinon ça n'aurait pas pris une telle ampleur.

Merci pour toutes ces précisions qui vont m'être bien utiles.


Mais j'ai encore du flou dans la définition du concept même qui sous-tend tout cela.

J'ai comme l'intuition (et quelques indices) qu'en fait le terme "conteneur"
est (mal) choisi pour des raisons plus "marketing" que basées sur l'essence même de l'objet.


SVP détrompez-moi,
ce qui me fais réagir maintenant est le terme "overlay" (surcouche)
que j'ai déjà rencontré (avec rootfs ...coïncidence... je ne pense pas ) dans des histoires de persistance pour des OS (images) embarqués.

J'ai donc l'impression et ça me semble assez logique, qu'en fait de conteneurs,
il s'agit plutôt de piles de calques (fs) ; les derniers venant surcharger les premiers.

Et que chaque pile/conteneur fait sa petite vie dans une dimension parallèle > son NameSpace


Dans cette logique (si elle est juste),
j'entrevoie la possibilité de créer un speudo-OS temporaire (en couche de fond)
(p.ex: linux-mini FROM scratch) identique à l'hôte
d'y ajouter une couche pour l'installation complète d'un logiciel
puis de supprimer la couche de fond pour ne conserver que ce qui est nécessaire au logiciel "containérisé"


C'est possible de faire cela ?

Je vais faire des tests, mais c'est toujours mieux de savoir d'avance s'il y a une chance de réussite ... ou pas

Merci.

Citation:

---

Et que chaque pile/conteneur fait sa petite vie dans une dimension parallèle > son NameSpace

---

C'est une image assez proche. Docker s'appuie sur les cgroups de Linux.

Par contre, pour la notion d'overlay .. Pour le contenu même de Docker au niveau fichiers ça peut être comparé à git. Tu as un projet de base, tu le modifie et quand tu fais un commit, tu créé une nouvelle "version", dépendante des anciennes, les anciennes versions restants accesibles.

Dans l'exemple que j'ai donné de partir sur une image avec Apache, avec laquelle on créée une nouvelle image avec MySQL, on pourrait créer une nouvelle image depuis l'image Apache avec PostGres, et une autre depuis l'image Apache/MySQL en y ajoutant Wordpress par exemple. Les images font leurs vies de façon indépendante mais sont un delta de l'image d'origine apache. Tu gardes la même base que tu peux décliner et tu économise de l'espace disque et tu peux réutiliser les mêmes images pour faire du déploiement. Tu peux aussi voir une image Docker comme un template. En général, tu vas exposer un ou plusieurs dossiers de l'hôte à un conteneur pour les données, ou un docker volume partagé ou non entre plusieurs conteneurs (tu peux voir ça comme une image disque).

Une précision,
lorsque j'écris :

Citation:

---

j'entrevoie la possibilité de créer un speudo-OS temporaire (en couche de fond)
(p.ex: linux-mini FROM scratch) identique à l'hôte
d'y ajouter une couche pour l'installation complète d'un logiciel
puis de supprimer la couche de fond pour ne conserver que ce qui est nécessaire au logiciel "containérisé"

---

Je pense à utiliser le système de gestion de paquets de l'OS natif (APT pour Debian)
donc en grande partie l'OS de base servirait à cela -> Installer les paquets nécessaires au conteneur.

------------------

Mon projet actuel est un moyen de sécuriser mon poste de travail Debian/XFCE en exécutant les applications sensibles,
notamment celles qui ont accès au réseau dans un environnement isolé et jetable.

Donc si j'ai besoin du navigateur => Créer un conteneur neuf avec le navigateur uniquement (c'est la 1ère étape)
à ce niveau je voudrais que les conteneurs soient les plus légers possibles.

En fait cette idée m'est venue après un test de Qubes-OS qui me paraît une bonne approche,
mais que je trouve trop lourde pour le matos que j'utilise.

Je précise cela, car je sens bien que l'usage principal de Docker n'est pas là,
mais sur les serveurs comme le montrent les exemples que tu me fournis.

Bien que tu puisse tout à fait entrer dans le conteneur et y exécuter une installation de paquet, on va plutôt utiliser un dockerfile qui est un script exécutant les actions pour préparer le conteneur.

Citation:

---

Mon projet actuel est un moyen de sécuriser mon poste de travail Debian/XFCE en exécutant les applications sensibles,
notamment celles qui ont accès au réseau dans un environnement isolé et jetable.

---

Docker n'est pas fait pour faire tourner des softs avec une interface graphique dans un conteneur.

Ce qu'il te faut c'est plutôt du sandboxing, comme Firejail.

Citation:

---

Docker n'est pas fait pour faire tourner des softs avec une interface graphique dans un conteneur.

Ce qu'il te faut c'est plutôt du sandboxing, comme Firejail.

---

Tu dois avoir raison.

Je ne regrette pas cette petite incursion dans l'univers des conteneurs,
cela m'a fait voir pas mal de choses et aussi me poser des questions bien constructives.

Je reviendrais vers Docker pour des applications côté serveur.

Je te remercie très sincèrement pour cet échange et ta patience.

Je te souhaite un bon WE.

@+