Utworzyłem kilka różnych katalogów na moim komputerze-hoście, próbując poznać Docker tylko po to, aby moje pliki dockerowe były uporządkowane. Mój plik Dockerfile, który właśnie uruchomiłem, wygląda następująco:

FROM crystal/centos
MAINTAINER crystal

ADD ./rpms/test.rpm ./rpms/ 
RUN yum -y --nogpgcheck localinstall /rpms/test.rpm 

Moje rzeczywiste obroty to tylko 1 GB. Ale kiedy próbuję to zrobić sudo docker build -t="crystal/test" ., wysyłam kontekst kompilacji do demona Dockera o pojemności 3,5 GB. Czy jest coś jeszcze, czego nie jestem świadomy, gdy nadal tworzysz obrazy Dockera? Czy moja pamięć gromadzi się, gdy tworzę więcej obrazów w innych katalogach na moim komputerze głównym?

Klient platformy Docker wysyła cały „kontekst kompilacji” do demona platformy Docker. Ten kontekst budowania (domyślnie) to cały katalog, w którym się Dockerfileznajduje (czyli całe rpmsdrzewo).

Możesz skonfigurować .dockerignoreplik, aby Docker ignorował niektóre pliki. Możesz z tym poeksperymentować.

Alternatywnie, możesz przenieść swój rpmsfolder o jeden poziom wyżej niż twój Dockerfilei tylko symboliczne łącze test.rpmdo Dockerfilekatalogu.

Często będziesz chciał dodać .gitfolder do folderu,.dockerignore który był przyczyną różnicy 150 MB -> 5 GB dla niektórych użytkowników w komentarzach tutaj.

Zaktualizuj 2019

Począwszy od wersji Docker 18.06 istnieje możliwość użycia nowego narzędzia do tworzenia obrazów o nazwie Build Kit .

Jest wstępnie dołączony do Dockera, nie trzeba niczego instalować. Jest wstecznie zgodny ze Dockerfileskładnią, nie trzeba zmieniać rozszerzenia Dockerfile.

Legacy Docker Build vs New Docker BuildKit

Oto przykład budowania obrazu z ogromnym nieużywanym plikiem w katalogu kompilacji:

Starsza kompilacja platformy Docker:

$ time docker image build --no-cache .
Sending build context to Docker daemon  4.315GB
[...]
Successfully built c9ec5d33e12e

real    0m51.035s
user    0m7.189s
sys 0m10.712s

Nowy zestaw Docker BuildKit:

$ time DOCKER_BUILDKIT=1 docker image build --no-cache .
[+] Building 0.1s (5/5) FINISHED                                                
 => [internal] load build definition from Dockerfile                       0.0s
 => => transferring dockerfile: 37B                                        0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
[...]
 => => writing image sha256:ba5bca3a525ac97573b2e1d3cb936ad50cf8129eedfa9  0.0s

real    0m0.166s
user    0m0.034s
sys 0m0.026s

Jedyną zmianą jest DOCKER_BUILDKIT=1zmienna środowiskowa, różnica w czasie jest ogromna.

.dockerignore Plik

Należy pamiętać, że .dockerignoreplik jest nadal aktualny i przydatny. Niektóre Dockerfilepolecenia, takie jak COPY . ., nadal będą uwzględniać .dockerignorezasady. Ale pliki poboczne w katalogu kompilacji (nie Dockerfileprzywoływane w ) nie są już kopiowane jako „kontekst kompilacji” przez BuildKit.

Naprawiłem to, przenosząc mój plik Dockerfile i docker-compose.yml do podfolderu i działało świetnie. Najwyraźniej docker wysyła bieżący folder do demona, a mój folder to 9 gigów.

Jeśli masz .dockerignoreplik, a kontekst kompilacji jest nadal duży, możesz sprawdzić, co jest wysyłane do kontekstu kompilacji platformy Docker za pomocą programu The Silver Searcher :

ag --path-to-ignore .dockerignore --files-with-matches

Zwróć uwagę, że niektóre **wzorce mogą nie działać poprawnie.

Zobacz ten numer Github, aby uzyskać dodatkowe komentarze: https://github.com/moby/moby/issues/16056

W moim przypadku było to wtedy, gdy -fwykonuję z niewłaściwymi argumentami - bez ścieżki do katalogu, w którym znajduje się plik Dockerfile

docker build --no-cache -t nginx5 -f /home/DF/Dockerfile /home/DF/ - dobrze

docker build --no-cache -t nginx5 -f /home/DF/Dockerfile - źle

Jeśli chcesz mieć pełną kontrolę nad kontekstem kompilacji, możesz później zbudować kontener całkowicie bez kontekstu i COPYodpowiednich danych.

docker build - < Dockerfile

Jedynym minusem tego byłoby to, że przy takim podejściu można to zrobić tylko ADD rzeczy w pliku docker odwoływać się do zdalnego adresu URL, a nie pliki z lokalnego hosta.

Zobacz https://docs.docker.com/engine/reference/commandline/build/#build-with--

Miałem ten sam problem co FreeStyler. Jednak budowałem z katalogu jeden w górę z mojego kontekstu. Więc argumenty -f były poprawne, kontekst był nieprawidłowy.

project 
|
-------docker-dir 

Budowanie z katalogu docker-dir było w porządku

docker build -t br_base:0.1 . 

Budowanie z dock-dir zmienił się kontekst budowania. Dlatego musiałem zmienić kontekst w poleceniu. Kontekst jest określony przez „.” w powyższym poleceniu.

Nowa komenda z katalogu projektu powinna brzmieć

docker build -t br_base:0.1 ./base

Kontekst jest tutaj określony przez „./base”

jeśli tworzysz obraz i otrzymujesz wiadomość wysyłającą kontekst kompilacji do demona Dockera którego skopiowanie zajmuje czas w logu,

następnie dodaj plik .dockerignore . powinien zawierać pliki lub katalog, których nie trzeba kopiować.

W przypadku NodeJS ApplicationDodaj .dockerignoreplik do katalogu głównego projektu i wewnątrz .dockerignorepliku dodaj następujące elementy

node_modules
dist

Podsumowując, co możesz zrobić, jeśli kontekst kompilacji obrazu platformy Docker jest zbyt duży:

• upewnij się, że nie masz nieużywanych plików w kontekście (nieużywane pliki - te, które wciąż są nietykalne podczas budowania obrazu);
• dodaj nieużywane pliki i / lub katalogi do .dockerignore (jak wspomniano tutaj );
• upewnij się, że określasz właściwy folder jako kontekst budowania obrazu (jak wspomniano tutaj );
• spróbuj użyć BuildKit z DOCKER_BUILDKIT = 1 (jak wspomniano tutaj );
• spróbuj podzielić projekt na mniejsze części, aby zoptymalizować zawartość kontekstu kompilacji;
• jeśli masz złożony projekt, możesz chcieć ręcznie zebrać wszystkie niezbędne pliki w oddzielnym folderze przed kompilacją i użyć ich jako kontekstu kompilacji dla określonego obrazu.