Смущает Dockerfile - PullRequest
       12

Смущает Dockerfile

1 голос
/ 03 августа 2020

Меня смущает Dockerfile и процесс сборки. В частности, я прорабатываю книгу Docker на AWS и чувствую себя застрявшим, пока не смогу проработать еще несколько деталей. Книга заставила меня написать следующий файл Docker.

#Test stage
FROM alpine as test
LABEL application=todobackend

#Install basic utilities
RUN apk add --no-cache bash git

#Install build dependencies
RUN apk add --no-cache gcc python3-dev libffi-dev musl-dev linux-headers mariadb-dev py3-pip
RUN ../../usr/bin/pip3 install wheel

#Copy requirements
COPY /src/requirements* /build/
WORKDIR /build

#Build and install requirements
RUN pip3 wheel -r requirements_test.txt --no-cache-dir --no-input
RUN pip3 install -r requirements_test.txt -f /build --no-index --no-cache-dir

# Copy source code
COPY /src /app
WORKDIR /app

# Test entrypoint
CMD ["python3","manage.py","test","--noinput","--settings=todobackend.settings_test"]

Ниже приводится список вещей, которые я понимаю и не понимаю.

  1. Я понимаю это.
    #Test stage
    FROM alpine as test
    LABEL application=todobackend

Он определяет стадию «тестирования», поэтому я могу запускать такие команды, как docker build --target test, и выполнять все следующие команды, пока следующая команда FROM / as не укажет на другую цель. LABEL обозначает конкретное изображение c docker, которое создается и из каких контейнеров будут «рождены» (не уверен, что это правильное слово). Я не чувствую путаницы по этому поводу, ИСКЛЮЧАЯ, если этот тег переводится в контейнеры, порожденные этим изображением.

Итак, СЕЙЧАС я начинаю чувствовать себя сбитым с толку.

Я ЧАСТИЧНО это понимаю
    #Install basic utilities
    RUN apk add --no-cache bash git

Я понимаю, что apk - это перегруженный термин, который представляет как диспетчер пакетов на Alpine Linux, так и тип файла. В данном контексте это команда диспетчера пакетов для установки (или обновления) пакета в работающей системе. ОДНАКО, я предполагаю, что собираю / упаковываю приложение и все его зависимости в закрытую «среду». Тааак ... где / когда появляется эта «среда»? Вот где я смущаюсь. Когда файл docker запускает apk, он просто говорит: «локально, на вашем текущем компьютере, пожалуйста, установите их обычным способом». (ie, эквивалент сценария bash, в котором apk устанавливается в свой рабочий каталог). Когда я запускаю docker build --target test -t todobackend-test в своем ранее вставленном файле docker, выполняет ли команда docker как собственное выполнение команды, так и вызов Docker Engine для создания изолированной среды для моего изображения docker? Мне feel нравится то, что должно происходить, когда команда docker запускается, она действует как оболочка вокруг встроенного диспетчера пакетов / bash / функций pip И механизма docker и делает и то, и другое, но я не Не знаю.

В любом случае, я надеюсь, что это имело смысл. Мне просто нужны некоторые детали реализации. Не стесняйтесь ссылаться на документацию, но она может показаться слишком утомительной и излишне подробной ИЛИ иногда запутанной. вместо py3-pip). Я получаю очень интересную ошибку:

/bin/sh: pip3: not found Обратите внимание на путь к команде. Я полагаю, что любой, кто читает это, поймет, почему это чертовски сбивает с толку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...