Создание контейнера зависимостей и монтирование его томов на другие контейнеры - PullRequest
0 голосов
/ 15 ноября 2018

У меня проблема с тем, что мои контейнеры стали слишком тяжелыми, и многие из них имеют много одинаковых зависимостей.

Я хотел бы создать базовый контейнер, который будет устанавливать и хранить все зависимости, а затем другие контейнеры, указывающие на dir зависимостей (с использованием томов) в этом базовом контейнере.

Я пытаюсь сделать небольшой POC для этого, и я начал с попытки установить один контейнер для установки пакета python, а затем другой контейнер, выполняющий сценарий python с использованием этого модуля.

Я думаю, что я создам каталог на хосте, который будет смонтирован на всех контейнерах и будет содержать все необходимые данные и зависимости.

Должен заметить, что я не могу использовать docker compose, хотя это, вероятно, лучше.

Это Dockerfile для моего базового контейнера:

FROM python:3.6-slim

RUN apt-get update && apt-get install -y vim

RUN pip install --install-option="--prefix=/volumes/shared/dependencies" deepdiff 

CMD tail -f /dev/null

Вы можете видеть, что pip установится в /volumes/shared/dependencies dir.

Я запускаю его так:

docker build -t base_container .
docker run -ti -v "$PWD/shared/base_dependencies":/volumes/shared/dependencies base_container

Теперь, если я иду в контейнер на /volumes/shared/dependencies, я вижу файлы, которые я поместил в директорию хоста, но не установленный пакет.С другой стороны, если директория хоста пуста, я вижу установленный пакет.

Я также попытался применить 2 тома (один для входящих файлов и один для файлов, которые создаст контейнер)

Как получить двусторонний том в этой ситуации, объяснениео том, почему это происходит, тоже будет приятно.

Ответы [ 2 ]

0 голосов
/ 15 ноября 2018

Один продуктивный подход, который вы можете предпринять, - это создать общую базу image , которая содержит ваши зависимости, а затем построить приложения поверх этого. Я покажу это, используя многоэтапный синтаксис Dockerfile, но вы можете сделать нечто подобное с совершенно отдельным базовым образом.

FROM python:3 AS base
RUN pip3 install numpy \
 && pip3 install scipy

FROM base
WORKDIR /app
COPY requirements.txt ./
RUN pip3 install -r requirements.txt
COPY . ./
CMD ["./myscript.py"]

Если бы у вас было несколько приложений, которым требовалась одна и та же большая базовая библиотека, все они могли бы создать FROM одно и то же базовое изображение, и они совместно использовали бы слои в этом изображении. (Немного зависит от настроек вашего репозитория.) Если вы затем обновите базовый образ, вам придется перестраивать приложения поверх него, но в то же время вещи, которые не были обновлены, защищены от неожиданных изменений под ними. им.

Делайте , а не делитесь кодом через тома. В частности, способность изображения вообще не запускаться зависит от какого-либо внешнего ресурса, которым изображение не управляет; это ломает точку изоляции Докера.

В качестве минимального примера того, что не так с подходом на основе объема:

docker run -d -v ./site-packages:/usr/local/lib/python3/site-packages ...
rm -rf site-packages/some-lib
# what now?
0 голосов
/ 15 ноября 2018

Когда вы делаете docker run с томом, он сначала создает каталог на вашем хост-компьютере, если он не существует, затем монтирует том, читая его. Итак, дело в том, что целевой каталог в контейнере будет заменен на каталог на хосте, в результате чего будет пустой каталог.

Просто скопируйте зависимость во время выполнения, и вам больше не нужен контейнер с tail -f

FROM python:3.6-slim

RUN apt-get update && apt-get install -y vim

RUN pip install --install-option="--prefix=/temp" deepdiff 

CMD cp -pr /temp /volumes/shared/dependencies
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...