Toon posts:

ENV VARs dynamisch updaten in Docker container

Pagina: 1
Acties:

Vraag


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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.

When you do things right, people won't be sure you've done anything at all.

Alle reacties


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:53
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
  • Registratie: Februari 2001
  • Laatst online: 22:20

CyBeRSPiN

sinds 2001

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
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

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


Wel met iets als supervisord als process manager.
Hier zal ik eens naar kijken.Thanks!

When you do things right, people won't be sure you've done anything at all.


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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:
1
2
3
4
5
6
7
8
9
10
[[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"

When you do things right, people won't be sure you've done anything at all.


  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 21:56
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

PV Output


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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:
1
2
3
4
5
6
7
8
9
10
[[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]

When you do things right, people won't be sure you've done anything at all.


  • cytherea
  • Registratie: Oktober 2003
  • Laatst online: 09-01 12:59
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
  • Registratie: Juni 2004
  • Laatst online: 21:56
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.

PV Output


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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.

When you do things right, people won't be sure you've done anything at all.


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

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

When you do things right, people won't be sure you've done anything at all.


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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?

When you do things right, people won't be sure you've done anything at all.


  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 21:56
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.

PV Output


  • JackBol
  • Registratie: Maart 2000
  • Niet online

JackBol

Security is not an option!

Topicstarter
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

When you do things right, people won't be sure you've done anything at all.

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee