En los últimos años, han surgido varias tecnologías para compartimentar aplicaciones. Desde ejecutar una aplicación desde una jaula, hasta virtualizar un sistema operativo completo dentro de nuestro sistema. Algo que se utiliza mucho en servidores. Actualmente hay una tecnología en auge, y es Docker. Docker nos permite encerrar una aplicación, junto con las bibliotecas que necesita para funcionar y ejecutarla en un entorno aislado, de forma que la aplicación compartimentada no pueda ver nada del exterior. Aunque, si lo deseamos, podrá conectar por red con otros recursos o a Internet.
Docker se usa mucho en el ámbito de los servidores. Nos permite ejecutar aplicaciones de manera que cada una se ejecute en un espacio determinado, con unos permisos, utilizando unos recursos de sistema definidos y utilizando un sistema operativo y bibliotecas de sistema determinadas, que pueden no ser las de nuestro sistema. Otra ventaja añadida es que los contenedores docker tienen un guión definido para su construcción, lo que nos asegura que la configuración del software del contenedor no variará entre instancias, podemos perfectamente configurarlo en nuestro ordenador local e instalarlo más tarde en un servidor cuando nos aseguremos de que todo esté bien, o hacer que todo un equipo (o empresa) utilice el mismo software, en la misma versión y con la misma configuración y evitar así la típica excusa de: «En mi ordenador funciona.»
Tabla de contenidos
Docker en el escritorio
Pero docker compartimenta aplicaciones, da igual del tipo que sean. Así que, ¿por qué no compartimentar aplicaciones de escritorio? De forma que encerremos todo lo que necesitamos de la misma en un entorno controlado y así evitamos tener problemas con dependencias, versiones, incluso con entornos Java cuando utilicemos dicha aplicación. Es muy común que una aplicación se actualice para utilizar bibliotecas en versiones muy nuevas y nuestra distribución no instale esas dependencias, incluso cuando las instalamos a mano, podemos meter la pata y hacer que nuestro sistema se vuelva inestable o que no funcione directamente. También es muy útil cuando necesitamos software que ya no está soportado, o necesitamos una versión antigua y vamos a ejecutarla en un sistema operativo más moderno que no instala las versiones de las bibliotecas que necesitamos.
Puede parecer un gasto innecesario de disco duro, porque seguramente tengamos muchas bibliotecas y software repetido en nuestro sistema; y de memoria, porque habrá veces que la misma biblioteca esté cargada en RAM varias veces (aunque podemos optimizar un poco nuestro kernel para que no tenga mucho problema con eso). Pero nos dará seguridad en nuestro sistema, ya que esta aplicación estará aislada y no tendrá acceso a recursos sin permiso, para esa aplicación ni existirán. Y además, la posibilidad de llevarnos la aplicación a otro equipo o servidor, construirla allí y que todo esté igual que en nuestro ordenador.
Construyendo el Dockerfile. Como ejemplo dbeaver
Cada Dockerfile será independiente de la aplicación que necesitemos ejecutar. Aunque podemos utilizar este archivo como base. En este caso, vamos a dockerizar el programa dbeaver, una poderosa herramienta de administración de base de datos con muchas opciones. Como vemos, es una aplicación hecha en Java. Y, puede que en nuestro ordenador o nuestro servidor, no nos interese tener un entorno de Java públicamente disponible, y solo dejarlo para este programa.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | FROM ubuntu:18.04 MAINTAINER Gaspar Fernandez <gaspar.fernandez@totaki.com> ARG UNAME=user ARG UID=1000 ARG GID=1000 RUN apt-get update \ && apt-get -y install wget \ && apt-get -y install libxext6 libxrender1 libxtst6 libxi6 software-properties-common \ && apt-get -y install openjdk-8-jre \ && wget -q --output-document=/tmp/dbeaver.deb https://dbeaver.io/files/dbeaver-ce_latest_amd64.deb \ && dpkg -i /tmp/dbeaver.deb \ && mkdir -p /home/$UNAME \ && echo "$UNAME:x:${UID}:${GID}:Developer,,,:/home/$UNAME:/bin/bash" >> /etc/passwd \ && echo "$UNAME:x:${UID}:" >> /etc/group \ && chown ${UID}:${GID} -R /home/$UNAME \ && gpasswd -a $UNAME audio \ && gpasswd -a $UNAME video COPY docker-entry.sh /usr/local/bin ENTRYPOINT ["/usr/local/bin/docker-entry.sh"] USER $UNAME ENV HOME /home/$UNAME |
En este caso, partimos de una versión 18.04 de Ubuntu, en la que tenemos que instalar dependencias del escritorio X y OpenDJK, seguidamente, descargar el .deb de la página oficial de dbeaver para proceder a la instalación del programa.
Seguidamente, aunque podemos continuar como root, sobre todo para los programas de escritorio, no es aconsejable y muchos de ellos se quejan al arrancar. Así que creamos un usuario (podríamos cambiarle el nombre al usuario, aunque no será tan importante, por ahora se llamará user). Luego le asignamos grupos (en este caso no es tan importante, pero hay programas con los que sí).
Generalmente, me gusta escribir un docker-entry.sh para cada aplicación a dockerizar, aunque solo sea para ejecutar el programa nada más. Porque, a veces tenemos que filtrar argumentos, ejecutar un pequeño script antes que el programa o hacer una copia de la configuración, etc. En este caso, nuestro docker-entry.sh será este:
1 2 3 4 | #!/bin/bash echo "Ejecutando dbeaver..." dbeaver |
Tras ello, aunque podríamos utilizar docker-compose, vamos a crear un script para construir el contenedor y otro para ejecutar la aplicación. Aunque la ejecución es más o menos sencilla, no tenemos por qué recordar los argumentos para ejecutar el programa. Además, así podremos crear más fácilmente accesos directos y otras utilidades derivadas.
build.sh
1 2 3 4 5 6 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker build -t gasparfm/dbeaver . popd |
Primero, almacenamos en la variable SCRIPTPATH el nombre del directorio donde se encuentra el script, me gusta utilizar esta línea por si llamamos al script desde una ruta diferente a la ruta donde está, o si hacemos un enlace simbólico al archivo. De esta forma, obtendremos en la variable la ruta exacta donde se encuentra el archivo de script al que hace referencia el enlace. Y así podremos realizar tareas en ese directorio, como por ejemplo la construcción de la imagen de nuestro contenedor.
run.sh
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker run --rm --name dbeaver -e DISPLAY=$DISPLAY \ -v /dev/shm:/dev/shm:rw \ -v /etc/machine-id:/etc/machine-id:ro \ -v /var/lib/dbus:/var/lib/dbus:ro \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/hosts:/etc/hosts:ro \ -v $(pwd)/user:/home/user \ -v $HOME/.ssh:/home/user/sshkeys:ro \ gasparfm/dbeaver popd |
Para ejecutar el script, podemos crear un enlace en /usr/local/bin a este archivo, llamándolo como queramos. Aquí comento algunos argumentos utilizados:
- –rm: Borra el contenedor si existe. Para utilizar siempre el mismo, porque normalmente solo vamos a necesitar una instancia en ejecución
- –name dbeaver: Le damos nombre al contenedor, para que no tenga un nombre aleatorio.
- -e DISPLAY=$DISPLAY: Asignamos la pantalla sobre la que escribirá la aplicación a la pantalla actual del usuario.
- -v /dev/shm:/dev/shm:rw: Algunos programas necesitan acceso a este dispositivo de memoria compartida.
- -v /etc/machine-id:/etc/machine-id:ro : Extraemos el identificador único de la máquina.
- -v /var/lib/dbus:/var/lib/dbus:ro : En este directorio también suele almacenarse el identificador único de la máquina.
- -v /tmp/.X11-unix:/tmp/.X11-unix : En este directorio suelen almacenarse los sockets para acceder al entorno X.
- -v /etc/localtime:/etc/localtime:ro : Aquí reside la zona horaria de nuestro ordenador y la vinculamos con la de la aplicación dockerizada.
- -v /etc/hosts:/etc/hosts:ro : Si tenemos hosts personalizados en /etc/hosts, nuestra aplicación debe poder acceder a ellos. O, al menos, resolverlos.
- -v $(pwd)/user:/home/user : Vinculamos el directorio local user (tendremos que crearlo) con el /home/user de la aplicación. Sobre todo porque este programa introduce mucha información que debe ser salvada. Por ejemplo, se descarga drivers de base de datos o genera muchos archivos de configuración, etc.
- -v $HOME/.ssh:/home/user/sshkeys:ro : Una opción de este programa es que nos permite acceder a bases de datos a través de túneles SSH. Por eso mismo, estaría bien poder acceder a nuestras claves privadas de SSH. Podríamos montar este volumen así o copiar las claves a mano al directorio user.
- gasparfm/dbeaver : Es el nombre del contenedor
Solo tendremos que ejecutar el programa:
Dockerizando yed
Ahora vamos a incluir un segundo programa, yed. Un software para crear diagramas, hecho en Java también. Pero esta vez necesita del JRE de Oracle. Lo que ya nos da una pista de la potencia y necesidad de dockerizar este tipo de aplicaciones.
Vamos a seguir el mismo sistema, creamos Dockerfile, docker-entry.sh, build.sh y run.sh.
Dockerfile
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | FROM ubuntu:18.04 MAINTAINER Gaspar Fernandez <gaspar.fernandez@totaki.com> ARG VERSION=3.18.1.1 ARG UNAME=user ARG UID=1000 ARG GID=1000 RUN apt-get update \ && apt-get -y install wget \ && apt-get -y install libxext6 libxrender1 libxtst6 libxi6 software-properties-common unzip RUN add-apt-repository ppa:webupd8team/java \ && apt-get update \ && echo debconf shared/accepted-oracle-license-v1-1 select true | \ debconf-set-selections \ && echo debconf shared/accepted-oracle-license-v1-1 seen true | \ debconf-set-selections \ && apt-get -y install oracle-java8-installer RUN wget -q --output-document=/tmp/yEd.zip https://www.yworks.com/resources/yed/demo/yEd-${VERSION}.zip \ && unzip /tmp/yEd.zip -d /opt/ \ && mkdir -p /home/$UNAME \ && echo "$UNAME:x:${UID}:${GID}:Developer,,,:/home/$UNAME:/bin/bash" >> /etc/passwd \ && echo "$UNAME:x:${UID}:" >> /etc/group \ && chown ${UID}:${GID} -R /home/$UNAME \ && gpasswd -a $UNAME audio \ && gpasswd -a $UNAME video COPY docker-entry.sh /usr/local/bin ENTRYPOINT ["/usr/local/bin/docker-entry.sh"] USER $UNAME ENV HOME /home/$UNAME |
docker-entry.sh:
1 2 3 4 5 6 7 8 9 10 | #!/bin/bash ARGS='' if [ $# -ge 1 ]; then ARGS="$HOME/$(basename $1)" shift 1 ARGS="$@ $ARGS" fi java -jar "/opt/$(ls)/yed.jar" $ARGS |
Esta vez, necesitamos que yed acepte argumentos del usuario, como por ejemplo el archivo que vamos a abrir.
build.sh
1 2 3 4 5 6 7 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker build -t gasparfm/yed . popd |
run.sh
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker run --rm --name yed -e DISPLAY=$DISPLAY \ -v /dev/shm:/dev/shm:rw \ -v /etc/machine-id:/etc/machine-id:ro \ -v /var/lib/dbus:/var/lib/dbus:ro \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/hosts:/etc/hosts:ro \ -v $(pwd)/user:/home/user \ gasparfm/yed popd |
De la misma forma podemos construir programas libres o privativos. Introduciendo una capa de seguridad en estos últimos, ya que no tendremos forma de saber lo que hacen. Incluso instalando versiones determinadas de wine para hacer funcionar algunos programas. Y como última idea, podemos dockerizar navegadores, instalaciones completas de Firefox / Chrome / Chromium en las que podremos limitar los recursos para no engullir RAM o CPU (podríamos limitarles la memoria a 1Gb, por ejemplo).
Dockerfile
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | FROM ubuntu:18.04 ARG UNAME=user ARG UID=1000 ARG GID=1000 RUN apt-get update \ && apt-get -y install sudo iproute2 \ && apt-get -y install chromium-browser \ && apt-get -y clean RUN mkdir -p /home/$UNAME && \ echo "$UNAME:x:${UID}:${GID}:Developer,,,:/home/$UNAME:/bin/bash" >> /etc/passwd && \ echo "$UNAME:x:${UID}:" >> /etc/group && \ chown ${UID}:${GID} -R /home/$UNAME \ && gpasswd -a $UNAME audio \ && gpasswd -a $UNAME video \ && echo "$UNAME ALL=(ALL:ALL) NOPASSWD: ALL" > /etc/sudoers.d/user COPY docker-entry.sh /usr/local/bin RUN chmod +x /usr/local/bin/docker-entry.sh USER $UNAME ENV HOME /home/$UNAME ENTRYPOINT ["/usr/local/bin/docker-entry.sh"] |
docker-entry.sh:
1 2 3 4 | #!/bin/bash # Podríamos incluir argumentos aquí. chromium-browser |
build.sh:
1 2 3 4 5 6 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) --build-arg UNAME=user -t gasparfm/chromium . popd |
run.sh:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | #!/bin/bash readonly SCRIPTPATH="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")" pushd $SCRIPTPATH docker run -i --rm --name chromium --privileged -e DISPLAY=$DISPLAY \ -v /dev/shm:/dev/shm:rw \ -v /etc/machine-id:/etc/machine-id:ro \ -v /run/user/$UID/pulse:/run/user/$UID/pulse:rw \ -v /var/lib/dbus:/var/lib/dbus:ro \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v $(pwd)/user:/home/user \ --device /dev/video0 \ --memory="1000m" \ --cpus 1 \ gasparfm/chromium popd |
En este caso, lo estamos limitando su procesamiento a 1 CPU (o núcleo) y aproximadamente 1Gb de memoria.
Aplicaciones dockerizadas
Y tú, ¿qué aplicación de escritorio dockerizarías?
Actualización 7/12/2018: Arreglado un fallo en la redacción cambiado Debian por Ubuntu, que se me fue la cabeza. Gracias a David Latorre por avisar.
Foto principal: unsplash-logoandrew jay