Faster Docker builds using a remote BuildKit instance
1–10 of 48 posts
Re: Faster Docker builds using a remote BuildKit instance
#2Re: Faster Docker builds using a remote BuildKit instance
#3I prefer to use a VPS
Re: Faster Docker builds using a remote BuildKit instance
#4[1]: https://earthly.dev/
Re: Faster Docker builds using a remote BuildKit instance
#5Of course, CI SaaSes implement a lot of caching on their end, but they also try to put people on the most anemic machines possible to try and capture those juicy margins.
Re: Faster Docker builds using a remote BuildKit instance
#6I really am hopeful we come a bit full circle on builders and machines to "we buy one or two very expensive machines that run CI and builds". Caching in particular is just sitting there, waiting to be properly captured, instead of constantly churning on various machines. Of course, CI SaaSes implement a lot of caching on their end, but they also try to put people on the most anemic machines possible to try and captur…
This unfortunately does not work for orgs that have, say, more than 20 engineers. The core issue is that once you have a test suite large enough to have ~30 shards, you only need one engineer `git push`ing once to saturate those 1-2 expensive machines you've got sitting in the office.
The CI workload is quite amenable to "serverless" when you get to a large enough org size, where most of the time you actually want to pay nothing (i.e. outside your business hours) but when your engineers are pushing code, you want 1500 vCPUs on-demand to run 4 or 5 test suites concurrently.
Re: Faster Docker builds using a remote BuildKit instance
#7I know it is out of style for some, but my microservice architecture, which has a dozen services, each takes about 1:30m to build, maybe 2m at most (if there is a slow Next.js build in there and a few thousand npm packages), and that is just on a 4 core GitHub Actions worker.
My microservices all build and deploy in parallel so this system doesn't get slower as you expand to more services.
(Open source template which shows how it works: https://github.com/bhouston/template-typescript-monorepo/act... )
Re: Faster Docker builds using a remote BuildKit instance
#830 minute docker builds? Crazy. I know it is out of style for some, but my microservice architecture, which has a dozen services, each takes about 1:30m to build, maybe 2m at most (if there is a slow Next.js build in there and a few thousand npm packages), and that is just on a 4 core GitHub Actions worker. My microservices all build and deploy in parallel so this system doesn't get slower as you expand to more servi…
At Blacksmith we do see this pretty often! Rust services in particular are the most common offender.
Re: Faster Docker builds using a remote BuildKit instance
#930 minute docker builds? Crazy. I know it is out of style for some, but my microservice architecture, which has a dozen services, each takes about 1:30m to build, maybe 2m at most (if there is a slow Next.js build in there and a few thousand npm packages), and that is just on a 4 core GitHub Actions worker. My microservices all build and deploy in parallel so this system doesn't get slower as you expand to more servi…
> 30 minute docker builds? At Blacksmith we do see this pretty often! Rust services in particular are the most common offender.
Re: Faster Docker builds using a remote BuildKit instance
#1030 minute docker builds? Crazy. I know it is out of style for some, but my microservice architecture, which has a dozen services, each takes about 1:30m to build, maybe 2m at most (if there is a slow Next.js build in there and a few thousand npm packages), and that is just on a 4 core GitHub Actions worker. My microservices all build and deploy in parallel so this system doesn't get slower as you expand to more servi…
If you're deploying all your "microservices" in parallel, then what you might have built is a distributed monolith.
A microservice can be tested and deployed independently.