Upgrade of the docker package to typescript

[phantomjinx]

The nginx.js njs module script is written as native javascript according to the unique standards of the njs module framework.

Convert the script to typescript to enforce greater typing for improved maintainability and to conform with the rest of the project.

This can be achieved using the njs template-starter project.

A POC branch has already been implemented here.

[phantomjinx]

The template-starter project uses rollup and babel rather than tsup. Therefore, either this would need some sort of migration or the docker package would remain with using a set of different transpilation tools.

[phantomjinx]

Upgrade would need to be mindful of the issues described in this gist concerning the different responses from jolokia.

[tadayosi]

@phantomjinx @grgrzybek I have another idea on the task. I don't think the current Nginx + NJS architecture is scalable in several ways:

1. The server side logic (NJS) is tightly integrated with Nginx server in a way that's similar to CGI. Thus, request handling and intermediate message processing need to be computed together in one container, which can be a bottleneck.
2. NJS is merely a subset of JS specification, thus we always need to be aware of its limitation, even if we transpile TS to JS for the NJS code. We may not be able to use the best practices and modern tools/techniques commonly used in the Node.js community.
3. NJS is a separate module; which means, in production, RHEL not likely provides a binary rpm for the NJS module. That makes our life in productising hawtio-online really hard and causes a lot of troubles there.

What I propose here instead is to migrate the hawtio-online architecture to Nginx + Node.js (two containers in one pod).

• Nginx -- Request handling, caching, and providing reverse proxy responsibility to K8s API server and backend application pods.
• Node.js -- RBAC and the rest of server side logic originally performed in NJS.

(Note a single pod can have multiple containers in K8s. https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)

This is actually a common architecture in Nginx and Node.js communities.
https://docs.nginx.com/nginx/deployment-guides/load-balance-third-party/node-js/

The benefits of the new architecture:

• You can develop the server side code as a typical Node.js application. You can make it in TypeScript very easily, and utilise every tool and method that is commonly used in modern Node.js development.
• No more productisation nightmare. As Nginx mostly uses standard configurations, it can be upgraded a lot more easily. Also the Node.js part is based on the Node.js runtime, it should be easy to maintain so long as it complies with the productised Node.js runtime.

[grgrzybek]

If I understand correctly, the node.js container in common pod would run express.js server with some endpoints implemented as express.js middleware, right?
This would allow us to develop/test this part outside of K8S, right?

[tadayosi]

If I understand correctly, the node.js container in common pod would run express.js server with some endpoints implemented as express.js middleware, right?
This would allow us to develop/test this part outside of K8S, right?

Yes, the Node.js container would provide some REST endpoints for Nginx, which can be run/tested outside of K8s. That doesn't exclude choosing other web servers such as Hono instead of Express.js.

[phantomjinx]

If I understand correctly, the node.js container in common pod would run express.js server with some endpoints implemented as express.js middleware, right? This would allow us to develop/test this part outside of K8S, right?

Not so much outside of k8s as we still need the responses from the k8s cluster to determine the url of the jolokiaAgent.

The njs logic to be replaced is here. The proxyJolokiaAgent function makes several checks then ultimately returns a connection url that can be clicked on in the UI to connect to the main hawtIO page.

There is, though, now an additional endpoint in the njs that we need to take account of:

• The proxy guard: allows only a limited set of endpoints to connect through to the cluster;

For this to be pushed down to the nodejs container as well, will require the /master endpoint to be pushed down too. As the communication, I think, will only be 1-way (nginx -> nodejs)?

Incidentally, this will mean that there will be 2 images for hawtio-online rather than one since each container in the pod will have their own image.