Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multistage Docker + Test in Docker #6345

Merged
merged 1 commit into from
Oct 1, 2020
Merged

Multistage Docker + Test in Docker #6345

merged 1 commit into from
Oct 1, 2020

Conversation

icirellik
Copy link
Contributor

This change updates force to use a multistage docker build and leverages
the new docker build enginer, buildkit. Some of the benefits are better
layer caching, meaning we should see decreases in the average image
build time, we now run our tests in the same docker image that they are
compiled in, and the production image is significantly smaller (down to
500MiB from 3GiB).

Copy link
Contributor

@joeyAghion joeyAghion left a comment

Choose a reason for hiding this comment

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

My comments are mostly just questions.

3GB to 500MB is huge!

name: build
pre-steps:
- run:
command: echo 'export BUILD_TARGET="builder"; export DOCKER_BUILDKIT=1; export BUILDKIT_PROGRESS=plain; export COMPOSE_DOCKER_CLI_BUILD=1;' >> $BASH_ENV
Copy link
Contributor

Choose a reason for hiding this comment

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

This isn't too bad.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't "need" to do this. It enables buildkit, makes the output greppable, and tells docker compose to use the docker cli. If this works well, it would make sense to add this to the orb.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a minimum version of Docker that we need to use for buildkit support?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The version that we are on is the minimum supported version.

!test.config.js
!test.mocha.js
!tsconfig.json
!yarn.lock
Copy link
Contributor

Choose a reason for hiding this comment

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

This is one of those things that may surprise developers with unexpected CI failures when "everything worked locally." It's acceptable but something to monitor...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, however as this pattern is implemented in more places it should become second nature to check this when adding new folders. I would expect most new files to end up in src.

@@ -0,0 +1,21 @@
FROM hokusai_force as data
Copy link
Contributor

Choose a reason for hiding this comment

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

Is <...>.Dockerfile the accepted naming convention? I feel like I've seen other styles like Dockerfile.dev but am not sure what's preferable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honestly, I prefer Dockerfile.dev. I am at odds with syntax highlighting, it only works when Dockerfile is the suffix.


mocha \
--retries 5 \
--require test.config.js \
-t 60000 \
-t 360000 \
Copy link
Contributor

Choose a reason for hiding this comment

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

6 minutes seems really long! Is anything taking that long?

Copy link
Contributor

Choose a reason for hiding this comment

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

On 2nd thought, this matches my experience locally, where initial requests take 1-2 minutes to get a response. I assumed that was a local problem, or different with "production" assets.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This timeout seems to be in place to allow the initial startup, its not really a "timeout". I'm sure that I can find a lower setting with a few extra run, I'll see what I can do.


# wait for it to accept connections
./node_modules/.bin/wait-on http://localhost:5000
sleep 10
Copy link
Contributor

Choose a reason for hiding this comment

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

Wait and sleep?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a bug, will remove. Nice catch!

@bhoggard bhoggard self-requested a review September 25, 2020 20:56
Copy link
Contributor

@izakp izakp left a comment

Choose a reason for hiding this comment

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

This is great! Perhaps just include a link to our remote-docker orb PR (reminder to update from a dev orb to a released version of the orb before merging)

name: build
pre-steps:
- run:
command: echo 'export BUILD_TARGET="builder"; export DOCKER_BUILDKIT=1; export BUILDKIT_PROGRESS=plain; export COMPOSE_DOCKER_CLI_BUILD=1;' >> $BASH_ENV
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a minimum version of Docker that we need to use for buildkit support?

steps:
- hokusai/setup-docker
- run: hokusai registry pull --tag "$CIRCLE_SHA1"
- run: docker run --rm -e NODE_ENV=test --entrypoint /bin/bash "hokusai_force" /usr/local/bin/yarn test:mocha
Copy link
Contributor

Choose a reason for hiding this comment

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

👏 this is much more consistent, it seems like we could package these into a run step in the orb as a follow up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have a branch over here: artsy/orbs#111

Dockerfile Outdated
jest.config.js \
package.json \
relay.config.js \
renovate.json \
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems unusual that we'd need renovate in the image.

COPY patches ./patches
COPY src ./src
COPY webpack ./webpack
COPY .env.oss \
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we access the .env.oss in tests? I wonder if it makes sense to consolidate those requirements in the .env.test files.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure I will test this. I remember adding it explicitly however that may have been before I added .env.test.

Dockerfile Outdated
# Release stage. This stage creates the final docker iamge that will be
# released. It contains only production dependencies and artifacts.
#
# TODO: Make the COPY steps more explicit, the iamge still copies in the all raw
Copy link
Contributor

Choose a reason for hiding this comment

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

trivial, iamge typo

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for finding this. I was able to remove the TODO completely!

Copy link
Contributor

@eessex eessex left a comment

Choose a reason for hiding this comment

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

Hooray, can't wait to see how this affects our CI speeds!

Copy link
Contributor

@bhoggard bhoggard left a comment

Choose a reason for hiding this comment

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

Awesome work!

@icirellik icirellik force-pushed the multistage-docker branch 2 times, most recently from e28119d to 7a4fc36 Compare September 29, 2020 14:53
@admbtlr
Copy link
Contributor

admbtlr commented Sep 30, 2020

Maybe change the PR title to chore: Multistage Docker + Test in Docker? 😬

@icirellik icirellik force-pushed the multistage-docker branch 12 times, most recently from 24a2d2a to d1c8fd0 Compare September 30, 2020 22:50
@icirellik icirellik force-pushed the multistage-docker branch 10 times, most recently from 7e5cd16 to 2525bce Compare October 1, 2020 15:16
This change updates force to use a multistage docker build and leverages
the new docker build enginer, buildkit. Some of the benefits are better
layer caching, meaning we should see decreases in the average image
build time, we now run our tests in the same docker image that they are
compiled in, and the production image is significantly smaller (down to
500MiB from 3GiB).
@eessex eessex merged commit 785a379 into master Oct 1, 2020
@icirellik icirellik deleted the multistage-docker branch October 1, 2020 18:17
@artsy-peril artsy-peril bot mentioned this pull request Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants