Heredar variables de entorno en el contenedor systemd Docker

9

Tengo un contenedor Docker que ejecuta systemd . Quiero pasar variables de entorno a las aplicaciones que se encuentran debajo.

Cuando inicio systemd desde Docker ( /sbin/initcomo línea de comando), Docker expone las variables a systemd, pero no a los servicios secundarios . Si agrego systemd.setenv=...al cmdline, se pasan las variables. Estoy buscando una solución más limpia.

¿Cómo expongo las variables de entorno transmitidas /sbin/inita las aplicaciones iniciadas por este?

% docker run -v /sys/fs/cgroup:/sys/fs/cgroup:ro --privileged -ti \
             -e VAR1=1 motiejus/systemd_fedora20 \
             init systemd.setenv=VAR2=2
...
Welcome to Fedora 20 (Heisenbug)!
...
[  OK  ] Reached target Multi-User System.
[root@740690365eb0 ~]# env | grep VAR
VAR2=2

Espero ver VAR1=1mientras ejecuto mi comando.

En otras palabras, ¿puede systemd pasar variables que se le pasan a los niños que comienza?

Para Dockerfile, vea el repositorio de github .

environment-variables systemd docker Motiejus Jakštys
fuente

Respuestas:

9

Para responder a la pregunta formulada (ya que no parece ser respondida en ningún otro lugar)

"¿Cómo expongo las variables de entorno pasadas a / sbin / init a las aplicaciones iniciadas por este?"

requiere un golpe ligeramente irritante y una función extremadamente útil del sistema de archivos linux / proc:

# Import our environment variables from systemd
for e in $(tr "\000" "\n" < /proc/1/environ); do
        eval "export $e"
done

Esto lee / proc / 1 / envion, que es el entorno dado al PID 1, pero está delimitado por nulos. Utiliza 'tr' para reemplazar los nulos con nuevas líneas, y luego itera sobre esas líneas y las evalúa con una 'exportación' antepuesta, para que sean visibles para los procesos secundarios.

Las variables de entorno de no exposición es otra "característica" de systemd, y no lo consideran un error.

xrobau
fuente
3
Quiero decir 'No necesito esta función, necesito variables de entorno'
Daniel Dai