Docker trabaja con imagenes, una imagen contiene un sistema base (una debian por ejemplo) con todo lo que necesitas para ejecutar tu aplicacion ya instalado.
Las imagenes son de solo lectura, asi que la arrancas y todo lo que hagas dentro se pierde cuando la reinicias.
Las imagenes son portables, yo puedo hacer una imagen en mi maquina y funciona exactamente igual en la tuya.
Una imagen (.tar) con el sistema instalado dentro y algo de metadatos; se define en un fichero llamado **Dockerfile** (script) que lo usamos para generar la image.
Una imagen se puede basar en otra imagen, por ejemplo ese Dockerfile usa 'registry.sindominio.net/debian' como imagen base.
Otra imagen podria estar basada en esta y asi sucesivamente.
Es decir que podemos tener un arbol grande de imagenes unas basadas en otras, de forma que usamos el sistema instalado de una imagen para construir la siguiente.
1.) En el **script** vemos diferentes infos, como ‘from’:
Si haces un **debootstrap** [debootstrap es una herramienta de debian para generar un sistema de ficheros con debian instalado, por ejemplo se usa para montar chroots, a debootstrap le das una carpeta y te monta un debian dentro] y lo metes en un tar es muy parecido a lo que es una imagen de docker.
Un comando muy importante es el **run**, que es el que junto con **copy** y **add** (para otro dia estos dos), usamos para poner lo que necesitamos en la imagen.
docker run lo que hace es descargarse una imagen ya generada
Lo interesante de las imagenes es que no solo son de solo lectura, sino que se componen de 'overlays' (capas) asi que la imagen registry.sindominio.net/debian es una capa y cuando haces el run hace otra capa y asi sucesivamente.
De tal forma que en una maquina donde tengamos 50 imagenes, pero todas usen registry.sindominio.net/debian esa capa solo esta una vez instalada, imaginate un monton de ficheros .tar (uno debian.tar, otro foo.tar,…) y cuando ejecutas la imagen lo que hace es primero descomprimir debian.tar luego encima de debian.tar descomprime foo.tar y asi sucesivamente.
**Todo eso lo pone en modo solo lectura y te pone otra capa encima donde puedes escribir pero se pierde cuando paras la imagen**
Por terminar de explicar ese dockerfile que he puesto de ejemplo **entrypoint** es el comando que se ejecuta cuando arrancas la imagen
una imagen docker no es como una debian que tiene muchos procesos corriendo, lo normal es que solo tenga un programa, y este es el que pones en entrypoint y **cmd** son los parametros que le pasas al entrypoint [linea 8 del Dockerfile]
[[momento en que entramos en la maquina donde jugaremos, compartimos terminal y descargamos la imagen git clone https://git.sindominio.net/estibadores/registry
y meskio propone en otro momento contarnos como se genera la imagen de debian, que es mas complicado]]
recordar **el punto (.)** del final para decirle que quiero buildear el directorio en el que estoy
si ves los steps basicamente son cada linea del Dockerfile ha sido muy rapido por que ha usado la cache, que esta misma imagen ya la tengo generada en esta maquina y no ha tenido que ejecutar apt de nuevo
ahora si haces docker images veras tu imagen en el listado de imagenes que hay en el docker daemon de esta maquina. Con less o con grep por si hay mucha basura.
***Los contenedores por defecto estan aislados, no pueden ni acceder al disco duro, si que pueden comunicarse por la red, tienen acceso a internet, pero no pueden abrir puertos.
Y como son de solo lectura cuando los apagas se pierde todo lo que hayan hecho***
docker-registry (que explicare luego lo que es) usa por defecto el puerto 5000
en la maquina en la que estamos el puerto 5000 ya esta ocupado, asi que vamos a decirle a docker run que cuando lance el contenedor el puerto 5000 de dentro del contenedor lo mapee al puerto 5005 de la maquina en la que estamos.
para eso le añadimos un -p 5005:5000 al docker run
Los volumes es como llama docker a dejarle acceder al contenedor a una carpeta o fichero de fuera del contenedor
En plan para poder copiar cosas de esa carpeta o fichero, asi que el puerto es la manera que docker se abre al exterior, como los puertos del server, y los volumenes son con los que comparte cosas.
Para que cada vez que pares el contendor los datos no se pierdan.
Para montar una carpeta de fuera del contenedor dentro y que pueda escribir cosas que se guarden entre reinicios docker-registry guarda cosas en **/var/lib/docker-registry**
4.) Vamos a aprender a **subir** tu imagen test1 ahi. Hasta ahora todo lo que hemos hecho es en **local**. Las imagenes solo existen en esta maquina y nadie mas tiene acceso a ellas, la forma de compartir imagenes es usar un registry
Ahora si miras en /tmp/test1 veras que el contenedor ha creado cosas ahi, basicamente la imagen que has subido y ahora que la imagen esta en el registry cualquiera puede descargarla y ejecutarla con:
Si os fijais registry.sindominio.net apunta a esta misma maquina https://git.sindominio.net/estibadores/registry <acadentrohayunarepoquesepuededescargarconwget
Si ponemos **always** docker se encargara de volver a lanzar la imagen si por alguna razon muere, lo mismo que el **systemctl restart** sirve para pasar variables de entorno, si hay mucho mas que se puede poner en **docker-compose**, pero con esto esta lo basico.
[Complicandose el tutorial: Se pueden poner en un solo fichero multiples imagenes y coordinar cosas como puertos que necesita una imagen para cominar con otra y cosas asi
pero esto lo tengo en pendientes de aprender mas para servicios complicados, donde necesitas multiples imagenes puedes coordinarlas asi; por ejemplo lanzar una base de datos, hacer que se comunique con otra imagen que corre php y una tercera que tiene nginx. Por ejemplo un wordpresss necesitaria un nginx, un php-fpm y un mariadb. Todo eso se pondria en el docker-compose.]
La idea del CI es que definimos nuestras imagenes en git.sd.net y automaticamente se buildean y aparecen en nuestro registry ahi hay un par de graficos de como funciona:
Podemos ver que hay en http://178.32.130.81:9000/hooks/build_image cada vez que cualquier repositorio de ese grupo tiene un comit gitea hace una conexion http con http://178.32.130.81:9000/hooks/build_image
Esa conexion http la recibe un servicio que hay en castiello si veis hay un paquete instalado llamado **webhook**
Este es un pequeño demonio (webhook- apt show webhook) que escucha conexiones http y lanza comandos dependiendo de lo que le envian por ahi en **/etc/webhook.conf** esta la configuracion
Ejecuta el comando **"/usr/local/bin/build_image"**
Gitea le hara una entrega por defecto http POST a esa url con un json (fichero estructurado), nosotros sacamos el nombre del repo de ese json [es un formato para estructurar datos, el fichero de configuracion webhook.conf que estamos mirando esta en json]
No esta en debian todavia, espero que entre pronto y si no a ver si le puedo meter un empujon. Laminar es un CI minimo, todo lo que hace es gestionar colas de tareas. Laminar es un demonio al que le dices ejecuta esto, y si el resto de tareas han termininado lo ejecuta. L web que tiene es de solo lecutra, osea no puedes mandarle ordenes por la web, asi que laminar lo soluciona. La idea es montar algo seguro que no sea facil de penetrar, por que esta es la maquina que genera todas las imagenes y la seguridad de sindominio depende de ella.
laminar es un demonio que ejecuta los trabajos que le decimos y en esa interfaz web muestra el resultado de los trabajos. laminar, se compone de un demonio que acepta tareas que ademas incopora un interfaz web para visualizarlas build_image es una de las tareas que tengo definidas en laminar. piensa en laminar como un duende que le dices ejecuta este escript y lo ejecuta y ademas te lo muestra en una web
la idea es que no necesitemos confiar en gitea, cada comit que hacemos en estibadores deberia estar firmado y si no lo esta laminar no buildea la imagen asi si gitea esta comprometido no nos pueden meter una imagen malefica.
tienen que comprometer nuestras maquinas donde tenemos nuestra clave gpg suena facil, pero hay algo de miga laminar se ejecuta con el user laminar [[(como el user ftp) laminar es un demonio, podrias configurarlo para ejecutarse con el user que quieras, aqui esta configurado para usar el usuario laminar esta instalado del paquete debian que da upstream que lo configura asi]]
Recordais que las imagenes pueden depender unas de otras de tal forma que tenemos un arbol de imagenes en el Dockerfile la primera linea suele ser image debian por ejemplo pero podriamos tener una imagen php que depende de nuestra imagen debian y una imagen nextcloud que depende de la imagen php
Cada vez que buildeamos una imagen puede que tengamos otras imagenes que dependan de esta imagen y que queramos rebuildear tambien. Si rebuildeamos la imagen debian deberiamos rebuildear todas las imagenes que usan debian como imagen base pues eso es lo que hace update_images mira en el registry que imagenes dependen de la imagen que acabamos de construir y las rebuildea
basicamente le dice a laminar que lance el trabajo build_image para esa imagen,
build_image es un script en /usr/loca/bin que tambien usa webhook para lanzar la tarea de buildear una imagen en laminar
Cuand buildeamos la imagen debian mirara en el registry y vera que hay que rebuildear php y cuando buildee php mirara en el registry y vera que hay que rebuildear nextcloud asi podemos rebuildear la parte del arbol de imagenes que hace falta … recorre toda la rama.
base_image este es el que buildea la imagen de debian. Esta es especial y no la puedo buildear desde un repo usa debuerrotype, que es lo que usa la gente de debian para generar las imagenes de docker oficiales es como un debootstrap pero que genera un tar reproducible no hace falta que entendamos los detalles!!
“Simplemente” hace un debootstrap y usa docker import para generar una imagen 'from scratch'
La idea es no depender de la imagen que hay en dockerhub Asi que esto buildea la ultima version de debian stable scratch == de la nada. Generar una imagen docker que no viene de otra imagen.
si veis en la **linea 18 tambien llama a update_images** asi cuando se genera una nueva imagen debian regenera todas las imagenes que dependen de ella.
este es un poco tonto, todo lo que hace es llamar a un script que esta en los scripts de laminar, check_updates lo que hace es comprobar si hay actualizaciones de algun paquete dentro de la imagen
basicamente hace un docker run apt update y mira si hay algo para actualizar
