Document using NPM registry for FlowFuse Device Agent (air-gapped environments)

[dgatti0213]

Description

https://app-eu1.hubspot.com/contacts/26586079/record/0-3/252826054853

We are working with a customer running FlowFuse in an air-gapped environment who would prefer to use Amazon CodeArtifact as their npm-compatible registry rather than the built-in flowfuse/npm-registry.

Their main reason is operational: using the built-in registry would require them to modify every container image to include a filesystem-watching process to sync modules, which they would like to avoid.

Instead, they need like all Node-RED runtime containers and palette dependencies to be pulled from CodeArtifact, which is already approved and used internally.

[dgatti0213]

Do Stacks apply for Remote and Hosted instances?

[hardillb]

You can not use the Team Library -> Custom Node with a different repository, it depends on the integrated verdaccio authentication plugin to work.

Adding 3rd party NPM registries is possible, but will require the users to create their own Node-RED catalogue. The catalogues and npmrc file for authentication can be configured in the default template so automatically applied to Hosted Instances (it currently needs be manually applied to Remote instances that are Application bound)

Do Stacks apply for Remote and Hosted instances?

Stacks only apply to Hosted Instances

[dgatti0213]

Sorry, I think im confusing NPM lib with repos for pulling container images. On a hosted instances, stacks works great.

On remote instances, they can define what image they want by the docker compose command. How do air gapped systems work with defining NR version on a remote instance?

[hardillb]

How will they deploy the Device Agent?

But the short answer is a .npmrc file can allows overriding the default npmjs.org registry for all packages, not just specific scopes.

[dgatti0213]

They will be deploying the Device Agent and all Remote Instances using Docker, and when running docker compose/deploy they will point to their own internally maintained forked containers.

All that forking means for them is the containers has been scanned and are hosted internally.

[hardillb]

OK, since they are building their own containers then adding a .npmrc at build time will be the best way forward.

They shouldn't need a NR catalogue if they are just proxying all the npm traffic via their own registry

[dgatti0213]

Perfect, Ill pass this on. Thank you!

[hardillb]

It needs to be included in the /opt/flowfuse-device directory in the container iirc

[dgatti0213]

Here is a link as an example of what they do currently to spin up Node-red:
https://drive.google.com/file/d/1EE96rfvMAe49WVkekN6MyaPfa9cYO1E_/view?usp=sharing

If i'm following, adding the repo to the directory will point at their server?

[hardillb]

@dgatti0213 I think we need a longer discussion about that Dockerfile (and the fact that is closer to a hosted instance, not a remote instance). But it shouldn't be here.