Support exporting a slug

[matthewmueller]

Hey there, thanks for working on this project, it seems like a much better supported version of Herokuish. Plus buildpacks will definitely make Docker more accessible.

Description

I'm looking to deploy my application to a VM without docker installed. I'd love to build using docker locally or in CI, but then only ship a .tar.gz to production.

Proposed solution

I'm wondering if it'd be possible to add an export slug command. So instead of exporting an image, you could instead export a .tar.gz file.

This would be the same as herokuish's slug export https://github.com/gliderlabs/herokuish#using-herokuish.

[josegonzalez]

Copying a message @sclevine on slack (in case it drops off there):

It would be relatively trivial to do this, and we could keep it in OCI image format so you could store it on a registry and take advantage of layer deduping.

That said, the purpose of droplets/slugs was to keep the runtime base image separate from the app bits, so you can swap them out. pack rebase / lifecycle rebaser provide this functionality now in a more efficient way. And the runtime base image isn’t duplicated for each repo on the registry. So I’d like to understand how the current implementation of this doesn’t meet desired use cases

In a way, you could imagine CNB-generated images to be droplets/slugs with mutable, cheap-to-update pointers to a version of the base image

[matthewmueller]

Thanks for the quick response! I'm happy to see you are part of this effort too @josegonzalez ☺️

That said, the purpose of droplets/slugs was to keep the runtime base image separate from the app bits, so you can swap them out. pack rebase / lifecycle rebaser provide this functionality now in a more efficient way.

Does this only apply to images or would this solve the use case of no docker in production? Even just a documented shell command to initialize an image, copy all the appropriate data out of the image and into a .tar.gz would be a great starting point.

FWIW, I'm not totally sure I want to go without docker, but I like the idea of reducing the complexity on my (small-scale) production systems.

[josegonzalez]

@matthewmueller might be good to jump into the buildpacks slack to discuss the use-case with other maintainers live :)

[dfreilich]

Looks like our slack limit just expired that conversation, sadly. @matthewmueller Did that conversation enable that? Can I close this issue?

[matthewmueller]

Nope, this isn't possible yet AFAIK. I joined that slack channel and replied to the discussion but unfortunately didn't hear back.

I've set this project on the side for now, so it's not blocking me or anything. I'd still love for this feature to be added at some point, especially if it's trivial 🙂

[jromero]

The scope of this request appears to go beyond the capabilities of pack on it's own and likely relies on lifecycle changes. It would be great to get an RFC on how this is expected to work, it's use cases, and some thought around it's implementation.

[natalieparellano]

Related lifecycle issue: buildpacks/lifecycle#423