Использование БД в контейнере. Не нашел причин по которой нужно БД в контейнере держать.

Если нужно несколько независимых БД разных версий или требуется простая миграция между хостами и т.п. — то БД в контейнере вполне удобно.

Если требуется производительность и ресурсы — то только хост. К примеру, при прочих равных у меня MariaDB в Docker-контейнере вдвое медленнее, чем на хосте. Что интересно, на LXC потеря производительности не заметна. Я полагаю, дело в aufs.

Плюс расход памяти. Когда БД одна на хосте, память БД — кеши, буфера — общая и может использоваться эффективно. А в контейнере свои кеши и буфера у каждого экземпляра.

Могу ли при запуске контейнера передать входящие параметры

Всё, что в docker run идёт после run, передаётся в контейнер.

тебе нужен docker-entrypoint.sh вот хороший пример из postgres там идет обработка того что передали докеру как команду.

https://github.com/docker-library/postgres/blob/443c7947d548b1c607e06f7a75ca4...

https://docs.docker.com/engine/reference/builder/

БД которая в контейнере, хранится в смонтированной хостовой папке, правильно я понимаю? Если контейнер падает то при повторном запуске с БД все нормально, не надо ничего восстанавливать? Где то читал что btrfs вроде как лучше чем aufs, но точно не знаю.

Это зависит. В постгресе, если ты вольюм с данными монтируешь, то он персистентный остаётся. Только если пустая директория, тогда инициализирует.

выбор ОС

На базе какого дистрибутива лучше сделать образ? Мне нужно на питоне ходить в хостовую БД, брать данные и рассылать письма. На обычном ПК у меня стоит убунту и апач. Что лучше в контейнере использовать, чтобы было не перегружено? CoreOS легкий, но как я понял он пустой, туда много чего надо ставить. У кого есть опыт, подскажите какой дистрибутив выбрать и что лучше использовать для моей задачи

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

Если «пробросить» volume с данными на хост, то, наверно, с производительностью всё должно быть ок.

Пример https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/

В `Dockerfile` можно указывать entrypoint; также его можно override при `docker run --entrypoint=«$COMMAND»`.

Погугли `docker pipe`; посмотри на -tia, --rm флаги.

Я тестировал именно с монтированием хостового каталога по -v.

Со данными из другого контейнера, работающего через aufs, видимо, будет ещё грустнее :)

Ну и, главное, повторюсь, память. Отводить каждому контейнеру многие гигабайты оперативки под БД, которые могут понадобиться, а могут и нет (в зависимости от флуктуаций нагрузки) — расточительно.

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

Вообще, возможно выделять данной задаче (контейнеру) некоторый пул ресурсов - нужная вещь.

docker без cow фс Кстати - в docker нельзя использовать стандартную ext4, чтобы избежать cow-fs (copy on write)?

imho, это лишний overhead.

Наверно, в LXC так можно сделать.

https://www.stgraber.org/2013/12/27/lxc-1-0-container-storage/

Видимо, в LXC можно пробросить директорию хоста для guest root-a.

По-идее, приложения в контейнерах потребляют столько же памяти, сколько и на хосте.

Тут речь не о расходе памяти в контейнере. А о проблеме разделения памяти на несколько серверов БД, не важно, в контейнерах они или на хосте. Выгоднее выделить на один сервер 70% памяти, чем на два сервера по 35% каждому.