New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement]: run container directly from image tarball #2204
Comments
Hi @nmoroze is this capability of the ContextArchive io.Reader // the tar archive file to send to docker that contains the build context You can find more info about that here: https://golang.testcontainers.org/features/build_from_dockerfile/#dynamic-build-context |
Thanks for the pointer! That's not quite what I'm looking for though. If I understand correctly, it seems like that feature lets you provide a tarball that contains the set of files to be added to a container (with the container otherwise being defined by a Dockerfile), whereas I'm looking to load a tarball in the form defined by the OCI image layout spec and/or the format produced by |
Hey @nmoroze, could you please elaborate your use case, why you need to do it like this? |
@kiview Our use case is running containerized integration tests using Bazel, which wants tests to be as hermetic as possible, i.e. eliminating dependence on the state of the host machine. Our build process generates container images for our services as tarballs, and it'd be nice to be able to load/run these in a way where we: a) know we're running the correct thing. However unlikely, loading an image then referencing it by label could have a race if a user loaded a different image with the same tag in between the load/run step. b) avoid polluting the user's local image storage
If nothing else, I think this would be nice. Otherwise, we have to either shell out to the container client directly, or bring in another package that provides bindings to the container client, which feels slightly less clean than having
I believe Podman supports this, which is the container client we're using: https://docs.podman.io/en/latest/markdown/podman-run.1.html#image. I think running directly from tar using this functionality would be ideal, but if Docker can't do this, I'd understand if you want to minimize divergence of Docker vs Podman codepaths. I did also note that page says |
Another thought - is there a way to tag an image that is loaded outside of |
Hi @nmoroze! Didn't you find out how to resolve this issue? We have same problem - our applications are built with Bazel and we want to launch them with testcontainers inside integration tests. The only way out I see here - parse ImageLoadResponse.Body to find out image sha, but it's rather weird.. |
Proposal
Hi, thanks for the great package!
I have a use case where it would be helpful to directly run an image from a path to a container tarball, like the type generated by
rules_oci
. This would facilitate the workflow described in https://blog.aspect.dev/integration-testing-oci#heading-example without having to perform the extra step of loading the tarball into Podman or Docker's local image storage.I was thinking one way to support this from a UX perspective would be to support the "transport" protocol described here: https://docs.podman.io/en/latest/markdown/podman-run.1.html#image, so you could specify
docker-archive:/path/to/tar
oroci-archive:/path/to/tar
as theImage
field in aContainerRequest
.I'm curious if you think this would be a reasonable feature to add?
It would also be useful to support supplying a path to the reaper container this way. I'm happy to open a separate issue for that if you think it's viable/worth discussing.
The text was updated successfully, but these errors were encountered: