You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is generally a good thing for security and performance reasons. Smaller images lead to faster builds, faster deployments, faster startups, and smaller attack surfaces.
In regards to #214, I believe we can do this without impacting people's ability to drop in whatever container they'd like. However, as we make the example image a little more complicated, we distract from the CI/CD and IaC that's in here. 🤔
None of the these examples (alpine/slim or distroless) should affect our ability to use ARM-based containers (#389).
The text was updated successfully, but these errors were encountered:
This article has some interesting reasoning that would lead us to use node:18.11.0-slim (or whatever the version number is once 18 becomes the LTS release). Version 18 defaults to bullseye, so there's no reason to be explicit about that.
I believe I'm suggesting that we use -slim variants. We can probably even build with them (as opposed to needing a multi-stage build where we build using the standard image and then copy built files into a -slim-based image).
At BYU, we occasionally use binaries that rely on glibc (like for our OracleDB connections), which precludes -alpine images because they're based on musl
The devs that would want to use tools like curl/wget are the same devs that would feel comfortable adding an apt-get update && apt-get install -y curl step
Compared to the base image, -slim is almost as small as -alpine
There's a tiny learning curve for alpine-based images (e.g. apk is the default package manager instead of apt-get)
Distroless doesn't provide distinct releases based on specific Node.js versions, so we can't easily pin to minor or patch versions, therefore distroless images will be harder to manage than -slim images
This is generally a good thing for security and performance reasons. Smaller images lead to faster builds, faster deployments, faster startups, and smaller attack surfaces.
In regards to #214, I believe we can do this without impacting people's ability to drop in whatever container they'd like. However, as we make the example image a little more complicated, we distract from the CI/CD and IaC that's in here. 🤔
None of the these examples (
alpine
/slim
or distroless) should affect our ability to use ARM-based containers (#389).The text was updated successfully, but these errors were encountered: