Update Node.js and Node.js Express Dockerfiles to use UBI

[arthurdm]

Is your feature request related to a problem? Please describe.
It would be nice to have a consistent stack used across Appsody, Kabanero.io and any other umbrella offerings like CP4Apps.

Describe the solution you'd like
If we update the Appsody Node.js and Node.js Express Stacks to use UBI, as illustrated here for Node.js and here for Node.js Express, then a single stack (for each) could be referenced across these projects.

This is not a requirement from Appsody, but it would reduce the amount of versions we keep of these stacks and create consistency as users move across projects.

[sam-github]

The problem with this is that IBM runtimes supports the community builds of Node.js, and the UBI don't contain those, they contain RedHat builds (which aren't just the same code, compiled by a different person, the build settings are quite different, OpenSSL version is different, etc.).

Discussions are ongoing internally.

EDIT: and to be clear, ^--- is a problem, but the advantages of not having multiple stack forks is pretty compelling. Though, as-is, building Node.js stacks that satisfy the non-root certification requirement is blocked on problems with the appsody dependency volume feature:

See: #518 (comment)

[sam-github]

This decision should be made appsody-wide, is appsody/stacks as a whole comitting to move from containing community builds of its runtimes to using RedHat builds, because that's what CP4Apps requires?

If so, then Node.js should do the same.

[arthurdm]

@neeraj-laad - would be good to get your views here. I believe we're seeing a few stacks make the move to using UBI at the appsody stack level, which creates a consistent "downstream path"?

[neeraj-laad]

I do not think that Appsody should move or force stack creators to switch to UBI. We do however allow/support stacks based on UBI.

If it makes it easier for stack creators to support/maintain stacks then that is a valid reason for them to go this way. But it should be driven more by what does the stack creator believe the developers will require/prefer to use.

I'm not familiar with the differences in node builds and what it means for developers.

@sam-github Do you see the impact on adoption or use of nodejs stacks if we switch to ubi?

[sam-github]

There are minor differences in the UBI vs community stacks. Among other things, if a bug is reported in a UBI build to github.com/nodejs/node, if it can't be reproed in the community build, it will be closed and the reporter will be redirecte to RedHat for support. Also, when Node.js gets QUIC support, it won't work with UBI images, but will work with community images.

But it should be driven more by what does the stack creator believe the developers will require/prefer to use.

I'm not sure I'm in agreement here. Do you have any adoption stats for nodejs/appsody? Who are "the developers" who are using these stacks?

UBI is the clear winner if appsody is targeted at the RedHat ecosystem. Node.js community images are the winner if appsody is targetted at the wider community. We are the clear losers if we have to support both simultaneously :-(.

@mhdawson has made the point, and I agree, that this should be an appsody wide decision. If all/most of the stacks in appsody/stacks are UBI, Node.js should be as well. If appsody/stacks has to be forked and maintained in parallel kabanero/collections, all of appsody/stacks should probably switch to UBI so that the fork is unnecessary.

All of which is to say - we don't see why Node.js is specifically being discussed, its a question of project wide direction, and we aren't in a position to observe any developer uptake of appsody, so its hard to gauge the impact there.

[arthurdm]

I think it's a Appsody-wide statement in terms of stacks that also want to be included in downstream certified hubs (like the CP4Apps hub).

Any Appsody Stack that has this desire (such as Open Liberty, Node, etc), then it makes sense to use UBI so that a single stack is used throughout the streams.