Комментарии 16
А где "подводный камень" то? Вы же в "stage-1" не задали переменных в cmd [ ]. Дело в том, что в докере cmd запускает новый шел, он наследует переменные, а вот cmd [ ] (форма со скобками) запускает только то что вы укажете и это описано в документации. У вас указано запустить java с двумя параметрами и никаких переменных.
Справедливости ради я об этом тоже не из документации узнал и это не очевидное поведение, но как оказалось документированное в той части, что [ ] не запускают шел.
Добрый день, благодарю вас обратную связь. Я правильно понимаю, что аргументы из build-stag в CMD[] будут видны?
Будет видно все что прописано в ENV у вас running stage. Т е если как в статье написано, то должны быть видны. Только учтите вот это: https://stackoverflow.com/questions/40454470/how-can-i-use-a-variable-inside-a-dockerfile-cmd
Ха, я когда увидел статью - тоже об этом подумал. Я на днях сделал свой первый docker file и столкнулся с этим - не переопределяются переменные при использовании cmd и entrypoint.
Не понял, в чем подводный камень? Ожидалось, что после стадии сборки, переменные окружения будут сохранены в jar?
У Spring Boot есть ещё одна очень удобная фишка при использовании configuration property под названием relaxed binding:
https://docs.spring.io/spring-boot/reference/features/external-config.html#features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables
Например в приведённом application.properties можно написать просто application.my.variable=HELLO FROM APPLICATION (без ${НАЗВАНИЕ_ПАРАМЕТРА:значение по умолчанию}).
А в Dockerfile написать: ENV APPLICATION_MY_VARIABLE='HELLO FROM BUILD STAGE'.
И при старте приложения в параметре application.my.variable будет именно 'HELLO FROM BUILD STAGE', а не значение по умолчанию.
То есть даже если в исходниках отсутствует конструкция ${НАЗВАНИЕ_ПАРАМЕТРА} значение в application.properties всё равно можно легко настраивать при запуске приложения.
Опять попался на кликбейт(
Если использовать хелм для деплоя, то можно использовать buildArgs и deployArgs в values.yaml для передачи переменных в контейнер, а там уже забирать их из окружения и подменять ими переменные объявленные в application.yaml.
Таким образом можно передеплоивать приложение изменяя deployArgs без нужды пересборки образа, например передавая их из cicd или gitlab variables.
При работе с Apache Maven мы можем получить в результате сборки application.jar (далее jar-файл), а после запросто запустить (при условии, что pom.xml, верно, настроен) приложение
а какая взаимосвязь между pom и запуском jar ? Или имелось ввиду запуск jar из самого мавена ?
Добрый день, имел ввиду если произойдет не совместимость некоторых зависимостей в pom.xlm, то сборка может не произойти. Для сборки с помощью Apache Maven необходимо ввести в терминал mvn package (mvn clean package - рекомендуется, чтобы очистить пакет target). Суть такова, что при вводе команды происходит автоматическое выполнение: validate (проверка совместимости зависимостей) -> compile (компиляция java-файлов) -> test (тестирование) -> package (сборка jar-файла).
Подводный камень в docker env и java