Bind mount para simplificar el uso de la imagen Docker

[javiersanp]

De cara a reducir el número de pasos necesarios para utilizar la imagen Docker podríamos usar un bind mount.

Estoy modificando el Dockerfile en la rama development para crear el directorio /catastro/local como punto de montaje del volumen.

El volumen se monta al construir el contenedor con la opción -v ruta:/catastro/local.

De esa forma, lo que se coloque en /catastro/local dentro del contenedor es visible desde fuera en la ruta indicada. Para copiar los archivos sería con "cp -r" dentro del host en lugar de "docker cp" desde fuera. También se puede ejecutar el programa dentro de /catastro/local

Por ejemplo, para montar el directorio actual sería:

docker run --name catastro -it -v $(pwd):/catastro/local egofer/catatom2osm

En w$ me parece que hay que poner %pwd% en lugar de $(pwd).

¿Qué te parece @egofer?

[javiersanp]

Otra opción es montar pwd en /catastro y trabajar directamente visible desde fuera. No habría que copiar nada.

[egofer]

Me parece bien. Esto que comentas también le estuve dando yo vueltas: asignar un volumen del contenedor a un directorio compartido en el host sería una buena idea. Con ello se simplificaría bastante el flujo de trabajo (pensando en usuarios con CLI-fobia), y sobre todo en la parte que probablemente lleve a más confusión.

Por otro lado veo que si se mostrasen los archivos del programa directamente visible desde el host, la configuración del archivo setup.py sería sencilla para este tipo de usuarios que no se sienten cómodos usando un editor como nano desde una terminal.

Si seguimos adelante con esto editaría el videotutorial para incluir los cambios.

[javiersanp]

Exponer dos volúmenes hacia afuera supondría más complicación para el usuario que tendría que añadir dos opciones "-v" al construir el volúmen. Aunque eso lo podemos arreglar usando docker-compose, hay que especificar una ruta muy específica en el host. Es más mejor modificar la forma de configurar el idioma usando una variable de entorno. Además no tiene sentido exponer hacia fuera todo el código del programa sólo para eso. Me parece que aparte del idioma no hay más ajustes ¿no?

Creo que finalmente voy a montar el volúmen en /catastro y que se trabaje todos los resultados visibles hacia afuera. Así ni siquiera se tienen que preocupar de copiar en la carpeta local

[egofer]

Que yo sepa a parte del idioma no hay más ajustes, al menos que yo conozca y haya utilizado. Si lo puedes parametrizar mucho mejor. No obstante cualquier progreso que simplifique el flujo de lo que ya hay será sin duda un gran avance, teniendo siempre en mente ampliar la base de usuarios que importen catastro. A la larga probablemente tendríamos que pensar alguna forma en la que usuarios menos experimentados puedan solicitar municipios, que corrijan el "highway_names.csv" y otros podamos procesar y subir a Github esos archivos (o automatizar la solicitudes de alguna manera: vía web, bot de telegram, no se...).

[javiersanp]

He probado a parametrizarlo y funciona.

Lo que comentas ya se ha propuesto en el canal de telegram. No se si puedes ver los mensajes anteriores a que entraras. Ya se ha habilitado en la página de resultados de la wiki. Sólo falta buscar voluntarios y anunciarlo.

[javiersanp]

Leyendo la documentación de docker acerca de los "bind mount" menciona que es un riesgo potencial de seguridad (que la aplicación modifique ficheros del host). Corremos el riesgo de que usuario de acceso a una carpeta que sea sensible sin darse cuenta. Igual es mejor dejar las cosas como están y ponerlo sólo como nota para usuarios avanzados.

[javiersanp]

Ventajas del bind mount:

1. Los ficheros se generan y están accesibles en el host.
2. Menos comandos implicados.
3. Git está disponible para su ejecución sin tener que instalarlo.

Ejemplos de ejecución: docker run --rm -it -v $(pwd):/catastro egofer/catatom2osm catatom2osm 17072 docker run --rm -it -v $(pwd):/catastro egofer/catatom2osm git clone https://github.com/OSM-es/catastro-import.git

Desventajas:

1. Hay que indicarle la ruta completa y tiene que existir, o usar el directorio actual. El directorio actual es $(pwd) en linux, ${PDW} en powershell y %cd% en el terminal de w$.
2. El comando es mucho más largo, pero se puede meter en un script.

Obstáculos: Colocar un script en un sitio visible y modificar el path también es una tarea compleja. ¿Empaquetamos un setup.exe para windows?

Oportunidades: El script ofrece la oportunidad de hacer otras cosas, como actualizar la imagen del contenedor, o resumir las tareas repetitivas de git.

El problema de usar %cd% o ${PWD} según sea cmd o powershell, se resuelve teniendo dos scripts: catatom2osm.bat y catatom2osm.ps1. Al hacer la llamada sin la extensión, se prioritiza el correspondiente en cada caso.

Las llamadas a este script podrían ser: catatom2osm update --> docker pull egofer/catatom2osm catatom2osm 17072 --> el script hace la llamada al catatom2osm dentro del contenedor.

[Crashillo]

Yo la verdad es q últimamente estoy usando bastante docker, y me resulta más cómodo el comando docker run que usar el docker-compose ya que este te pide otra instalación a través de python para el script, por lo que son más pegas para el usuario final (el CLI-fóbico)

Luego, lo de los volumenes, muy de acuerdo. Como ya digo los dockers que suelo usar ya SIEMPRE configuran una carpeta de datos-v data:/data o algo así, para compartir información. No se me había ocurrido que te ahorrarías el docker cp, lo cual es más cómodo. Sobre este tema además hay una serie de parámetros que suelen venir siempre en los contenedor, para más ejemplos puedes echar un ojo a https://fleet.linuxserver.io/, si entras en cualquier imagen y vas a la pestaña de Container info verás ejemplos de qué parámetros usar, como timezone, user permissions, etc...

Por otro lado, docker permite ejecutar en máquina, docker exec <container> ls -l por ejemplo, por lo que si hubiese un script exterior, existe la posibilidad de empaquetar ambos comandos, el docker run con volumen de carpeta actual + docker exec catatom2osm catatom2osm <ID> (donde el primer catatom2osm es el nombre del contenedor, y el segundo el ejecutable de la máquina).

Y luego respecto a la actualización de elementos, yo uso el contenedor watchtower q te gestiona las actualizaciónes de manera comodísima. Lo recomiendo para gente acostumbrada a usar docker, pero para el resto lo veo demasiado overkill, serviría con preguntar en el script si el contenedor tiene la última versión.

[javiersanp]

Lo que comentas es un volumen va bien para compartir información entre contenedores en ejecución, pero a la larga para sacar los archivos de dentro tienes que usar "bind mount" es decir, montar un enlace a una carpeta externa, o los comandos para copiar archivos de docker.

El exec es para mandar un comando a un contenedor que esté en funcionamiento. Mi idea sería levantar el contenedor en cada ejecución y eliminarlo después --rm. El watchtower no sería necesario en este caso. El script puede actualizar la imagen antes de crear el contenedor.

[Crashillo]

No sé si te estoy entendiendo, pero diría que hablamos de lo mismo. ¿No es posible lo siguiente?:

// arrancas la imagen sin entrar a ella,
// linkando tu carpeta actual a la carpeta home habilitada, que es /catastro
docker run egofer/catatom2osm -v $(pwd):/catastro

// ejecutas el programa con el ID que toque,
// como está linkada con tu carpeta, los archivos se generan en tu $(pwd)
docker exec egofer/catatom2osm catatom2osm 39088

// paras y borras contenedor e images (prune)
docker stop egofer/catatom2osm && docker rm egofer/catatom2osm

[javiersanp]

Todo eso se puede hacer en una sola línea

docker run --rm -it -v $(pwd):/catastro egofer/catatom2osm catatom2osm 39088

[javiersanp]

Hay que ver como integrarlo con #60

[Crashillo]

Las variables de entorno las puedes pasar con -e LANG=XX igual que -v

[javiersanp]

Si, sería algo así como -e LANG=$(LANG).

[javiersanp]

Idea: el usuario lanza el acceso directo a un script, este abre una terminal con un contenedor del programa en ejecución

https://stackoverflow.com/questions/9392874/bat-file-open-new-cmd-window-and-execute-a-command-in-there#11393481