Поскольку можно иметь хороший контейнер Docker для запуска всей сборки, было бы замечательно, если бы инструменты, используемые контейнером для сборки и запуска кода, были доступны для хоста.
Представьте себе следующий вариант использования:
- Представьте, что вы разрабатываете приложение Java с использованием OpenJDK 12 и Maven 3.6.1, чтобы собрать, запустить все тесты и упаковать все приложение в исполняемый файл .jar.
- Вы создаете Docker-контейнер, который служит «сборочным контейнером». В этом контейнере установлены OpenJDK 12 и Maven 3.6.1, и его можно использовать для сборки и упаковки всего приложения (вы можете использовать его локально, во время разработки, а также на сервере сборки, вызывая сборку всякий раз, когда происходят изменения кода). толкнул).
Теперь вы действительно хотите начать писать некоторый код ... естественно, вы пойдете дальше и откроете свой проект в вашей любимой IDE (IntelliJ IDEA?), Сконфигурируете SDK проекта и все, что еще нужно настроил и начал качать!
Разве не было бы фантастически иметь возможность сказать IntelliJ (Eclipse, NetBeans, VSCode и т. Д.) Просто использовать те же инструменты с теми же версиями, что и контейнер сборки? Конечно, вы можете сказать своей IDE делегировать сборку «сборочному контейнеру» (Docker), но без установки соответствующего «Project SDK» (и других конфигов), тогда вы будете «кодировать в темноте» ... вы потерял бы почти все преимущества использования мощной IDE для разработки. Никаких подсказок по коду, никакого статического анализа кода и т. Д. И т. Д. И т. Д. Ваша классная и модная среда IDE по сути сводится к простому текстовому редактору, который может по крайней мере вызвать полную сборку, вызвав ваш контейнер сборки.
Чтобы продолжать пользоваться многими функциями IDE, вам необходимо установить OpenJDK 12, Maven 3.6.1 и все, что вам нужно (по сути, те же инструменты, с которыми вы уже потратили время на настройку образа Docker) и затем сообщите IDE, что «они» - это инструмент, который следует использовать для «этого» проекта.
К сожалению, слишком легко случайно установить неправильную версию инструмента на вашем хосте (локально), что потенциально может привести к синдрому "он работает на моей машине". Конечно, вы все равно заметите проблемы в будущем, когда проект будет построен с использованием соответствующих инструментов и версий сборочным контейнером / сервером, но ... не говоря уже о том, какими неприятными могут быть ситуации, когда нужно поддерживать целый зоопарк инструменты и их версии на вашем компьютере (+ возможно, имеешь дело со всеми видами фанки-несовместимостей или взаимодействий между всеми инструментами), когда вам приходится работать над несколькими проектами (один проект требует JDK 8, другой JDK 11, другой использует Gradle , а не Maven, тогда вам также понадобится Node 10, Angular 5, но также 6 и т. д. и т. д.).
До сих пор я сталкивался только с любопытными обходными путями, но без «хорошего» решения. Самое терпимое, что я нашел до сих пор, - это вручную выставить (скопировать) инструменты из контейнера на хост-машине (например: определить том, общий для обоих, а затем выполнить ручной сценарий, который не будет копировать инструменты из контейнера в общий каталог тома, чтобы хост мог также обращаться к ним) ... хотя это будет работать, к сожалению, это включает ручной шаг, который означает, что всякий раз, когда контейнер обновляется (например, используются новые версии определенных инструментов или даже дополнительные, полностью) новые), тогда разработчик должен помнить, чтобы выполнить шаг ручного копирования (выполнить любой скрипт явно), чтобы все новейшие и лучшие материалы были доступны хосту еще раз (конечно, это могло бы означать обновление конфигураций IDE как - но это - по крайней мере, обновление версии - может быть в значительной степени смягчено, если инструменты находятся в не зависящих от версии путях).
У кого-нибудь есть идеи, как этого добиться? Виртуальные машины исключены и могут показаться излишним ... Я не понимаю, почему доступ к ресурсам контейнера Docker в режиме только для чтения не должен быть возможным, а повторное использование и ссылка соответствующий инструментарий при разработке и сборке.