WIP: Initial separate builder/runner images #138
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Define a new container, striot/striot-runtime, intended to be used as
the basis for runtime containers. Based on Debian 10 slim (aka Buster,
the current stable version at the time of writing) with the additional
librdkafka1 installed.
Adjust the Dockerfile-generation code to use a multi-stage build, where
the build takes place in striot/striot-base, and the resulting "node"
binary copied over to a new container based on the runtime.
The resulting images are much smaller: striot/striot-base is 3.15GB
right now, and striot/striot-runtime would be about 93.5MB. The binaries
we build are typically around 50M, but could be reduced to about 33M if
we strip the debug symbols out.
striot-base is based on haskell:8.6, which is based on Debian "Stretch"
("oldstable", the release before the current stable). There could be ABI
incompatibilities between libc or librdkafka1 in the builder and runner
containers. We should harmonize on a common base version; possibly the
/next/ Debian stable release (bullseye), which is due very soon, once
there are hub.docker.com/_/haskell containers based on it. I've marked
this "WIP" for that reason. (We might also need to look at GHC version.
I think 8.6 is already "unsupported" in the containers)
Another reason this is WIP: it will break the Taxi example, since node1
requires "sorteddata.csv" in the container.
debian:stretch