У нас есть приложение весенней загрузки, которое зависит от openjdk-alpine базового образа. Мы создаем образы с помощью Docker и управляем оркестровкой через Kubernetes.
У нас также есть точка монтирования (NFS / CEPH) на нескольких узлах для хранения сгенерированных данных.
Предположение - Node1 в данный момент работает Image1
Два подхода к развертыванию нового кода (сценарий A) ИЛИ, когда контейнер умирает (сценарий B):
1-й подход:
- Новый код регистрируется, NewImage2 получает сборку на основе DockerFile и отправляется в реестр (применимо только для A)
- Узел2 развертывает новый Image2 (Сценарий A), или Узел2 развертывает Image1, когда контейнер Node1 умирает (Сценарий B)
2-й подход: Таким образом, существует общая точка монтирования между Node1 и Node2, которая имеет jdk, и всеми необходимыми основными двоичными файлами.
- Новый код регистрируется, Дженкинс собирает jar и отправляет его в общую точку монтирования (применимо только к сценарию A)
- Узел2 развертывает новый контейнер с JAR-файлом в общей точке монтирования (Оба сценария)
Аргумент в том, что подход 2 будет быстрее, так как он будет иметь все смонтированные двоичные файлы вместо загрузки его. Я чувствую, что это побеждает всю цель докеров и k8s, если мы просто хотим развернуть jar.
Пожалуйста, пролите немного света на эти 2 подхода.