Tyranron

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).

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.