Toon posts:

.env vs config files vs hardcoded best practices

Pagina: 1
Acties:

  • DHH
  • Registratie: Augustus 2014
  • Laatst online: 23-03 21:55
Goedemorgen,

Ik ben bezig met een (Python) projectje waarbij ik data ophaal uit meerdere APIs en de data samenvoeg in een Azure SQL Server. Ik wil e.e.a. uiteindelijk via github publiceren, dus het is wel handig om de database credentials en API keys e.d. af te zonderen. M'n server, database, username en password komen daarmee in .env.

Voor het bouwen van een connectionstring maak ik gebruik van {ODBC Driver 17 for SQL Server}, maar als een toekomstige gebruiker ooit Driver 18 geïnstalleerd heeft, zal dat misschien ook wel gaan werken. De driver lijkt me daarom meer iets voor een config file i.p.v. een environment variable.

Het resultaat is dat je de connection string dan opbouwt uit een combinatie van config en .env, wat er naar mijn idee wel behoorlijk lelijk uit ziet. Werkt natuurlijk prima, maar het voelt ergens wel aantrekkelijk om die driver maar bij de credentials in .env te zetten zodat alles een beetje bij elkaar staat.

Ik ben nog een beetje zoekende in wat de best practices zijn op het gebied van .env files, config files en hardcoded. Ik verbaas me er soms over hoe druk ik me kan maken over dit soort triviale dingen, maar ben wel benieuwd hoe de meer ervaren programmeurs hier mee omgaan.

Misschien in het verlengde hiervan ook leuk om iets te zeggen over de best practices over het delen van de verwachte opbouw van een .env file (in mijn voorbeeld hierboven verwacht ik bijv. dat .env 'username' verwacht en niet (bijv.) 'dbuser'. Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen of meld je dit in je readme.md / andere documentatie?

  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 19:22
Ik zou wel dbuser gebruiken omdat je env file meerdere usernames kan bevatten, bv een username voor een externe API ofzo

Een voorbeeld bestand met voorbeeld waarden is absoluut goed om er bij te doen

[Voor 25% gewijzigd door Kalentum op 15-01-2022 13:49]

PV Output


  • MadGazelle
  • Registratie: Oktober 2006
  • Laatst online: 27-03 00:03
Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen...
Ja. Wat ik meestal doe ik is een ".env.example" bestand toevoegen met alle variabelen die de applicatie verwacht. Indien nodig met default of voorbeeld values, resp. bijv. "FLASK_ENV=development" of "SECRET_KEY=insecure_key_for_dev"
... of meld je dit in je readme.md / andere documentatie?
Dat ook. In de readme vermeld ik dan onder de sectie 'Getting started' (oid) dat men de ".env.example" moet kopiëren, hernoemen naar ".env" en waar nodig de values moet aanpassen voor hun situatie.

  • Morrar
  • Registratie: Juni 2002
  • Laatst online: 18:03
Ik gebruik ook vaak een default_config.yaml of iets dergelijks voor zulke dingen. Of in de docs zetten welke ENV variabelen gezet moeten worden.

Als je het echt chique will doen zou je zelfs nog een configuratie CLI kunnen bouwen. Via een script entrypoint in je setup.py is dat vrij simpel te implementeren. Eventueel met typer is het nog makkelijker.

  • DHH
  • Registratie: Augustus 2014
  • Laatst online: 23-03 21:55
Hoe zouden jullie dan omgaan met mijn voorbeeld van bijv. de driver? Het is geen 'groot geheim' dus m.i. hoeft 't niet in .env, maar het voelt wel weer lelijk om dat dan als enige 'connection' configuratie apart in een config bestand te zetten.

Ik heb het idee dat er niet echt een verkeerd antwoord is, maar ben benieuwd naar wat 'gangbaar' is.

  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 19:22
Een .env is niet alleen voor secrets maar is voor alles wat je configureerbaar wilt maken. Dus die connection string kan ook prima in een env

PV Output


  • milo526
  • Registratie: Februari 2014
  • Laatst online: 19:49
Ik lees dat je met Python bezig bent, mijn achtergrond is meer JavaScript (NodeJS).
Hierin is het vrij gebruikelijk om een in een configuratie bestand, je environment variabele te importeren.
Vervolgens gebruik je door de applicatie je configuratie bestand (en dus nooit direct je environment variabele).

Wat hiervoor al genoemd wordt, je environment variables zijn om je omgeving in te stellen.
Niet alles hiervan hoeft noodzakelijk geheim te zijn.
De vraag is meer, wat wil je aan kunnen passen op andere omgevingen/servers.
Het is net zo zeer mogelijk om secrets in een config bestand te zetten, mits je dat config bestand niet meeneemt in je source control - hiervoor heb je dan weer een example bestand.

  • onoweb
  • Registratie: December 2016
  • Laatst online: 27-01 23:01
alles in de config files en als er dingen in de config file "gevoelig" zijn of van veranderende aard per omgeving (dus niet mee mogen gecommit worden) dan steek je die in .env en verwijs je naar de env variabele in je config file.

Webdeveloper


  • M0nkeymen
  • Registratie: Maart 2009
  • Laatst online: 20:11

M0nkeymen

Monkeystyle!

Aangezien je DB op Azure staat en je python projectje misschien ook? Zou je ook Azure Key vault kunnen gebruiken.

psn: M0nkeymen81 | Inglourious Guardians


  • knarfyboy
  • Registratie: November 2001
  • Laatst online: 00:14
Doe m’n mongo db string gewoon in de env file. Ook omdat je per server allemaal flags kan hebben en anders moet je zo gaan rotzooien in de code.

  • whoami
  • Registratie: December 2000
  • Laatst online: 13:33
Ik heb geen python achtergrond, maar wel een .NET / Azure achtergrond. Echter, ik denk dat dit eerder over een conceptueel iets gaat , dan iets wat specifiek toe te spitsen is op één technologie.

Eigenlijk moet je uw 'Config' zien als een verzameling van gegevens, en die gegevens kunnen van verschillende plaatsen komen. Je kan je Config opbouwen met gegevens uit een config file, uit environment variables of een .env file etc... Vanuit je applicatie ga je altijd het 'Configuration' object aanspreken om een config value op te halen, en nooit rechtstreeks de 'config-bron' gaan aanspreken.
Op die manier kan je uw configuratie zo opzetten dat je bepaalde config-values kunt gaan overschrijven.

In pseudo code zo je het zo kunnen beschouwen:

code:
1
2
3
var config = ConfigurationBuilder.AddConfigFile("filename")
        .AddEnvironmentVariables()
        .Build();


Zaken zoals connectionstrings, wachtwoorden, etc... komen bij niet in de reguliere config terecht. Die bewaar ik in een secret-store zoals bv Azure KeyVault.
Ik beschouw die zaken in mijn code ook liefst niet als gewone 'config values', maar ik wil die in mijn code ook als secrets gaan beschouwen. (Je zou nl. Azure KeyVault ook als een config-source kunnen toevoegen aan je configuration object).
Om dit onderscheid te maken, maak ik -in .NET dan- gebruik van de Arcus Security library, waarin een SecretProvider gedefinieerd is. Dit werkt dan gelijkaardig aan dat 'Configuration' object: Ik kan er ook verschillende 'sources' aan hangen: Azure KeyVault, maar ook Environment variables of zelfs mijn Configuration object. Op die manier maak ik in mijn code expliciet het onderscheid tussen 'configuratie' en 'secrets', en kan ik tijdens development op mijn workstation gewoon een .env file bijhouden waarin ik ook connectionstrings etc bewaar. (Die .env file gaat natuurlijk niet mee in source-control).
In productie zitten alle secrets mooi in KeyVault, en worden Configuration values opgeslagen in de Config van mijn Azure web App bv.

Als je een project opensourced, dan kan je idd een voorbeeld .env file meeleveren, maar meestal zet ik dergelijke dingen gewoon in de readme.md, evt met wat samples er bij. (Dat doe ik niet alleen voor open-source zaken, maar voor alle projecten die ik voor klanten doe).

https://fgheysels.github.io/

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