Discussion :

[Neckara]

Bonjour,

J'ai actuellement :

• un gros ordinateur fixe capable de lancer plusieurs machines virtuelles ;
• un raspberry-pi tournant h24 servant à de l'affichage ;
• un ordinateur portable ;
• un serveur auto-hébergé servant aussi pour de la sauvegarde.

Pour le moment, je séparer mes différents services sur le serveur avec LXC, mais ce n'est pas très pratique pour les sauvegardes et la portabilité.
Je pensais donc les migrer sur dans des containers Dockers que je pourrais bidouiller au sein d'une machine virtuelle sur mon ordinateur personnel avant de les pousser sur le serveur.

Pour mon fixe et portable, le problème, est que j'ai besoin grossièrement des même logiciels/configurations ainsi que des même données.
Le problème est donc de séparer les données des configurations. Donc je peux stocker mes données dans un volume /data et les synchroniser via le serveur via Seafile puis faire de la sauvegarde incrémentale (?).
Le problème reste donc pour enregistrer la configuration et la rétablir en cas de problème sur un ordinateur (ex. disque-dur qui crash, ordinateur portable volé/qui meurt, …). Pour cela, j'ai l'impression qu'il existe des chose comme "puppet" et "chef", mais je n'ai pas tout à fait compris leur fonctionnement.

De plus, je me demande aussi s'il n'est pas possible de pouvoir administrer sommairement le serveur autrement que de s'y connecter en ssh, en ayant une sorte de tableau de bord en somme. De même pour administrer mon portable et/ou mon raspberry à distance à partir du fixe.

Après, j'ai aussi des ensembles d'applications, par exemple j'ai besoin d'un environnement de développement. Pour cela je peux peut-être utiliser une VM afin de garder un environnement "propre" et distribuable ? Mais une VM me parait lourd et assez limité. J'utilise VirtualBox et ne peux sortir mes fenêtre de l'écran où j'ai lancé la VM, ce qui est dommage si j'utilise plusieurs écrans. D'un autre côté, il ne me semble pas que je puisse utiliser Dockers dans ce cas de figure.


Je trouve beaucoup de tutoriels techniques sur Dockers sur internet mais ils restent un peu au niveau du "Hello World" et n'en dise pas beaucoup sur les bonnes pratiques, sur la philosophie qu'il y a derrière.
J'ai donc des ressources pour voir comment on l'utilise au sens technique, mais pas comment on l'utilise au sens outil. C'est comme si on me donnait un marteau, qu'on me disait comment taper avec, mais que je ne trouve rien quant à la manière de positionner le tableau sur le mur, quels types de tableaux je peux clouer, etc.


Auriez-vous donc quelques conseils ou quelques outils à me conseiller ?

[Neckara]

Donc si je comprend bien, pour Dockers :

• on construit une image à partir d'un "Dockerfile" qui décrit les actions à effectuer pour créer cette image ( http://doc.ubuntu-fr.org/docker#importexport ), ce qui est très léger et facilement plaçable dans un dépôt git : https://docs.docker.com/engine/artic...est-practices/
• on peut ouvrir un shell dans l'image et y enregistrer les modifications avec git. => Est-ce que les actions modifient le Dockerfile ?
• import /export font une bête archive des fichiers de l'image => Pourquoi ne tout simplement pas utiliser le Dockerfile pour importer/exporter des container ?
• pour une mise à jour, que fait-on ? On utilise git ou on détruit et reconstruit le container ? J'ai l'impression qu'on conseil l'utilisation de git, ce qui évite de reconstruire l'image en permanence.
• pour les logs /fichiers, il peut monter un répertoire de l'hôte, qu'on peut ensuite sauvegarder régulièrement ou créer un container dédié aux données : http://docs.docker.com/v1.8/userguide/dockervolumes/

On ne peut normalement ne lancer qu'un seul processus, mais il est possible de le contourner avec Supervisor : http://docs.docker.com/engine/articl...g_supervisord/

Quelle image de base pour mes containers ?

• Busybox ? ~4Mb https://hub.docker.com/_/busybox/
• Debian Jessie ?
• Un Debian minimaliste ?

Quelle image pour le système hôte dont le seul but sera de faire tourner des containers et fournir divers outils d'administrations (ex. ssh) ?

• Un Debian Jessie ?
• Un système minimaliste au possible ?

Sachant qu'on peut aussi lancer un container en mode graphique : http://www.rpresle.totoandco.eu/logi...cker-haroopad/
Donc au lieu d'utiliser une VM, je pourrais utiliser un container contenant tous mes outils de builds.

Mais serait-il délirant qu'au lieu d'utiliser directement l'OS installé sur l'ordinateur portables, le fixe ou le raspberry, d'y installer une distribution minimaliste et d'y lancer dessus un (ou plusieurs) container en mode graphique qui contiendra tous mes logiciels comme client de mails, etc. ? Ou est-ce que je commence à délirer un peu?

[chrtophe]

Je commencerais par docker vs virtualisation :

Docker c'est du cloisonnement, ça sert à faire tourner une application cloisonné. C'est une évolution des softs tels que openvz ou lxc, ou un peu comme du chroot évolué:
https://fr.wikipedia.org/wiki/OpenVZ
https://fr.wikipedia.org/wiki/LXC

Les instances docker utilisent le même noyau Linux.

Avec la virtualisation, toutes les machines sont autonomes, tu peux avoir un Linux tournant en même temps qu'un Windows sur le même hôte, c'est plus lourd mais complètement isolé. Le disque dur d'une VM est un fichier image stocké sur l'hôte.
Sur système non linux, docker tourne dans une VM Linux.

Les deux ont leurs avantages et inconvénients.

Si tu as besoin d'interface graphique, à mon avis il vaut mieux une VM. Tu crée une image de base que tu exporte, puis tu les importe pour les modifier. Avec Virtualbox, tu peux créer des clones liés à une image de base, en gros ta VM liée est un delta de la VM principale.

J'ai utilisé openvz, Au niveau fichier, ton container correspond à un dossier qui est accessible hors de celui-ci et qui correspond à un équivalent chroot. Je ne pense pas que tu puisses accéder au contenu d'un container docker aussi simplement.

Au niveau de Docker, je n’utilise pas mais de ce que j'en ai compris, l'instance que tu récupères est un script qui indique comment construire le container (un peu comme une appliance en virtualisation). Une fois celui-ci créé, tu peux sauvegarder son contenu dans une image avec une commande. Tu peux modifier le script de création pour faire ta propre "appliance").

[Neckara]

Merci pour ta réponse.

Si tu as besoin d'interface graphique, à mon avis il vaut mieux une VM. Tu crée une image de base que tu exporte, puis tu les importe pour les modifier. Avec Virtualbox, tu peux créer des clones liés à une image de base, en gros ta VM liée est un delta de la VM principale.

Pourquoi vaut-il mieux une VM qu'un container ?

Sinon, je viens de réussir à utiliser une VM VirtualBox sur plusieurs écrans en intégré, je suis plutôt content.
Clic-droit sur la VM -> Configuration -> Affichage -> Nombre d'écran = 2.
Reste plus qu'à configurer les écrans avec un logiciel comme arandr.

Pour plus de transparence, je peux lancer la VM au démarrage et enlever la connexion au boot (et supprimer la veille ).
Après, je sais que lancer une application dans une VM sera moins efficace (30% ?) que s'il était lancé en natif. Mais quid du coût / consommation passive ?
Sans réellement utiliser la VM lancée, je n'ai pas l'impression que cela consomme beaucoup.

Serait-il acceptable de mettre toutes mes applications dans une VM ? Comment ensuite partager ces VMs entre mon fixe et mon portable ?
Il faudrait séparer les fichiers de la configuration. Pour les fichiers, c'est assez simple avec VirtualBox, il suffit ensuite de synchroniser avec Seafile.
En revanche, pour mettre à jour la configuration ex. ajouter/supprimer un logiciel, j'ai un peu peur des conflits et je ne vois pas trop comment faire sans remplacer le disque virtuel de VirtualBox. De plus, c'est une chose que je ne peux pas faire à chaud et difficilement le faire de manière automatique.

Je ne pense pas que tu puisses accéder au contenu d'un container docker aussi simplement.

C'est une des deux solutions, sinon, il suffit de monter un dossier du système hôte dans le container invité.



Sachant aussi que pour ce qui est du raspberry pi, une VM me semble un peu trop lourde pour tourner dessus. Un container serait peut-être plus adapté ?

[chrtophe]

Pourquoi vaut-il mieux une VM qu'un container ?

Je ne dirais pas ça, je dirais que selon la situation, l'un est mieux adapté que l'autre.

Serait-il acceptable de mettre toutes mes applications dans une VM ? Comment ensuite partager ces VMs entre mon fixe et mon portable ?

Si tu veux la même machine sur les 2 postes (avec conf différente éventuellement), tu crée ta VM sur l'un des postes et l'importe exporte sur l'autre.Tu peux aussi créer une VM pour le dev, une autre pour la bureautique, avec en idée générale qu'elles ne seront pas utilisées en même temps.

Après, je sais que lancer une application dans une VM sera moins efficace (30% ?) que s'il était lancé en natif. Mais quid du coût / consommation passive ?

30% c'est peut être exagéré, quand tu démarres une VM qui as 2 Go de RAM affecté, ces 2 Go ne sont plus dispo pour l'hôte même si non entièrement exploité par la VM. Idem pour les coeurs, donc si ton hôte bosses, il aura moins de ressources pour le faire. Pour la conso passive, tant que tu ne démarres pas l'hyperviseur, la seule conso utilisée est l'espace disque occupé par les VM.

Sachant aussi que pour ce qui est du raspberry pi, une VM me semble un peu trop lourde pour tourner dessus. Un container serait peut-être plus adapté ?

oui et tu n’auras pas le choix, le CPU ARM équipant celui-ci ne comportez pas de fonctions de virtualisation.

[Neckara]

tu crée ta VM sur l'un des postes et l'importe exporte sur l'autre

Le problème, c'est la synchronisation par la suite des VMs.
Si j'ajoute un IDE dans ma VM de dev du fixe, il faudra que je répercute cela sur la VM du portable et inversement.

quand tu démarres une VM qui as 2 Go de RAM affecté, ces 2 Go ne sont plus dispo pour l'hôte même si non entièrement exploité par la VM. Idem pour les coeurs, donc si ton hôte bosses, il aura moins de ressources pour le faire.

Ah... c'est un véritable problème ça.

Pour la RAM, il me suffit d'en acheter un peu plus, mais pour les cœurs CPU ou la mémoire GPU, cela peut très vite devenir limitant (ou très cher ), et je ne parle que du fixe.
Donc il me faudrait vraiment allumer et éteindre mes VMs selon mes besoins. Et donc créer une interface discrète permettant de lancer/arrêter les VMs et de voir celles qui sont lancées.

Après, je ne sais pas combien de VMs je pourrais lancer à la fois, ni combien de VMs je vais avoir au final.

• Windows "test projets"
• Debian "test projets"
• Environnement de dev Windows 1
• Environnement de dev Debian 1
• Virtualisation de mon serveur pour des tests/configurations avant de pousser sur le vrai serveur
• Bureautique
• ... ?

Le tout serait donc de savoir comment découper tout cela sans aller trop loin ni trop peu dans le découpage.
Sachant que certaines auront plus de chances d'être exécutées en même temps que d'autres.

Dockers me semble avoir au moins l'avantage d'éviter cette problématique. Même si je me doute que se sera plus compliqué de lancer une barre en mode graphique. Sachant que je ne pourrais pas me passer de VM pour lancer Windows par exemple.
Bon, je peux toujours utiliser une VM dans un premier temps puis migrer si j'ai des problèmes.

[chrtophe]

Le problème, c'est la synchronisation par la suite des VMs.
Si j'ajoute un IDE dans ma VM de dev du fixe, il faudra que je répercute cela sur la VM du portable et inversement.

Oui mais après une config d’environnement de dev ne bouge pas tous les jours.

Donc il me faudrait vraiment allumer et éteindre mes VMs selon mes besoins. Et donc créer une interface discrète permettant de lancer/arrêter les VMs et de voir celles qui sont lancées.

Démarrer ou arrêter une VM en ligne de commande, ça ne pose pas de probs. Mieux, tu les suspend, ça comme une mise en veille prolongée.

Windows "test projets"
Debian "test projets"
Environnement de dev Windows 1
Environnement de dev Debian 1
Virtualisation de mon serveur pour des tests/configurations avant de pousser sur le vrai serveur
Bureautique

Je ferais ceci :

VM environnement dev Windows
VM environnement dev Linux
VM clone liée environnement dev Windows pour test
VM clone liée environnement dev Linux pour test
VM bureautique voire bureautique directement dans l’hôte (selon fréquence utilisation et environnement principal linux/Windows)
VM serveur

Dockers me semble avoir au moins l'avantage d'éviter cette problématique. Même si je me doute que se sera plus compliqué de lancer une barre en mode graphique. Sachant que je ne pourrais pas me passer de VM pour lancer Windows par exemple.

Rien ne t’empêche d'utiliser les deux technologies. En théorie l'un ne doit pas gêner l'autre en fonctionnement simultané, je ne pense pas que Docker utilise les fonctions de virtualisation CPU. Méfiance quand même.

[Neckara]

Démarrer ou arrêter une VM en ligne de commande, ça ne pose pas de probs. Mieux, tu les suspend, ça comme une mise en veille prolongée.

Ouais, mais va falloir que je me fasse des scripts shells avec une petite interface graphique. C'est pas long, mais faut quand même le faire .


Après, c'est toujours l'histoire du cordonnier mal chaussé, va falloir que je me trouve un peu de temps pour tout faire correctement.
Cela fait plusieurs mois que mon serveur seafile est down et que j'ai la flemme de le relancer , faut que je m'écrive des outils pour gérer tout ça sans devoir à chaque fois me connecter en ssh, devenir root, rentrer dans le LXC, devenir root, exécuter quelques scripts, lancer le service. Un peu fatiguant à la longue.