Autodetection returns internal IP when running in Docker container

[sejnub]

I am in the process of building a Docker container for the noflo-nodejs-runtime (First version is for the raspberry pi. Other versions will be added if I succeed). I will hone this container and the documentation so that it will be easily usable. The Dockerfile can be found under https://github.com/sejnub/docker-noflo-runtime-js/blob/master/Dockerfile

Here comes the problem(s): After node is configured with

node node_modules/.bin/noflo-nodejs-init --user <id> --host <public runtime ip> --port 3569 --label "noflo-nodejs on Raspi"

it shows the following:

Stored the following configuration to /flowhub.json

id: "<36 digit id>"
user: "<another 36 digit id>"
host: "<public ip of the runtime host>"
port: 3569
label: "Local NoFlo Test"
secret: "<secret>"
permissions: {
  "<same secret again>": [
    "protocol:component",
    "protocol:runtime",
    "protocol:graph",
    "protocol:network",
    "component:getsource",
    "component:setsource"
  ]
}

When I then start the runtime with

node node_modules/.bin/noflo-nodejs --capture-output=false

the runtime is registered and visible in the browser on the app.flowhub.io after logging in.
But the runtime is shown with "ws://172.17.0.4:3569" which is the local ip address of the container the runtime is hosted in.
So when I click the runtime it of cause can not connect.

I found out that I have to set the host again when I start the runtime with

node node_modules/.bin/noflo-nodejs --host

Why is this?
I did set the host with "noflo-nodejs-init --host" so why set it again with "noflo-nodejs --host "?
If I don't set it again here the runtime does register at app.flowhub.io but it is registered
with the local ip of the container 172.17,... and so the flowhub-app can't reach the runtime.

First question: Why do I have to set the host two times? Is this intended behaviuor

But even if I set it here again I can't find a way to use this runtime in a github synced project. The registered runtime is not shown when I try to use the "Select runtime" button.

Second question: How can I use my registered runtime inside a github project? (Or is this question noflo-ui related and I should post it there?)

When I register the runtime manually via "new runtime register / add manually" it works, but only one time. When I go back to "home" (app.flowhub.io) the manually registered runtime is shown for only half a second, then it's gone.

Third question: Why is the manually registered runtime only usable a single time? (Or is this question noflo-ui related and I should post it there?)

I am sorry, if this is the wrong place to ask this questions. I could not find a better one.

[bergie]

Thanks for the bug report! Sounds like there is indeed an issue with the defaults handling in noflo-nodejs. I'll look at this next week.

[bergie]

FYI: the noflo-ui side of this is being handled in noflo/noflo-ui#680 where we change the manual runtime registration so that it both:

• Saves the new runtime in Flowhub registry (so it is available to your other Flowhub client instances)
• Saves the new runtime in IndexedDB

[sejnub]

Great!
I will have a look at it the day after tomorrow.

FYI and a bit off topic: If you think it might be interesting for others as well I will gladly hone the docker image until it is easily usable and also runs on x86 (and not only ARM).

[bergie]

@sejnub yes, Docker image sounds useful. Are you planning to distribute it via https://hub.docker.com/ ?

[bergie]

Also, I'd be happy to include the Dockerfile in this repo if you make a PR. Then we can add some Docker testing to the CI suite

[sejnub]

Yes, it will be on https://hub.docker.com
Continuous test for the container would be useful.
You will here from me during the next days.

[sejnub]

I worked on the docker image.
You can pull it from https://hub.docker.com/r/sejnub/noflo-runtime-js/
The source you find at https://github.com/sejnub/docker-noflo-runtime-js

I still have some questions and remarks about noflo-ui. If it's OK with you I will post them as issues at https://github.com/noflo/noflo-ui/issues

I also still have a remark about the relation between the node_modules/.bin/noflo-nodejs-init and the node_modules/.bin/noflo-nodejs the way they share the responsibilities now doesn't make much sense for a docker image because for every docker run I have to call both of them. But I think it's better to post that as a separate issue so that this issue can be just about the docker image and not about those internals.

I would be glad if you could test this docker image and give me some feedback.

p.s.: About the PR: I wouldn't know where inside your source I should place my docker stuff. So I didn't create one.

[bergie]

@sejnub yes, you're certainly more than welcome to report issues in noflo-ui repo!

As for noflo-nodejs-init, the idea of that script is just to prepopulate a config file so that the options don't need to be passed to noflo-nodejs every time you run it.

So in theory at least these three should be equivalent:

• Create a .flowhub.json file manually and run noflo-nodejs
• Use noflo-nodejs-init to create .flowhub.json and run noflo-nodejs
• Just run noflo-nodejs and pass it all the relevant options, no config file needed

[sejnub]

Ah, OK, that's simple enough.

Then

• --label must be added to noflo-nodejs because at least in my case I want to change it with every run and therefore now I must execute noflo-nodejs-init with each docker run
• the names should be harmonized. e.g.: --id vs --uuid
• I have to test if now the noflo-nodejs-init --host option is really used by noflo-nodejs. When I last checked it seemed it wasn't.

Do you need any further improvements for the docker image before you can integrate it into the CI suite?

[bergie]

@sejnub for integration, a pull request adding it to this repository would be awesome. We can then rig it in to the Travis setup

[sejnub]

I created PR #107. I hope this will be useful.