Publi

Contenedores docker de aplicaciones de escritorio [con ejemplos listos para usar]

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.”

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

Otras ideas: navegadores

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

También podría interesarte....

There are 4 comments left Ir a comentario

  1. Osqui /
    Usando Mozilla Firefox Mozilla Firefox 63.0 en Fedora Linux Fedora Linux

    ¿Flatpak no persigue el mismo objetivo?

    1. Gaspar Fernández / Post Author
      Usando Mozilla Firefox Mozilla Firefox 63.0 en Ubuntu Linux Ubuntu Linux

      Pues sí, es otro enfoque. Y el caso es que Flatpak, o Snap están por defecto en muchos sitios ya. Los paquetes que están disponibles son fáciles de instalar. Aunque me surgió el caso en el que no me era posible utilizar ninguno de los dos, pero sí pude utilizar Docker 🙂

  2. David Latorre /
    Usando Mozilla Firefox Mozilla Firefox 63.0 en Linux Linux

    Creo ver un pequeño error arriba y es el “Partimos de la versión 18.04 de Debian” esa es una versión de Ubuntu, en Debian vamos por la 9 😉

    1. Gaspar Fernández / Post Author
      Usando Mozilla Firefox Mozilla Firefox 63.0 en Ubuntu Linux Ubuntu Linux

      ¡¡ Gracias David !! Arreglado, que se me fue la cabeza. ¡Saludos!

Leave a Reply