Sergey K

Для начала нужно понять "контейнер" и "контейнеризацию".
Контейнеризируя процесс, мы его изолируем в своей среде, со своим личным user space. При этом ядро ОС (kernel) при работе контейнера используется то же самое, что и у основной ОС машины.

Выгода здесь в том, что к контейнерам можно относиться как к этаким "бинарникам", грубо говоря. У Вас есть какое-то приложение, не важно какое-оно, будь то набор скриптов на PHP, либо уже скомпилированное что-то (postfix, nginx, apache, и т.п.). Вы это приложение и все его зависимости упаковываете в контейнер (создаете image) и на выходе получаете единое готовое "что-то", что Вы можете запустить и оно не требует более никаких зависимостей (кроме рантайма контейнеров - Docker, rkt, и т.п.). Полная аналогия с тем, как из вороха либ и исходников Вы компилите единый бинарник, который просто потом запускаете где хотите, без необходимости иметь исходники.
Как мы привыкли в менеджерах зависимостей (composer, bower, другие) описывать и фиксировать зависимости исходного кода, так же и в контейнере мы делаем то же самое, но для окружения нашего приложения. Reproducibility во все поля.

Это очень сильно упрощает жизнь. Вам больше не нужно заботиться о том, что для приложения нужно точно воспроизводить окружение на каждой машине, оно у Вас зафиксировано внутри контейнера. Никаких больше конфликтов между различными версиями jvm, php, python, ruby, nginx и т.д. Вы легко на одной и той же машине используете какие хотите приложения, каких хотите версий. Выкатка его же на другую машину больше не требует филигранной подгонки и согласования окружения в соответствие. У Вас больше не отвалится внезапно приложение, из-за недонастроенных апдейтов ОСи и внезапного обновления зависимых либ.

А что Docker?
Docker - это набор инструментов для работы с контейнерами.
Docker daemon являет собой рантайм контейнеров, он их запускает, останавливает, отслеживает.
Docker registry - это контроль версий созданных образов (images) приложения, по аналогии к контролю версий исходников приложения.

Все. Концептуально ничего более Docker и контейнеризация не дают.

Отвечая на Ваши вопросы:

1. 
   

   docker-daemon - это HTTP-сервер и он может взять на себя это работу на стороне сервера, т.е. nginx не нужен

   
   Нет. Docker daemon - это рантайм контейнеров. Он умеет "слушать" на определенных портах, но это сделано для взаимодействия с Docker runtime'ом, а не для выполнения функциональности HTTP-сервера. HTTP-сервер все ещё нужен, и он может (а по-хорошему и должен) быть запущен внутри контейнера.
   
   
2. 
   

   docker на дев-машине можно (как-то) связать с докером на хостинге

   
   Мы не жонглируем docker'ами. Docker - всего лишь инструмент для работы с контейнерами. Мы жонглируем контейнерами и приложениями, упакованными в них. Нет смысла связывать docker'ы на хостинге и на дев-машине. Вы создаете образ (image) и можете его запускать через docker как на дев-машине, так и на хостинге. Если Вам нужно, чтобы одни приложения на дев-машине общались с другими на хостинге, то это не вопрос к docker'у - это вопрос к организации связи между Вашими приложениями.
   
   
3. 
   

   и учитвыая предудущий пункт - docker можно использовать для деплоя

   
   ИМХО, нужно. Вы закатали в образ точную версию приложения и его окружения. Осталось теперь этот "бинарник" запустить где хочется.
   
   
4. 
   

   docker можно использовать для отката, если деплой не задался

   
   Легко. Просто тушим контейнер нового образа и подымаем обратно старый.
   
   
5. 
   

   пропадает необходимость в во всяких rbenv и pyenv, если нужна другая версия языка, то просто создается новый контейнер в котором и происходит установка

   
   Да. Вы в Dockerfile, по сути, точно декларируете свое окружение. Нужно другое окружение - меняем Dockerfile и создаем новый образ.
   
   
6. 
   

   докер очень быстрый, в т.ч. старты и рестарты

   
   Не понятно - быстрый в чем? Наверное, имеется в виду сравнение с виртуальными машинами. Да, накладные расзоды меньше, нежели у виртуалок, так как используется одно и то же ядро ОС. Просто процессы запускаются в разных user space'ах. В остальном скорость Docker - это скорость запуска, собственно, процессов. Если у Вас тяжелое приложение с медленным стартом (привет, FMS!) или остановкой, то Docker тут Вам ничем не поможет.
   
   

1. Чтобы при перезапуске машины контейнеры сами стартовали, нужно всего лишь соответствующий systemd service сделать enabled. Cron здесь не нужен.
sudo systemctl enable docker-project.service

2. Любой systemd service - это всего лишь абстракция. А что именно он выполняет - решать именно Вам. Что у Вас ExecStart'ом будет стартовать один контейнер через docker run, что связка контейнеров через docker-compose up, для systemd и CoreOS принципиальной разницы нет.

3. В приведенной Вами декларации systemd service'а в секции [Unit] есть следующие строки:

Requires=docker-project.service
After=docker-project.service

Они означают, что декларируемый Вами service должен быть запущен только после того, как был запущен docker-project.service. Но, насколько я понимаю из Вашего описания, это и есть декларация docker-project.service. То есть Вы говорите systemd что сервис должен быть запущен после запуска самого себя. Это не есть гуд. Эти строки, судя по всему, должны быть такими:

Requires=docker.service
After=docker.service

Дабы systemd пытался запустить этот сервис только после того, как будет запущен Docker daemon.

4. В файлике docker-up.sh у Вас docker-compose up запускается в foreground'е. Первая связка контейнеров то запустится, а что со второй - не понятно. Наверное, все же стоило их запускать с -d ключиком, а в systemd декларации в секции [Service] указать Type=forking, если прям так нужно обе связки контейнеров запускать одним systemd service. Но вообще, имхо, на каждый docker-compose.yml должен быть свой отдельный systemd service, и никаких forking.
Также, заворачивать docker-compose команды внутрь docker-up.sh было не самой хорошей идеей. Вам ничего не мешало написать несколько ExecStart'ов подряд, тем самым не размазывая декларацию по нескольким файлам, и было бы видно на каком именно шаге оно отваливается при systemctl start docker-project.service.

5. Логи наше все. Используйте journalctl --unit=docker-project.service дабы глянуть что там вообще произошло, и кто на кого ругается.

В заключение:
Вообще, честно говоря, видно полное профанство с Вашей стороны по данному вопросу. Это нормально, ведь невозможно знать все технологии и инструменты, и постоянно приходится что-то изучать. Не нормально то, что ничего не мешает заглянуть в официальную документацию по тому же systemd. 20-30 минут чтения хотя бы этой страницы, и подобного непонимания бы просто не было.
Пожалуйста, не поленитесь, потратьте немного времени и почитайте доки. Systemd умеет ещё много чего, что сможет Вам помочь в решении Ваших задач, и даст понимание что, куда, и как.

К размышлению:
Раз уж Вы используете CoreOS, посмотрите в сторону Kubernetes для запуска сервисов/контейнеров. Ставится на CoreOS он в пол-оборота, а возможностей, гибкости и вкусных абстракций уж гораздо поболее, нежели у systemd/fleet.

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

В конфиге php-fpm надо писать
listen = 9000
вместо
listen = 127.0.0.1:9000