#angular #spring-boot #docker #dockerfile
#angular #spring-boot #docker #dockerfile
Вопрос:
У меня есть два разных проекта spring boot и angular project. Теперь я хочу создать образ docker, который будет включать оба проекта. Я проверил, maven-resource-plugin в который копируются файлы angular spring-boot /target/classes/resources directory . И docker-maven-plugin из которого создается образ docker spring-boot-app .
Должен ли я использовать выходные данные обоих плагинов для создания желаемого результата или мне следует изменить способ создания образа docker? Теперь мой образ docker — это образ сборки из spring boot app.
FROM java:8
VOLUME /tmp
ADD gs-spring-boot-docker-0.1.0.jar app.jar
RUN bash -c 'touch /app.jar'
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
Комментарии:
1. Есть ли причина для развертывания обоих в одном контейнере? Я предлагаю развернуть в другом контейнере, создав два разных образа
2. Ну, это веб-приложение будет использоваться редко, примерно раз в месяц, и я не хочу постоянно поддерживать отдельный контейнер пользовательского интерфейса для этого.
Ответ №1:
Вы можете разместить wwwroot, созданный webpack, в виде статических файлов, обслуживаемых вашим приложением spring boot.
Вместо запуска вашего приложения angular на webpack-dev путем выполнения ng serve вам следует создать статические файлы с помощью ng build --prod (я могу неправильно написать некоторые команды, записывая из памяти) и поместить их в виде статических файлов в spring boot app, как показано здесь https://spring.io/blog/2013/12/19/serving-static-web-content-with-spring-boot
Я не эксперт по spring, но вы можете сделать это, как вы сказали. Конечно, было бы неплохо иметь отдельный контейнер только с интерфейсом, но если ваше spring приложение будет тесно связано с интерфейсом и не будет обслуживать api для других сервисов, вы можете выбрать решение, размещающее angular на spring boot server.
В конце концов, вы просто отправляете файлы html, js и css в браузер клиента, где код выполняется в реальном времени, поэтому размещение статических файлов не будет обременительным.
Было бы разумно отделить api от службы обслуживания внешнего интерфейса (т. Е. nginx, httpd), если вы хотите масштабировать только внутреннюю службу для обработки большего трафика, но я думаю, что здесь это не тот случай.