Обычно контейнеры Docker не могут получить доступ к хост-устройствам и не должны монтировать дополнительные файловые системы. Эти ограничения даже ужесточаются во время последовательности docker build
, потому что различные варианты, которые позволят вам обойти это, вам недоступны.
Самый простой вариант - написать скрипт-обертку, который будет монтировать и размонтировать вас, что-то вроде:
#!/bin/sh
if [ ! -d tools ]; then mkdir tools; fi
mount -r tools.iso tools
docker build "$@" .
umount tools
Тогда у вас может быть двухэтапный образ Docker, где первый этап имеет доступ ко всему содержимому DVD и запускает установщик, а второй этап фактически создает образ, который вы хотите запустить. Это выглядело бы примерно (совершенно гипотетически)
FROM registry.access.redhat.com/rhscl/devtoolset-7-toolchain-rhel7:latest AS install
COPY tools tools
RUN cd tools && ./install.sh /opt/whatever
FROM registry.access.redhat.com/rhscl/devtoolset-7-toolchain-rhel7:latest
COPY --from=install /opt/whatever /opt
EXPOSE 8888
CMD ["/opt/whatever/bin/whateverd", "--bind", "0.0.0.0:8888", "--foreground"]
Очевидная проблема с этим состоит в том, что все содержимое DVD будет отправлено по сетевому каналу от хоста к себе как часть последовательности docker build
, а затем снова скопировано на этапе COPY
; если он попадает в диапазон гигабайт, то это становится громоздким. Вы можете использовать файл .dockerignore
, чтобы некоторые из них были скрыты, чтобы немного ускорить процесс.
В зависимости от того, что представляет собой программное обеспечение, вы должны также рассмотреть вопрос о том, может ли оно успешно работать в контейнере Docker (ожидает ли оно запуска нескольких служб с довольно жестким шаблоном связи?); виртуальная машина может оказаться лучшим вариантом развертывания, а «монтирование DVD на ВМ» - гораздо более определенная операция.