EIP: Language-Specific Extism Docker Images

[syke99]

What

I propose providing language-specific Docker images for users to build on top of for easy deployment.

Why

Docker is obviously the predominant container platform currently. And with the cloud being the hype, and with Extism always gaining more traction every day, I can see users wishing to Dockerize an Extism host application to deploy via Docker Compose, Kubernetes+Helm Charts, etc. Whenever users have to have binaries already installed for their applications to run and are already considering Dockerizing it, they often opt for a Docker image with the bare minimum of what they need (often just a language runtime) for ease of use as long as the resulting image is small enough to satisfy the users' needs; especially if there is an official one vendored by the company/foundation/group that provides the binary (see ffmpeg's Docker image).

Proposed specs:

• Built on top of Alpine/Scratch image to keep image small
• Two different image options,
  1. one with only Extism pre-installed (possibly named extism-lite-<semver_number>)
  2. another with the language runtime (or other necessary binaries/files/etc.) as well as Extism pre-installed (possibly named extism-<semver_number>-<language_name>-<semver_number>)
• Language-specific images should be maintained and updated for the last 3 major releases for backwards compatibility (if compatible with Extism version), after which, routine maintenance and updating is stopped and only performed whenever critical issues are opened
• Implemented and maintained inside of language specific SDK repos, or in central repo specifically for Docker images for ease of maintainability

[bhelx]

I'm still a little unsure about this and might be speaking to my unfamiliarity with some of the devops practices people have with docker images. Is the goal to basically use Docker as a package manager? It seems to me more portable to have the runtime as just a binary that you can download into your own docker image as a binary or build it from source. This matrix might get more complicated as we have more compile time options too.

I think this may be less of an issue as we move towards 1.0 as well because we're moving away from the shared object runtime. It will still exist, but only for a few languages. And where possible, it will be embedded in the language specific package. We want installing Extism to be as simple as pip install extism or npm install exitsm for example. No more need to know about the shared object.

[syke99]

Yeah, it was more of a devops benefit for people who want to containerize their applications for some sort of automated orchestration environment (k8s etc.); it's not an uncommon practice for tools provide a bare bones docker image to build on top of (usually, itself, built on top of some really thin image such as alpine or scratch). But I agree. I made this EIP, if I remember correctly, right around the time removing the shared object runtime in favor of the embedded runtimes per language was brought up in the discord server 😅

[bhelx]

I know, so sorry I got to this one so late! We're gearing up for 1.0 and just following up on some things i missed.

[syke99]

Oh I'm sorry!! I should clarify I was agreeing that this could easily be out of scope!! I'm so sorry 😅

[bhelx]

Yes I understood that. Don't worry, not upset 😆 . Really appreciate any ideas about how we can make Extism easier to use. I was just apologizing for getting back to you late.