Programma's regelen vaak de werking via configuratie die bij de software wordt geleverd, en omgevingsvariabelen maken gebruikers om ze tijdens runtime in te stellen. Het uitvoeren van processen in Docker-containers maakt het echter ingewikkelder, dus hoe geef je omgevingsvariabelen door aan een container?
Waar worden omgevingsvariabelen voor gebruikt?
Met omgevingsvariabelen kunt u de configuratie loskoppelen van het uitvoerbare bestand van de toepassing. Je zou bijvoorbeeld het wachtwoord van je productiedatabase niet in je codebase willen opslaan. Als je dat deed, zou het zichtbaar zijn vanuit Git, en iedereen met toegang tot je code zou je database kunnen verwijderen.
In plaats daarvan stelt u het in met een omgevingsvariabele, die een eenvoudig sleutel-waardepaar opslaat en u toegang geeft tot de waarde in elke toepassing die in dezelfde shell-sessie wordt uitgevoerd (ze zijn niet wereldwijd toegankelijk). Dit heeft ook het voordeel dat u gemakkelijk verschillende configuraties voor verschillende omgevingen kunt definiëren. Bijvoorbeeld afzonderlijke sleutels hebben voor ontwikkelings- en productiedatabases, of een ander API-eindpunt gebruiken.
Het instellen van deze variabelen voor Docker-containers kan op drie manieren: met CLI-argumenten, .env-configuratiebestanden , of via docker-compose.
Met een opdrachtregelargument
De opdracht die wordt gebruikt om Docker-containers te starten, docker run, accepteert ENV-variabelen als argumenten. Voer het gewoon uit met de vlag -e, afgekort voor –env, en voer het key=value-paar in:
sudo docker run -e POSTGRES_USER='postgres' -e POSTGRES_PASSWORD='password' .. Advertentie
En als je die omgevingsvariabelen al hebt ingesteld in de omgeving waarin die opdracht wordt uitgevoerd, kun je ze gewoon rechtstreeks op naam doorgeven:
//set variabele POSTGRES_PASSWORD='password' //gebruik het later docker run -e POSTGRES_PASSWORD -e POSTGRES_USER …
Extra beveiliging met een .env-bestand
Het doorgeven van variabelen met CLI-argumenten werkt prima, maar heeft een nadeel: die variabelen zijn zichtbaar vanaf de host. Ze zijn ingelogd in de opdrachtgeschiedenis en zijn zichtbaar in de proceslijst voor het gestarte proces.
Linux heeft een ingebouwde manier om permissies voor deze bestandstoegang te beheren. Door de variabelen in een .env-bestand op te slaan, kunt u de toegang tot dat bestand beheren met bestandsrechten (chmod, chown).
Maak een .env-bestand met variabelen in de volgende indeling, elk op een nieuwe regel:
POSTGRES_PASSWORD='password' POSTGRES_USER='postgres' APPLICATION_URL='example.com'
Geef het vervolgens door aan docker run met de –env-file vlag:
docker run –env-file ./envfile …
Met Docker-Compose
Natuurlijk starten veel mensen Docker-containers niet rechtstreeks met docker run, maar kiezen ze in plaats daarvan voor het gebruik van een docker-compose-bestand om de configuratie van meerdere containers te verwerken die allemaal een enkele applicatie vertegenwoordigen.
Om omgevingsvariabelen door te geven aan een container die op deze manier wordt gestart, moet u het samenstellingsbestand configureren om de variabelen van de sessie door te geven aan de Docker-container. Deze configuratie geeft de variabele POSTGRES_USER door aan zowel de build-omgeving als de runtime-omgeving en stelt een standaardwaarde in als deze niet bestaat.
versie: '3.1' services: mijn-service: build: context: . args: – POSTGRES_USER=${POSTGRES_USER:-default} omgeving: – POSTGRES_USER=${POSTGRES_USER:-default} Advertentie
U moet de omgevingsvariabelen instellen voordat u docker-compose uitvoert, anders zal het niet ze kunnen benaderen. Je zou ze kunnen opslaan in het opstelbestand, maar dat wordt meestal bijgehouden en geversied, wat het doel van env-variabelen tenietdoet.
Met Kubernetes< /h2>
Kubernetes is een orkestratiesysteem dat honderden containers over een netwerk kan draaien. Het gebruikt nog steeds Docker, maar je raakt alleen configuratie aan, dus het rechtstreeks doorgeven van omgevingsvariabelen werkt niet.
In plaats daarvan kun je ze definiëren in de configuratie voor de Pod:
apiVersion : v1 soort: Pod metadata: naam: voorbeeld spec: containers: – … env: – naam: SERVICE_PORT waarde: “80” – naam: SERVICE_IP waarde: “172.17.0.1”
Kubernetes is ingewikkeld, en er zijn veel verschillende manieren om met omgevingsvariabelen te werken. Voor meer informatie kunt u hun handleidingen lezen over het injecteren van gegevens in Pods.