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

Podman, Buildah, and Skopeo support #1561

Open
c16a opened this issue Oct 19, 2019 · 6 comments
Open

Podman, Buildah, and Skopeo support #1561

c16a opened this issue Oct 19, 2019 · 6 comments

Comments

@c16a
Copy link

c16a commented Oct 19, 2019

Support for Podman, Buildah, and Skopeo

The current fn init and subsequent containers exclusively use Docker, and require the Docker daemon to be running. The open-source leaner alternatives Podman, Buildah, and Skopeo are intended to replace Docker, and provide a daemon-less container experience. The can also compliment and augment to the feature set of Fn CLI.

@c16a
Copy link
Author

c16a commented Oct 19, 2019

Interfaces similar to the below can be practically re-used to implement support any OCI-compliant container tools.

type ImagePuller interface {
PullImage(ctx context.Context, cfg *docker.AuthConfiguration, img, repo, tag string) chan error
SetRetryPolicy(policy common.BackOffConfig, checker drivers.RetryErrorChecker) error
}

@c16a c16a changed the title Podman support Podman, Buildah, and Skopeo support Oct 19, 2019
@c16a
Copy link
Author

c16a commented Oct 19, 2019

At this point, I might have to agree that Fn is tightly coupled with Docker. Not sure if this can be implemented as a feature, or a standalone fork.

@rdallman
Copy link
Contributor

Hello, we have the driver interface https://github.com/fnproject/fn/blob/master/api/agent/drivers/driver.go which seems to be what you're looking for, this enables swapping out container drivers. Of course, it has become very docker specific over time, it's possible to stub out certain things to get something working to ignore certain feature sets we currently offer via the docker driver, and the basic create container / run container ought to be sufficient. it would be possible to implement such a driver separately and configure fn to start with it, no fork needed. it would be nice to run containers without the docker daemon!

@c16a
Copy link
Author

c16a commented Oct 29, 2019

Is someone looking to work on this? Hope I can self-assign and start working?

@rdallman
Copy link
Contributor

go for it!

@davidkhala
Copy link

Looking forward to have them support, especially now that docker desktop has its license changed.

@fnproject fnproject deleted a comment from yufeifly May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants