Avoid upgrading base OS image during the life of a major version of Node.js

[targos]

Problem

The update of the base OS image used for node:18 from Debian 11 to 12 has caused issues for various people:

• If you have this problem, you should upgrade docker! [was: node aborts and core dumps as soon as it starts] node#43064 (comment) (last comments)
• node:18 (bookworm) lacks libcrypto.so.1.1 present in previous releases such as 18-bullseye #1916
• website build broken during Docker image preparation build#3382

Solution

Keep the same base OS image during the entire life of any major version of Node.js and only upgrade it for future major versions.

Alternatives to Consider

Teach the community to specify the name of the base OS in their Dockerfiles, but I'm afraid it's too late for that. I don't remember seeing any documentation that recommends to do it.

[felix98765]

Same issue, use FROM node:18-bullseye AS base fix it. I will put the logs here for others to search.

[22:34:35] #10 [deps 1/3] RUN corepack enable && corepack prepare "pnpm@8.5.1" --activate
[22:34:35] #10 sha256:xxxxx
[22:34:35] #10 0.085 node[7]: ../src/node_platform.cc:68:std::unique_ptr<long unsigned int> node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start(): Assertion `(0) == (uv_thread_create(t.get(), start_thread, this))' failed.
[22:34:35] #10 0.086  1: 0xb7a940 node::Abort() [node]
[22:34:35] #10 0.086  2: 0xb7a9be  [node]
[22:34:35] #10 0.087  3: 0xbe98be  [node]
[22:34:35] #10 0.087  4: 0xbe99a1 node::NodePlatform::NodePlatform(int, v8::TracingController*, v8::PageAllocator*) [node]
[22:34:35] #10 0.088  5: 0xb38f5b node::InitializeOncePerProcess(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, node::ProcessFlags::Flags) [node]
[22:34:35] #10 0.088  6: 0xb395ab node::Start(int, char**) [node]
[22:34:35] #10 0.088  7: 0x7fcea1ef918a  [/lib/x86_64-linux-gnu/libc.so.6]
[22:34:35] #10 0.088  8: 0x7fcea1ef9245 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
[22:34:35] #10 0.089  9: 0xabbdee _start [node]
[22:34:35] #10 0.093 Aborted (core dumped)
[22:34:35] #10 ERROR: executor failed running [/bin/sh -c corepack enable && corepack prepare "pnpm@8.5.1" --activate]: exit code: 134
[22:34:35] ------
[22:34:35]  > [deps 1/3] RUN corepack enable && corepack prepare "pnpm@8.5.1" --activate:
[22:34:35] ------
[22:34:35] Dockerfile:5
[22:34:35] --------------------
[22:34:35]    3 |     
[22:34:35]    4 |     FROM base AS deps
[22:34:35]    5 | >>> RUN corepack enable && corepack prepare "pnpm@8.5.1" --activate
[22:34:35]    6 |     COPY pnpm-lock.yaml ./
[22:34:35]    7 |     RUN pnpm fetch

[LaurentGoderre]

I don't think it's practical to pin the version because the OS and Node version don't line up. There is an inherent risk to using shortcut tags and it's a balancing act between stability and security.

For example, we had pinned to a major node version and specific OS version which meant we weren't getting security updates until we bumped to the new OS version.

[ronag]

I think this causes an unnecessary problem. In the docker node v20.3 image, we have broken a large number of users (e.g. Ubuntu LTS users). From a user's perspective, this kind of breakage is unexpected in what looks like a server minor update.