В чем разница между System Containers и Application Containers?

Если вопрос про LXC, то он некорректный. Там только system containers.

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

В системных контейнерах есть каталог, из которого запускается вся система, включая systemd, с достаточными правами, чтобы этот systemd и все остальное, что он вздумает запустить, работало и не вылезало за этот каталог. Как правило, там еще есть cron, syslog и прочие системные демоны, которые обычно запущены на обычной линуксовой машине. Нет ничего плохого в том, чтобы запустить в одном системном контейнере Apache с PHP и там же MySQL и заодно еще почтовый сервер, и все это замониторить через какой-нибудь Munin, который сидит в том же контейнере.

А в application containers есть каталог, в котором есть программа и ее минимальные зависимости. Ее запускает непосредственно менеджер контейнеров, и никакого systemd посередине между ними нет. Нет и привычных сисадмину вещей типа cron и syslogd. За сохранение логов отвечает менеджер контейнеров, а крон - анахронизм. О мониторинге думают в последнюю очередь (так как в руководстве ни строчки об этом нет), и по идейным соображениям (это же application container!) сажают в отдельный контейнер. Т.е. в примере выше будет отдельный контейнер для Apache с модулем PHP, отдельный - для MySQL, отдельный - для почтового сервера, и взаимодействовать они будут либо по сети, либо через общие папки. Из плюсов - каждый контейнер можно обновлять отдельно, и права можно урезать гораздо сильнее (например, часто нет необходимости держать более одного user id внутри, и не надо разрешать systemd перенастраивать сеть, так как systemd просто нет).

Ее запускает непосредственно менеджер контейнеров

lxc тоже так умеет:
man lxc-execute

«to quickly launch an application in an isolated environment.»

Если вопрос про LXC, то он некорректный.

почему?

Формально, да, получается application container. Однако именно «формально», поскольку при старте системы он не запустится. В отличие от application container'а, созданного, например, через docker.

В названии в основном.

поскольку при старте системы он не запустится.

почему?

Systemd can be used to start and to stop LXCs via lxc@CONTAINER_NAME.service. Enable lxc@CONTAINER_NAME.service to have it start when the host system boots.

Нееет, счас обязательно должны набежать адепты и всё разъяснить, что я ничего не понимаю в микросервисной архитектуре и подходе «инфраструктура как код», и что нужно читать доки.

Systemd can be used to start and to stop LXCs via lxc@CONTAINER_NAME.service. Enable lxc@CONTAINER_NAME.service to have it start when the host system boots.

$ systemctl cat lxc@.service
# /lib/systemd/system/lxc@.service
[Unit]
Description=LXC Container: %i
# This pulls in apparmor, dev-setup, lxc-net
After=lxc.service
Wants=lxc.service
Documentation=man:lxc-start man:lxc

[Service]
Type=simple
KillMode=mixed
TimeoutStopSec=120s
ExecStart=/usr/bin/lxc-start -F -n %i
ExecStop=/usr/bin/lxc-stop -n %i
# Environment=BOOTUP=serial
# Environment=CONSOLETYPE=serial
Delegate=yes
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

Т.е. это относится только к системным контейнерам (которые запускаются через lxc-start). Как минимум, lxc нигде не записывает, что именно вы собрались запустить внутри контейнера приложений. Т.е. как он поймет, что надо запускать именно Apache? lxc-execute это понимает, поскольку эта информация есть в командной строке. Docker это понимает, поскольку соответствующая строка есть в Dockerfile. С системными контейнерами такой проблемы нет, т.к. запускается всегда /sbin/init, т.е. systemd.

Какой то странный из пальца высосанный «недостаток».

Написать свой юнит (в т.ч. параметризованный) кто то запрещает?

Или, прости господи, об этом не говорится в справочном руководстве, а значит этого не бывает?

Это не по понятиям! Это уже кастомная разработка! С точки зрения менеджмента поддерживать кастомную разработку одна сплошная головная боль. Админы же решают задачи стандартными путями (т.е. ставят готовое ПО, пусть и другое).

До чего дошел прогресс! Так мы дойдем до того, что написание конфигов админами - это тоже кастомная разработка и все сервисы должны работать на дефолтном конфиге...

Какие ещё конфиги, ты о чём? Кругом docker, всё должно устанавливаться готовое к работе!

Ну-ну, мечта хипстора - готовые образы докера подо всё. Только когда образ ломается(например из личного опыта - база монги в контейнере, сделанном интеграторами, наворачивается при нештатном рестарте сервера - это к слову не проблема контейнера, это проблема монги, но о ней знать надо), хипстор начинает судорожно читать мануалы по всему и искать куда же пишутся логи. Потому что установил всё в режиме «далее-далее-далее» и в душе не е^W знает как оно там вообще устроено и как его в случае чего чинить.

На вопрос какой контейнер для чего предназначен - круглые глаза в стиле «ничо не знаю - оно само работает»

Какая же радость-то - дебажить системы без документации методом реверс-инжиниринга.