Docker-compose dgraph/standalone

Issues Dgraph
1

Report a Dgraph Bug

Unable to get the dgraph/standalone docker image to work with docker-compose. Most likely issue is user error but I have been unable to find a working example.

Steps to reproduce the issue (command/config used to run Dgraph).

Here is the relevant section of the docker compose file:

dgraph-standalone:
    image: dgraph/standalone:latest
    volumes:
      - /tmp/data:/dgraph
    ports:
      - 5080:5080
      - 6080:6080
      - 8080:8080
      - 9080:9080
      - 8000:8000

Expected behaviour and actual result.

Error:

dgraph-standalone_1  | E0617 22:58:52.216163      42 groups.go:1177] Error during SubscribeForUpdates for prefix "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x15dgraph.graphql.schema\x00": Unable to find any servers for group: 1. closer err: <nil>

I’m guessing this is a result of dgraph zero not being run. However, if I run dgraph zero with the following config, then ratel is no longer available on port 8000.

  dgraph-standalone:
    image: dgraph/standalone:latest
    volumes:
      - /tmp/data:/dgraph
    ports:
      - 5080:5080
      - 6080:6080
      - 8080:8080
      - 9080:9080
      - 8000:8000
    command: dgraph zero --my=zero:5080
2

The standalone container just runs both an alpha and zero process in one container:

dgraph zero & dgraph alpha

So it should have both running. When you change the command in your snippet, you are only running the zero.

Ratel is not running in that container but can be accessed at play.dgraph.io and connecting to your local instance. (Or by running it’s container in your compose setup)

3

Thanks, @iluminae!

4

@iluminae I’m trying to use the standalone image in some E2E tests (using my Docker Dgraph Container helper, https://github.com/matthewmcneely/dgraph-docker-helper) and need to allocate some uids via the zero’s /assignIds endpoint. Seems as tho 6080 is not exposed in the standalone’s Dockerfile (https://github.com/dgraph-io/dgraph/blob/9e8ab992b2c38e18f89f40bdb698e272a9c402ce/contrib/standalone/Dockerfile).

Is this by design? Perhaps nobody has tried to administer the zero container in the standalone…

5

Yep, feel free to add that port and ping me to review it.

6

@MichelDiz I’ve managed to confuse myself… if I start standalone via docker cli with the 6080 port bound

   docker run <snip> -p 6080:6080 dgraph/standalone:v21.03.2

I’m able to hit the http://localhost:6080/assign endpoint…

However, inspecting the image via:

$ docker image inspect dgraph/standalone:v21.03.2
[
    {
        "Id": "sha256:fa19f7b7f08a609eb2a2caabd527224b21b3597103e2d0526a444e67ee4398a0",
        "RepoTags": [
            "dgraph/standalone:v21.03.2"
        ],
        "RepoDigests": [
            "dgraph/standalone@sha256:c61d82d05ad934106c49468138ca6abd2d0fb4c0d6d68e56bfde60f4e6edf9ae"
        ],
        "Parent": "",
        "Comment": "",
        "Created": "2021-08-26T08:14:44.974245286Z",
        "Container": "95949f0222bc769c8a653d8346e687d3b55f7caedfec4210e2464e74898cc729",
        "ContainerConfig": {
            "Hostname": "95949f0222bc",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "8000/tcp": {},
                "8080/tcp": {},
                "9080/tcp": {}
            },
<snip>

shows only the three ports available to be exposed. Thoughts?

7

No idea, based on that dockerfile it shouldn’t be exposed. Might be something from Docker.

8

OK, I can confirm that if I build an image thusly:

FROM dgraph/standalone:v21.03.2

EXPOSE 6080

and run that image via my Dgraph Docker Helper in which I programmatically bind a free port to 6080, then I’m able to access the /assign endpoint at the natted port in my golang tests (via http.Get). Still not sure how forcing the bind with docker run -P is working (the Docker Golang SDK is not).

@MichelDiz Not sure if that’s worth a PR given that I’m the first person (I’m guessing) that needed to access 6080 in E2E tests using the Docker Golang SDK. Thoughts?

9

Let me ping @dmai

10

when you exposed the port with -p that port did not have to be in the docker file. Honestly EXPOSE in the docker file does nothing at all. From the docker docs:

The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published.

So when you added the port with -p it worked because that is the only way it actually exposes the port.

11

@iluminae Thanks. So it must be an issue (feature?) with the Docker SDK: that it will not bind a port that is not in the ExposedPorts definition:

Looking at the image from the above Dockerfile…

$ docker inspect image test_standalone:latest
[
    {
        "Id": "sha256:fac2115b85306916a3bedd1ed02d73f48d811ad2b704937ae002dac9a56b8f8f",
<snip>
            "ExposedPorts": {
                "6080/tcp": {},
                "8000/tcp": {},
                "8080/tcp": {},
                "9080/tcp": {}
            },
<snip>
]

The dgraph/standalone:v21.03.2 does not have the 6080/tcp entry, thus the SDK won’'t allow it to be mapped.

12

Yea I do not know anything about the docker SDK but sounds like a good hypothesis to me. Note I was not arguing against adding the EXPOSE layer to the standalone image in the docker repo, I was merely explaining why it worked when you used docker run with -p.

13

Created a PR: https://github.com/dgraph-io/dgraph/pull/8064