systemd et systemctl dans Ubuntu Docker images [fermé]
il semble systemd n'est pas actif ou disponible dans les images du Docker Ubuntu.
Je m'occupe des conteneurs Docker de la ubuntu:16.04 et ubuntu:16.10 images.
si j'exécute systemctl status ssh dans le 16,04 contenant le résultat est l'erreur Failed to connect to bus: No such file or directory. Dans le 16.10 contenant l'erreur est bash: systemctl: command not found.
Si je fais which systemctl systemctl se trouve dans le 16.04 conteneur, mais pas dans le 16.10 conteneur.
j'ai remarqué que /lib/systemd existe.
j'ai essayé d'installer systemd apt-get install systemd libpam-systemd systemd-ui. Puis which systemctl trouve systemctl 16.10 mais systemctl status ssh donne toujours l'erreur Failed to connect to bus: No such file or directory
ma question principale est: comment systemd et systemctl peuvent-ils être activés pour être utilisés dans les images de Dockers Ubuntu?
pourquoi systemd n'est-il pas actif dans les dockers Ubuntu? Systemd n'est-il pas utilisé pour instancier le conteneur?
Je n'ai pas trouvé de documentation à ce sujet pour Ubuntu / Ubuntu Docker images, seulement des informations sur la transition Ubuntu de Upstartsystemd. Y a-t-il des documents donnant une explication complète?
1 réponses
C'est par la conception. Docker devrait exécuter un processus au premier plan dans votre conteneur et il sera généré en tant que PID 1 dans l'espace de noms pid du conteneur. Docker est conçu pour l'isolation des processus, pas pour la virtualisation du système D'exploitation, donc il n'y a pas d'autres processus et démons D'exploitation du système d'exploitation à l'intérieur du conteneur (comme systemd, cron, syslog, etc.), seulement votre point d'entrée ou la commande que vous exécutez.
S'ils incluaient des commandes systemd, vous trouverez beaucoup de choses qui ne fonctionnent pas depuis votre point d'entrée remplace init. Systemd utilise également les cgroupes qui restreignent le docker à l'intérieur des conteneurs, car la possibilité de changer les cgroupes pourrait permettre à un processus de sortir de l'isolement du conteneur. Sans systemd tournant comme init à l'intérieur de votre conteneur, il n'y a pas de démon pour traiter vos commandes start et stop.