Skip to content
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

Support podman #413

Closed
abitrolly opened this issue Dec 12, 2019 · 12 comments
Closed

Support podman #413

abitrolly opened this issue Dec 12, 2019 · 12 comments
Labels
status/not-planned Issue or PR that is not planned to be supported (yet).

Comments

@abitrolly
Copy link
Contributor

abitrolly commented Dec 12, 2019

https://podman.io is the daemonless docker alternative which supports CGroupsV2 and capable of running unpriviliged containers.

https://buildah.io/ can be interesting too.

@sclevine
Copy link
Member

sclevine commented Dec 12, 2019

Hi @abitrolly,

CNB doesn't depend on docker build, and we only depend on Docker at all because it's the only straightforward solution for running containers on Windows and Mac workstations.

There's been some discussion of supporting Linux containers directly on Linux workstations (without podman or docker), but that would result in UX inconsistencies with Mac/Windows. Supporting podman on Linux and Docker on Windows/Mac would have the same issues.

Buildah isn't helpful here, because the CNB lifecycle generates OCI images directly (in unprivileged containers as a normal user without any user namespacing support).

If you're looking to build images in CI (not locally), I'd encourage you to use the lifecycle directly for that, so that you don't need Docker. Here's an example: https://github.com/tektoncd/catalog/blob/master/buildpacks/buildpacks-v3.yaml

@abitrolly
Copy link
Contributor Author

@sclevine docker is just a wrapper over standard Linux containers. It should run Linux on Mac/Windows to let you send command over the socket API which is unix:///var/run/docker.sock. How does it do that on Windows?

There would be no problem if pack just used docker from command line. podman is CLI compatible with it.

@abitrolly
Copy link
Contributor Author

I solved my problem by using heroku/heroku:18-build image to refresh gems in an old Heroku project. Don't need buildpack to recreate its build environment.

@zmackie zmackie added the status/not-planned Issue or PR that is not planned to be supported (yet). label Feb 4, 2020
@zmackie
Copy link
Contributor

zmackie commented Feb 4, 2020

Sounds like this issue is solved. For the broader feature ("Support Podman") we'd be happy to review a pull request.

@abitrolly
Copy link
Contributor Author

@zmackie podman provides Docker API over /run/user/$UID/podman/podman.sock socket. But I can not find where in the pack source this path can be detected, or set explicitly through a config.

$ pack build myapp --builder heroku/buildpacks:18 -v
Pulling image index.docker.io/heroku/buildpacks:18
ERROR: failed to fetch builder image 'index.docker.io/heroku/buildpacks:18': Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

@dvaumoron
Copy link

Hi @zmackie, i went through the source and want try to do it, have you some advice ?

@jjbustamante
Copy link
Member

@dvaumoron I think pack supports interaction with podman already, some documentation about is here or are you planning to help with something else?

@dvaumoron
Copy link

My idea is to call podman directly without the socket, this way pack could be stand alone

@dvaumoron
Copy link

I want to add a flag switch which call an other function instead of tryInitSSHDockerClient in the initClient to get an alternative implementation of the interface CommonAPIClient

@jjbustamante
Copy link
Member

Oh I see, interesting. I am not 100% sure BUT, I will suggest to open an RFC to discuss your idea and we can move forward with it, because it sounds really nice!

@dvaumoron
Copy link

Ok, i will do it

@abitrolly
Copy link
Contributor Author

https://buildpacks.io/docs/app-developer-guide/building-on-podman/ advertises podman as rootless and daemonless and then goes on with setting up systemd daemon for interactions. It would be very nice to have a full userspace deamonless and rootless experience for assembling buildpacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/not-planned Issue or PR that is not planned to be supported (yet).
Projects
None yet
Development

No branches or pull requests

5 participants