data.coop/ansible
8
3
Fork 7
Code Issues 49 Pull requests 9 Projects 1 Releases Wiki Activity

Enable Watchtower for all services #123

Merged
valberg merged 19 commits from watchtower into main 2023-01-21 17:17:56 +00:00
Conversation 16 Commits 19 Files changed 13 +15 -32
samsapti commented 2022-11-18 20:05:21 +00:00
Owner
Copy link

Fixes #119

Fixes #119
samsapti added the
Infrastructure Issue
Security Hardening
 labels 2022-11-18 20:05:21 +00:00
samsapti added 2 commits 2022-11-18 20:05:21 +00:00 
The auth file created by the registry login task doesn't need to be
stored in a non-default path.
samsapti added 1 commit 2022-11-18 20:07:19 +00:00
valberg reviewed 2022-11-19 16:15:10 +00:00
roles/docker/tasks/services/watchtower.yml Outdated
@ -13,2 +11,3 @@
WATCHTOWER_POLL_INTERVAL: "60"
- "/var/run/docker.sock:/var/run/docker.sock"
- "/root/.docker/config.json:/config.json:ro"
valberg commented 2022-11-19 16:15:10 +00:00
Owner
Copy link

This means that docker-registry should be run before watchtower right?

This means that `docker-registry` should be run before `watchtower` right?
samsapti commented 2022-11-19 16:47:12 +00:00
Author
Owner
Copy link

Yes, which is currently also the case.

Yes, which is currently also the case.
👍 1
samsapti marked this conversation as resolved
valberg reviewed 2022-11-19 16:15:53 +00:00
roles/docker/tasks/services/watchtower.yml Outdated
@ -3,3 +3,3 @@
docker_container:
name: watchtower
image: containrrr/watchtower:1.4.0
image: containrrr/watchtower:latest
valberg commented 2022-11-19 16:15:53 +00:00
Owner
Copy link

Let's pin this to a version instead of latest.

Let's pin this to a version instead of latest.
samsapti commented 2022-11-19 16:48:18 +00:00
Author
Owner
Copy link

Why not latest?

Why not latest?
valberg commented 2022-11-19 17:00:02 +00:00
Owner
Copy link

Because I want to avoid confusion due to an unintended upgrade.

Because I want to avoid confusion due to an unintended upgrade.
samsapti commented 2022-11-19 17:05:18 +00:00
Author
Owner
Copy link

I don't fully agree. I think it's better to always use the latest version security-wise, especially when it has access to the Docker socket.

I don't fully agree. I think it's better to always use the latest version security-wise, especially when it has access to the Docker socket.
valberg commented 2022-11-19 17:14:10 +00:00
Owner
Copy link

I agree, and we should strive to upgrade whenever a new version is available. But I don't want stuff to suddenly break behaviour without us knowing why.

I agree, and we should strive to upgrade whenever a new version is available. But I don't want stuff to suddenly break behaviour without us knowing why.
samsapti commented 2022-11-19 17:17:43 +00:00
Author
Owner
Copy link

I'll pin it then. GitHub supports RSS feeds for releases, maybe we could use that to be notified about new releases? We could set up notifications in our Matrix channel somehow.

https://github.com/containrrr/watchtower/releases.atom

I'll pin it then. GitHub supports RSS feeds for releases, maybe we could use that to be notified about new releases? We could set up notifications in our Matrix channel somehow. https://github.com/containrrr/watchtower/releases.atom
👍 1
valberg commented 2022-11-19 17:19:28 +00:00
Owner
Copy link

Sounds like a great idea!

Sounds like a great idea!
👍 1
samsapti marked this conversation as resolved
samsapti added 2 commits 2022-11-19 17:20:17 +00:00
reynir commented 2022-11-21 08:58:49 +00:00
Owner
Copy link

Jeg kunne godt tænke mig at der blev lavet review af alle vores containere om de kan tåle at blive opgraderet automatisk. Specifikt er jeg skeptisk at containere der bruger databaser kan opgraderes automatisk. Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk?

Jeg har ikke lyst til at vores services helt automatisk går i stykker af sig selv.

Jeg kunne godt tænke mig at der blev lavet review af alle vores containere om de kan tåle at blive opgraderet automatisk. Specifikt er jeg skeptisk at containere der bruger databaser kan opgraderes automatisk. Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk? Jeg har ikke lyst til at vores services helt automatisk går i stykker af sig selv.
samsapti commented 2022-11-21 15:40:30 +00:00
Author
Owner
Copy link

Jeg kunne godt tænke mig at der blev lavet review af alle vores containere om de kan tåle at blive opgraderet automatisk. Specifikt er jeg skeptisk at containere der bruger databaser kan opgraderes automatisk. Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk?

Jeg har ikke lyst til at vores services helt automatisk går i stykker af sig selv.

Enig, men så synes jeg at vi skal kontrollere det ved at pinne versioner via image tags, fremfor at slå Watchtower helt fra. F.eks. så er Nextcloud pinnet til nextcloud:22-apache, så Watchtower vil altid holde den på major version 22.x.x, men minor og patch versioner vil få opdateringer.

(Fra eget setup kan jeg hilse og sige, at Nextcloud kræver database-migrering ved upgrade til version 25, men det beder den selv om første gang en admin-bruger logger på web UI'et og klares vha. et enkelt klik, og så et par shell commands).

> Jeg kunne godt tænke mig at der blev lavet review af alle vores containere om de kan tåle at blive opgraderet automatisk. Specifikt er jeg skeptisk at containere der bruger databaser kan opgraderes automatisk. Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk? > > Jeg har ikke lyst til at vores services helt automatisk går i stykker af sig selv. Enig, men så synes jeg at vi skal kontrollere det ved at pinne versioner via image tags, fremfor at slå Watchtower helt fra. F.eks. så er Nextcloud pinnet til `nextcloud:22-apache`, så Watchtower vil altid holde den på major version `22.x.x`, men minor og patch versioner vil få opdateringer. (Fra eget setup kan jeg hilse og sige, at Nextcloud kræver database-migrering ved upgrade til version 25, men det beder den selv om første gang en admin-bruger logger på web UI'et og klares vha. et enkelt klik, og så et par shell commands).
samsapti commented 2022-11-21 18:08:17 +00:00
Author
Owner
Copy link

Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk?

Jeg ved at Rallly's entrypoint.sh kører migration hver gang containeren starter. Har ikke tjekket med de andre.

> Er vi garanteret at containeren kommer med migration scripts som bliver kørt automatisk? Jeg ved at Rallly's `entrypoint.sh` kører migration hver gang containeren starter. Har ikke tjekket med de andre.
valberg commented 2022-11-21 19:16:16 +00:00
Owner
Copy link

Jeg synes det lyder fint med at indføre den regel at hvis man har sat et image til at være "latest" så bliver det opdateret. Alle services bør som regel være pinned så vi kan styre opgraderingerne - men der er tilfælde, som vores hjemmeside og medlemssystem, hvor det bare skal opgraderes så snart der bliver skubbet et nyt image op til docker repoet.

Hvad angår migreringer så er det lidt blandet - gitea, passit, rallly, vores medlemssystem, gør det alle automatisk - mastodon skal man køre ting selv.

Jeg synes det lyder fint med at indføre den regel at hvis man har sat et image til at være "latest" så bliver det opdateret. Alle services bør som regel være pinned så vi kan styre opgraderingerne - men der er tilfælde, som vores hjemmeside og medlemssystem, hvor det bare skal opgraderes så snart der bliver skubbet et nyt image op til docker repoet. Hvad angår migreringer så er det lidt blandet - gitea, passit, rallly, vores medlemssystem, gør det alle automatisk - mastodon skal man køre ting selv.
👍 2
samsapti commented 2022-11-22 17:47:02 +00:00
Author
Owner
Copy link

Foreløbigt review

Efter forespørgsel fra @reynir ;)

Services der allerede bruger latest

  • PrivateBin
    • PrivateBin har ingen database, så den kan formentligt godt tåle automatisk opgradering
  • Rallly
    • Rallly håndterer selv database-migreringer, så den kan også tåle automatisk opgradering
  • Netdata
    • Bruges allerede implicit, da intet tag er specificeret
  • Restic Backup
    • Samme som ovenfor
  • Passit
    • Ikke latest, men den har et stable som vi bruger
  • Membersystem
    • Jf. @valberg 's kommentar kan den godt tåle automatisk opgradering
  • ulovliglogning.dk
    • Se ovenfor
  • new-new.data.coop
    • Se ovenfor

Services der formentligt godt kan tåle latest

  • Docker Registry
  • Drone CI
  • Gitea
  • Matrix (synapse), latest bruges i den officielle README.md
  • Postfix
  • Watchtower (men det synes @valberg ikke)
## Foreløbigt review Efter forespørgsel fra @reynir ;) ### Services der allerede bruger `latest` - PrivateBin - PrivateBin har ingen database, så den kan formentligt godt tåle automatisk opgradering - Rallly - Rallly håndterer selv database-migreringer, så den kan også tåle automatisk opgradering - Netdata - Bruges allerede implicit, da intet tag er specificeret - Restic Backup - Samme som ovenfor - Passit - Ikke `latest`, men den har et `stable` som vi bruger - Membersystem - Jf. @valberg 's kommentar kan den godt tåle automatisk opgradering - ulovliglogning.dk - Se ovenfor - new-new.data.coop - Se ovenfor ### Services der formentligt godt kan tåle `latest` - Docker Registry - Drone CI - Gitea - Matrix (synapse), `latest` bruges i den officielle `README.md` - Postfix - Watchtower (men det synes @valberg ikke)
valberg commented 2022-11-22 19:47:00 +00:00
Owner
Copy link

Selvom at services godt kan tåle at opgradere uden at vi skal ind og gøre noget vil jeg stadig gerne være meget påpasselig med at lade dem opgradere automatisk.

Der kan ske alt muligt som kan ende i at vi mister eller korrumperer data, og selvom at vi har backup kan der gå lang tid med at finde ud af hvornår var det nu egentlig at data forsvandt etc.

Jeg ser hellere at vi opgraderer services når vi ved at de er sikre at opgradere.

Services som ikke har den store omgang brugerdata, eller som vi styrer selv (som medlemsystemet) kan vi sagtens sætte på latest.

Her er min liste af services jeg har det fint med at have på latest👍

  • alle statiske websites
  • membersystem
  • netdata
  • portainer

Jeg ved det ikke er mange, men jeg tror på at det vil skabe mindre bøvl for os, også selvom at det betyder at vi skal manuelt ind og opgradere.

Selvom at services godt kan tåle at opgradere uden at vi skal ind og gøre noget vil jeg stadig gerne være meget påpasselig med at lade dem opgradere automatisk. Der kan ske alt muligt som kan ende i at vi mister eller korrumperer data, og selvom at vi har backup kan der gå lang tid med at finde ud af hvornår var det nu egentlig at data forsvandt etc. Jeg ser hellere at vi opgraderer services når vi ved at de er sikre at opgradere. Services som ikke har den store omgang brugerdata, eller som vi styrer selv (som medlemsystemet) kan vi sagtens sætte på latest. Her er min liste af services jeg har det fint med at have på latest👍 - alle statiske websites - membersystem - netdata - portainer Jeg ved det ikke er mange, men jeg tror på at det vil skabe mindre bøvl for os, også selvom at det betyder at vi skal manuelt ind og opgradere.
👍 1
samsapti commented 2022-11-22 20:04:03 +00:00
Author
Owner
Copy link

Well, jeg kan godt se din pointe. For mit vedkommende, vil jeg gerne tilføje følgende til den liste:

  • Rallly
  • Alle dem der i forvejen bruger latest eller tilsvarende (måske med undtagelse af Restic og Passit)
Well, jeg kan godt se din pointe. For mit vedkommende, vil jeg gerne tilføje følgende til den liste: - Rallly - Alle dem der i forvejen bruger `latest` eller tilsvarende (måske med undtagelse af Restic og Passit)
valberg commented 2022-11-22 20:09:11 +00:00
Owner
Copy link

Problemet med at inkludere Rallly er at vi pludselig kan ende i en situation hvor at der er forsvundet "events" eller "tilmeldinger til events" fordi et eller andet går galt.

Når et docker image er released er det kun blevet testet af dem der har produceret imaget, for det meste. Så det bliver først rigtig tryktestet når det har været ude og folk har opgraderet. Her vil jeg helst ikke have at vi er en af dem der tester ;)

Ja helst sikkert at restic og passit skal pinnes.

Problemet med at inkludere Rallly er at vi pludselig kan ende i en situation hvor at der er forsvundet "events" eller "tilmeldinger til events" fordi et eller andet går galt. Når et docker image er released er det kun blevet testet af dem der har produceret imaget, for det meste. Så det bliver først rigtig tryktestet når det har været ude og folk har opgraderet. Her vil jeg helst ikke have at vi er en af dem der tester ;) Ja helst sikkert at restic og passit skal pinnes.
samsapti commented 2022-11-22 20:28:54 +00:00
Author
Owner
Copy link

Det kan jeg godt følge dig i. Problemet er bare, at Rallly ikke har noget versionssystem som sådan, så et image kan enten tagges latest eller med et commit-hash.

Det kan jeg godt følge dig i. Problemet er bare, at Rallly ikke har noget versionssystem som sådan, så et image kan enten tagges `latest` eller med et commit-hash.
valberg commented 2022-11-22 21:44:39 +00:00
Owner
Copy link

Det er vel også en form for versionering (tongue-in-cheek :P). Men ja, så synes jeg at vi skal pinne til en specifik SHA værdi.

Jeg har lige opgraderet keycloak fra 15 til 20 - og det var ikke trivielt da indstillinger ændrer sig osv. Så hvis det var sket automatisk med en service hvilket ville betyde at denne går ned, så ville vi skulle håndtere det ekstraordinært, fremfor på et tidspunkt hvor det er os der styrer hvad der skal opgraderes og har forberedt os ved at læse opgraderings guides etc.

Det er vel også en form for versionering (tongue-in-cheek :P). Men ja, så synes jeg at vi skal pinne til en specifik SHA værdi. Jeg har lige opgraderet keycloak fra 15 til 20 - og det var ikke trivielt da indstillinger ændrer sig osv. Så hvis det var sket automatisk med en service hvilket ville betyde at denne går ned, så ville vi skulle håndtere det ekstraordinært, fremfor på et tidspunkt hvor det er os der styrer hvad der skal opgraderes og har forberedt os ved at læse opgraderings guides etc.
👀 1
decibyte commented 2022-11-23 07:53:45 +00:00
Owner
Copy link

Jeg synes det lyder som en god ide at være varsom med sætte ting på auto. Hvis det er manuelle opdateringer kan I også annoncere det på forhånd, så folk har en chance for at vide at det dels er "meningen" hvis der er bump på vejen og dels at I nok allerede er på sagen.

Jeg synes det lyder som en god ide at være varsom med sætte ting på auto. Hvis det er manuelle opdateringer kan I også annoncere det på forhånd, så folk har en chance for at vide at det dels er "meningen" hvis der er bump på vejen og dels at I nok allerede er på sagen.
👍 2
benjaoming commented 2022-11-23 14:54:29 +00:00
Owner
Copy link

Jeg synes det lyder som en god ide at være varsom med sætte ting på auto. Hvis det er manuelle opdateringer kan I også annoncere det på forhånd, så folk har en chance for at vide at det dels er "meningen" hvis der er bump på vejen og dels at I nok allerede er på sagen.

Hvis der opstår variationer, så kan vi måske indføre et badge eller en ny definition til "stabilitet". Jeg tænker at "ustabil" både kan dække over "overlagt bleeding edge" eller "vi har ikke testet det her setup".

> Jeg synes det lyder som en god ide at være varsom med sætte ting på auto. Hvis det er manuelle opdateringer kan I også annoncere det på forhånd, så folk har en chance for at vide at det dels er "meningen" hvis der er bump på vejen og dels at I nok allerede er på sagen. Hvis der opstår variationer, så kan vi måske indføre et badge eller en ny definition til "stabilitet". Jeg tænker at "ustabil" både kan dække over "overlagt bleeding edge" eller "vi har ikke testet det her setup".
👍 1
samsapti commented 2022-11-23 17:24:46 +00:00
Author
Owner
Copy link

Jeg synes jeg er blevet overtalt om at latest nok ikke er hensigtsmæssigt. Hvad med evt. kun at pinne til major versioner på det meste, som vi allerede gør med nextcloud:25-apache, sådan at tjenester stadig automatisk får minor- og patch-opdateringer (såfremt den bestemte tjeneste bruger semantisk versionering eller lignende). Om ikke andet, så er min holdning at som minimum bør patch-versioner opdateres automatisk, da det som regel er bugfixes og ikke-breaking ændringer.

Med tjenester der ikke bruger SemVer eller andet lignende versioneringssystem, eller er meget kritiske mht. brugerdata eller infrastruktur (Mailu, Keycloak, nginx-proxy, etc.), kan vi gøre en undtagelse.

Og ja, vi skal helt sikkert annoncere hvis vi laver større opgraderinger på nogle af vores tjenester.

Jeg synes jeg er blevet overtalt om at `latest` nok ikke er hensigtsmæssigt. Hvad med evt. kun at pinne til major versioner på det meste, som vi allerede gør med `nextcloud:25-apache`, sådan at tjenester stadig automatisk får minor- og patch-opdateringer (såfremt den bestemte tjeneste bruger [semantisk versionering](https://semver.org) eller lignende). Om ikke andet, så er min holdning at som minimum bør patch-versioner opdateres automatisk, da det som regel er bugfixes og ikke-breaking ændringer. Med tjenester der ikke bruger SemVer eller andet lignende versioneringssystem, eller er meget kritiske mht. brugerdata eller infrastruktur (Mailu, Keycloak, nginx-proxy, etc.), kan vi gøre en undtagelse. Og ja, vi skal helt sikkert annoncere hvis vi laver større opgraderinger på nogle af vores tjenester.
👍 1
valberg commented 2022-11-23 18:30:24 +00:00
Owner
Copy link

Jeg synes jeg er blevet overtalt om at latest nok ikke er hensigtsmæssigt. Hvad med evt. kun at pinne til major versioner på det meste, som vi allerede gør med nextcloud:25-apache, sådan at tjenester stadig automatisk får minor- og patch-opdateringer (såfremt den bestemte tjeneste bruger semantisk versionering eller lignende). Om ikke andet, så er min holdning at som minimum bør patch-versioner opdateres automatisk, da det som regel er bugfixes og ikke-breaking ændringer.

Ja! Det synes jeg lyder meget fornuftigt!

> Jeg synes jeg er blevet overtalt om at `latest` nok ikke er hensigtsmæssigt. Hvad med evt. kun at pinne til major versioner på det meste, som vi allerede gør med `nextcloud:25-apache`, sådan at tjenester stadig automatisk får minor- og patch-opdateringer (såfremt den bestemte tjeneste bruger [semantisk versionering](https://semver.org) eller lignende). Om ikke andet, så er min holdning at som minimum bør patch-versioner opdateres automatisk, da det som regel er bugfixes og ikke-breaking ændringer. Ja! Det synes jeg lyder meget fornuftigt!
👍 1
samsapti commented 2022-11-23 18:47:06 +00:00
Author
Owner
Copy link

Cool. Jeg tror lige jeg merger main ind i denne branch, og så kigger jeg på pinning.

Cool. Jeg tror lige jeg merger main ind i denne branch, og så kigger jeg på pinning.
samsapti added 1 commit 2022-11-23 18:52:11 +00:00
samsapti added 4 commits 2022-11-23 20:00:54 +00:00 
Gitea's "minor" version change seems to be the one that occasionally
introduces breaking changes, so let's not update that automatically.
Only keep the patch-releases automatically updated.
From https://docs.hedgedoc.org/setup/getting-started/#upgrading-hedgedoc

> HedgeDoc follows [Semantic Versioning](https://semver.org/).
> This means that minor and patch releases should not introduce
> user-facing backwards-incompatible changes.
samsapti added 1 commit 2022-11-23 20:05:08 +00:00
samsapti added 1 commit 2022-11-23 20:09:15 +00:00
samsapti added 1 commit 2022-11-25 21:12:56 +00:00
samsapti added 1 commit 2022-11-26 15:50:04 +00:00
samsapti added 1 commit 2022-12-06 17:05:52 +00:00
samsapti added 1 commit 2022-12-06 17:06:37 +00:00
samsapti added 1 commit 2022-12-27 18:49:16 +00:00
samsapti commented 2022-12-27 18:55:03 +00:00
Author
Owner
Copy link

I think this is ready to be merged. What do you guys think?

CC: @data.coop/Owners

I think this is ready to be merged. What do you guys think? CC: @data.coop/Owners
samsapti added 1 commit 2023-01-06 13:54:09 +00:00
valberg requested changes 2023-01-21 12:14:39 +00:00
valberg left a comment
Owner
Copy link

Lige et par ting :)

Lige et par ting :)
roles/docker/defaults/main.yml Outdated
@ -115,3 +115,3 @@
domain: "pad.{{ base_domain }}"
volume_folder: "{{ volume_root_folder }}/hedgedoc"
version: 1.9.6
version: 1
valberg commented 2023-01-21 12:12:55 +00:00
Owner
Copy link

Hvorfor ikke 1.9?

Hvorfor ikke 1.9?
samsapti commented 2023-01-21 16:31:03 +00:00
Author
Owner
Copy link

Fordi den kører SemVer, så minor opgraderinger har ikke breaking changes.

Fordi den kører SemVer, så minor opgraderinger har ikke breaking changes.
samsapti marked this conversation as resolved
roles/docker/tasks/services/membersystem.yml Outdated
@ -34,4 +34,2 @@
DJANGO_ADMINS: "{{ services.membersystem.django_admins }}"
DEFAULT_FROM_EMAIL: "noreply@{{ services.membersystem.domain }}"
labels:
com.centurylinklabs.watchtower.enable: "true"
valberg commented 2023-01-21 12:12:44 +00:00
Owner
Copy link

Den her skal blive - deploy af membersystem afhænger af watchtower :)

Den her skal blive - deploy af membersystem afhænger af watchtower :)
samsapti marked this conversation as resolved
roles/docker/tasks/services/watchtower.yml Outdated
@ -11,4 +10,1 @@
- /var/run/docker.sock:/var/run/docker.sock
- "{{ services.docker_registry.volume_folder }}/auth/config.json:/config.json"
env:
WATCHTOWER_LABEL_ENABLE: "true"
valberg commented 2023-01-21 12:14:29 +00:00
Owner
Copy link

Hvordan er det nu at services der skal opdateres bliver fundet hvis det ikke er via label?

Hvordan er det nu at services der skal opdateres bliver fundet hvis det ikke er via label?
samsapti marked this conversation as resolved
samsapti added 1 commit 2023-01-21 16:33:54 +00:00
valberg approved these changes 2023-01-21 17:17:45 +00:00
valberg merged commit b445d7db17 into main 2023-01-21 17:17:56 +00:00
samsapti deleted branch watchtower 2023-01-21 17:20:13 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
valberg
Labels
Clear labels   
Blocked

Something is blocking progress

  
Existing Service

Issues/improvements regarding existing services

  
Infrastructure Issue

Infrastructure issue that needs investigation or time to fix

  
Refactor

Refactoring of files / file structure or other improvements

  
Security Hardening

Non-verified / non-critical security improvements

  
Security Issue

Urgent security issue that needs to be fixed ASAP

  
Service Idea

Ideas for new services

  
Service Removal

Removal of services for one reason or another

  
Upgrade service
No labels
Blocked
Existing Service
Infrastructure Issue
Refactor
Security Hardening
Security Issue
Service Idea
Service Removal
Upgrade service
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 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: data.coop/ansible#123
No description provided.
Delete branch "watchtower"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?