ENV VARs dynamisch updaten in Docker container

[JackBol]

Mijn vraag

Ik heb een telegraf container op docker draaien die elke minuut een curl doet van een externe pagina die met OAUTH 2.0 autoriseert (op google.com). Als ik zelf handmatig een Authorisation Token en Bearer Token aanvraag bij de token server en deze als ENV VAR opsla in de docker container, kan ik die Bearer Token in de http header gebruiken om de curl te laten werken en de data op te halen en te parsen.

Probleem is dat de lifetime van die Bearer Token 3600 seconde is en dus ik moet minimaal eens per uur een nieuwe Bearer Token moet aanvragen bij de Token server. Ik kan dit met de hand prima doen met mijn refresh token, en vervolgens handmatig de variabele in de docker container updaten (inloggen in de container en een nieuwe "export TOKEN=<token>") doen.


Relevante software en hardware die ik gebruik

- Synology NAS 920
- Docker 20.10.3
- container met Telegraf 1.21.1
- Externe Site: https://developers.google.com/nest/device-access
- Token Server: https://www.googleapis.com/oauth2/v4/token
- API Endpoint: https://smartdevicemanagement.googleapis.com/v1/


Wat ik al gevonden of geprobeerd heb
Wat niet werkt:
- In de container crond draaien en een cronjob maken die elke 50 min de bearer token opnieuw aanvraagt. ---> Aangezien je niet twee processen gelijktijdig in een container kan laten kopen
- met "docker exec -it <containerid> /bin/bash -c "export TOKEN=<token>" ---> deze var wordt niet in de container toegevoegd (doe ik het verkeerd?)


De vraag is, hier MOET een bestaande oplossing voor dit probleem zijn. Ik ben niet de eerste in de wereld die vanuit een container een OAUTH wil doen. Maar na uren gegoogle ben ik er nog altijd niet uit hoe ik het moet doen.

[Thralas]

JackBol schreef op dinsdag 28 december 2021 @ 23:17:
Wat niet werkt:
- In de container crond draaien en een cronjob maken die elke 50 min de bearer token opnieuw aanvraagt. ---> Aangezien je niet twee processen gelijktijdig in een container kan laten kopen

Wel met iets als supervisord als process manager.

Niet heel mooi. Kun je beter gewoon in je container de token refreshen vóórdat je curl aanroept, toch?

- met "docker exec -it <containerid> /bin/bash -c "export TOKEN=<token>" ---> deze var wordt niet in de container toegevoegd (doe ik het verkeerd?)

Nee, dat werkt inderdaad zo niet (export exporteert de variabele binnen je huidige shell, dwz. degene die je een split second draait onder docker exec) en de environment variables van een ander proces updaten kan niet.

[CyBeRSPiN]

Je moet je curl script in je container aanpassen:
1. Is je token niet meer geldig? Haal nieuwe op en sla op in TOKEN
2. Doe de curl met $TOKEN
3. Sleep 60
4. Go to 1

[JackBol]

Thralas schreef op woensdag 29 december 2021 @ 00:37:
[...]


Wel met iets als supervisord als process manager.

Hier zal ik eens naar kijken.Thanks!

[JackBol]

CyBeRSPiN schreef op woensdag 29 december 2021 @ 00:45:
Je moet je curl script in je container aanpassen:
1. Is je token niet meer geldig? Haal nieuwe op en sla op in TOKEN
2. Doe de curl met $TOKEN
3. Sleep 60
4. Go to 1

In de container draait geen curl maar Telegraf met een HTTP input plugin. Ik heb het werkend met deze config, maar die ${ACCESSTOKEN} moet ik dus elk uur verversen in de container, daar ben ik een oplossing voor aan het zoeken.

code:

[[inputs.http]]
  # Read from Google Smart Devicess
  urls = [ "https://smartdevicemanagement.googleapis.com/v1/blablabla" ]
  method = "GET"
  data_format = "json"
  headers = {"Accept" = "text/event-stream"}
  headers = {"Authorization" = "Bearer ${ACCESSTOKEN}"}
  [inputs.http.tags]
    influxdb_bucket = "abc"
    source = "def"

[Kalentum]

Voor taken die periodiek moeten runnen gebruik ik cron . Kun je gewoon in je container runnen. Ik weet niet waarom je denkt dat je geen twee processen in 1 container kan hebben.

En verder eens met @CyBeRSPiN . Laat je script automatisch een nieuw token vragen als de geldigheid verstreken is

[JackBol]

Kalentum schreef op woensdag 29 december 2021 @ 06:53:
Voor taken die periodiek moeten runnen gebruik ik cron . Kun je gewoon in je container runnen. Ik weet niet waarom je denkt dat je geen twee processen in 1 container kan hebben.

Omdat dat in mijn ogen een beetje het idee van '1 container - 1 taak' breekt.

En verder eens met @CyBeRSPiN . Laat je script automatisch een nieuw token vragen als de geldigheid verstreken is

Zoals hierboven al aangegeven doe ik de GET niet vanuit een script maar vanuit een Telegraf http plugin.
In heb ondertussen in de documentatie van de HTTP plugin gevonden dat deze en aparte variabele heeft om naar een file met een bearer-token te laten wijzen.

code:

[[inputs.http]]
  # Read from Google Smart Devicess
  urls = [ "https://smartdevicemanagement.googleapis.com/v1/blablabla" ]
  method = "GET"
  data_format = "json"
  headers = {"Accept" = "text/event-stream"}
  bearer_token = "/etc/telegraf/telegraf.d/BearerToken"
  [inputs.http.tags]
    influxdb_bucket = "abc"
    source = "def"

Ik heb nu een tweede container draaien met daarin een python scriptje dat ieder uur (met sleep 3600) een nieuwe token opvraagt en in de token file opslaat.

Alles draait nu, dus even kijken of het automatisch rotate over een uurtje
Als het werkt ga ik denk ik een dedicated container voor cron draaien om het een beetje gestructureerd te houden.

[Voor 4% gewijzigd door JackBol op 29-12-2021 07:49]

[cytherea]

Zelf vind ik het ook handiger om meerdere containers hiervoor te gebruiken, supervisor in een container draaien breekt het idee een beetje. Daarnaast ben je de stdout output kwijt die je normaal van het proces zou hebben. Niet handig als je logging wil verzamelen in een kubernetes setup.

Zelf heb ik wel eens een externe cron `docker exec` laten uitvoeren, beetje een poor mans oplossing maar werkt op zich wel. Als je meerdere containers naar dezelfde mount laat verwijzen heb je dat misschien niet perse nodig.

[Kalentum]

Ik heb voor een vergelijkbare use case ook wel zitten denken over hoe dit aan te pakken en ben vooralsnog op een container die cron draait uit gekomen.

Het principe '1 container 1 taak' snap ik wel maar het hangt natuurlijk van je taakdefinitie af. Persoonlijk vind ik het niet zo erg om een cron process toe te voegen aan een container als de taak 'Ophalen data van een API' is, en die API ieder uur een token nodig heeft.

Mijn use case zijn 4 jobs die op verschillende intervallen moeten draaien. Ze horen bij 1 applicatie en lezen verschillende API's uit.

Eerste ingeving was docker run met --rm, dus een kort levende container, vanuit crontab van de host. Maar vanuit oogpunt van isolatie niet zo goed, want dan moet de host de crontabs bevatten. En dat is eigenlijk applicatieconfiguratie

Ook nog even gespeeld met supervisord maar ja toen realiseerde ik mij dat ik dan net zo goed ipv supervisord een crond kon gebruiken. Supervisord is bedoeld voor lang lopende processen en mijn scriptjes hoeven maar 1x per 5 of 15 minuten iets te doen. En met langlopende processen heb je ook nog eens kans op memory leaks enzo, ik vermijd het liever.

Voor TS use case (plugin voor Telegram) zou ik in de eerste plaats afstappen van die http plugin en een eigen plugin maken, die de Google API beter ondersteund, liefst gebruik makend van de clients die Google zelf beschikbaar heeft. Dikke kans dat dat bearer probleem dan al is opgelost.

Als dat niet kan, een crond deamon aan de container toevoegen die 1x per uur (50 minuten) de token ophaalt.

Als dat ongewenst is ivm 1 process per container, dan moet je toch op zoek naar een manier om de door container X opgehaalde token op container Y te laten terecht komen. Gedeelde mount op de host, kan, is potentieel onveilig (maar voor thuis gebruik valt het wel mee) en breekt het principe van isolatie van de container.

Dan komt ik uit op dingen als Redis of een andere manier om data te delen tussen containers, via het interne netwerkje van je containers. Maar dan ga je wel erg overengineeren voor deze use case.

[JackBol]

Het concept werkt, waarbij dat python containertje elke 55 minuten de token ververst.
Dus ik ga nu een dedicated crond container spinnen die dit gestructureerd doet.

Qua communicatie tbv de token tussen de python container en de telegraf container gebruik ik gewoon een shared mount op externe storage.


Verder wil ik zoveel mogelijk containers uit de repo's gebruiken. Dus zelf een container maken met telegraf en cron vindt ik niet sustainable naar de toekomst toe. Ik heb nu een vanilla telegraf:latest welke ik gewoon regelmatig opnieuw can pullen om bij te blijven.

[JackBol]

Thanks voor alle tips hier, heeft me zeker wat beter inzicht gegeven in wat de 'juiste' manier is om iets te doen.

[JackBol]

Kalentum schreef op woensdag 29 december 2021 @ 09:24:
Gedeelde mount op de host, kan, is potentieel onveilig (maar voor thuis gebruik valt het wel mee) en breekt het principe van isolatie van de container.

Ik heb in deze stack nu een losse 'concierge' container draaien met crond die voor de hele stack kleine taakjes gaat verrichten. Het eerste taakje is dus de BearerToken uptodate houden.

Op welke manier bedoel je dat het de isolatie van de container breekt?
Ik kan de telegraf container toch gewoon een dependency op de concierge container geven?

Of bedoel je het op een andere manier?

[Kalentum]

JackBol schreef op woensdag 29 december 2021 @ 11:59:
[...]


Ik heb in deze stack nu een losse 'concierge' container draaien met crond die voor de hele stack kleine taakjes gaat verrichten. Het eerste taakje is dus de BearerToken uptodate houden.

Op welke manier bedoel je dat het de isolatie van de container breekt?
Ik kan de telegraf container toch gewoon een dependency op de concierge container geven?

Of bedoel je het op een andere manier?

Ik neem aan dat je op je Synology een directory hebt waar je je token neer zet? Dus een directory op de host die gemount is in je 'cron' container en in je telegram container?

Als mijn aanname klopt... Dan kan je je container niet zomaar draaien op een ander systeem, want je bent nu afhankelijk van een externe directory.

Dat hoeft natuurlijk niet slecht te zijn, het is meer iets ik persoonlijk zou willen vermijden, tenzij het echt niet anders kan (bv als je Docker container data bevat die het verwijderen van een container moet kunnen overleven)

Misschien is isolatie niet helemaal een juist woord en bedoelde ik 'onafhankelijk' . Je Docker container heeft nu een extra afhankelijkheid.

[JackBol]

Kalentum schreef op woensdag 29 december 2021 @ 12:24:
[...]


Ik neem aan dat je op je Synology een directory hebt waar je je token neer zet? Dus een directory op de host die gemount is in je 'cron' container en in je telegram container?

100% correct

Als mijn aanname klopt... Dan kan je je container niet zomaar draaien op een ander systeem, want je bent nu afhankelijk van een externe directory.

Ah nee, dat klopt. Maar aangezien ik maar 1 NAS heb, gaat dit voor mij geen probleem zijn totdat ik ooit besluit docker clusters te gaan bouwen. Tegen die tijd kan ik altijd nog redis gaan draaien