Los programas a menudo controlan la operación a través de la configuración incluida con el software, y las variables de entorno permiten a los usuarios configurarlas en tiempo de ejecución. Sin embargo, la ejecución de procesos en contenedores Docker complica las cosas, entonces, ¿cómo se pasan las variables de entorno a un contenedor?
¿Para qué se utilizan las variables de entorno?
Las variables de entorno le permiten desacoplar la configuración del ejecutable de la aplicación. Por ejemplo, no le gustaría almacenar la contraseña de su base de datos de producción en su base de código; si lo hiciera, sería visible desde Git, y cualquier persona con acceso a su código podría eliminar su base de datos.
En su lugar, lo configura con una variable de entorno, que almacena un par clave-valor simple y le permite acceder al valor en cualquier aplicación que se ejecute en la misma sesión de shell (no son accesibles globalmente). Esto también tiene la ventaja de poder definir fácilmente diferentes configuraciones para diferentes entornos. Por ejemplo, tener claves separadas para las bases de datos de desarrollo y producción, o usar un extremo de API diferente.
La configuración de estas variables para los contenedores Docker se puede realizar de tres formas principales:con argumentos CLI, .env
archivos de configuración, o a través de docker-compose
.
Con un argumento de línea de comandos
El comando utilizado para lanzar contenedores Docker, docker run
, acepta variables ENV como argumentos. Simplemente ejecútelo con -e
bandera, abreviatura de --env
y pase el par clave=valor:
sudo docker run -e POSTGRES_USER='postgres' -e POSTGRES_PASSWORD='password' ...
Y, si ya tiene esas variables de entorno configuradas en el entorno que ejecuta ese comando, puede pasarlas directamente por nombre:
// set variable POSTGRES_PASSWORD='password' // use it later docker run -e POSTGRES_PASSWORD -e POSTGRES_USER ...
Seguridad adicional con un archivo .env
Pasar variables con argumentos CLI funciona muy bien, pero tiene un inconveniente:esas variables son visibles desde el host. Están registrados en el historial de comandos y son visibles en la lista de procesos para el proceso iniciado.
Linux tiene una forma integrada de administrar permisos para esto:acceso a archivos. Almacenar las variables en un .env
le permite controlar el acceso a ese archivo con permisos de archivo (chmod
, chown
).
Crea un .env
archivo con variables en el siguiente formato, cada una en una nueva línea:
POSTGRES_PASSWORD='password' POSTGRES_USER='postgres' APPLICATION_URL='example.com'
Luego, pásalo a docker run
con el --env-file
bandera:
docker run --env-file ./envfile ...
Con Docker-Compose
Por supuesto, muchas personas no lanzan contenedores Docker directamente con docker run
, y en su lugar optar por usar un docker-compose
archivo para manejar la configuración de varios contenedores, todos los cuales representan una sola aplicación.
Para pasar variables de entorno a un contenedor lanzado de esta manera, deberá configurar el archivo de redacción para pasar las variables de la sesión al contenedor Docker. Esta configuración aquí pasa el POSTGRES_USER
variable tanto para el entorno de compilación como para el entorno de tiempo de ejecución, y establece un valor predeterminado si no existe.
version: '3.1' services: my-service: build: context: . args: - POSTGRES_USER=${POSTGRES_USER:-default} environment: - POSTGRES_USER=${POSTGRES_USER:-default}
Deberá configurar las variables de entorno antes de ejecutar docker-compose up
, de lo contrario no podrá acceder a ellos. Puede almacenarlos en el archivo de redacción, pero normalmente se realiza un seguimiento y una versión, lo que anula el propósito de las variables env.
Con Kubernetes
Kubernetes es un sistema de orquestación que puede gestionar la ejecución de cientos de contenedores en una red. Todavía usa Docker, pero solo tocará la configuración, por lo que pasar variables de entorno directamente no funcionará.
En su lugar, puede definirlos en la configuración del Pod:
apiVersion: v1 kind: Pod metadata: name: example spec: containers: - ... env: - name: SERVICE_PORT value: "80" - name: SERVICE_IP value: "172.17.0.1"
Kubernetes es complicado y hay muchas formas diferentes de trabajar con variables de entorno. Para obtener más información, puede leer sus guías sobre la inyección de datos en Pods.