Rework docker compose for swarm support

[jeanmi151]

This is a rework of docker compose for swarm support

[jeanpommier]

First, quick review.

Before any remarks, this is really interesting work, thanks a lot for the contribution !

Apps

Apps started but not available on the interface:

• metadata-editor. Not routed in GW. /etc/georchestra/metadata-editor does not exist in config

Apps not configured

• smtp (documented ?)
• geonetwork (as before afaik, but would be good to give a kickoff hint)
• datahub shows error due to GN not initialized

Documentation

Readme

• tells the user to rsync on port 2222. Relies on ssh_data container, removed from the compo
• SMTP service references the old behaviour (trapped into local sink), while this offers an SMTP relay, to be configured (document how to)
• double paragraphs about kibana

Running as docker compose

Seems fine, apart from previously mentioned points

Running as docker swarm

On first deploy, some services fail before they're restarted and their dependencies are fulfilled. Maybe worth mentioning it, so that the users wait for them to settle

Cleaning the volumes

I noticed it is not really straightforward to clean the volumes afterwards. Maybe a quick instruction on how to do it would help. Either for classic cleanup after having given swarm a try. Or because you need to start fresh for whatever reason.
It came out with something that might not be perfect:

STACK_NAME=georchestra
for vol in `docker volume ls --filter "Name=${STACK_NAME}_.*" --format json | jq -r '.Name'`; do docker volume rm $vol ; done

[jeanpommier]

Is it ? Trapped ? AFAIK, with the new config, we have an smtp relay, that will not really work since it's not configured by default.
=> tell folks to configure the SMTP relay and modify accordingly this line ?
Does it mean we drop the old SMTP sink stuff ? (not against it, since it was really demo-mode only, but asking anyway)

[jeanpommier]

"trapped by a local SMTP service." is not true anymore, or is it ?

[jeanmi151]

thanks @jeanpommier for your tests,

I created a pr to add metadata-editor in the datadir georchestra/datadir#502

And I took into account you remark about the README

[edevosc2c]

I don't think there is a need for this constraint, these lines can be omitted:

placement:
  constraints: [node.platform.os == linux]

One will only run geOrchestra on Linux since all the other Docker images are only supported for Linux.

See "OS/ARCH" for this example Docker image: https://hub.docker.com/r/georchestra/geoserver/tags

[jeanpommier]

Are you sure @edevosc2c that those are an exact match ?

I had a quick look on a Windows machine, where an docker info --format '{{ .OSType }}/{{ .Architecture }}' returns linux/x86_64. I'd say this matches the OS type supported by the docker instance, i.e. the OS/ARCH tag.
While the placement constraint above, I believe, looks for the node's OS, which could be a Windows machine for instance.

We don't officially support Windows hosts, even if it might be working, or close to working. So, keeping the placement constraint on linux OS has the advantage to be explicit.

[edevosc2c]

I was suggesting for saving a couple of lines that those could be omitted since the Docker swarm modules would only be deployed on Linux machines.

docker-compose.swarm.yml is not deployed by default. One has to explicitly ask Docker to deploy it: https://github.com/georchestra/docker/pull/377/changes#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R80

Even if by mistake someone would deploy that image on Windows, it wouldn't harm the deployment since the image portainer/agent:lts has support for Windows: https://hub.docker.com/r/portainer/agent/tags