Skip to content
New issue

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

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

Already on GitHub? # to your account

Reducing wait time for cold caches with large apps #81

Closed
toolmantim opened this issue Jul 6, 2016 · 10 comments
Closed

Reducing wait time for cold caches with large apps #81

toolmantim opened this issue Jul 6, 2016 · 10 comments

Comments

@toolmantim
Copy link
Contributor

toolmantim commented Jul 6, 2016

Currently the best way to handle a large app that takes ages to build is to have two separate instances of the stack: builders and runners, and https://github.com/buildkite-plugins/docker-compose-buildkite-plugin to have a build step that runs before the steps.

The builder doesn't autoscale, sits there with a warm docker cache, and pushes to a registry. The test steps run on the runners queue, and pulls from docker hub without doing any git clone at all.

The pipeline looks like this:

steps:

  - name: ":docker: :package:"
    plugins:
      docker-compose:
        build: app
        image-repository: index.docker.io/myorg/myapp
    agents:
      queue: elastic-builders

  - wait

  - name: ":spec: %n"
    command: ".buildkite/steps/knapsack"
    plugins:
      docker-compose:
        run: app
    agents:
      queue: elastic-runners
    parallelism: 75

A simpler setup would be to use something like http://blog.runnable.com/post/145362675491/distributing-docker-cache-across-hosts to make the cache mostly invisible, and require no separate queue or pipeline config changes.

@lox
Copy link
Contributor

lox commented Jul 19, 2016

Distributing cache across hosts would be great. For that to work, you'd need a list of images to save and then some code in the environment and post-command hooks. Thoughts on how you'd specify which images to cache?

@toolmantim
Copy link
Contributor Author

So @tonistiigi just released https://github.com/tonistiigi/buildcache (moby/moby#20316 (comment)) which we could potentially use

@mtibben
Copy link

mtibben commented Aug 25, 2016

Codeship has a blog post explaining how they tackled this problem https://blog.codeship.com/building-a-remote-caching-system/

@lox
Copy link
Contributor

lox commented Apr 14, 2017

This will be solved by #234.

It could also be solved by using the new docker 1.13 --cache-from stuff, which needs some investigation.

@jdotjdot
Copy link

jdotjdot commented Jul 12, 2017

I'm seeing some recursion here between this Issue and #234. Is the shared layer cache support being handled?

@lox
Copy link
Contributor

lox commented Jul 12, 2017

@jdotjdot you should be able to use the new --cache-from stuff in docker-compose 1.14, which is on the latest stack version. I'm going to close this for now, do you have a specific issue that you are currently seeing?

@lox lox closed this as completed Jul 12, 2017
@jdotjdot
Copy link

jdotjdot commented Jul 12, 2017 via email

@lox
Copy link
Contributor

lox commented Jul 12, 2017

Ah, right, you don't use docker at all? Or just not docker-compose?

@jdotjdot
Copy link

jdotjdot commented Jul 12, 2017 via email

@lox
Copy link
Contributor

lox commented Jul 12, 2017

You should be able to make use of the --cache-from stuff in Docker.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

4 participants