Использование docker в web разработке

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

Где все это должно храниться? Должно ли это храниться внутри отдельного контейнера или же эти компоненты должны выноситься куда то вне контейнеров?

Оба способа практикуются равно и холиворно :) Я, например, предпочитаю хранить файлы на хосте. Это удобнее с точки зрения ручной работы с хоста. Многие предпочитают для хранения данных использовать отдельные volume-контейнеры. Это полезно с точки зрения унификации работы, переноса между нодами и т.п.

ну например в директории, которая примонтирована докером, где работает БД

Должно ли это храниться внутри отдельного контейнера или же эти компоненты должны выноситься куда то вне контейнеров? Если держать это добро внутри контейнеров то вырисовывается перспектива их разрастания до безумных размеров. Напротив если держать наши компоненты на отдельных хостах то образы докера превращаются в неких посредников между запросами извне и серваки с компонентами. Расскажите как этот вопрос решается на профессиональном уровне?

Обычные контейнеры подразумеваются stateless, т.е. имеют под собой readonly ФС или имеют, но система оркестрации имеет право очистить её по своему усмотрению при перезапуске. Чтобы запускать БД предусмотрено понятие volume - внешних ФС, монтируемых внутрь контейнера. Они бывают 2х типов:

• Эфемерные. Сохраняются при перезапуске, но теряеются при миграции на другую ноду. Полезны для кеша.
  
• Персистентные. Сохраняются в любых случаях. Тут начинаются костыли и боль.
  

Инстансы с персистентными вольюмом обычно просто не мигрируют между хостами, функции отказоустойчивости перекладывают на плечи БД. Есть ещё вариант запускать поверх Ceph, но это медленно.

Специфицируются вольюмы внутри системы оркестрации при деплое, а не внутри докерфайла при сборке. См. опции тулзы docker, а также спеки docker-compose, docker swarm, kubernetes и т.п.

До систем оркестрации я пока не добрался но объяснили доходчиво. Спасибо!)) Как вы говорили отказоустойчивость обеспечивается за счет БД (внешних файлов возможно на отдельном хосте). Окей, а вот этот самый персистивный вольюм он при своем «инстанцировании» получается как то подхватывает текущие файлы снаружи? В случае если я их как то изменяю в рамках «контейнерной сессии» они изменятся в своих исходных местах хранения (откуда изначально формируется volume)? Сорри если что-то трактую неверно. Пока многое остается неясным.

Volume - это обычная изменяемая ФС хоста, каталог в которой просто bind mount-ом монтируется внутрь контейнера.

которое мы распространяем через docker образы

Если ты его распространяешь (деплоишь) через докер образы, то само собой и данные должны быть в одном из контейнеров. Но может быть так, что там, куда ты это всё деплоишь уже есть «стандартные» сервисы БД, например, тогда тебя не должно волновать где они хранят данные, а локально можешь поступать как угодно.