https://pantsbuild.org/ logo
Join Slack
Powered by
What kind of caching can pants do for docker image...
# general
r
What kind of caching can pants do for docker images? I have a docker image that takes a long time to build but doesn't change that often. I had expected pants could just pull it out of the remote cache once I had set that up but that does not appear to be the case?
c
yea, the actual built image is not cached by pants, only the inputs going into the docker build context
r
Is it possible to set 
--cache-from
and 
--cache-to
in pants? Or does it just use whatever's configured for docker? I'm struggling to find how to configure these in docker outside of command line arguments.
c
those arrive with pants 2.19
perhaps we ought to get the docs for 2.19 published..? cc @happy-kitchen-89482
šŸ‘ 1
r
Yeah is there a dev version of 2.19 available yet?
c
rc even, please try it out if you have the opportunity šŸ™‚ https://pantsbuild.slack.com/archives/C18RRR4JK/p1701650032492969
r
Where can I set those options? I just bumped to the rc but I don't see the option in the docker subsystem anywhere.
c
itā€™s on the 
docker_image
target, 
pants docker_image --help
r
sweet gonna try this out now
šŸ™Œ 1
cache_from
type: Dict[str, str] | None
default: None
Use an external cache source when building the image.
This option requires BuildKit to be enabled via the Docker subsystem options.
Example:
docker_image(
name="example-local-cache-backend",
cache_to={
"type": "local",
"dest": "/tmp/docker-cache/example"
},
cache_from={
"type": "local",
"src": "/tmp/docker-cache/example"
}
)
Values may use placeholders in curly braces to be interpolated. The placeholders are derived from various sources, such as the Dockerfile instructions and build args.
cache_to
type: Dict[str, str] | None
default: None
Export image build cache to an external cache destination.
This option requires BuildKit to be enabled via the Docker subsystem options.
Example:
docker_image(
name="example-local-cache-backend",
cache_to={
"type": "local",
"dest": "/tmp/docker-cache/example"
},
cache_from={
"type": "local",
"src": "/tmp/docker-cache/example"
}
)
Values may use placeholders in curly braces to be interpolated. The placeholders are derived from various sources, such as the Dockerfile instructions and build args.
Is there any way to get the full image tag as a placeholder so I can just set a default for the whole repo?
c
let me checkā€¦
uhm, no that is not currently available šŸ˜•
r
Actually I think I'm good because the cache is addressed by image sha
c
but you can use the target name and path etc to build a cache name that is perhaps generic enough?
r
so I can just dump all the images in the same folder
c
thereā€™s also 
{pants.hash}
that is calculated based in all the inputsā€¦
r
So I tested this out yesterday trying to use 
docker-container
as the driver (which is the default from setup-buildx-action) but it's claiming the base image, which it just packaged is not found. So it seems like this fixes the issue of publishing using a driver other than 
docker
except for images where pants is also building the base image.
This looks to be an issue with this driver in general though https://github.com/moby/buildkit/issues/2343
However if I try and use the plain ol' docker driver I get this:
Copy code
ERROR: Cache export feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")
c
cc @nutritious-hair-72580 any ideas?
r
I think the 
--load
option needs to be added automatically for images with 
use_buildx
But that will not work for multi-platform builds, which I don't need but somebody else might. But pants doesn't really support that anyway because it's dependent on the local image store for publishing to begin with.
I'm curious how Rhys is using it
āž• 1
h
(published the 2.19 docs)
šŸ™ 1
r
I think this could be engineered around by adding images to the build context after packaging if using the docker-container driver. I banged my head against this issue for a good chunk of today but couldnā€™t come up with a quick solution. Have other things I need to get to this week but I want to revisit this and finally make a contribution.
šŸ‘ 1
n
Sorry just seeing this.. The 
--load
flag is set (via the equivalent 
--output=type=docker
) . I've not tested / investigate support with multiple images - there could be some gaps there. If you could raise an issue with the scenario, happy to take a look.
šŸ™ 1
r
Hey Rhys, I think we could integrate 
bake
into the buildx functionality and this will handle this issue https://github.com/pantsbuild/pants/issues/20189#issuecomment-1845817114
n
That sounds like a great option! Were you able to get that to work within Pants, or separately? Adding images to the build context does also sound like another option. I see there's a lot of discussion here also but nothing straightforward.
r
I tried the build context method but couldn't get it to work. Bake worked on my first attempt. And I just wanted to prove it out separately but I think all that needs to change within pants is using the bake command instead of build and generating a 
docker-bake.json
file prior to calling the command.
n
From looking at bake briefly, it seems it would need to be provided the details of both images to build concurrently. I'm not sure how that would work within the current framework in Pants. @curved-television-6568 might know better than me.
r
The bake file inputs match up very nicely with the params on the 
docker_image
target actually. But you're right that the bigger issue might be getting it so we're doing all of the packaging with a single command instead of packaging each thing independently.
c
yea, I really like the looks of bake, only spent like 30s looking at the high level docs so far, but I think weā€™d want a ā€œbake pipelineā€ that is different from the regular build to facilitate the generation of the bake file..
potentially a new 
docker_bake
target, that depends on the images to includeā€¦
šŸ‘ 1
r
Would that solve the problem of not packaging the dependencies ahead of time though?
c
yea, we donā€™t have to package targets in order to work with them
n
Happy New Year! I think I have a fix for the buildx multistage issue - see https://github.com/pantsbuild/pants/issues/20189#issuecomment-1878162989 @curved-television-6568, @broad-processor-92400 Could I get a review on https://github.com/pantsbuild/example-docker/pull/12/files (and the approach in general). If that's all good, will put in a PR to update docker backend docs.
šŸ 1
c
Happy New Year! Currently ooo, but will take a look next week.
šŸ‘ 1
r
I'll check this out when I have time too, probably also next week šŸ˜„
šŸ‘ 1
f
@ripe-gigabyte-88964 is your docker bake implementation available anywhere? Iā€™m looking for cross architecture alternatives that donā€™t require the containerd snapshotter
t
@curved-television-6568 and @ripe-gigabyte-88964 I could not find any more infos, but is 
buildx bake
available with pants? This would be incredibel!
r
@thousands-plumber-33255 No unfortunately I never had time to work on it.
c
Oh, I missed this ping, sorry. I'm curious as how would you see pants integrate with the bake feature here, @thousands-plumber-33255?
(I'm in a new position, so are no longer actively using Docker, so my Docker-fu is slowly deteriorating.. šŸ˜¬ )
t
We are running our docker builds on depot.dev (another option would be docker build cloud). If I can initiate my build with bake, it will build all the images concurrently and should therefore speed up things I hope.
c
Ah, I see. Cool. šŸ™‚
4 Views
Open in Slack
PreviousNext
Powered by