secret example create configmap configuration docker environment-variables configuration-files kubernetes

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:

  1. ¿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

  1. 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: