ConfigMap și Secret
Configurația unei aplicații nu trebuie inclusă direct în imaginea containerului. În acest laborator folosim:
- un ConfigMap pentru valorile nesensibile
- un Secret pentru parola bazei de date.
ConfigMap
Fișierul k8s/10-configmap.yaml conține:
apiVersion: v1
kind: ConfigMap
metadata:
name: ticketing-config
namespace: cc-lab3
data:
APP_VERSION: "1.0.0"
PORT: "8080"
USE_POSTGRES: "true"
DB_HOST: "postgres"
DB_PORT: "5432"
DB_NAME: "tickets"
DB_USER: "tickets"
DB_HOST este numele Service-ului Kubernetes prin care aplicația va găsi
PostgreSQL. Aplicația nu depinde de IP-ul unui Pod.
Aplicați și inspectați obiectul:
kubectl apply -f k8s/10-configmap.yaml
kubectl get configmap ticketing-config -n cc-lab3
kubectl describe configmap ticketing-config -n cc-lab3
Secret
Fișierul k8s/11-secret.yaml conține o parolă destinată exclusiv laboratorului:
apiVersion: v1
kind: Secret
metadata:
name: ticketing-db-secret
namespace: cc-lab3
type: Opaque
stringData:
DB_PASSWORD: "tickets-lab-password"
Câmpul stringData permite scrierea valorii în clar în manifest. La crearea
obiectului, Kubernetes o transformă în reprezentarea Base64 din câmpul data.
Aplicați și inspectați metadatele Secret-ului:
kubectl apply -f k8s/11-secret.yaml
kubectl get secret ticketing-db-secret -n cc-lab3
kubectl describe secret ticketing-db-secret -n cc-lab3
Comanda describe afișează numele cheii și dimensiunea valorii, nu parola.
Base64 este o codificare, nu o metodă de criptare. Manifestul folosește intenționat o parolă fictivă, pentru laborator. Nu includeți credențiale reale în Git și nu presupuneți că orice utilizator care poate citi obiectul Secret trebuie să aibă acces la valoarea sa.
Cum ajung valorile în containere
Deployment-ul API folosește ambele obiecte:
envFrom:
- configMapRef:
name: ticketing-config
- secretRef:
name: ticketing-db-secret
StatefulSet-ul PostgreSQL selectează numai cheile de care are nevoie prin
configMapKeyRef și secretKeyRef. Astfel, fiecare container primește doar
configurația necesară rolului său.