Запуск Dockerized приложений для преобразования локальных файлов с неизвестными именами

Question

Я работаю над Dockerizing набором Ruby приложений, хранящихся на сервере. Большинство этих приложений используются для редактирования локальных файлов (различные zip и HTML файлы) на компьютере пользователя. Это общий рабочий процесс:

1. Пользователь добавляет свободные файлы в рабочую папку. Это файлы, с которыми они будут работать.
2. Пользователь запускает апплет, хранящийся в той же рабочей папке, что и файлы. Апплет запускает приложение основного средства доступа Ruby, которое открывает окно терминала и печатает список (из файла YAML) всех доступных приложений Ruby.
3. Пользователь выбирает имя нужного ему приложения. бежать. Приложение выполняется в рабочей папке, в файлах в этой папке.
4. Пользователь закрывает терминал, когда все готово.

Имена файлов не известны, но расширения: поэтому приложения используют класс каталогов Ruby с символом подстановки для перебора всех файлов в папке: Dir.glob("*.{file extension]").

Я создал Docker образ для приложений, который должен работать одинаково. Я не уверен, что сейчас это наиболее эффективный рабочий процесс, когда я использую Docker, но в любом случае это мой упрощенный Dockerfile:

FROM ruby:2.5

RUN mkdir /applications 
WORKDIR /applications

COPY Gemfile /applications/ 
COPY Gemfile.lock /applications/ 

RUN bundle install

COPY . /app_src

ENTRYPOINT ruby main.rb    # the main accessor app that prints the list of apps

и мой docker -композитный файл (с подключенным томом, чтобы мне было легче работать в режиме разработки):

version: '3'

services:
  script_library:
    build: ./app_src
    stdin_open: true
    tty: true
    volumes:
      - './app_src:/applications'

Естественно, что при тестировании приложения работают, если я включаю рабочие файлы в папку app_src. На практике, конечно, когда я создаю и запускаю образ, я не могу добавить файлы, для которых я хочу запускать приложения, потому что это зависит от выбора пользователя. Похоже, что единственный вариант - это монтировать файлы в том, к которому контейнер Docker может затем обратиться, но во всех примерах, которые я видел, для этого используются абсолютные пути.

Подводя итог, как заставить приложения Dockerized:

• запускаться на свободных файлах в локальной папке, из которой пользователь запускает приложения,
• запускать файлы без известных имен файлов или абсолютных путей ( приложения используют относительные пути для поиска и изменения файлов) и
• выводят новые версии файлов в одну и ту же папку после завершения запуска приложений?

Answer 1

Вы правы, что у вас нет выбора, кроме как использовать привязку здесь. Однако на чистом Docker уровне нет конкретного требования c, чтобы вы использовали один и тот же путь на стороне хоста и контейнера.

Типичная настройка для этого - выбрать некоторый фиксированный путь внутри контейнер и рассматривать это как часть внешнего интерфейса контейнера. Есть несколько способов справиться с этим; вероятно, лучше всего сделать так, чтобы скрипт принимал имя пути в качестве параметра

# Copy the application source into the same place as the Gemfile
# (This is a correction from the original Dockerfile)
COPY . /application

# When the container is launched, explicitly pass an alternate
# directory /data as a command-line parameter
# (Use JSON-array form for ENTRYPOINT so that additional parameters
# passed in CMD don't get swallowed)
ENTRYPOINT ["ruby", "/application/main.rb", "/data"]

, а затем передавал монтирование bind при его запуске

docker run      \
  --rm          \  # delete the container on exit
  -it           \  # accept interactive input
  -v $PWD:/data \  # mount current directory on /data
  -u $(id -u)   \  # run as host user ID
  myscript         # image name
                   # do not bind mount content over the image code

Даже при этом существует число вещей, которые контейнер не может сделать, например, запустить новое окно терминала. Точно так же Docker Compose обычно ориентирован на параллельную работу нескольких долго выполняющихся контейнеров, и он может не работать просто с docker-compose up файлом, который вы показываете. (Я ожидаю, что docker-compose run script_library сработает.)

Обратите внимание, что вы тратите немало усилий, чтобы обойти изоляцию файловой системы Docker, и по-прежнему существуют серьезные проблемы с безопасностью (что происходит если вы используете -u root -v /etc:/data?). Для инструментов, основной целью которых является чтение и запись локальных файлов, Docker обычно не подходит как механизм упаковки. Это вдвойне верно, если скрипт находится в том же каталоге, что и файлы, над которыми вы работаете, как вы описали в вопросе; проще просто установить Ruby и запустить ruby main.rb.