deveria systemd-udev-trigger ser mascarado no container?

Question

Eu perguntei isso question Eu acho que o systemd-udev-trigger não deve ser executado no contêiner do docker, seja lá o que for - privilegiado ou não.

Existe alguma cena que precisa ser excute systemd-udev-trigger no container docker?

    

Answer 1

A primeira resposta, menos específica, é que o systemd-udev não foi projetado para ser executado dentro de contêineres. E que o Docker não tem a intenção de rodar o systemd dentro dele, apenas um daemon.

A imagem do container que você mencionou tem instruções para executar o systemd. Eles envolvem a remoção dos serviços do udev que seriam executados em um contêiner não privilegiado. Isso é válido dentro de um contêiner do Docker porque você nunca deve usar o gerenciador de pacotes após o processo de compilação.

Em um contêiner privilegiado, acho que essas instruções também devem ser suficientes para desabilitar o udev. No meu sistema Fedora 26, é uma falta estática de sysinit.target . Observe como o código remove todas as necessidades estáticas de sysinit.target , exceto systemd-tmpfiles-setup.service .

Systemd integration

Systemd is now included in both the centos:7 and centos:latest base containers, but it is not active by default. In order to use systemd, you will need to include text similar to the example Dockerfile below:

Dockerfile for systemd base image

dockerfile FROM centos:7 ENV container docker RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == \ systemd-tmpfiles-setup.service ] || rm -f $i; done); \ rm -f /lib/systemd/system/multi-user.target.wants/*;\ rm -f /etc/systemd/system/*.wants/*;\ rm -f /lib/systemd/system/local-fs.target.wants/*; \ rm -f /lib/systemd/system/sockets.target.wants/*udev*; \ rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \ rm -f /lib/systemd/system/basic.target.wants/*;\ rm -f /lib/systemd/system/anaconda.target.wants/*; VOLUME [ "/sys/fs/cgroup" ] CMD ["/usr/sbin/init"]

This Dockerfile deletes a number of unit files which might cause issues. From here, you are ready to build your base image.

console $ docker build --rm -t local/c7-systemd .

Example systemd enabled app container

In order to use the systemd enabled base container created above, you will need to create your Dockerfile similar to the one below.

dockerfile FROM local/c7-systemd RUN yum -y install httpd; yum clean all; systemctl enable httpd.service EXPOSE 80 CMD ["/usr/sbin/init"]

Build this image:

console $ docker build --rm -t local/c7-systemd-httpd .

Running a systemd enabled app container

In order to run a container with systemd, you will need to mount the cgroups volumes from the host. Below is an example command that will run the systemd enabled httpd container created earlier.

console $ docker run -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/c7-systemd-httpd

This container is running with systemd in a limited context, with the cgroups filesystem mounted. There have been reports that if you're using an Ubuntu host, you will need to add -v /tmp/$(mktemp -d):/run in addition to the cgroups mount.