Separate traefik config on CI system and this traefik config #6

Open
opened 2020-10-15 14:29:34 +00:00 by decentral1se · 6 comments
Owner

Since we need traefik to see apps on the CI box, our CI here can have errors and breakages when we change configs and don't bump the versions because the app never gets destroyed on the CI box. I think we said we'd figure this out later but didn't see a ticket for it. Maybe we need a separate traefik for the CI box to stand on its own and then to make this CI separate and more repeatable.

Since we need traefik to see apps on the CI box, our CI here can have errors and breakages when we change configs and don't bump the versions because the app never gets destroyed on the CI box. I think we said we'd figure this out later but didn't see a ticket for it. Maybe we need a separate traefik for the CI box to stand on its own and then to make this CI separate and more repeatable.
Owner

I think we said we’d figure this out later but didn’t see a ticket for it.

Indeed, thanks for opening this!

Any thoughts on where we run the Traefik CI that's not the testing box? Do we just need another one?

> I think we said we’d figure this out later but didn’t see a ticket for it. Indeed, thanks for opening this! Any thoughts on where we run the Traefik CI that's not the testing box? Do we just need another one?
Owner

Question: what was your thought on auto-versioning secrets, and did it extend to configs? Seems the main issue we run into with CI is incrementing TRAEFIK_YML_VERSION which seems generally like a pointless step we might want to remove.

Question: what was your thought on auto-versioning secrets, and did it extend to configs? Seems the main issue we run into with CI is incrementing `TRAEFIK_YML_VERSION` which seems generally like a pointless step we might want to remove.
Author
Owner

Hey, good question. A lot of what I know about the name/secret versions comes from this post which also suggests the auto-versioning. You don't need to read all of it but they are basically suggesting something like this.

For secrets:

$ MY_SECRET_VERSION=$(print mysecretvalue | md5sum --text | cut -d " " -f1)
$ print $MY_SECRET_VERSION
8e871f330b7d64c16f3c62c61d603db9

For configs:

$ MY_CONFIG_VERSION=$(md5sum my_config.txt | cut -d " " -f1)
$ print $MY_CONFIG_VERSION
d3b07384d113edec49eaa6238ad5ff00

Where the version is generated from the content which means that it will most likely also be unique. Not sure about reliability of md5sum here but it generates something small which is good because docker secret/config have limits on the character length of the name.

Hey, good question. A lot of what I know about the name/secret versions comes from [this post](https://blog.viktoradam.net/2018/02/28/swarm-secrets-made-easy/) which also suggests the auto-versioning. You don't need to read all of it but they are basically suggesting something like this. For secrets: ```bash $ MY_SECRET_VERSION=$(print mysecretvalue | md5sum --text | cut -d " " -f1) $ print $MY_SECRET_VERSION 8e871f330b7d64c16f3c62c61d603db9 ``` For configs: ```bash $ MY_CONFIG_VERSION=$(md5sum my_config.txt | cut -d " " -f1) $ print $MY_CONFIG_VERSION d3b07384d113edec49eaa6238ad5ff00 ``` Where the version is generated from the content which means that it will most likely also be unique. Not sure about reliability of `md5sum` here but it generates something small which is good because docker secret/config have limits on the character length of the name.
Owner

Read the post, is amazing (the author's other stuff is cool too – interesting Python-based system for deploying app updates after image updates)

md5sum looks cool and easy for configs -- wondering about secrets; would it mean abra needs access to the plaintext to md5sum it during each run?

Read the post, is amazing (the author's other stuff is cool too – interesting [Python-based system](https://github.com/rycus86/webhook-proxy) for deploying app updates after image updates) `md5sum` looks cool and easy for configs -- wondering about secrets; would it mean `abra` needs access to the plaintext to `md5sum` it during each run?
Author
Owner

wondering about secrets; would it mean abra needs access to the plaintext to md5sum it during each run?

Good point. I guess we can't store plaintext because that would be $bad. Maybe we just ask for the passwords on deploy input flow and then sum them and save them into the swarm. Leaving the user to take care of managing their passwords? Not sure.

> wondering about secrets; would it mean abra needs access to the plaintext to md5sum it during each run? Good point. I guess we can't store plaintext because that would be $bad. Maybe we just ask for the passwords on deploy input flow and then sum them and save them into the swarm. Leaving the user to take care of managing their passwords? Not sure.
Owner

Good point. I guess we can’t store plaintext because that would be $bad

If people are using pass then it's feasible to md5sum secrets too. Maybe we offer a fully-automatic mode like that for pass-wielders like ourselves, and a manual way as you suggest for the others?

> Good point. I guess we can’t store plaintext because that would be $bad If people are using `pass` then it's feasible to md5sum secrets too. Maybe we offer a fully-automatic mode like that for `pass`-wielders like ourselves, and a manual way as you suggest for the others?
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/traefik#6
No description provided.