switch to traefik2.1

[yelizariev]

not tested yet. See also Tecnativa/doodba#278

WIP until:

• Prepare to use copier #69

[yelizariev]

All tested except to test.yaml

[yajo]

Thanks, very interesting PR. I had this in my TODO list for a long time. 😊

I'll test and review ASAP.

One question in the mean time: is there any way to handle backwards compatibility? Requiring to update at the same time your traefik deployment and all environments in each server is a challenging task...

[yelizariev]

One question in the mean time: is there any way to handle backwards compatibility? Requiring to update at the same time your traefik deployment and all environments in each server is a challenging task...

I don't think that there is backward compatibility... I'd switch projects from v1 to v2 one by one, but for this you may need different prefixes for labels (``traefik2.enable: "true"```), but there is no such option.

So, the only solution I see is some script to update all projects with shared inverse proxy at once.

[yajo]

And if we leave in place both sets of labels? Would that make containers compatible with both traefik 1 and 2?

[yelizariev]

I didn't try. If traefik ignores labels from another version, then it can help with the transition. I can imagine the following scheme:

• the server needs an additional IP address
• then redirect IP2:80, IP2:443 to traefik2.1 ports via iptables
• now add labels for traefik2.1 in a project
• switch the project to IP2
• when all projects are switched, traefik 1.6 can be stopped and corresponding labels are deleted

[yajo]

AFAICS the new labels don't collide with the old ones, and the ones that are equal behave the same, right? So, the test to do is quite easy:

1. Add all labels to containers (for traefik 1 and 2).
2. Boot container behind traefik 1.
3. Check traefik logs and functionality; make sure it works ok.
4. Replace traefik 1 for 2.
5. Check traefik logs and functionality; make sure it works ok.

If it works fine, it'll be the easiest deprecation method IMHO.

[yelizariev]

Keeping both set of labels looks reasonable. Can you assisting on testing it? I didn't use traefik 1 and I'm not really interested to support both version.

I've returned traefik 1 labels and also fixed test.yaml (without testing even in traefik 2.1): https://github.com/Tecnativa/doodba-scaffolding/compare/4e424eef980979e7d5b6998b58ca61bc0a21c07b..fe378832b89e16956949ac201df870a5007caaa8

[yajo]

I have tested it and, as expected, traefik v1 ignores the labels it doesn't understand, so it seems to work fine as a deprecation path.

I took the freedom to amend your commit, with some stylistic stuff that was faster to write myself.

However, since I haven't tested it, I wouldn't like to make it seem like we support traefik 2.x officially.

In that regard, please could you add a PR to the main doodba project, to the README? It would indicate that there's experimental support for traefik 2 and, if possible, the recommended docker-compose.yml configuration to deploy it, just like we have for v1.

[yajo]

Have you considered this? traefik/traefik#4863 (comment)

[yelizariev]

Isn't it the same as I did?

[yajo]

Sorry, wrong link, I meant traefik/traefik#4863 (comment)

[yelizariev]

I didn't try. Though, it should make configuration cleaner.

[yelizariev]

@yajo I've updated PR with README updates in doodba: Tecnativa/doodba#278

[yajo]

Have you been able to test if this works fine also for traefik v2.1? I mean, if it ignores properly v1.x labels

[yelizariev]

No, I didn't try this config with traefik 2.1. I switched to other tasks for now. Some assistance is needed to finalize this PR

[yajo]

Traefik v2 needs global names per provider (docker server, in our case).

This means a big problem for doodba...

Read traefik/traefik#6290 patiently and you'll see.

I guess we won't be able to merge a patch like this safely until #69 lands... 🤦‍♂️

[yajo]

It seems that for traefik 2.2 traefik/traefik#4863 is fixed, so we'll maybe be able to be less verbose here.