Мы изучаем докеры и пытаемся выяснить, предоставляют ли докеры способ сделать следующее, чтобы устранить некоторые накладные расходы на управление с текущим подходом, который мы используем.
Мы смотрим на что-то вроде ниже:
Иметь базовый шаблон с ОС Linux + App1 — Oracle + App2 — Mysql + App3 — Mongodb
Всякий раз, когда у нас есть запрос, мы должны иметь возможность вытащить контейнер из базового шаблона для конкретного приложения. Пример: контейнер с установленной ОС Linux + только приложение Oracle. Аналогично OS + Mongodb на другом контейнере
У нас есть ограничение на наличие разных шаблонов для каждого приложения, поэтому нам нужен только один главный шаблон, который может иметь все приложения и каждый раз извлекать контейнеры с конкретным приложением, включенным только из базового шаблона.
Любой указатель на то, как мы можем достичь этого, будет полезен. Может ли dockerfile или что-то еще помочь?
Заранее спасибо.


у каждого докера должен быть один ПИД. Это означает, что мы должны запустить один сервис в одном контейнере.
Не могли бы вы? да. Тебе следует? Нет.
Многоуровневые файловые системы означают, что вы можете создавать несколько образов и совместно использовать общие части файловой системы. Вы создаете свои Dockerfile с общими частями в верхней части Dockerfile или в общем базовом образе. Эти общие части должны быть минимальными, вам не нужно пересобирать app2 из-за изменений в app1.
Изображения должны быть помечены разными репозиториями для каждого приложения и разными тегами для разных сборок каждого приложения. Сами образы должны содержать двоичные файлы, библиотеки и другие зависимости, необходимые для запуска приложения, но не конфигурацию или постоянные данные. Конфигурация внедряется извне с помощью переменных среды, аргументов командной строки, конфигураций, секретов или тома только для чтения. И данные почти всегда сохраняются в томе или базе данных.
Образы не включают ОС, если в ОС включено ядро Linux. Контейнеры совместно используют ядро хост-ОС. Не путайте контейнер с ВМ, они разные, ведут себя по-разному и управляются по-разному.
Для смешивания и сопоставления разных приложений с разными конфигурациями и базами данных имеет смысл перейти к yml-файлу compose или kubernetes, в котором указано, какие образы и конфигурации развертывать. Когда вы меняете приложения, вы не просто меняете конфиги монолитного образа, вместо этого вы вытаскиваете соответствующий образ для этой конкретной задачи.
Вы можете сделать это, но вы никогда не должны объединять несколько сервисов в одном контейнере. У него много недостатков и никакой пользы.
Несколько недостатков:
Рассмотрите возможность использования Шлем.