Skip to content

Conversation

@cpuguy83
Copy link
Member

@cpuguy83 cpuguy83 commented Nov 5, 2019

More optimizations for the Dockerfile

  1. Do not use the dev target for building binaries since we don't need all that stuff. This is much faster since we don't need to compile things like CRIU.
  2. Do not use autoversion
  3. Allow bind-mounting the build context to the binary target stages instead of copying.
  4. Do not include Dockerfile or .dockerignore in build context - (maybe controversial)
    i. Prevents rebuilding things just because there is some change in either of these files.
    ii. Is not needed since we don't do nested build.

Dockerfile Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of copying these to /usr/local/bin we could just add the bundles directory to PATH, similar to what I did in docker/cli#419 (not sure if there's code that expects the binaries to be in /usr/local/bin though)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the logic:

copy_binaries() {
local dir="$1"
local hash="$2"
# Add nested executables to bundle dir so we have complete set of
# them available, but only if the native OS/ARCH is the same as the
# OS/ARCH of the build target
if [ "$(go env GOOS)/$(go env GOARCH)" != "$(go env GOHOSTOS)/$(go env GOHOSTARCH)" ]; then
return
fi
if [ ! -x /usr/local/bin/runc ]; then
return
fi
echo "Copying nested executables into $dir"
for file in containerd containerd-shim ctr runc docker-init docker-proxy rootlesskit rootlesskit-docker-proxy dockerd-rootless.sh; do
cp -f "$(command -v "$file")" "$dir/"
if [ "$hash" = "hash" ]; then
hash_files "$dir/$file"
fi
done
# vpnkit is amd64 only
if command -v "vpnkit.$(uname -m)" 2>&1 >/dev/null; then
cp -f "$(command -v "vpnkit.$(uname -m)")" "$dir/vpnkit"
if [ "$hash" = "hash" ]; then
hash_files "$dir/vpnkit"
fi
fi
}

So we can add them anywhere into PATH, or add anywhere to PATH, or just copy them manually.
I wanted to reduce redundant code as much as possible here.
The other thing that makes it kinda tricky is each build target builds in a subdir, like bundles/binary-daemon and bundles/dynbinary-daemon, so I'd have to do this copy twice.

I could bind-mount the files in and update PATH to include each one, but this would only reduce the amount of copying we are doing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically my worry here is we have this list of commands that need to be copied as part of a build and different lists get out of sync.

@cpuguy83 cpuguy83 changed the title No more dev tools Build binaries with minimal deps Nov 6, 2019
@cpuguy83
Copy link
Member Author

Ping

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, forgot about this one; left some comments 🤗

@thaJeztah thaJeztah added area/project kind/refactor PR's that refactor, or clean-up code status/2-code-review labels Nov 27, 2019
This makes the binary build targets use a minimal build env instead of
having to build all the stuff needed for the full dev enviornment.

Signed-off-by: Brian Goff <[email protected]>
This eliminates the need to lay down an auto-generated file.
IIRC this was originally hadded for gccgo which we no longer support.

Signed-off-by: Brian Goff <[email protected]>
The Dockerfile is not needed in any of the build targets.
The one exception may be the dev image, however in most cases the docker
source will be bind mounted into the container anyway.

Signed-off-by: Brian Goff <[email protected]>
@cpuguy83
Copy link
Member Author

cpuguy83 commented Dec 2, 2019

Fixed.

@thaJeztah thaJeztah changed the title Build binaries with minimal deps Build binaries with minimal deps and remove autogen code Dec 3, 2019
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Dockerfile Outdated

FROM dev AS src
FROM runtime-dev AS src
# Make arg inheritable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: outdated comment?


FROM src AS final
FROM dev AS final
COPY . /go/src/github.com/docker/docker
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (no need to change); /go/src/github.com/docker/docker is the WORKDIR, is this could be

COPY . .

// Code generated by hack/make/.go-autogen. DO NOT EDIT.
DVEOF
LDFLAGS="${LDFALGS} \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops; typo: (LDFALGS); fixing in #40389

thaJeztah added a commit to thaJeztah/docker-ce-packaging that referenced this pull request Jan 17, 2020
Upstream moby/moby#40180 removed the auto-generated code, replacing
it with build-time variables (-X).

This patch updates the Dockerfiles to account for this change.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
cpuguy83 added a commit to cpuguy83/docker that referenced this pull request Feb 6, 2020
This was removed after refactoring the Dockerfile in moby#40180

Signed-off-by: Brian Goff <[email protected]>
@thaJeztah thaJeztah added this to the 20.03.0 milestone Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/project kind/refactor PR's that refactor, or clean-up code status/2-code-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants