tpires / neo4j Goto Github PK

Hi,
i'm trying your docker image, but the i have a problem when i stop and start the container.

Example:
RUN container -> IPADDR 172.10.1.42, so neo4j conf is listening on the correct ip
STOP container
START container -> now the value of IPADDR is 172.10.1.43 but the neo4j configuration has not replace d the old ip

this is the log of the container :

10:47:18.357 [main] WARN  o.e.j.u.component.AbstractLifeCycle - FAILED ServerConnector@17a5e4ea{HTTP/1.1}{172.10.1.42:7474}: java.net.BindException: Cannot assign requested address
java.net.BindException: Cannot assign requested address

How can i manage start and stop?

Thanks

Hi,

I am new to Docker. I have a Rails app that uses Neo4j graph database, and I would like to run this app in docker. I'd want to use a docker-compose.yml to have two services, one is neo4j and the other is web that links to neo4j. In neo4j service part, I would like to use the neo4j image you created (and hosted in Docker Hub):

neo4j:
image: tpires/neo4j
ports:
- "7474:7474"
....

web:
build .
...
links:
- neo4j

I'd want to run the neo4j image with authentication enabled and a username/password set, just like what you mentioned:

docker run -i -t -d -e NEO4J_AUTH=username:password --name neo4j --cap-add=SYS_RESOURCE -p 7474:7474 tpires/neo4j

How would I do it from within my docker-compose.yml? If neo4j's authentication can't be set in docker-compose.yml, where can I do it?

Thanks for your any input.

Alex

This is a common pattern (see: official postgres image), which uses environment variables, e.g. NEO4J_USER and NEO4J_PASSWORD, to create these credentials in the container.

Would this be possible?

The http repo used here: https://github.com/tpires/neo4j/blob/master/Dockerfile#L12 doesn't contain the latest 3.x versions of neo4j community. Instead it tops out at 2.2.3.

By changing the repo to https:// I was able to get the latest version of neo4j, but I had to also add the apt-transport-https package to get it to work.

resulting in 10secs delay, and db recover on next startup.

this is because the image is launching a .sh script, which doesn't pass the termination signal to the sub processes, as described in moby/moby#2436