Docker: Operation not permitted [FAILED]

Судя по Failed to get D-Bus connection: Operation not permitted Starting my_app (via systemctl) - проблема у вас возникает из-за тгого, что вы используете ОС с systemd который не работает корректно в Docker(справедливости ради стоит отметить что Upstart в docker тоже не заводится) и /etc/init.d/my_app у вас перенаправляет на systemctl start my_app, при этом возникает ошибка связанная с тем что systemd в контейнере Docker не запускается корреткно и systemctl не может подключиься к шине D-Bus к systemd и произвести необходимые действия для запуска службы my_app. Частая ошибка новичков юзающих Docker. Вместо инит-скрипта нужную вам службу необходимо запускать руками, указав нужны параметры в обычном sh-скрипте, и прописав путь к нему в CMD в докерфайле.

Если запустить нужно несколько служб, лучше разнести из по разным контейнерам. Есть конечно извращенцы, юзающие Supervisord, runit, tini и dumb-init в контейнерах, но это - плохой тон,и выкручиваться с помощью данных систем инициализации стоит только в том случае, если нужно запустить несколько служб на одном контейнере и при этом данные службы ну никак нельзя разнести по разным контейнерам.

проблема у вас возникает из-за тгого, что вы используете ОС с systemd который не работает корректно в Docker

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

справедливости ради стоит отметить что Upstart в docker тоже не заводится

Справедливости ради стоит отметить, что по причине рукожопости авторов докера, в докер-контейнерах вообще практически никакие реализации init'а не работают. Кроме самых примитивных или специально допиленных для работы в докере.

Жуть какая.
И чего с ним, ущербным, все носятся...
Хотя понятно, всё ради «бдыщь-бдыщь и в продакшен».

Спасибо за разъяснения! Разработчики писали свое приложение под RHEL6 и там подобных проблем не было. Но в целевой среде оказался RHEL7. В любом случае опишу запуск в sh-скрипте.

Докер—штука для контейнеризации приложений, а не ОС, не нужна там система инициализации и тем более systemd, by design. Хотя это и не отменят рукожопости авторов докера.

Докер—штука для контейнеризации приложений, а не ОС, не нужна там система инициализации и тем более systemd, by design.

Это не помешало любителям докера запилить куски инита в виде отдельных приложений, совместимых с докером. Пример: http://supervisord.org/.

Если ты хочешь запускать свой софт через инит-скрипты, то тебе нужны нормальные контейнеры навроде lxc/lxd, а не наколенные поделки типа docker.

Проекту supervisord более 10 лет, тогда ещё никакими доскерами не пахло.

Совершенно верно. Но авторы докера считают это не багом, а фичей. Уверяют что одно приложение нужно запускать в одном контейнере, несколько в нескольких и т.п., а не init с кучей сервисов в одном контейнере. Если нужно что-то, что расходится с их видением данной проблемы - начинается велосипедостроение с использованием недоинитов.

Верно, supervisord и runit появились задолго до Docker. Но потом появились и dumb-init с tini, которые пились уже специально для контейнеров, которых запилили любители докера.

Не за что) Я подозревал, что приложение тестили с более старой ОС, чем та на которой его запускают теперь. Именно в таких ситуациях очень часто всплывают подобные проблемы.

При чём тут Development?

Проекту supervisord более 10 лет, тогда ещё никакими доскерами не пахло.

Да, тут я ошибся. Но факт починки костылями поломанного докера это не отменяет.

Если запустить нужно несколько служб

Не проще тогда всё это в nspawn или подобную хрень засунуть?

У systemd-nspawn до сих пор имеются проблемы с обеспечением безопасности, сейчас например можно из контейнера ребутнуть весь хост.

А у lxc/lxd есть какой-то аналоги swarm или kubernetes?

сейчас например можно из контейнера ребутнуть весь хост

Как?

openstack?

сейчас например можно из контейнера ребутнуть весь хост

Можно пруф?

Arch Linux, 4.8.10-1-ARCH, systemd 231-4

mkdir box
pacstrap -d -c box base
systemd-nspawn --boot --directory=box

авторизация: root, без пароля

[root@box ~]# echo b > /proc/sysrq-trigger

если ребутать не хочется, то можно:

'm' - Will dump current memory info to your console.

[root@box ~]# echo m > /proc/sysrq-trigger

dmesg на хосте:

[18529.421008] sysrq: SysRq : Show Memory
[18529.421016] Mem-Info:
[18529.421028] active_anon:398347 inactive_anon:124929 >isolated_anon:0
active_file:83056 inactive_file:84631 >isolated_file:0
unevictable:0 dirty:255 writeback:0 unstable:0
slab_reclaimable:9008 slab_unreclaimable:99856
mapped:93061 shmem:125442 pagetables:7025 >bounce:0
free:52856 free_pcp:1169 free_cma:0