Global template for labels when/if we move to caddy #428

New Issue

2023-02-28T20:35:48Z

codegod100 commented

2023-02-28 20:35:48 +00:00

It's kinda annoying to put the traefik labels in all the recipes e.g.

      labels:
        - "traefik.enable=true"
        - "traefik.http.services.${STACK_NAME}.loadbalancer.server.port=3000"
        - "traefik.http.routers.${STACK_NAME}.rule=Host(`${DOMAIN}`${EXTRA_DOMAINS})"
        - "traefik.http.routers.${STACK_NAME}.entrypoints=web-secure"
        - "traefik.http.routers.${STACK_NAME}.tls.certresolver=${LETS_ENCRYPT_ENV}"
        # Redirect from EXTRA_DOMAINS to DOMAIN
        - "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect"
        - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true"
        - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}"
        - "coop-cloud.${STACK_NAME}.version=0.1.0+2.1.1"

Maybe inherit from a common source when we switch over? Just an idea I'm putting out there.

It's kinda annoying to put the traefik labels in all the recipes e.g. ``` labels: - "traefik.enable=true" - "traefik.http.services.${STACK_NAME}.loadbalancer.server.port=3000" - "traefik.http.routers.${STACK_NAME}.rule=Host(`${DOMAIN}`${EXTRA_DOMAINS})" - "traefik.http.routers.${STACK_NAME}.entrypoints=web-secure" - "traefik.http.routers.${STACK_NAME}.tls.certresolver=${LETS_ENCRYPT_ENV}" # Redirect from EXTRA_DOMAINS to DOMAIN - "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect" - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true" - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}" - "coop-cloud.${STACK_NAME}.version=0.1.0+2.1.1" ``` Maybe inherit from a common source when we switch over? Just an idea I'm putting out there.

👀 2

codegod100 added the enhancement label 2023-02-28 20:35:48 +00:00

decentral1se commented

2023-04-10 21:26:37 +00:00

Yeh would be nice to DRY-ify this labels situation.

These could be programmatically appended into the labels at runtime by abra? It could actually maybe work, I'm not sure. It might create a situation where we need to make an abra release to support some new recipe release? But some of these labels are just pure boilerplate and we could create .env pluggable values to thread in?

Yeh would be nice to DRY-ify this labels situation. These could be programmatically appended into the labels at runtime by `abra`? It could actually maybe work, I'm not sure. It might create a situation where we need to make an `abra` release to support some new recipe release? But some of these labels are just pure boilerplate and we could create `.env` pluggable values to thread in?

3wordchant commented

2023-04-10 21:47:43 +00:00

Thanks for the suggestion @codegod100! 🙏

I agree with not-repeating-ourselves in general.

It does feel like there's a balance in this specific situation between reducing duplication, and preserving the ability for Co-op Cloud recipes to be used without abra – if we remove the reverse proxy labels, then we reduce the number of people who could use recipes without abra from "possibly some" (whoever is using Traefik, and happy to accept our conventions about env variable naming) to "definitely none" (because they'd have to fork the recipe to add labels, every time).

Also, this might be affected by whatever we decide on #388, and whether there would more labels we'd need to add to do so – if it continues to be 3 lines (down from the current 10), it seems a lot more bearable to keep them in the recipes.

- "coop-cloud.${STACK_NAME}.version=0.1.0+2.1.1"

For completeness - this isn't a Traefik label, I'm pretty sure we need to keep it regardless.

Thanks for the suggestion @codegod100! 🙏 I agree with not-repeating-ourselves in general. It does feel like there's a balance in this specific situation between reducing duplication, and preserving the ability for Co-op Cloud recipes to be used without abra – if we remove the reverse proxy labels, then we reduce the number of people who could use recipes without abra from "possibly some" (whoever is using Traefik, and happy to accept our conventions about env variable naming) to "definitely none" (because they'd have to fork the recipe to add labels, every time). Also, this might be affected by whatever we decide on #388, and whether there would more labels we'd need to add to do so – if it continues to be 3 lines (down from the current 10), it seems a lot more bearable to keep them in the recipes. `- "coop-cloud.${STACK_NAME}.version=0.1.0+2.1.1"` For completeness - this isn't a Traefik label, I'm pretty sure we need to keep it regardless.

👍 1

codegod100 commented

2023-04-10 21:51:52 +00:00

"It does feel like there's a balance in this specific situation between reducing duplication, and preserving the ability for Co-op Cloud recipes to be used without abra"

Why would someone use coop cloud and not abra?

"It does feel like there's a balance in this specific situation between reducing duplication, and preserving the ability for Co-op Cloud recipes to be used without abra" Why would someone use coop cloud and not abra?

decentral1se commented

2023-04-10 21:52:05 +00:00

the ability for Co-op Cloud recipes to be used without abra

Oh yeh, how did I forget this... gotta document this recipe Prime Directive 😄

> the ability for Co-op Cloud recipes to be used without abra Oh yeh, how did I forget this... gotta document this recipe Prime Directive 😄

3wordchant commented

2023-04-10 21:53:35 +00:00

Why would someone use coop cloud and not abra?

Here's one set of reasons! https://cgalo.dev/pages/from-coop-cloud-to-plain-docker-swarm/

Personally, it's also a project goal to try and make the constituent pieces of Co-op Cloud useful even if the wheels fall off the project as a whole. (This goal is less of a priority the more time that goes on that we continue existing, but it's still present)

> Why would someone use coop cloud and not abra? Here's one set of reasons! https://cgalo.dev/pages/from-coop-cloud-to-plain-docker-swarm/ Personally, it's also a project goal to try and make the constituent pieces of Co-op Cloud useful even if the wheels fall off the project as a whole. (This goal is less of a priority the more time that goes on that we continue existing, but it's still present)

👍 1

decentral1se commented

2023-04-28 07:47:25 +00:00

Btw the approach in https://docs.coopcloud.tech/operators/handbook/#proxying-apps-outside-of-co-op-cloud-with-traefik shows that we could probably drop all labels from the compose configurations and generate /etc/traefik/file-providers/... configurations instead. I'm not suggesting we do that atm as I haven't really thought through it but it might be something to experiment or try out if you're prototyping over here.

Btw the approach in https://docs.coopcloud.tech/operators/handbook/#proxying-apps-outside-of-co-op-cloud-with-traefik shows that we could probably drop all labels from the compose configurations and generate `/etc/traefik/file-providers/...` configurations instead. I'm not suggesting we do that atm as I haven't really thought through it but it might be something to experiment or try out if you're prototyping over here.

decentral1se commented

2024-03-27 06:44:25 +00:00

Pushed https://docs.coopcloud.tech/abra/design/. I guess we're settling on "appropriate levels of copy/pasta atm". Gonna close off for now, please re-open if you have more for it. Thanks for weighing in.

decentral1se closed this issue

2024-03-27 06:44:25 +00:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#428