configuration - example - Kubernetes equivalente de env-file en Docker
kubernetes configmap (5)
Al definir un pod para Kubernetes usando un archivo YAML, no hay forma directa de especificar un archivo diferente que contenga variables de entorno para un contenedor. El proyecto Kubernetes dice que mejorarán esta área en el futuro (ver los documentos de Kubernetes ).
Mientras tanto, sugiero usar una herramienta de aprovisionamiento y hacer que el pod YAML sea una plantilla. Por ejemplo, usando Ansible su archivo YAML pod podría verse así:
archivo
my-pod.yaml.template
:
apiVersion: v1
kind: Pod
...
spec:
containers:
...
env:
- name: MYSQL_ROOT_PASSWORD
value: {{ mysql_root_pasword }}
...
Luego, su libro de jugadas de Ansible puede especificar la variable
mysql_root_password
algún lugar conveniente y sustituirla al crear el recurso, por ejemplo:
archivo
my-playbook.yaml
:
- hosts: my_hosts
vars_files:
- my-env-vars-{{ deploy_to }}.yaml
tasks:
- name: create pod YAML from template
template: src=my-pod.yaml.template dst=my-pod.yaml
- name: create pod in Kubernetes
command: kubectl create -f my-pod.yaml
archivo
my-env-vars-prod.yaml
:
mysql_root_password: supersecret
archivo
my-env-vars-test.yaml
:
mysql_root_password: notsosecret
Ahora crea el recurso pod ejecutando, por ejemplo:
ansible-playbook -e deploy=test my-playbook.yaml
Antecedentes:
Actualmente estamos usando Docker y Docker Compose para nuestros servicios.
Hemos externalizado la configuración para diferentes entornos en archivos que definen variables de entorno leídas por la aplicación.
Por ejemplo, un archivo
prod.env
:
ENV_VAR_ONE=Something Prod
ENV_VAR_TWO=Something else Prod
y un archivo
test.env
:
ENV_VAR_ONE=Something Test
ENV_VAR_TWO=Something else Test
Por lo tanto, simplemente podemos usar el archivo
prod.env
o
test.env
al iniciar el contenedor:
docker run --env-file prod.env <image>
Luego, nuestra aplicación retoma su configuración en función de las variables de entorno definidas en
prod.env
.
Preguntas:
- ¿Hay alguna manera de proporcionar variables de entorno desde un archivo en Kubernetes (por ejemplo, al definir un pod) en lugar de codificarlas de esta manera:
apiVersion: v1 kind: Pod metadata: labels: context: docker-k8s-lab name: mysql-pod name: mysql-pod spec: containers: - env: - name: MYSQL_USER value: mysql - name: MYSQL_PASSWORD value: mysql - name: MYSQL_DATABASE value: sample - name: MYSQL_ROOT_PASSWORD value: supersecret image: "mysql:latest" name: mysql ports: - containerPort: 3306
- Si esto no es posible, ¿cuál es el enfoque sugerido?
Esta es una pregunta antigua pero tiene muchos espectadores, así que agrego mi respuesta.
La mejor manera de separar la configuración de la implementación de K8 es usar Helm.
Cada paquete Helm puede tener un archivo
values.yaml
y podemos usar fácilmente esos valores en el gráfico Helm.
Si tenemos una topología de múltiples componentes, podemos crear un paquete Helm paraguas y el paquete de valores primarios también puede sobrescribir los archivos de valores secundarios.
Esto funciona para mi:
archivo
env-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: env-secret
type: Opaque
stringData:
.env: |-
APP_NAME=Laravel
APP_ENV=local
y en el
deployment.yaml
o
pod.yaml
spec:
...
volumeMounts:
- name: foo
mountPath: "/var/www/html/.env"
subPath: .env
volumes:
- name: foo
secret:
secretName: env-secret
````
Puede llenar las variables de entorno de un contenedor mediante el uso de Secrets o ConfigMaps . Use Secretos cuando los datos con los que está trabajando sean confidenciales (por ejemplo, contraseñas) y ConfigMaps cuando no lo sea.
En su definición de Pod, especifique que el contenedor debe extraer valores de un Secreto:
apiVersion: v1
kind: Pod
metadata:
labels:
context: docker-k8s-lab
name: mysql-pod
name: mysql-pod
spec:
containers:
- image: "mysql:latest"
name: mysql
ports:
- containerPort: 3306
envFrom:
- secretRef:
name: mysql-secret
Tenga en cuenta que esta sintaxis solo está disponible en Kubernetes 1.6 o posterior. En una versión anterior de Kubernetes, deberá especificar cada valor manualmente, por ejemplo:
env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_USER
(Tenga en cuenta que
env
toma una matriz como valor)
Y repitiendo para cada valor.
Cualquiera que sea el enfoque que utilice, ahora puede definir dos Secretos diferentes, uno para producción y otro para desarrollador.
dev-secret.yaml:
apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
data:
MYSQL_USER: bXlzcWwK
MYSQL_PASSWORD: bXlzcWwK
MYSQL_DATABASE: c2FtcGxlCg==
MYSQL_ROOT_PASSWORD: c3VwZXJzZWNyZXQK
prod-secret.yaml:
apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
data:
MYSQL_USER: am9obgo=
MYSQL_PASSWORD: c2VjdXJlCg==
MYSQL_DATABASE: cHJvZC1kYgo=
MYSQL_ROOT_PASSWORD: cm9vdHkK
E implemente el secreto correcto en el clúster Kubernetes correcto:
kubectl config use-context dev
kubectl create -f dev-secret.yaml
kubectl config use-context prod
kubectl create -f prod-secret.yaml
Ahora, cada vez que se inicia un Pod, rellenará sus variables de entorno a partir de los valores especificados en el Secreto.
Una nueva actualización para Kubernetes (v1.6) permite lo que solicitó (hace años).
Ahora puede usar
envFrom
como este en su archivo yaml:
containers:
- name: django
image: image/name
envFrom:
- secretRef:
name: prod-secrets
Donde desarrollo-secretos es tu secreto, puedes crearlo de la siguiente manera:
kubectl create secret generic prod-secrets --from-file=prod/env.txt`
Donde el contenido del archivo txt es un valor-clave:
DB_USER=username_here
DB_PASSWORD=password_here
Los documentos siguen siendo lagos de ejemplos, tuve que buscar mucho en esos lugares:
-
envFrom
secretos , buscarenvFrom
: muestra que esta opción está disponible. -
Los documentos equivalentes de
ConfigMap
muestran un ejemplo sobre cómo usarlo.