sábado, 10 de agosto de 2019

Cuando Docker se descontrola, toca tratar de lidiarlo.

No soy partidario de Docker, eso ya lo sabéis y conoceréis más en unos días. No obstante, hay veces que no queda más remedio que hacer algo que no ves ideal. Por ejemplo, hoy en día es bastante frecuente ver cómo se dockerizan -sin sentido- aplicaciones en producción, lo que es un atentado total. Y hay veces que se dan problemas que tenemos que entender muy bien. Hoy vamos a ver 2 pequeños fallos que pueden ocurrir, uno que es inexplicable el por qué sucede (en realidad sí se puede explicar, pero requiere ser crítico) y el otro que es una tontería y tiene fácil solución pero que nos puede dejar pillados por un momento si no lo hemos visto antes.


El primer fallo es realmente una tontería, y es que simplemente cuando dockerizados una aplicación con gunicorn+ Django + nginx + mariadb (por ejemplo), puede que, cuando abramos en el navegador nuestra web, la veamos pero sin el css ni los js en caso de utilizarlos. Esto es muy simple.

ls -ltrah data/gunicorn/static
total 32K
drwxr-xr-x 4 root root 4.0K Aug  6 13:13 ..
drwxr-xr-x 6 root root 4.0K Aug  7 07:51 rest_framework
drwxr-xr-x 5 root root 4.0K Aug  7 07:51 admin
drwxr-xr-x 2 root root 4.0K Aug  7 07:51 js
drwxr-xr-x 2 root root 4.0K Aug  7 07:51 images
drwxr-xr-x 2 root root 4.0K Aug  7 07:51 fonts
drwxr-xr-x 8 root root 4.0K Aug  7 07:51 .
drwxr-xr-x 2 root root 4.0K Aug  7 07:51 css

Imaginemos que tenemos una aplicación en Django. Pues en la carpeta data/gunicorn, necesitaremos tener los static, siendo estos los js, las imágenes, las fuentes y el css. Pues lo que vendría a ocurrir es que, esta carpeta no la tendríamos. Podemos darnos cuenta de esto si, dentro de la carpeta del proyecto escribimos:

docker-compose logs

Para solucionar esto es muy simple, basta con ejecutar esta línea.

docker exec -it cont_gunicorn_1 python manage.py collectstatic

Tan simple como ejecutar, dentro del contenedor, el manage.py y solicitar los estáticos. Tras esto, si recargamos la página ya deberíamos verla correctamente. Ahora pasemos al otro fallo que es más absurdo y que llevó un tiempo darse cuenta de este cuando me ocurrió.

Docker no es amigo de las bases de datos.

Como sabéis, cuando creáis una imagen de Docker, no basta con eso, tenéis que crear también unos volúmenes si queréis conservar los datos que almacenéis. Esto se debe a que Docker no es nada amigo del almacenamiento. Esto que quede claro.

Resulta que, a veces, si pasas los frm, MYD y MYI a la carpeta data/mysql/proyecto de la máquina antigua a la nueva que quieres migrar por ejemplo, a veces eso funciona y a veces no.

A veces, cuando lanzas

docker-compose up --build -d
docker-compose logs

Funciona todo sin problemas, y otras veces te dicen que hay tablas que no existen. No problema:

docker exec -it cont_mysql_1 bash

Entramos al contenedor del mysql y escribimos

mysql -u [NUESTO USUARIO] -p

Escribimos nuestra contraseña y entramos. Una vez ahí

use [NUESTRA DB];
show tables;

...¡Y vemos la tabla que dice que no existe! Pero Docker no lo termina de pillar bien porque, como hemos dicho, Docker no es amigo del almacenamiento ¿Solución? Hacerlo de la forma artesana y como en realidad es la más correcta.

docker exec -i cont_mysql_1 mysql -u[user] -p[PASS] [DB] < [dump]


Y así sí que nos lo debería de pillar sin problemas, aunque Docker, aunque muchos desarrolladores y managers no quieran verlo, es inestable, por lo que siempre tienes que estar esperando el fallo. A menos que desarrolles una aplicación bien, pero bien de verdad y no con Docker en PROD.

¿Hackeamos el mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...