examples: add example to run with docker stack

[dinigo]

resolves #306

[dinigo]

ID                  NAME                IMAGE                  NODE                DESIRED STATE       CURRENT STATE         ERROR               PORTS
g6dkxb1bietu        jitsi_web.1         jitsi/web:latest       swarm               Running             Running 3 hours ago
zi4icxe1gcmi        jitsi_prosody.1     jitsi/prosody:latest   swarm               Running             Running 3 hours ago
r28c3qm7u4dn        jitsi_jvb.1         jitsi/jvb:latest       swarm               Running             Running 3 hours ago
s0k82gql7xwt        jitsi_jicofo.1      jitsi/jicofo:latest    swarm               Running             Running 3 hours ago

Just had a chat with a friend using it

[saghul]

Why ddo we need to duplicate the docker-compose.yml file? How about providing a bash script wich creates the required yaml file for Docker Stack?

[dinigo]

righ

[sgohl]

Did anyone have success here, yet? I'm pulling my hair off trying to get it working on swarm.

What are the Hostnames in the config for swarm? Like, those:

      XMPP_AUTH_DOMAIN: auth.meet.jitsi
      XMPP_DOMAIN: meet.jitsi
      XMPP_SERVER: xmpp.meet.jitsi
      XMPP_GUEST_DOMAIN: guest.meet.jitsi
      XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
      XMPP_RECORDER_DOMAIN: recorder.meet.jitsi

I don't get that thing with the aliases and the domain suffixes. Why aren't they just talking by service hostname? This works with swarm and docker-compose.

nginx wasn't the best choice either. It's not able to do dynamic dns lookups (at least not like you configured it without resolver). If any container restarts, upstream is dead and remains dead. Also it makes no sense that Etherpad MUST be running when nginx starts, just because nginx too dumb to ignore. In my opinion, Caddy would've been a better choice. More even, to be able to connect the stack with an already running traefik, like I have.

The only way I see that whole thing would make sense, was an all-in-one image. It's the same base image for everything anyways, and you're using an init system, so this way all upstreams could be localhost and voila. Wouldn't bloat my swarm portforwardings either, I hate using them.

[dinigo]

yes. basically you alias the shared network when needed

[tu-nv]

The PR does not work for me when there are 3 or more people in the meeting. I see the error xmpp.meet.jitsi: Name or service not known in jvb.

Also tried to not using network alias but using the service name (i.e.: set XMPP_SERVER=prosody), and this DOES work with docker-compose up -d, but does not work with swarm (error: prosody: Name or service not known). I tried ping prosody from other container and it works.

The docker overlay network just bug me everytime I need it :disappointed:

[hamletmun]

What about using the overlay network?

networks:
    meet_jitsi:
	driver: overlay
        attachable: true