Static docker image name fails with custom build for other architectures

[al-sabr]

See : neunhoef/ArangoDBStarter#13

[al-sabr]

This comes as output in the docker container:

docker volume create arangodb2 && \
    docker run -it --name=adb2 --rm -p 4005:4000 -v arangodb2:/data \
    -v /var/run/docker.sock:/var/run/docker.sock arangodb/arangodb-starter \
    --dockerContainer=adb2 --ownAddress= --join=

docker volume create arangodb3 && \
    docker run -it --name=adb3 --rm -p 4010:4000 -v arangodb3:/data \
    -v /var/run/docker.sock:/var/run/docker.sock arangodb/arangodb-starter \
    --dockerContainer=adb3 --ownAddress= --join=

[al-sabr]

arangodb/arangodb-starter should actually be the image name of the parent container or dynamically assignable

[ewoutp]

Note that this output is only there to give you an advise for what to do.
If you package the starter in another images, it should be no problem to use that image name instead (as long as the starter is the entrypoint).

Now we can probably detect the image name of the containing docker container and use that.
We'll look into that.

[al-sabr]

I don'T understand this output is not actually executed on the host ?

Why those command should be entered manually ?

[ewoutp]

The commands should be executed on different hosts to achieve high availability of your cluster.
If you want a local cluster for testing purposes (WITHOUT High availability), use the --starter.local option.

[al-sabr]

I was asking myself why do I need to manually do that when starter can send a command to the swarm cluster and tell other nodes to run the commands...

I think that that this is not 21th century thinking... There is a lack of design in this solution.

If you can already communicate with docker then why not take advantage of the power of docker swarm

[ewoutp]

That would work on docker running in swarm mode.
But not when running servers with individual docker instances

[al-sabr]

There is no point of running the starter with individual instances its purpose is for clustering and swarming

[ewoutp]

I disagree on that. There are plenty of companies that use lots of docker servers, without using swarm. Instead they use some other orchestration system.

That does not mean that docker swarm would make an interesting addition for the starter. We'll discuss what to do with that.

[al-sabr]

Alright fair enough... I think that what is missing for arango-starter is video tutorial with demo instead of text file and README.MD. It is a product on its own and needs care and introduction.

Thanx a lot have a good day

[sloniki]

I'm trying to build a cluster on 3 physical docker hosts. I started arangodb-starter on the first host 192.168.1.98 with parameters:
-p 8528:8528
--starter.address=192.168.1.98 --starter.join=192.168.1.98

Then I start another stater instance on another host 192.168.1.99 with parameters:
-p 8528:8528
--starter.address=192.168.1.99 --starter.join=192.168.1.98

Getting this on the second agency container:
17T21:35:06Z [1] ERROR {cluster} cannot create connection to server '' at endpoint 'tcp://192.168.1.98:8541'
I noticed that the first agent is listening port 8531, how can I change the port numbers for automatically created containers? Or could you advise, how to build a cluster across several physical hosts. I need authentication and TLS as well.

[ewoutp]

@sloniki Make sure to leave out the --starter.join option for the first starter.

About the port numbers, they are automatically derived from a base port (--starter.port).
The coordinator gets an offset of 1, the dbserver and offset of 2 & the agent an offset of 3.

You cannot change these offsets, but you can change the base port.
E.g. --starter.port=1234 will result in ports 1234 (for the starter), 1235 (for the coordinator) and so on.

[ewoutp]

@sloniki TLS can be activated by the --ssl.keyfile option, for authentication use the --auth.jwtsecret option.