Adds Compose files for Traefik setup

[vedmaka]

Removes Caddy from the stack and replaces it with Traefik running as a front-end. Note that the stack file was split into two:

• docker-compose.traefik.yml - for a standalone Traefik instance
• docker-compose.yml - for Cansata stack pre-configured to run with Traefik as a front-end

Warning: merging this change will break https://github.com/CanastaWiki/Canasta-CLI

[jeffw16]

Wow, thanks @vedmaka!

Should we perhaps consider replacing Caddy entirely with Traefik? I see little benefit to supporting both if Traefik is more capable and scalable.

[vedmaka]

@jeffw16 I had a feeling that running Traefik for a single wiki instance is a bit of an overkill, though maybe it's not, so let me know your vote

[jeffw16]

I don't think it's overkill

[jeffw16]

Wow, awesome PR! I have several comments I will post soon. It is getting close to SMWCon so it's crunch time ;)

[jeffw16]

Is there a reason why a new file was created instead of adding this to docker-compose.yml?

[gitmapd]

Hi, i think he separated the files to show the difference between using traefik or not using it.

[jeffw16]

While that may be the case, that's not a valid reason to ultimately have two files for people to use. How would they handle this? However, please let the PR author comment. I don't want us pointlessly speculating and confusing ourselves.

[vedmaka]

I forgot to update the initial PR description so believe this confused you (I have updated it now). The idea behind these new stack files is as below:

• docker-compose.yml is for running a single wiki instance which is pre-configured to work with Traefik as a front-end
• docker-compose.traefik.yml is for running pre-configured Traefik instance that can serve one or more wiki instances

The reason of having it on separate files is that one could want to have multiple wikis running on a single VPS, having both Traefik and Wiki on a the same stack file would make this impossible without the file modification, but having it separated allows to easily spin necessary number of Wiki stacks and then run a single Traefik instance to serve all the Wikis

Please also see the README updates

[jeffw16]

Thank you very much @vedmaka for the clarification, I'll read this and think about it some more.

[vedmaka]

Thanks @jeffw16, you did understand this right and your point on that this increases complexity compared to a simple docker-compose up -d is absolutely legit too.

I don't have a good solution for this though, since even running a single instance of wiki paired with a single Traefik requires an extra step to be performed by end user ( to create a docker network [1] )

We probably could have both wiki and Traefik sitting on the same docker-compose.yml by default, this would mean that running a single wiki instance will stay as simple as possible ( though the initial network creation may still be necessary ) and if one would want to have multiple instances served at time - the README will contain information on how to split the Compose file and what commands to run

The alternative could be to remove the need of running docker commands by end user and instead have own entrypoint for the stack. We did something similar to that on https://github.com/WikiTeq/docker-wikiteq-stack ( see compose.sh ) when we wanted to split stack yml into separate pieces and eventually allow this to evolve into config-available / config-enabled pattern

It looks like the https://github.com/CanastaWiki/Canasta-CLI is an evolution for that, so maybe we could delegate all of the start configurations to the CLI and impose a rule that the stack has to be managed via CLI by end users? In this case the simplicity of docker-compose up -d won't be lost because the CLI can do all the necessary operations on start or similar command

In the end, since there is no silver bullet, I think it's up to you to choose which approach looks better

[jeffw16]

Yeah, we are stuck in a tough position here. But I think the reason the proposal here to split the Traefik container to a separate YAML is because it can serve multiple Canasta container instances. Our 2023 GSoC project is to add wiki farm support. Let's revisit this PR as we get closer to the GSoC contributor finishing up their wiki farm project.

[tosfos]

We're well into the summer. How do we proceed here?

[jeffw16]

Now that wiki farm support is released, is this PR still relevant? We no longer wish to encourage running multiple Canasta instances on the same server, in general. It's technically possible, but there are limited use cases for it.

[vedmaka]

The farm feature and multi-instance deployment are separate approaches with different goals and side effects, and it would be nice to be able to run it via Traefik as multi-container setup. Either way, it seems like this PR deserves a rework to move the Traefik setup into completely optional vs how it's done right now. It's also likely the Traefik Compose should not be part of it and instead be a separate stack

[yaronkoren]

@vedmaka - could you please answer @jeffw16's two (I think) questions? I really would like to get this patch in, assuming there are just a few minor issues that need to be resolved.

[tosfos]

We'll check this soon

[tosfos]

Just letting you know we haven't forgotten about this. We're revising the code now and testing.

[jeffw16]

@Justman100: I'm in no way obligated to reply to PRs even if they are stale or have been pending for over a year. Please reconsider the way you get people's attention. You are not my boss (and my manager wouldn't talk to me in such a disrespectful tone either).

[jeffw16]

Then ask politely. Like "Hey, circling back on this, would you be able to take a look?" Don't command us to do anything.

Everyone is busy and has their own life. No maintainer of an open source project is obligated to do anything, because we are all volunteers. You can mention other maintainers for assistance too.

[jeffw16]

In my opinion, it is impolite. I've set my boundaries, now you can make of that what you will.

In any case, we are still blocked on this PR; we're waiting for the response that I requested.