The build and copy steps take an absurdly long time

[krainboltgreene]

Description

While building my containers with docker-compose build I'm encountering absurdly long build times. The Building {{container}} step takes upwards of 2 minutes and a simple COPY {{file}} {{file}} can take upwards of 1 minute.

Steps to reproduce the issue:

1. Run docker-compose build
2. Watch

Describe the results you received:

It took a long time on very simple operations.

Describe the results you expected:

It doesn't take a long time.

Additional information you deem important (e.g. issue happens only occasionally):

I'm building containers locally, on a Mac, via Docker Toolset.

Output of docker version:

$ docker-machine ssh wolf-machine docker version
Client:
 Version:      1.13.0
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Wed Jan 18 16:20:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.0
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Wed Jan 18 16:20:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

$ docker-machine ssh wolf-machine docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 32
Server Version: 1.13.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 86
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.4.43-boot2docker
Operating System: Boot2Docker 1.13.0 (TCL 7.2); HEAD : 5b8d9cb - Wed Jan 18 18:50:40 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.858 GiB
Name: wolf-machine
ID: 6ZPY:NZFB:4FGB:SCNM:5N7S:7OOH:7WNH:7DGW:Z2YY:BMID:MLTD:DHTH
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 72
 Goroutines: 76
 System Time: 2017-01-24T17:40:04.496970561Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

[krainboltgreene]

My host machine is beefy as all heck, so I doubt it's that:

[krainboltgreene]

Also, I'm using NFS via docker-machine-nfs: https://github.com/adlogix/docker-machine-nfs

[thaJeztah]

The actual build is executed on the daemon. When doing a build, the "build context" is therefore sent to the daemon as a tar archive; the time to start the build therefore dependent on the size of your build context (the directory from which you're starting the build); can you tell how big the context is?

[krainboltgreene]

@thaJeztah If you can give me the commands to do it I'll get you what you need. I love docker and want to see if I can fix this for my team.

[thaJeztah]

@krainboltgreene just the size, and number of files that are in the directory that your Dockerfile is in (right-click get info in the Finder should do)

[krainboltgreene]

@thaJeztah

$ du -hs .
1.2G	.

[krainboltgreene]

Okay, so I did some spring cleaning and I'm down to 622MB, 420 of which are from {{container}}/node_modules/.

If my project tree looks like this:

| tree -L 2
.
├── FAQ.md
├── README.md
├── a
│   ├── Dockerfile
│   ├── node_modules/
├── docker-compose.yml
├── b
│   ├── Dockerfile
├── c
│   ├── Dockerfile
│   ├── README.md
│   └── vendor/
│   ├── node_modules/
└── d
    ├── Dockerfile

How do I ignore node modules in a and c for the sake of build context?

[thaJeztah]

In your docker-compose you can specify the "context", so for docker-compose to build a/Dockerfile you just specify build ./a/ then, for building that dockerfile, docker will tar the content of "a" and send it to the daemon. (see https://docs.docker.com/compose/compose-file/#/build)

If your source code doesn't change, repeated builds should be able to use the cache, but docker will always send the build-context (to verify if the source files changed)

In addition, you can use a .dockerignore file to exclude files from being added to your image

[krainboltgreene]

@thaJeztah I feel like I've tried to use .dockerignore and it wouldn't ignore, but maybe I was just doing it wrong. I'll give it another try.

[krainboltgreene]

Also, thanks a lot for the information.

[pafmaf]

I feel like I've tried to use .dockerignore and it wouldn't ignore, but maybe I was just doing it wrong. I'll give it another try.

We've had * in our .dockerignore and it wouldn't work for node_modules, adding the node paths specifically reduces build time by 6 mins. Not related to this project tho. lsof hinted us that way.

[thaJeztah]

Docker 17.07 will add an option to "incrementally" send the build-context, see #32677, #33786, and docker/cli#231, which may be helpful for various use cases