Docker docker-compose не подбирает соответствующее кэшированное изображение

Question

Я побежал docker-compose build celery и (после нескольких часов попыток по моей плохой связи) это удалось. Первые 80% файла Dockerfile app идентичны, но он не повторно использует кеш. Из того, что я могу рассказать обо всём, Docker сравнивает базовое изображение и инструкции в файле Dockerfile и, если возможно, повторное использование.

---

ОБНОВЛЕНИЕ: Проблема в этом вопросе относится к исчезновению, не знаю почему. Примечания ниже.

---

Но я получаю:

docker-compose build celery 
Building celery 
Step 1 : FROM python:2.7 
---> eb867117097c 
Step 2 : RUN apt-get update && apt-get install -y vim gdal-bin libgdal-dev postgresql-client 
---> Using cache 
---> 2966946ca235 

. . . identical steps . . . 

Step 9 : RUN pip install --no-cache-dir -r requirements/production.txt 
---> Running in 02b42f721a34 
Collecting git+https://github.com . . . 
. . . 
---> f70ecc01cada 
Removing intermediate container 02b42f721a34 
Step 10 : RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 
---> Running in 3575383edcef 

Когда я типа docker images я могу видеть f70ecc01cada, но он не найден в следующем:

docker-compose build app 
Building app 
Step 1 : FROM python:2.7 
---> eb867117097c 
Step 2 : RUN apt-get update && apt-get install -y vim gdal-bin libgdal-dev postgresql-client 
---> Using cache 
---> 03e5040df047 

. . . identical steps . . . 

Step 9 : RUN pip install --no-cache-dir -r requirements/production.txt 
---> Running in bb26fab28548 
Collecting git+https://github.com . . . 
. . . 

Правильно ли я в размышлении последний должен повторно использовать кэшированное изображение f70ecc01cada? [Изменить: теперь я понимаю, что 03e5040df047 - это просто контейнер, спасибо @Ohmen, поэтому не нужно его удалять]

Я пробовал редактировать docker-compose, чтобы быть одинаковой памятью и т. Д., Но это не помогло. Могу ли я использовать повторное использование?

---

ОБНОВЛЕНИЕ: app построить внезапно начал собирание кэш из celery сборки. Я не знаю, что это зафиксировало. Между тем, что он не работал и работал, я подключился к изображению на иерархии celery, прежде чем Dockerfiles разошлись, вручную выполнили оставшиеся команды на изображении app (docker run -it ... --entry=bash, adduser) и docker committed. Затем я повторно запустил docker-compose build app и по какой-то причине он правильно взял кеш из иерархии celery и успешно выполнил оставшиеся команды (создать пользователя и chown). Я понятия не имею, что заставило его работать внезапно.

---

EDIT: история Docker двух деревьев изображения, показывающие, что история расходились на линии RUN apt-get update && apt-get install -y vim gdal-bin libgdal-dev postgresql-client. Может быть, я запустил оба сборника одновременно? Я был уверен, что этого не сделал, поскольку по моей связи они занимают час или больше, но, возможно, это скучное и неловкое объяснение. Возможно, Docker случайно выбрал дерево, которое впоследствии потерпело неудачу, затем случайным образом (после 56 попыток) выбрал тот, который этого не сделал.

Первые успешные сборки - слои виртуализированных снизу вверх:

Chriss-MacBook-Pro:~ technicaltitch$ docker history fdw_celery 
IMAGE    CREATED    CREATED BY          SIZE    COMMENT 
d71bf8f2b902  28 hours ago  /bin/sh -C#(nop) ENTRYPOINT ["/bin/sh" "-c" 0 B     
336bdb2b9ca9  28 hours ago  /bin/sh -C#(nop) USER [celery]    0 B     
a1259f89bc1f  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 15.39 MB    
57dd9a330337  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 335.2 kB    
3accad8aa55c  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 0 B     
b4ff0c1d71fb  28 hours ago  /bin/sh -C#(nop) COPY dir:a8f922c5264fe2275a 15.39 MB    
bc65bc84abbc  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 0 B     
f70ecc01cada  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 214.1 MB    
85eb413bd5da  28 hours ago  /bin/sh -C#(nop) ARG PIP_INDEX_URL=https:// 0 B     
3cee97bf3ce1  28 hours ago  /bin/sh -C#(nop) ARG PIP_TRUSTED_HOST=127.0 0 B     
cb090c4b1886  28 hours ago  /bin/sh -C#(nop) WORKDIR /usr/src/app   0 B     
d0a1d3d15f94  28 hours ago  /bin/sh -C#(nop) COPY dir:ec1503af2cbef5220d 3.145 kB    
e27ecd707562  28 hours ago  |1 http_proxy= /bin/sh -c mkdir -p /usr/src/a 0 B     
0b6e2857206c  28 hours ago  |1 http_proxy= /bin/sh -c VERSION=$(gdal-conf 5.903 MB    
2966946ca235  29 hours ago  |1 http_proxy= /bin/sh -c apt-get update && a 241.4 MB    
eb867117097c  42 hours ago  /bin/sh -C#(nop) CMD ["python2"]    0 B     

Во-вторых, не сумев построить, с таким же сценарием:

Chriss-MacBook-Pro:~ technicaltitch$ docker history 5ee 
IMAGE    CREATED    CREATED BY          SIZE    COMMENT 
5ee29875a771  29 hours ago  /bin/sh -C#(nop) ARG PIP_INDEX_URL=https:// 0 B     
daad37fd701b  29 hours ago  /bin/sh -C#(nop) ARG PIP_TRUSTED_HOST=127.0 0 B     
f891ee9277da  29 hours ago  /bin/sh -C#(nop) WORKDIR /usr/src/app   0 B     
2cce4acf9f2f  29 hours ago  /bin/sh -C#(nop) COPY dir:ec1503af2cbef5220d 3.145 kB    
9484e6b7fa51  29 hours ago  |1 http_proxy=None /bin/sh -c mkdir -p /usr/s 0 B     
0031cdd56926  29 hours ago  |1 http_proxy=None /bin/sh -c VERSION=$(gdal- 5.903 MB    
03e5040df047 <-- [already diverged]  |1 http_proxy=None /bin/sh -c apt-get update 243.1 MB    
eb867117097c  42 hours ago  /bin/sh -C#(nop) CMD ["python2"]    0 B     

Наконец, это история изображение после того, как она волшебным образом удалось. Я не уничтожал другие изображения, когда работал (и до сих пор нет):

Chriss-MacBook-Pro:~ technicaltitch$ docker history fdw_app 
IMAGE    CREATED    CREATED BY          SIZE    COMMENT 
edc615da4d6f  26 hours ago  /bin/sh -C#(nop) ENTRYPOINT ["/usr/src/app/ 0 B     
747c8744f6a7  26 hours ago  /bin/sh -C#(nop) EXPOSE 8000/tcp    0 B     
8c543333e10b  26 hours ago  /bin/sh -C#(nop) USER [django]    0 B     
b08f02d80d29  26 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 15.39 MB    
ba42415ad78b  26 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 335.2 kB    
027e0c8e39a9  26 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 0 B     
d56a78c02d18  26 hours ago  /bin/sh -C#(nop) COPY dir:9274abe4540edd1e86 15.39 MB    
bc65bc84abbc  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 0 B     
f70ecc01cada  28 hours ago  |3 PIP_INDEX_URL=https://pypi.python.org/simp 214.1 MB    
85eb413bd5da  28 hours ago  /bin/sh -C#(nop) ARG PIP_INDEX_URL=https:// 0 B     
3cee97bf3ce1  28 hours ago  /bin/sh -C#(nop) ARG PIP_TRUSTED_HOST=127.0 0 B     
cb090c4b1886  28 hours ago  /bin/sh -C#(nop) WORKDIR /usr/src/app   0 B     
d0a1d3d15f94  28 hours ago  /bin/sh -C#(nop) COPY dir:ec1503af2cbef5220d 3.145 kB    
e27ecd707562  28 hours ago  |1 http_proxy= /bin/sh -c mkdir -p /usr/src/a 0 B     
0b6e2857206c  28 hours ago  |1 http_proxy= /bin/sh -c VERSION=$(gdal-conf 5.903 MB    
2966946ca235 <-- [correct img, suddenly..why?!] ..xy= /bin/sh -c apt-get update && a 241.4 MB    
eb867117097c  42 hours ago  /bin/sh -C#(nop) CMD ["python2"]    0 B     

Ниже начало обоих Dockerfiles. Я попытался сделать определения машины в docker-compose.yml одинаковыми, но безрезультатно (возможно, после создания изображения 03e).

FROM python:2.7 

RUN apt-get update && apt-get install -y vim gdal-bin libgdal-dev postgresql-client 

# On Jessie, $(gdal-config --version) gives 1.10.1 and Pypi only has 1.10.0 
# so we need to strip the last part of the version number 
RUN VERSION=$(gdal-config --version); CFLAGS=$(gdal-config --cflags) easy_install GDAL==${VERSION%.*} 

RUN mkdir -p /usr/src/app/requirements 
COPY requirements /usr/src/app/requirements 

WORKDIR /usr/src/app 

ARG PIP_TRUSTED_HOST=127.0.0.1 
ARG PIP_INDEX_URL=https://pypi.python.org/simple/ 
RUN pip install --no-cache-dir -r requirements/production.txt 

# Clean up APT when done. 
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 

COPY . /usr/src/app 

RUN mkdir -p /usr/src/app/log 

Answer 1

---> 03e5040df047 это просто временное имя для контейнера это не указывает Diferent изображения ...

Docker использует кэш, если базовое изображение известно, и команды одинаковы. Для ADD od COPY также должна совпадать контрольная сумма файлов. Как будто я могу сказать, что докер использует кеш в вашем фрагменте.

Вы можете использовать только докер до not с помощью кеша.

Answer 2

COPY Требования/USR/SRC/приложение/требования

Если изменить любой файл в этом каталоге будет недействительной кэш с этого момента. Это включает в себя файлы tmp, созданные вашим редактором, если вы не поместили их в свой файл .dockerignore.

ARG PIP_TRUSTED_HOST = 127.0.0.1 ARG PIP_INDEX_URL = https://pypi.python.org/simple/

При изменении любого из этих ARG будет недействительным кэш с этого момента.

Я предполагаю, что одно из этих изменений, в результате чего оно пропускает кеш.