#container.exportImage fails with "client has no supported api for loading image"

1 messages · Page 1 of 1 (latest)

misty compass
#

This works

$ dagger -c 'my-container | export-image myimage:mytag'    
$ docker images
REPOSITORY                  TAG        IMAGE ID       CREATED          SIZE
myimage                     mytag      2f711418bc87   39 minutes ago   109MB

But I want to run something like

$ dagger -c 'export-my-container-image myimage:mytag'

When I do I get the error:

! client has no supported api for loading image

My dagger module looks like this:

func (h *Headway) MyContainer(ctx context.Context) *dagger.Container {
  return dag.Container().From("debian:bookworm-slim")
}

func (h *Headway) ExportMyContainerImage(ctx context.Context, imageNameAndTag string) error {
  container := h.MyContainer(ctx)
  return container.ExportImage(ctx, imageNameAndTag)
}

The real reason I want to do this is that I have a bunch of services which need their containers built, so I'd like to do them all as part of a single function call, like:

$ dagger -c 'build-all-images my-release-tag'

The output of that would be the 10 or so containers, all with their own names and tagged with my-release-tag.

I'm aware there are other methods for publishing to a remote registry - but I want to export to my local docker daemon (just like what happens with | export-image) so that I can test my stack locally using docker compose.

How do I get around this error?

Note: I'm on macos using orbstack

solar notch
#

So in your case try dagger call my-container export-image --name foo

misty compass
#

Sorry, but I don't understand your response. I am not having trouble exporting my image from the command line by piping to export-image (my first example).

The trouble is with my second example - where the call to exportImage happens within my golang code.

Or are you saying that it is impossible to export an image from golang using container.ExportImage?

solar notch
misty compass
#

Or, phrased closer to my whole problem:

func (h *Headway) FirstContainer(ctx context.Context) *dagger.Container {
  return dag.Container().From("debian:bookworm-slim")
}

func (h *Headway) SecondContainer(ctx context.Context) *dagger.Container {
  return dag.Container().From("debian:bookworm-slim")
}

Currently I can do:

$ dagger -c 'first-container | export-image first-container:mytag'
$ dagger -c 'second-container | export-image second-container:mytag'

But I want to be able to wrap that up in a single call, like

$ dagger -c 'export-containers mytag'
solar notch
#

because calling ExportImage within the function currently runs in the sandboxed Go runtime which doesn't have access to your hosts' docker.socket

#

allowing things like that by default would be a security concern

misty compass
#

So it sounds like the best I can do is:

$ dagger -c 'first-container | export-image first-container:mytag'
$ dagger -c 'second-container | export-image second-container:mytag'
...
$ dagger -c 'tenth-container | export-image tenth-container:mytag'

But I guess wrapped in some bash script or something to give me a sane API

solar notch
misty compass
#

Oh interestng. I didn't realize there was control flow in the dagger shell language. Is there a reference for the dagger language? I didn't immediately find it.

For the record, I'd much prefer using a common programming language (like golang) for this kind of thing and I don't immediately understand the difference in security posture of this other approach, but I'm willing to do whatever works!

solar notch
#

which, in the case of orbstack and docker, they run as root

misty compass
#

Oh, in the case of running like running untrusted code in dagger like a third party daggerverse module or something?

solar notch
#

one of the main principles and benefits of Dagger is that we guarantee complete function isolation and all things that require host interaction usually have to be set explicitly by the caller

#

that's why we're very careful on what things module functions can actually access to and from the host