Docker (CentOS 7 с SYSTEMCTL): не удалось смонтировать tmpfs и cgroup

попробуйте запустить контейнер в привилегированном режиме:

docker run -ti --privileged=true -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/centos7-systemd

это должно решить вашу проблему

Более современный подход к этому, после того, как Дэниел Уолш внес серию патчей, заключается в следующем...

docker run -ti --tmpfs /tmp --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/centos7-systemd

По сути, запуск в привилегированном контейнере — плохая идея по соображениям безопасности. Поскольку Даниэль внес исправления, чтобы сделать его ненужным, мы можем начать без повышения привилегий.

Хотя в целом мы должны поддерживать принцип «один сервис/процесс для каждого контейнера», некоторые люди хотят запускать контейнеры, поддерживаемые RedHat, что означает использование systemd.

См. https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privived-container/ для получения дополнительной информации.

Чтобы продемонстрировать урезанный контейнер systemd, что-то вроде этого будет иметь запущенные apache и tomcat; не единый принцип службы/процесса, а просто пример. Очевидно, вам нужно сделать больше с этим изображением, но это основная идея. Я думаю, что я получил это из одного из постов Дэниела где-то, но я не помню сейчас.

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/*;
RUN yum -y install httpd tomcat tomcat-javadoc.noarch \
    tomcat-docs-webapp.noarch tomcat-admin-webapps.noarch ; \
    yum clean all
RUN systemctl enable tomcat.service
RUN systemctl enable httpd.service

VOLUME [ "/sys/fs/cgroup" ]
EXPOSE 80 8080
CMD ["/usr/sbin/init"]

docker build -t apache ./
docker run --tmpfs /tmp --tmpfs /run -it -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 8081:80 -p 8080:8080 --name apache apache

У меня такая же проблема с Docker для Windows (1.12.3)...

$ docker logs bareos
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to CentOS Linux 7 (Core)!

Set hostname to <bareos>.
Failed to install release agent, ignoring: No such file or directory
Failed to create root cgroup hierarchy: No such file or directory
Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object, freezing.

В последнем boot2docker нет systemd. У нас не может быть systemd в контейнере Docker, если его нет на хосте. Поскольку важной папкой для этого является /sys/fs/cgroup/systemd.

Итак, наконец, я создаю виртуальную машину default в VitualBox на основе Alpine Linux и default docker-machine с драйвером generic.

Как я уже сказал здесь, вы не обязаны использовать параметр --privileged=true (что может быть опасно, ИМХО), вы просто забыли добавить -v /run к своей команде docker run.

Итак, ваша последняя команда запуска, которая должна работать, будет:

docker run -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /run -p 80:80 local/centos7-systemd

Если вам не нужно запускать контейнер на переднем плане, вы можете запустить в автономном режиме, чтобы избежать этой ошибки. Например:

docker run -d --name=my_container_name image_id

Затем вы можете использовать что-то вроде этого, чтобы получить оболочку в контейнере:

docker exec -ti my_container_name /bin/bash

Если у вас нет команды на переднем плане в CMD Dockerfile, вызывающей немедленный выход из контейнера, вы можете добавить команду, которая поддерживает его работу, например:

docker run -d --name=my_container_name image_id tail -f /dev/null

Подробнее о последнем примере см. в SO answer.

MacOS X не требует монтирования тома cgroups в контейнере

$docker run -it -p 80:80 ${ImageID}

После запуска многих экземпляров контейнера Мой Mac застрял в

[!!!!!!] Failed to mount API filesystems, freezing.

ссылка В настоящее время режим bash у меня работает нормально

$docker run -it -p 80:80 ${ImageID} /bin/bash

Хотя вы можете запустить systemd внутри контейнера, я не думаю, что это хорошая идея. Вот почему:

1. #P2#

   #P3#
2. #P4# <блочная цитата> #P5# #P6#

3. Этот сообщение в блоге был связан в качестве примера того, как заставить его работать, но вы можете видеть, что контейнер по-прежнему нужно запускать от имени пользователя root:

   EXPOSE 80
   CMD [ "/sbin/init" ]
   

   Хотя это, конечно, не уникально для этих контейнеров, это все же менее безопасно:

   • Just say no to root (in containers)
   • Почему некорневые контейнеры важны для Безопасность

4. В качестве еще одного доказательства того, что это не очень хорошая идея, даже собственные Dockerfiles Red Hat CentOS не делают этого. Например (источник):

   FROM centos:centos7
   
   # RHSCL httpd24 image.
   #
   # Volumes:
   #  * /opt/rh/httpd24/root/var/www - Datastore for httpd
   #  * /var/log/httpd24 - Storage for logs when $HTTPD_LOG_TO_VOLUME is set
   # Environment:
   #  * $HTTPD_LOG_TO_VOLUME (optional) - When set, httpd will log into /var/log/httpd24
   
   EXPOSE 80
   EXPOSE 443
   
   COPY run-*.sh /usr/local/bin/
   RUN mkdir -p /var/lib/httpd24
   COPY contrib /var/lib/httpd24/
   
   RUN rpmkeys --import file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 && \
       yum -y --setopt=tsflags=nodocs install https://www.softwarecollections.org/en/scls/rhscl/httpd24/epel-7-x86_64/download/rhscl-httpd24-epel-7-x86_64.noarch.rpm && \
       yum install -y --setopt=tsflags=nodocs gettext hostname bind-utils httpd24 httpd24-mod_ssl && \
       yum clean all
   
   # When bash is started non-interactively, to run a shell script, for example it
   # looks for this variable and source the content of this file. This will enable
   # the SCL for all scripts without need to do 'scl enable'.
   ENV BASH_ENV=/var/lib/httpd24/scl_enable \
       ENV=/var/lib/httpd24/scl_enable \
       PROMPT_COMMAND=". /var/lib/httpd24/scl_enable"
   
   
   VOLUME ["/opt/rh/httpd24/root/var/www"]
   VOLUME ["/var/log/httpd24"]
   
   ENTRYPOINT ["/usr/local/bin/run-httpd24.sh"]
   CMD ["httpd", "-DFOREGROUND"]
   

Конечно, если вы знаете обо всем этом и все еще хотите запустить systemd в контейнере, как уже упоминалось другими, это возможно. Я не думаю, что есть смысл повторять то, что они уже сказали.