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
Docker buildx workers fail when run inside a sysbox container #384
Comments
Was hoping this would fix it, but it doesn't: docker buildx create --name mybuilder --driver docker-container --driver-opt network=bridge --use |
This is the problem that we need to address:
References: |
Looks like they worked around this in docker/buildx#887, will test. |
@lox, thanks for letting us know. I'll need to look at that fix in more detail but I suspect that it won't be applicable to Sysbox. Btw, we already have an internal fix for this (as well as other related issues) to enable buildkit within Sysbox containers. We are currently testing most of the buildkit features (which are a few) and expect to have all this released within a few weeks. |
Is there any workaround, or can we get the internal fix? I would love to use |
Thanks, next couple of days works for me. Looking forward to it! |
I built my own release using 3513b74 and it seems like the error is still present. Hopefully I'm just doing something wrong. I used the build instructions found here, copied the binaries to my sysbox host, replaced the binaries in /usr/bin/sysbox and restarted sysbox.service. For good measure I also restarted my GitLab runner and Docker services. After failing to get this to work in my runners, I tried the example at the top of this issue. The result is the same everywhere:
I'm pretty sure my version is correct, as you can see in the journal output of my sysbox service:
|
You did everything right @href, it's my fault as I missed to merge two commits with relevant changes into our public sysbox-fs repo. And, unfortunately, our CI didn't catch this either coz this being a brand-new feature, we haven't updated our ci-jobs to execute the new buildx-specific testcases ... Thanks for letting me know. I'll have this fixed in a couple of hours. |
This one fixes issue [#384](nestybox/sysbox#384). Notice however, that even though this enables various features provided by Buildx's docker-container driver, the multi-arch support functionality won't arrive till we integrate the pending `binfmt` changes. Signed-off-by: Rodny Molina <rmolina@nestybox.com>
@href, changes are merged now. Another thing, please keep in mind that Sysbox will need to be configured as the default runtime if you are attempting to launch a buildkit container from your host system (buildkit would run at level-1 in this case). Unfortunately, neither
Alternatively, if you are trying to launch buidkit within a sysbox container (buildkit running at level-2), then there's no extra configuration required. |
Thanks, I retried it with the latest build and it worked as expected. Thank you! Looking forward to a release 🙂 |
@lox, I'll go ahead and close this one now. Please re-open it if have any question. |
I was hoping to use the
cache-from
andcache-to
directives to cache docker layer cache between builds in my CI setup, but ran into an error.To reproduce:
I suspect this relates to the builder setting a network mode of
host
.The text was updated successfully, but these errors were encountered: