Ответ 1

Ваше понимание неверно.

Изображения докеров формируются слоями; см. следующую диаграмму:

Когда вы устанавливаете JRE на свой образ, пусть предположим, что его контрольная сумма равна 91e54dfb1179 на следующем рисунке, она действительно займет ваш диск.

Но, если все ваши контейнеры тогда все основаны на одном и том же изображении и добавляют разные вещи, говорит, ваше другое приложение микросервиса на тонкий слой R/W, все контейнеры будут делиться 91e54dfb1179, так что это не будет n * m отношения.

Вы должны обратить внимание на использование одного и того же базового изображения для всех приложений Java, насколько это возможно, и добавить разные вещи к тонкому слою R/W.

Ответ 2

Остальные ответы на докеры очень хорошо отражены, поэтому я просто хочу добавить детали для вас.

Правильно ли этот подход? Следует ли добавлять "OpenJDK" из DockerHub к каждому изображению?

Да. Если это не изображение, оно не будет в контейнере. Вы можете сэкономить дисковое пространство, используя повторное использование как можно большего количества слоев. Поэтому попробуйте написать свой файл Docker из "Скорее всего, чтобы измениться" на "Скорее всего, чтобы измениться". Итак, когда вы создаете свой образ, чем чаще вы видите "Использование кеша", тем лучше.

Почему размер изображения большой, даже если у целевого ПК уже есть JDK?

Докер хочет как можно меньше общаться с хостом. Докер даже не хочет иметь дело с хозяином. Первое, что он делает, это создать виртуальную машину для скрытия. Изображения Docker предполагают, что единственное, что предоставит хост, это пустые RAM, диск и процессоры. Поэтому каждое изображение Docker также должно содержать его собственную ОС/ядро. (Это то, что делает ваш первоначальный ОТ, выбор образа базовой ОС для использования). Таким образом, ваш конечный размер изображения - это OS + tools + app. Размер изображения немного вводит в заблуждение, поскольку он представляет собой сумму всех слоев, которые повторно используются через изображения.

(Подразумевается) Должно ли каждое приложение/микросервис находиться в собственном контейнере?

В идеале, да. Преобразование вашего приложения в изолированный модуль упрощает замену/балансировку этого модуля.

На практике, может быть, нет (для вас). Spring Boot не является легкой основой. Фактически, это основа для модуляции вашего кода (Эффективно работает система управления модулем внутри системы управления модулем). И теперь вы хотите разместить 10-20 из них? Вероятно, это не будет работать на одном сервере. Docker заставит Spring загружать себя в память за приложение; и объекты теперь не могут быть повторно использованы через модули, поэтому они тоже должны быть созданы с несколькими экземплярами! И если вы ограничены одним производственным сервером, горизонтальное масштабирование не является вариантом. (Вам понадобится ~ 1 ГБ HEAP (ОЗУ) за каждую весеннюю загрузку, прогоните мою очень основанную на базе кода). И с 10-20 приложениями, рефакторинг, чтобы сделать приложение легче для развертывания Docker, может оказаться невозможным/в бюджете. Не говоря уже о том, что если вы не можете выполнить минимальную настройку локально для тестирования (недостаточная ОЗУ), усилия по разработке получат намного больше "удовольствия".

Докер - не золотой молот. Попробуйте, оцените плюсы и минусы, и решите, стоят ли плюсы за минусы для вас и вашей команды.

Ответ 3

Вы должны изучить Union Fileystem docker.

Унифицированная файловая система позволяет каждому слою, который создается для повторного использования неограниченным количеством изображений. Это экономит много места на диске и позволяет создавать изображения быстрее, поскольку это просто повторное использование существующего уровня.

Кроме того, верхний уровень чтения/записи дает вид, что вы можете изменить изображение, но нижележащие уровни только для чтения сохраняют целостность контейнера, изолируя содержимое файловой системы.

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

Я решил использовать tianon/true изображение с его сверхлегкого веса в 125 байт. Но потом я помню, что я использовал базу Ubuntu для своего веб-приложения. Поэтому, если у меня уже есть образ Ubuntu, на самом деле лучше просто повторно использовать это базовое изображение для моего контейнера томов данных вместо создания большего количества слоев с использованием tianon/true.

Ответ 4

Ответ Lagom велик, но я хотел бы добавить, что размер контейнеров Docker должен быть настолько малым, насколько это возможно, чтобы облегчить передачу и хранение.

Следовательно, существует множество контейнеров, основанных на дистрибутиве Alpine Linux, которые очень малы. По возможности используйте их.

Кроме того, не добавляйте каждый инструмент, который можно вообразить в вашем контейнере, например, вы часто можете обойтись без wget...