systemd et systemctl dans les images Ubuntu Docker
Il semble que systemd ne soit ni actif ni disponible dans les images Ubuntu Docker.
J'utilise les conteneurs Docker à partir du ubuntu:16.04 et ubuntu:16.10 images.
Si j'exécute systemctl status ssh dans le 16,04 conteneur le résultat est l'erreur Failed to connect to bus: No such file or directory. Dans le 16.10 conteneur 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 récipient.
J'ai repéré que /lib/systemd existe.
J'ai essayé d'installer systemd avec apt-get install systemd libpam-systemd systemd-ui. Ensuite which systemctl trouve systemctl dans 16.10 mais systemctl status ssh donne toujours l'erreur Failed to connect to bus: No such file or directory
Ma question principale est la suivante: comment activer systemd et systemctl pour une utilisation dans les images Ubuntu Docker?
Pourquoi systemd n'est-il pas actif dans les conteneurs Ubuntu Docker? Est-ce que systemd n'est pas utilisé dans l'instanciation du conteneur?
Je n'ai trouvé aucune documentation sur ce sujet pour les images Ubuntu/Ubuntu Docker, seulement des informations sur la transition Ubuntu de Upstart à systemd. Existe-t-il une documentation donnant une explication complète?
C'est par conception. Docker devrait exécuter un processus au premier plan dans votre conteneur et il sera créé en tant que PID 1 dans l'espace de nom pid du conteneur. Docker est conçu pour l'isolation de processus, pas pour la virtualisation de système d'exploitation. Par conséquent, aucun autre processus ni processus de système d'exploitation ne s'exécute dans le conteneur (comme systemd, cron, syslog, etc.), uniquement votre point d'entrée ou votre commande.
S'ils incluaient des commandes systemd, vous constateriez que beaucoup de choses ne fonctionnaient pas depuis que votre point d'entrée remplace init. Systemd utilise également les groupes de contrôle, qui sont limités par le menu dans les conteneurs, car la possibilité de changer de groupe de contrôle pourrait permettre à un processus d'échapper à l'isolement du conteneur. Si systemd ne s'exécute pas en tant qu'initial dans votre conteneur, il n'y a pas de démon pour traiter vos commandes de démarrage et d'arrêt.