J'essaye de créer un conteneur docker basé sur systemd, mais lorsque j'essaye d'exécuter le conteneur construit, mon système plante. Je pense que l'exécution d'init dans le conteneur peut être à l'origine du conflit et est en quelque sorte en conflit avec systemd sur mon hôte.
Lorsque j'essaye d'exécuter le conteneur Docker, je suis déconnecté de mon compte et vois brièvement à quoi ressemble mon système via un processus de démarrage. Mon hôte exécute Arch Linux, avec linux 4.20.7.
Ce n'est que lorsque j'essaye de "démarrer" le conteneur en exécutant systemd via / sbin / init , que le problème se produit.
FROM ubuntu:18.04
# Don't start any optional services.
RUN find /etc/systemd/system \
/lib/systemd/system \
-path '*.wants/*' \
-not -name '*journald*' \
-not -name '*systemd-tmpfiles*' \
-not -name '*systemd-user-sessions*' \
-exec rm \{} \;
RUN apt-get update && \
apt-get install --yes \
python sudo bash ca-certificates dbus systemd && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
RUN systemctl set-default multi-user.target
RUN systemctl mask dev-hugepages.mount sys-fs-fuse-connections.mount
STOPSIGNAL SIGRTMIN+3
# Workaround for docker/docker#27202, technique based on comments from docker/docker#9212
CMD ["/bin/bash", "-c", "exec /sbin/init --log-target=journal 3>&1"]
Dockerfile (adapté de solita / ubuntu-systemd ):
docker run -it \ --volume=/sys/fs/cgroup:/sys/fs/cgroup:rw \ --privileged 66304e3bc48
Je m'attendrais à ce que le conteneur démarre simplement en exécutant systemd, et je ne le suis pas votre ce que je pourrais faire de mal.
3 Réponses :
"Faire correspondre l'hôte le plus près possible" était l'objectif initial du docker-systemctl -replacement script. Vous pouvez tester des scripts de lecteur dans un conteneur qui peuvent être exécutés ultérieurement sur une machine virtuelle. Il permet d'exécuter certaines commandes systemctl sans démon systemd actif.
Il peut également servir de démon d'initialisation si vous le souhaitez. Un système d'exploitation compatible systemd se sentira assez similaire à l'intérieur d'un conteneur avec lui.
J'avais essayé cela mais je ne pouvais pas le faire fonctionner. Je pense qu'il me manquait juste Python 3, car après avoir essayé à nouveau et m'être assuré qu'il est installé, il fonctionne maintenant. Je vais essayer et voir si cela fait le travail.
Ahh, je vois - merci pour le feedack. J'ai mis un indice sur l'exigence Python sur la première page. ................... Il y a quelques années, toutes les images de docker avaient Python préinstallé comme les vrais systèmes d'exploitation, mais cela a quelque peu changé l'année dernière. D'ici 2019, il est fondamentalement nécessaire d'installer python dans une image docker lorsque l'on souhaite utiliser des outils basés sur python. De même, Ansible veut être intelligent, il faut donc créer le répertoire / run / systemd / system maintenant. Avoir cela sur la page d'accueil peut être une bonne idée maintenant.
J'ai fini par utiliser l'image Docker paulfantom / ubuntu-molecule .
Actuellement, il semble qu'ils installent simplement systemd, définissent certaines variables d'environnement et utilisent directement le binaire systemd comme point d'entrée. Cela semble fonctionner sans les problèmes que j'ai mentionnés dans l'article d'origine.
FROM ubuntu:18.04
ENV container docker
ENV LC_ALL C
ENV DEBIAN_FRONTEND noninteractive
RUN sed -i 's/# deb/deb/g' /etc/apt/sources.list
# hadolint ignore=DL3008
RUN apt-get update \
&& apt-get install -y --no-install-recommends systemd python sudo bash iproute2 net-tools \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# hadolint ignore=SC2010,SC2086
RUN cd /lib/systemd/system/sysinit.target.wants/ \
&& ls | grep -v systemd-tmpfiles-setup | xargs rm -f $1
RUN rm -f /lib/systemd/system/multi-user.target.wants/* \
/etc/systemd/system/*.wants/* \
/lib/systemd/system/local-fs.target.wants/* \
/lib/systemd/system/sockets.target.wants/*udev* \
/lib/systemd/system/sockets.target.wants/*initctl* \
/lib/systemd/system/basic.target.wants/* \
/lib/systemd/system/anaconda.target.wants/* \
/lib/systemd/system/plymouth* \
/lib/systemd/system/systemd-update-utmp*
RUN systemctl set-default multi-user.target
ENV init /lib/systemd/systemd
VOLUME [ "/sys/fs/cgroup" ]
ENTRYPOINT ["/lib/systemd/systemd"]
Docker ne souhaite pas inclure par défaut Systemd dans le menu fixe car il se publie lui-même en tant que conteneur d'applications (ce qui signifie une application par conteneur). Il existe un autre type de conteneurs appelé conteneurs système . les plus connus sont OpenVZ, LXC / LXD et Systemd-nspawn. tous ceux-ci exécuteront un système d'exploitation complet avec systemd comme s'il s'agissait d'une machine virtuelle.
et utiliser systemd dans docker est tellement dangereux par rapport à l'exécution de systemd dans LXD
il y a même un nouveau bébé appelé Podman qui est un clone de docker mais il utilise par défaut systemd inside lorsque vous l'installez ou lorsque vous utilisez une image qui contient déjà systemd comme celles des images cloud ubuntu http://uec-images.ubuntu.com/releases/server/bionic/release/
donc mon conseil est de tester LXD et systemd-nspawn; et gardez un œil sur Podman, il résout ce que docker ne veut pas résoudre; lisez ceci pour comprendre https://lwn.net/Articles/676831/
références:
https://coreos.com/rkt/docs /latest/rkt-vs-other-projects.html https://podman.io/slides/2018_10_01_Replacing_Docker_With_Podman.pdf https://containerjournal.com/features/system-containers- vs-application-conteneurs-différence-matière
Les environnements d'exécution et la malédiction du conteneur privilégié https://brauner.github.io/2019/02/12/ privileged-containers.html
L'ajout de
--privilegeddonne ce droit au processus de conteneur, et systemd veut gérer un lot de choses. Pourriez-vous atteindre votre objectif final avec un processus d'initialisation plus léger comme supervord, ou mieux encore, un conteneur à processus unique sans init dédié?Je préférerais faire cela, le problème est que je l'utilise pour les tests de gestion de la configuration et je veux donc que le conteneur corresponde le plus possible à l'hôte. Je finis par avoir besoin de tester que le redémarrage des services à l'aide de
systemctlfonctionne."Faites correspondre l'hôte le plus près possible": un conteneur Docker n'exécute pas la plupart des éléments exécutés par un système hôte complet typique, y compris les démons système, les services de connexion à distance, etc. Si "correspond au host "est votre objectif, une machine virtuelle sera une correspondance beaucoup plus naturelle.
Ouais, malheureusement, ce n'est pas vraiment faisable. J'espère tester les rôles lors d'une exécution de CI où seuls les conteneurs docker sont disponibles.
J'ai ce problème avec les versions nocturnes d'Ubuntu 19.04 et de Docker. J'ai également eu ce problème avec Ubuntu 18.04 et quelle que soit la version actuelle du docker. Le système hôte ne redémarre pas - X11 semble tomber en panne ou être arrêté.