как мне вообще отладить проблему такого рода. Как я могу знать, ПОЧЕМУ docker -композит думает, что все изменилось (хотя я почти уверен, что НИЧЕГО не изменилось), какие файлы / команды / результаты отличаются
В общем, , как показано здесь :
Я немного расстроен тем, что не могу найти способ заставить Docker построить более многословный
Но когда это приходит к docker -составить , это зависит от вашей версии и используемой опции.
moby/moby выпуск 30081 объясняет ( Себастьян ван Стейн (thaJeztah) ) :
Текущие версии docker-compose и docker build во многих (или всех) случаях не будут совместно использовать кэш сборки или, по крайней мере, не создавать тот же дайджест.
Причина в том, что при отправке контекста сборки с docker-compose он будет использовать немного другое сжатие (docker-compose записано в Python, тогда как docker cli записано в Go) .
Могут быть и другие различия из-за другой реализации (и языка).
(это было также обсуждается в docker / compose проблема 883 )
В следующем выпуске docker compose будет иметь (в настоящее время opt-in) функцию, позволяющую использовать фактический docker cli, чтобы выполнить сборку (установив переменную окружения COMPOSE_DOCKER_CLI_BUILD=1). Это было реализовано в docker / compose # 6865 (1.25.0-rc3 +, октябрь 2019)
С этой функцией docker compose также может использовать BuildKit для построения образов (установка переменной среды DOCKER_BUILDKIT=1).
Я бы настоятельно рекомендовал использовать buildkit для ваших сборок, если это возможно .
При использовании BuildKit (требуется Docker 18.09 или выше, и на данный момент не поддерживается сборка Windows контейнеров), вы увидите значительное улучшение скорости сборки и продолжительности отправки контекста сборки демону в повторных сборках (сборка использует интерактивный сеанс для отправки только тех файлов, которые необходимы во время сборки, вместо загрузки всего контекста сборки).
Поэтому сначала проверьте, если ваш docker -compose использует BuildKit, и если проблема (кэширование не используется повторно) сохраняется затем:
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Себастьян добавил в проблему 4012 :
BuildKit все еще не включен (так как нет Windows поддержка пока), бу Это качество производства, и его можно использовать по умолчанию для создания Linux изображений.
Наконец, я понимаю, что для конвейеров Azure у вас (вероятно) нет контроля над версиями Docker и Docker Compose установлен, но для локальных компьютеров обязательно обновите его до последней версии патча 19.03; например, Docker 19.03.3 и выше имеют различные улучшения и исправления в механизмах кэширования BuildKit (см., например, docker # 373 ).
Обратите внимание, что в вашем конкретном случае, даже если это не главная проблема в вашем вопросе, было бы интересно узнать, поможет ли следующее:
yarnpkg / yarn / issue 749 предлагает:
Вы не смонтируете каталог кэша пряжи. Вместо этого вам следует убедиться, что вы используете преимущества кэширования слоя изображений Docker.
Вот команды, которые я использую:
COPY package.json yarn.lock ./
RUN yarn --pure-lockfile
Затем попробуйте yarn install команда, и посмотрите, если docker все еще не использует свой кеш.
RUN yarn install --frozen-lockfile --production && yarn cache clean
Не забудьте yarn cache clean, чтобы предотвратить кеш пряжи от наматывания в docker слоев .
Если проблема не устранена, переключитесь на buildkit напрямую (для тестирования), набрав buildctl build --progress=plain, чтобы увидеть более подробный вывод, и отладьте ситуацию кэширования.
Как правило, многоступенчатый подход, как показано здесь , может быть полезен:
FROM node:alpine
WORKDIR /usr/src/app
COPY . /usr/src/app/
# We don't need to do this cache clean, I guess it wastes time / saves space: https://github.com/yarnpkg/rfcs/pull/53
RUN set -ex; \
yarn install --frozen-lockfile --production; \
yarn cache clean; \
yarn run build
FROM nginx:alpine
WORKDIR /usr/share/nginx/html
COPY --from=0 /usr/src/app/build/ /usr/share/nginx/html