Estamos entrando a la sección seis del curso, la cual es sumamente importante porque vamos a empezar
a tocar temas de en multi stage.
Bill Qué quiere decir esto?
Bueno, básicamente el multi Stage field nos va a ayudar a nosotros a queríamos.
Teníamos todo este código y este código es lo que nosotros hemos estado creando nuestra imagen basado
en nuestro Docker Field.
Pero qué pasaría si realmente, o lo que hemos visto hasta el momento, es que solo este sector de la
aplicación es para controlar o crear las dependencias?
OK, las dependencias de desarrollo, las dependencias que ocupamos para construir la aplicación estas
de aquí únicamente es para el testing y este pedacito de aquí es para hacer el Bill, por ejemplo.
Y al final el mero mero mero final únicamente es para correr la aplicación que nosotros ya tenemos.
O sea, decir este es el paso final.
Pero si un cambio sucede, por ejemplo en la dependencia, digamos un pequeño cambio sucede aquí.
Entonces todo lo que sigue después de esa, de ese pequeño cambio, se tiene que volver a reconstruir,
tiene que volverse a evaluar, tiene que volverse a ejecutar.
Y a pesar de que lo que nosotros tenemos únicamente en esta sección del testing no ha cambiado.
De igual manera se va a volver a reconstruir y eso reconstruye el siguiente paso y se reconstruye.
Siguiente paso y así sucesivamente.
La idea de el multi state o multi stage técnicamente es multi stage en el nombre oficial usted lo va
a encontrar como multi stage, pero en varios lugares se lo van a ver como un state.
Pero bueno, no importa.
State State State es el nombre oficial que le he dado.
Queda en la documentación oficial.
Hoy también lo pueden encontrar, pero la idea es que nuevamente nosotros tenemos nuestro código aquí,
que este es la construcción total de nuestra aplicación.
La idea es que tomemos este pequeño, este pequeño bloque de instrucciones o el que ustedes necesitan,
y vamos a empezar a crear unas pequeñas imágenes temporales.
Podríamos verlo de esta manera Estas imágenes temporales van a realizar una tarea y hacerla bien.
Por ejemplo, este bloque que tenemos aquí solo van a ser para las dependencias y voy a ponerle todas,
todas las dependencias.
Entonces todas esas dependencias caen ahí.
Si la única dependencia que nosotros o que esa imagen va a tener de nuestro código en este caso sería
el package JSON.
Ok, digamos sólo para un ejemplo.
No importa si ustedes saben o no saben.
No, no importa.
Pero este paquete JSON es un archivo que le dice a nuestra aplicación en Y sabes qué?
Hubo un cambio en alguna dependencia, algún procedimiento?
Entonces únicamente si ese archivo cambia, entonces reconstruye la imagen.
Caso contrario, maneja ese layer, o sea, va a crear, va a empezar a crear leyes o todos lo que vaya
creando sus leyes para construir esa imagen.
Entonces, si las dependencias no cambian, si no teníamos ninguna modificación al JSON, entonces no
tiene que hacer absolutamente nada.
Entonces lo siguiente nosotros vamos a tener aquí nuevamente, vamos a tener otro stage en el cual nos
va a servir a nosotros para en este caso ejecutar el balde de producción y el testing, aunque realmente
sería primero el testing y luego el paint.
Por ejemplo, ya vamos a crear una aplicación internamente que usan diferentes estrelles y ustedes van
a ver cuál es el objetivo del mismo.
Entonces con el BID y el testing nosotros podemos definir OK, si hay cambios en el código, usualmente
están en el mismo lugar, porque si hacemos algún cambio que requiera hacer un video, tenemos que hacer
el testing.
Por eso es que usualmente yo prefiero tener estos dos en conjunto, porque puede ser que ningún archivo
de testing cambió, pero sí cambió nuestro código.
Entonces es relativo.
Por eso prefiero tener el bille y el testing.
Pero esto puede ser algo subjetivo por persona.
Entonces, cuando nosotros hacemos algún cambio en nuestro código y hacemos algún cambio en la parte
del testing, lo vuelvo a revisar y que se vuelva a construir.
Pero si no hay ningún cambio ahí, todas estas imágenes van quedando en caché para que eso de ellos
sean reutilizados.
Y luego tenemos otro paso en el cual podríamos decir OK, en este paso nosotros vamos a únicamente ejecutar
las dependencias de producción.
Pero dependencias.
Y el paso final o el paso final que tenemos aquí va a ser la construcción ya propiamente de la imagen.
Voy a poner aquí la imagen propiamente de eso, o sea, de nuestra aplicación corriendo.
La idea es que cada uno de estos layers o estas imágenes que estamos creando temporales, que son imágenes
temporales, nos van a servir a nosotros para poder compartir información entre sí.
Es decir, aquí cada una de estas de de esta, de ésta, de esta y de esta.
Cada una es independiente y totalmente aislada y cada vez que yo levanto una de esas imágenes no conocen
nada del paso anterior.
Eventualmente, digamos que en la parte de las dependencias de producción o en las dependencias de desarrollo,
yo puedo tomar este pedacito de código que es generado dentro de esa imagen en proceso de construcción
y moverla acá.
Y mover sólo lo que yo necesito y olvidarme de todo lo anterior.
El objetivo de esta imagen sólo va a ser una tarea en específico, en este caso cargar todas las dependencias.
Esas dependencias caen en un módulo de NOD que yo ya nosotros vimos y esos módulos no son los que nosotros
movemos a la siguiente etapa, pero en la siguiente etapas dice es el Bill y el testing el objetivo
del build.
Y obviamente el testing testing es obviamente probar la aplicación, pero el objetivo del video es que
nos cree nuestra carpeta de distribución.
OK va a crear nuestra carpeta de distribución en el cual tiene todo el código fuente.
Ese código fuente lo voy a ir a meter acá, o sea, lo hubiera insertar ahí el producto del Bill, lo
muevo ahí y todas las dependencias de producción que están acá también.
Esa dependencia las voy a colocar aquí.
Yo puedo mover lo que yo necesite entre etapas, pero específicamente yo tengo que decirle qué es lo
que quiero mover, porque por defecto cada uno de estos detalles que nosotros vamos creando, por ejemplo,
este es el vamos a crearnos el primero aquí.
Entonces tenemos nuestro primer paso, luego nuestro segundo paso, luego nuestro tercer paso.
Y digamos que este es el 4.º paso y por último el 5.º paso.
Entonces cada uno de esos pasos es totalmente independiente.
Sus estrelles son independientes y son imágenes como tal completas.
Entonces, entre esta, esta etapa y esta etapa, si yo no especifico nada, no se comparte nada.
Lo genial que también vamos a hacer es que pudiera ser que tenemos una imagen en particular, digamos
de la la cero, la cual es puramente desarrollo, que tiene un Binding mouse para tener nuestro código
enlazado con el del contenedor.
Y todo esto lo podemos tener en el mismo Docker File.
El mismo toque final.
Todo esto lo podemos tener en mi nuevo perfil y yo puedo especificar solo ejecuta esto en desarrollo,
pero cuando ya lo hacemos en producción, ejecuta todos los pasos para construir mi imagen final.
Puedo hacerlo así o vía este.
Todo eso lo vamos a empezar a trabajar en esta sección, pero el multi stage tiene como objetivo que
nosotros podamos ir creando etapas para la construcción final de la imagen que nosotros queremos.
Es súper genial, es bastante utilizado, especialmente en aplicaciones en las cuales nosotros tenemos
que realizar acarreo de ciertos de ciertos paquetes anteriores, que eso fue un problema que nosotros
tuvimos que hacer en la sección anterior, removiendo los módulos de nuevo y volviéndolos a instalar
pero únicamente de de producción después de haber realizado el testing.
Ese es el objetivo de la sección Aprender a crear nuestros propios testing, nuestros propios vill,
nuestros propios runners, es decir, nuestros propios stages, para que hagamos la aplicación que nosotros
estamos esperando y al final exportar una única imagen, la mejor, lo único que nosotros realmente
necesitamos para correrla.
Que no tengan nada, nada, nada de basura.
Y eso es lo que vamos a hacer en esta sección.