What is the "Connect URL" when using Kubernetes Ingress and reverse-proxy?

Hi folks!

I am trying to host Neo4j, exposing it using a Kubernetes Ingress resource. I am running in GCP, Google Cloud Platform. And I find that while I can bring up the browser UI, I cannot then make the bolt connection to the DB.

Background

I've been using Neo4j's instructions and helm charts with all the defaults, specifically:

  1. To get a neo4j instance running, I follow the quickstart-standalone instructions, which references the helm chart 'neo4j/neo4j'

  2. To then expose via Ingress, I follow the accessing-neo4j-ingress instructions, which references the helm chart 'neo4j/neo4j-reverse-proxy'. These docs also have a helpful diagram, near the top, that explains the flow between user and reverse-proxy.

I do make one important change to the defaults, though: I use 'contour' ingress instead of 'nginx', which is what is specified in their Ingress instructions linked above.

So, questions:

1 Assuming everything is working with the Ingress and reverse-proxy server, what is the Connect URL value supposed to be?

Let's say that to get to the browser UI I go to http://my-hostname.xyz.com/browser, then the Connect URL is auto-populated with with bolt:// and my-hostname.xyz.com:7687

This is confusing because from the reverse-proxy setup as described in the diagram in the Ingress docs linked above (and also from trying to read through the kubernetes manifest and the reverse-proxy's go code), it seems like the browser UI is meant to talk to the reverse-proxy via http on port 80. But the UI is trying bolt, on port 7687.

I found myself wondering if my URL was wrong and trying many variations, none successful.

So what is the bolt Connect URL supposed to be?

2 Is 'nginx' Ingress a hard requirement, or might other types of Ingress, like 'contour', also work? If so, why?

For various reasons I cannot use 'nginx' and so cannot readily experiment. But looking in the diagram in the Ingress docs (again, linked above), it seems like the browser UI is trying to make an http connection to the reverse-proxy server, which seems straightforward and like it could work with 'contour'.

But then looking at the browser's network traffic, it looks like the browser trying to make websocket connections, which I didn't understand and isn't shown on the diagram (in the diagram, it shows websocket is handled between the reverse-proxy server and the neo4j instance, not between the user/browser and the reverse-proxy server...)

So I was wondering if anyone can elaborate on the plumbing here. Is there some characteristic to the 'nginx' ingress that 'contour' does not support? Is the browser not actually talking to the reverse-proxy, to make the bolt connection?

Thank you! :slight_smile:

1 Like

Hi again folks! I ended up not using Ingress, I used LoadBalancer.

I do not see an option to 'close out' this issue, so, I'll just note that I am considering it closed now. But I will write a little update explaining why and what I learned, in case it helps people in the future.

I used LoadBalancer for a few reasons:

  1. LoadBalancer pretty much 'just worked' as expected/documented by Neo4J's docs. It also seemed simpler overall: it avoided the complication of the Ingress approach with its 'go' proxy, for example, and overall deployed fewer resources.
  2. As far as I could tell, the Ingress approach as documented in the helm chart and the diagram here does not work as documented, or, I just was misunderstanding or missing something and could not get it to work.
  3. I had initially tried to avoid LoadBalancer only because I thought my Kubernetes admins here wanted us to avoid it. But it turns out I was reading outdated guidance.

To make LoadBalancer work nicely, I did a few additional things:

  1. This is mentioned briefly in the Neo4J docs here but with the LoadBalancer on its own, you get a dynamic IP. I added staticIP for it, and an A Record, thereby setting up a hostname to make the instance easily accessible in the browser.
  2. I also set up a TLS cert so I could use https/bolt+s, and found the Neo4j docs for this to be straightforward—I just did what they said. Basically in my cluster we have a way of generating certs. Once I had that, all I had to do was plug in the SSL items in the helm chart, as is more or less shown here

Hope this helps folks.

1 Like