#Building images from inside Dagger

1 messages · Page 1 of 1 (latest)

pine compass
#

Hi everyone,

Am evaluating dagger to see if it can be used in our CI workflows and have a quick question about building new images from within the dagger function.

I am evaluating a tool https://project-copacetic.github.io/copacetic/website/ that uses a Trivy vulernability report to determine if an image has any vulnerabilities that can be patched. If it can be patched it will run and generate a new image.

I am trying to get this working in dagger - so far I have been able to use a Trivy container, build a buildkit container as service and finally build a Copa container (based on its Dockerfile for GH Actions - https://github.com/project-copacetic/copa-action/blob/main/Dockerfile). However, I am finding that when Copa runs and patches the image my dagger function hangs on the last step of Copa which is to create the new image. I ultimately want the new image to be available on my host machine/where dagger is installed.

Is anyone able to advise on how I can debug what is happening or has any experience on recreating the local image?

copa is a CLI tool written in Go and based on buildkit that can be used to directly patch container images given the vulnerability scanning results from popular tools like Trivy.

manic seal
#

when Copa runs and patches the image my dagger function hangs on the last step of Copa which is to create the new image
not sure how to debug this exactly but reading copa docs it sounds like it has similar dependencies as the dagger engine itself, a buildkit daemon, docker on the outside, etc...

https://project-copacetic.github.io/copacetic/website/quick-start

buildkit daemon installed & pathed. Examples
The docker daemon runs a buildkit service in-process. If you are using this for your buildkit instance, Docker must have the containerd image store feature enabled.
If you are using a buildx instance, or using buildkitd directly, there is no need to enable the containerd image store. However, only images in a remote registry can be patched using these methods.
docker daemon running and CLI installed & pathed.

This guide illustrates how to patch outdated containers with copa.

#

have you gone through the "specify a buildkit instance to connect to" steps inside your module container? like pop yourself into a terminal and try to containerd, docker buildx, or look at the buildkitd.sock

#

or you could be hitting this

If you are using a buildx instance, or using buildkitd directly, there is no need to enable the containerd image store. However, only images in a remote registry can be patched using these methods.

#

you also might need ExperimentalPrivilegedNesting?

pale plover
tawny dune
#

a docker compat bridge would be really nice ...

pine compass
#

Thanks for the feeback. At a high level this is what my code is doing:

  • I start a trivy container with a mounted cache
  • I scan the image and produce a report.json for Copa to use
  • I start a buildkit container using moby/buildkit:latest and set the entrypoint to use --addr=tcp://0.0.0.0:1234 and expose that port
  • I build the Copa container as per the Dockerfile in my original post and I use it as follows:
  .withServiceBinding("buildkit", bk.asService({insecureRootCapabilities: true}))
  .withFile("report.json", trivy.file("report.json"))
  .withExec(["copa", "patch", "-r", "report.json", "--image", imageName, "--output", "vex.json", "--format", "openvex", "--tag", "patched", "--addr", "tcp://buildkit:1234", "--debug"])```
- Copa runs, patches the image and then basically times out:
```time="2025-03-06T14:30:44Z" level=debug msg="stopping session"                                                                                                                                                                           
time="2025-03-06T14:35:41Z" level=error msg="patch exceeded timeout 5m0s"                                                                                                                                                                
Error: patch exceeded timeout 5m0s```