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

Figure out how to remove platform specific files from docker images #89

Open
Tracked by #49
jsturtevant opened this issue Apr 14, 2023 · 8 comments
Open
Tracked by #49

Comments

@jsturtevant
Copy link
Contributor

Ideally, WASM images should be built to contain pretty much only the wasm module and maybe a configuration file for the runtime (i.e. slightfile.toml) and not much else. This would keep the OCI packages cross platform with out relying on multi-arch manifests improving the ability to use them everywhere, without modifications.

This might be tricky for a few reasons:

  • The current slight dockerfile contains linux specific logic for getting and install certs:
    RUN apt-get update && apt-get install ca-certificates -y
    . When porting to windows these files are not useful as is.
  • For Windows there are some platform specific files (some files that are required by the Windows snapshotter in Contianerd) that are need but don't make sense on Linux. If we use buildx on Windows, then these files and a few other files get added to the image.
  • other OS specific deps (please list below if you have come across any)

There is a crate in runwasi that helps with the creation of images like this without the need for buildx: https://github.com/containerd/runwasi/tree/main/crates/oci-tar-builder

There will need to be some investigation on how to provide things like ssl certs and likely other components as well. The end goal would be to have purely "wasm" based images but that might not be practical, in those cases how do we deal with OS specific deps?

@jsturtevant
Copy link
Contributor Author

Discussed a bit at Runwasi office hours and offline with a few folks, A couple options we came up with (there might be more):

  • Using a tool like tar-builder to build images in OCI image format
  • Using a tool to build OCI artifacts that contain WASM Modules.
    • There is a proposal for a storing wasm modules in a registry proposal for OCI v1.1 content source bytecodealliance/registry#87
      • The challenge with the proposal is that containerd doesn't necessarily know about OCI artifacts only OCI image manifests.
    • One solution to explore is using Stream Processors to translate the unknown media types to formats that Containerd does know: https://github.com/containerd/containerd/blob/main/docs/stream_processors.md
      • This possibly has a couple benefits:
        • work directly with modules instead of image formats (possibly address the concern around file systems mentioned above)
        • no need to write/adopt new snapshotters.
        • could potentially handle OS specific files via annotations
        • don't need to modify core contianerd, which means we can iterate faster than needing a containerd release atleast initially.

Prototyping the second solution using stream processors would be a good way to determine if it is feasible.

@jsturtevant
Copy link
Contributor Author

jsturtevant commented Apr 26, 2023

@cpuguy83 @Mossaka Incase I am missing something

@cpuguy83
Copy link
Collaborator

So today we should be able to use stream processors, however it was suggested is to handle this at the "unpacker" level (via the transfer service) and essentially choose an unpacker passed on the image platform. So we could have a wasi/wasm unpacker and have different implementations of the unpacker when running on linux vs windows.

This (transfer service) is not wired up to CRI today, but it is being discussed.

@jsturtevant
Copy link
Contributor Author

Is there any docs/issue/pr on the transfer service or unpacker that I could look at? What would be the differences and pros/cons of using stream processor vs transfer service?

@cpuguy83
Copy link
Collaborator

I think the main thing is you can select an unpacker based on image platform and not have to do anything special with new types.

Using a stream processor requires a new type, a backchannel to containerd to create the content in, and installing more binaries on a node.

@jsturtevant
Copy link
Contributor Author

@jsturtevant
Copy link
Contributor Author

The stream processor approach didn't work out since (see prototype)

@jsturtevant
Copy link
Contributor Author

I have since done a few prototypes and have a proposal in review at https://docs.google.com/document/d/11shgC3l6gplBjWF1VJCWvN_9do51otscAm0hBDGSSAc

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

2 participants