Dans un container, en faisant df ou htop, tu vois la charge de l'hôte, pas celle de ton container.
Pour df, effectivement tu vois les partitions de l'hôte.
Toutefois, je viens de lancer un htop, et je n'ai que les process de mon conteneur. Bon, dans le doute j'ai aussi lancé top, même résultat : aucun process host.
Par contre effectivement, le load est le même si tu parles de ça (à vrai dire je n'avais jamais remarqué ce "problème").
N'étant pas sur Ubuntu et utilisant LXC en première version, je ne saurai dire si ça évolue selon l'OS et/ou la version.
Le root du container est aussi root sur l'hôte
À ma connaissance c'est toujours d'actualité et un problème classique des conteneurs (Docker a le même) : si tu arrives à sortir du conteneur, tu seras l'utilisateur qui l'a lancé.
Docker est toujours en root, pour un truc de plus en plus utilisé en production j'ai toujours trouvé ça moyen (je l'utilise très régulièrement mais si j'avais le choix, je tenterai de regarder ce qu'il se passe ailleurs). Après, peut-être que les développeurs n'ont pas trouvé la manière propre de faire des Docker unprivileged ?
LXC peut effectivement être utilisé en unprivileged (ce que je fais tout le temps), toutefois cela signifie qu'en arrivant à sortir du conteneur et que l'utilisateur qui a lancé le conteneur a beaucoup de droits (ou pire : peut utiliser des commandes sudo sans mot de passe), on retombe un peu dans un problème similaire (mais normalement moindre).
Le réseau bridgé sous Linux c'est chiant, tu peux pas juste démarrer ton container en lui disant "met toi en bridge", non il faut monter un pont avec brctl, puis déplacer l'IP de ton serveur dessus (elle peut pas rester sur eth0)
A vérifier mais pas sûr qu'on puisse manipuler les interfaces réseau et le pare-feu depuis un container LXC
J'aimerai pouvoir te répondre ... Mais là je vais juste spéculer : je pense que tu peux créer des interfaces et gérer un pare-feu interne au conteneur en question.
Tu éveilles ma curiosité. Peut-être que cet article donne quelques pistes malgré son âge.
A une époque les images de distributions Linux dans LXC avaient un OpenSSH déjà configuré et démarré
Là encore, les conteneurs unprivileged te forcent à utiliser un template téléchargé et il semble que le serveur SSH ne soit pas toujours installé par défaut (dans le cas d'un template Debian 9 amd64, je n'ai pas de serveur SSH).
Toutefois en lisant le template lxc-debian fourni pour créer des privileged, il semblerait que le paquet openssh-server soit installé pour cette même distro (petite déception je dois avouer ...).
Après Docker c'est vraiment pas le même usage selon moi, c'est fait de pour de l'applicatif pur.
Je plussoies largement. D'ailleurs les concepteurs n'ont jamais caché que Docker est normalement prévu pour faire tourner une application par conteneur.
Je n'ai jamais vu de VPS basés sur Docker jusque là (plus du OpenVZ et du KVM), ça existe vraiment ? Décidément, il y aura toujours des personnes pour enfoncer des vis avec un marteau ...
[^] # Re: Encore une rupture
Posté par smumu . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 2.
Pour df, effectivement tu vois les partitions de l'hôte.
Toutefois, je viens de lancer un htop, et je n'ai que les process de mon conteneur. Bon, dans le doute j'ai aussi lancé top, même résultat : aucun process host.
Par contre effectivement, le load est le même si tu parles de ça (à vrai dire je n'avais jamais remarqué ce "problème").
N'étant pas sur Ubuntu et utilisant LXC en première version, je ne saurai dire si ça évolue selon l'OS et/ou la version.
À ma connaissance c'est toujours d'actualité et un problème classique des conteneurs (Docker a le même) : si tu arrives à sortir du conteneur, tu seras l'utilisateur qui l'a lancé.
Docker est toujours en root, pour un truc de plus en plus utilisé en production j'ai toujours trouvé ça moyen (je l'utilise très régulièrement mais si j'avais le choix, je tenterai de regarder ce qu'il se passe ailleurs). Après, peut-être que les développeurs n'ont pas trouvé la manière propre de faire des Docker unprivileged ?
LXC peut effectivement être utilisé en unprivileged (ce que je fais tout le temps), toutefois cela signifie qu'en arrivant à sortir du conteneur et que l'utilisateur qui a lancé le conteneur a beaucoup de droits (ou pire : peut utiliser des commandes sudo sans mot de passe), on retombe un peu dans un problème similaire (mais normalement moindre).
J'utilise lxc-usernet comme indiqué dans le wiki Debian pour les conteneurs unprivileged et ça m'a paru assez simple.
Après je ne sais pas ce que ça donne en privileged, si quelqu'un a testé je suis preneur !
J'aimerai pouvoir te répondre ... Mais là je vais juste spéculer : je pense que tu peux créer des interfaces et gérer un pare-feu interne au conteneur en question.
Tu éveilles ma curiosité. Peut-être que cet article donne quelques pistes malgré son âge.
Là encore, les conteneurs unprivileged te forcent à utiliser un template téléchargé et il semble que le serveur SSH ne soit pas toujours installé par défaut (dans le cas d'un template Debian 9 amd64, je n'ai pas de serveur SSH).
Toutefois en lisant le template lxc-debian fourni pour créer des privileged, il semblerait que le paquet openssh-server soit installé pour cette même distro (petite déception je dois avouer ...).
Je plussoies largement. D'ailleurs les concepteurs n'ont jamais caché que Docker est normalement prévu pour faire tourner une application par conteneur.
Je n'ai jamais vu de VPS basés sur Docker jusque là (plus du OpenVZ et du KVM), ça existe vraiment ? Décidément, il y aura toujours des personnes pour enfoncer des vis avec un marteau ...