Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
De la misma manera que tu aplicación, cuando tiene bastante tráfico, cuando hace procesos fuertes, requiere de bastantes recursos, de esa misma manera, cuando tu build toma mucho tiempo porque hace muchos llamados o procesos complicados, también necesita recursos, también necesita una infraestructura donde tiene que correr. Y me gusta que decís que con GitHub Actions o con cualquier otro que
utilizado el CI-CD que has trabajado se vuelve abstracto para vos todo lo que hay detrás de la infraestructura y de eso se trata, de eso se trata la cultura DevOps que lo que estamos en la parte de sistemas o operaciones empoderemos a los programadores.
Hola a todos y bienvenidos a un episodio más de Dev & Ops, su podcast favorito donde hablamos de temas de desarrollo, tecnología y DevOps en general, todo lo que incluye su cultura. Y como siempre, acompañado de mi gran amigo Juan Ramos, a quien le doy la bienvenida a un episodio más. Juan, ¿qué tal estás hoy?
Juan (01:03)
Hola Douglas muy bien. Aún recuperándome un poco sobre la gripe que me ha azotado. Estas épocas de entre diciembre y enero para mí siempre han sido complicadas toda la vida. Pero bueno, estamos con la actitud para la plática del día de hoy. Creo que va a ser muy interesante.
Douglas (01:23)
Sí, es lo que cuenta aquí ahorita Juan la actitud de estas épocas, como lo decís, nos afectan bastante los episodios anteriores. Yo era quien estaba un poco mal de salud. Ya me recuperé por gracias a Dios y en estos episodios que hemos grabado, tu situación es la que ahora se ha empeorado un poco, pero me alegra que estés lo suficientemente bien como para que tengamos esta plática hoy, sobre todo porque la plática de hoy, Juan, me parece a mí a nivel personal que es muy interesante y que va a ser de mucho valor.
Juan (01:39)
No,
Douglas (01:54)
para personas que están en el área de sistemas, en el área de SRE, DevOps, como le dicen, al igual que para desarrolladores. Y es que vamos a continuar, que hemos tocado en temas recientes, lo que son los CI-CD pipelines, Y en esta ocasión quisiera que habláramos un poco de lo que es el esqueleto de un CI-CD pipeline de la infraestructura.
que hay alrededor de un CI-CD pipeline. Y por qué este me parece un tema interesante Juan, yo recuerdo que cuando recién iniciaba yo a incursionar en lo que tiene que ver CI-CD, inicialmente sin ponerle mucha mente yo creía que instalaba Jenkins en una VM y listo, ya funcionaba todo, ¿no? Porque pues si vos mirabas un tutorial alguien instalaba Jenkins y te hacía una pruebita de algo y a correr un pipeline y listo.
tenía que trabajar en la implementación, me daba cuenta que había mucho más realmente detrás de una simple instancia corriendo Jenkins en ese momento en particular.
Hoy en día, Juan, mucha gente ve que en GitHub solo le da click a la pestaña de actions y empezás a ver cómo corre su action y qué es que está haciendo y nos parece tan simple, Y creemos que porque es un servicio de nube, empresa probablemente no tiene requerimientos que impliquen que yo levante infraestructura y la conecte a GitHub para...
que mi pipeline pueda funcionar. O lo mismo si usas GitLab en la nube o cualquier otro servicio. En realidad, que conceptualmente lo que tiene el CICD, un esqueleto y lo mínimo de infraestructura alrededor de ello, conceptualmente es prácticamente lo mismo. ¿Verdad? Entonces, medio habíamos hablado un poco de estas cosas, Juan, pero ¿sabías vos, me gustaría que nos menciones un poquito de eso, sabías vos como developer que realmente la infraestructura de lo que
tiene que ver tu sistema de CI-CD es tan grande y es tan segmentada y descompuesta y de la misma manera que un cluster segmenta, perdón que una aplicación separamos en capas que la base de datos, que el cache, que la aplicación, ¿sabías que estaban así los diferentes elementos de un CI-CD pipeline? porque lo mismo ocurre te voy a decir si instalas por ejemplo GitLab ocupas una base de datos, ocupas redis para cache, ocupas los servidores de enfrente
Juan (04:08)
Mm-hmm.
Douglas (04:25)
que están sirviendo el contenido aparte de los demás elementos entonces sabía vos me gustaría bastante saber tu perspectiva en tu experiencia como developer con respecto a esto
Juan (04:39)
Hoy en día tengo un concepto un poco más grande sobre todo lo que sucede en el CI-CD Pipeline. No pretendo decir que sé perfectamente cómo funciona todo porque hay muchas cosas que suceden en una capa de abstracción a la que no tengo acceso, ya sea en mi trabajo porque no tengo las llaves para entrar a esas partes de toda la infraestructura.
o porque tal vez estoy utilizando GitHub Actions y ya me dan esta abstracción por la cual estoy muy contento, la verdad es que es algo muy bueno. Ya lo decíamos en unos episodios anteriores que es algo que ha venido a darles un nivel introductorio a nosotros los desarrolladores para poder involucrarnos en lo que es el ciclo de la aplicación, el deployment, testing y todo. Al inicio...
recuerdo mis primeras impresiones de Jenkins yo lo miraba como algo bueno esto era la pieza de software más increíble que yo había encontrado porque todas las funcionalidades que tenía sin embargo sí tenía la misma percepción como lo que acabas de relatar donde pues instalaba Jenkins y listo obviamente eran era un proyecto muy muy
simple por decirlo de alguna forma, así que en teoría era suficiente pero pues nunca me puse a pensar en cómo podría evolucionar más allá de eso, no tenía el acceso a un sistema tan grande y luego cuando fui llegando a diferentes empresas y a diferentes lugares pues dependiendo del lugar los proyectos eran... cambiaban, ¿no? he visto partes donde el pipeline es gigantesco
y tiene muchas capas, o sea sé que tienen las capas y las diferentes secciones, pero realmente no sé cómo están diseñadas ni cómo funcionan. Y también he visto la otra parte donde el pipeline es generar el build en tu computadora y compartir ese ejecutable ⁓ o esa compilación a otro departamento y lo publican a todos los clientes.
Entonces he visto un poco de los dos lados, pero sí, la verdad es que sé que crear un pipeline bastante eficiente, robusto y que sea extensible definitivamente es un trabajo que lleva mucho tiempo y requiere mucha experiencia, definitivamente.
Douglas (07:23)
Sí, no, mira, por supuesto, algo que es extenso y que tarda, consumir recursos. De la misma manera que tu aplicación, cuando tiene bastante tráfico, cuando hace procesos fuertes, requiere de bastantes recursos, de esa misma manera, cuando tu build toma mucho tiempo porque hace muchos llamados o procesos complicados, también necesita recursos, también necesita una infraestructura donde tiene que correr. Y me gusta que decís que con GitHub Actions o con cualquier otro que
utilizado el CI-CD que has trabajado se vuelve abstracto para vos todo lo que hay detrás de la infraestructura y de eso se trata, de eso se trata la cultura DevOps que lo que estamos en la parte de sistemas o operaciones empoderemos a los programadores.
Sin embargo, interactuas con toda esta infraestructura, Juan, sin darte cuenta. E incluso la puedes personalizar un poco, esta infraestructura y estos servicios, a veces sin darte cuenta que es otro servicio. Entonces, si te parece, comencemos con...
con los diferentes, quiero tocar cuatro elementos de la arquitectura de un CI-CD pipeline que están, en mi opinión esos cuatro elementos van a estar en el 90 % de un pipeline, bueno algunos de ellos van a estar en todo pipeline, verdad, pero los cuatro en general juntos.
Juan (08:34)
Ok
Douglas (08:45)
están en la gran mayoría. alguna gente no le gusta que me invente porcentajes porque pues sí me los invento, lo que trato de hacer es una ilustración de que la gran mayoría, la gran mayoría tienen eso, porque me invento un porcentaje de mi experiencia más no una estadística. Quiero aprovechar a hacer esa aclaración.
Juan (08:52)
jajaja
un 89.3
%
Douglas (09:08)
89.44
sí. Entonces el primer elemento Juan son los runners ¿Verdad? ¿Qué son los runners Juan?
Juan (09:17)
Ok.
Douglas (09:20)
es donde corren tus jobs de CI-CD, donde corren tus trabajos, como se le dice en español, de CI-CD. Ocupas un servidor que corra el script de build, ocupas un servidor que corra los unit testing, ¿verdad? Ocupas de la misma manera como en tu local corres el comando de build, de la misma manera como corres los tests en tu local.
ocupan un sistema donde tienen que correr y son los runners. ¿De qué manera interactúas con ellos? Cuando en tu GitHub Actions vos decís, runs on y dice Ubuntu latest. Entonces si te has fijado que la mayoría de GitHub Actions dicen eso, ahí estás seleccionando un runner que te da GitHub en la nube, ese runner está en la nube, y es una máquina virtual con Ubuntu.
Juan (10:03)
Ok, sí.
Douglas (10:16)
una versión Leres de Ubuntu que tienen ellos con un montón de herramientas pre-instaladas.
Juan (10:22)
Sí.
Douglas (10:22)
mira
porque aquí los runners son importantes estos runners que te da Keysoft Actions tienen un montón de herramientas pre-instaladas y software pre-instalado para que la mayoría de flujos de trabajo de builds en su gran mayoría y hace ahí casi todo sin embargo si has hecho un pipeline que requiere de Node.js por ejemplo en tu Keysoft Actions tienes un step donde estás instalando Node primero no sé si te has percatado de eso espero que muchas personas que no vengan no se escuchan si se hayan percatado
de ello, primero configuran el GitHub Action y perdón, instalan Node.js antes de correr su build, instalan npm, lo que van a necesitar ⁓ o si ocupas conectarte de manera segura a algún lugar, primero tal vez bajar los keys por medio de secrets a que estén en tu runner, que estén en esa máquina virtual que acaba de crearte GitHub Actions para darte que corras ahí, primero
Juan (11:02)
Sí.
Douglas (11:22)
las copias del SSH key, lo que sea, para que luego se conecte, verdad, y esos son los runners, máquinas fuera de donde está corriendo la aplicación, en este caso de GitHub como tal, eso es la nube de Amazon, pero es un servidor fuera.
Si vos tenés un Jenkins, que es lo que tal vez la mayoría le ha tocado interactuar en mantener de manera directa, a mí me ha tocado mantener Jenkins inicialmente, hoy en día me toca manejar varios servidores de GitLab, que no son servidores solo, sino que tienen diferentes componentes.
también en GitLab pero quienes han trabajado con Jenkins saben que en una instancia o en varias si tenés high availability instala Jenkins y luego tenés otras instancias que vas agregando que son los runners verdad, Jenkins tienen otro nombre pero son los runners que es donde se va a ejecutar ¿por qué pueden?
Juan (12:16)
Osea, un runner
viene siendo como un servidor, una instancia donde su único trabajo es ejecutar las tareas que le estamos enviando. Por cierto, están los jobs y luego, trayendo la analogía o como es la sintaxis en GitHub Actions, están los steps. Entonces, un job es como un grupo de diferentes pasos a seguir, ¿no? Algo así lo podríamos ejemplificar para las personas que vienen empezando.
Douglas (12:28)
Exacto.
Sí.
Si un job es una serie de steps, o un trabajo, o una serie de pasos, ¿verdad? Y los pasos los puedes agrupar en etapas o en stages, ¿verdad? Y tienes una etapa de test.
Juan (12:56)
Ok
Douglas (13:01)
en un stage de test y en ese stage tenés el unit testing de un módulo de cobros y el unit testing de un módulo de usuarios y también tenés un regression test. Entonces son tres jobs que cada job, tres trabajos separados que cada trabajo llama diferentes pasos pero como están en un stage corren en paralelo.
Juan (13:09)
ok
Douglas (13:27)
o los trabajos paralelos que aguanta el verdad, corre en el paralelo y hasta que termina todo ese stage pasa al siguiente. Entonces eso te permite agrupar, verdad, pero es un runner, es donde corren estos trabajos.
Juan (13:28)
Sí.
Douglas (13:42)
¿Por qué ocupamos un runner, ya sea el que te da tu servicio de nubes, en este caso usas GitHub Action, pero por qué, aunque esté en GitHub Action, pudiera necesitar un runner personalizado? Mira, estos son los diferentes motivos. Uno de ellos puede ser que necesites que ya tenga pre-instalado todo lo que necesitas por motivo de tiempo. Sí, sí, sí, claro.
Juan (14:03)
Pero antes de eso Douglas,
¿por qué utilizar un runner aparte y no hacerlo en la misma instancia donde está Jenkins? ¿Por qué separarlo?
Douglas (14:13)
Bueno,
buena pregunta. Supone que tenés un, y te lo voy a responder así, supone que tenés un Jobs que están haciendo Build e instalando aplicaciones hechas en Golem. Luego tenés otro que está haciendo Docker files, sea Docker, perdón, Images. Luego tenés otro que está haciendo Build de aplicaciones de Node.js. Luego tenés otro Jobs que está haciendo Build de aplicaciones de PHP.
Entonces estamos contando cuatro diferentes tecnologías con diferentes requerimientos que tienen que estar todas instaladas en ese servidor aparte de Jenkins para que pueda existir el comando de Composer Install, para que pueda existir el comando de Docker Build, para que pueda existir el comando de Go Build, se llama el de Go, si lo recuerdo bien. Entonces tendría que tener todo eso instalado.
Juan (15:04)
Go build,
Douglas (15:09)
en la misma instancia peleando por recursos, peleando por dependencias, si quisieras que todo corra ahí mismo. Además, se te vuelve todo un single point of failure y de repente tenés esos 10, 12, 15, 20 jobs corriendo al principio, al mismo tiempo, perdón, y la instancia no aguanta y crashea y se vuelve un problema. Entonces, Lord Runners, me permite tener uno para Gollum.
y sus aplicaciones, me permite tener otro para Docker, donde van a ser Docker Build, puedo tener otro runner para PHP. Entonces, esa es la razón por la cual necesito runners que corran externos al lugar donde está instalado Jenkins, usando Jenkins como ejemplo. ⁓
Juan (15:51)
A mi me ha pasado eso
con mi HomeLab porque utilizo DocPloy y DocPloy da la opción para que los builds se hagan en un servidor pero se estén ejecutando en otro. Pero yo lo tengo todo en un solo servidor pequeño y pues a veces si estoy viendo una película y deja de funcionar porque se cayó el servidor. Todo, demasiados recursos y ya no pudo.
Douglas (16:15)
Exacto.
Y ese es estar ese es el problema y ahí te puedo sugerir algo a medida avancemos en la conversación si tenés una máquina aparte simplemente ponéle Docker y hacerlo como un runner con Docker y hacer los builds dentro de contenedores y de esa manera esa carga se va aparte.
Juan (16:35)
Ok
Douglas (16:35)
Pero
lo que acabo de responder ahorita es, ¿por qué necesitamos de manera general runners que estén fuera de lo que es mi servidor o servicio de CI-CD? O fuera de donde tengo instalado Jenkins o GitLab. Ahora voy a tocar ejemplos de por qué necesito runners.
Fuera de los que me da normalmente el servicio de nube, si tenés GitLab en la nube o si tenés GitHub Actions y en lugar de Runs On Ubuntu Latest ocupar un runner que yo necesite levantar en mi propio data center si tengo data center o en mi propia nube de Amazon o mi propia nube de Azure, donde sea.
¿Por qué podría necesitar eso? Porque ocurre más de lo que crees Juan, ¿verdad? Ese tipo de cosas. Una de ellas es para poder publicar o interactuar con aplicaciones que ya sea. Necesitan de información sensitiva, privada, que no querés compartir con secrets de otra manera o con accesos privados.
que ya están guardados en ese runner porque cuando me conecte, cuando tu servicio de CICD, tú que es un vaccines, se conecta ese runner, ya tiene credenciales para conectarse a donde necesita, no necesitas pasarle por medio de secrets porque las credenciales ya las tiene guardadas de manera local y no están guardadas en la nube. O.
también más común para accesar servicios que están de manera privada, que están en redes privadas que no pueden estar expuestos, que no le puede dar una IP pública, entonces ocupa que el runner esté ahí, para que luego de hacer el build como ya están en la misma red, de ahí no más haga el despliegue, de ahí no más haga el deployment. Y alguien puede decir, ¿y por qué no usas un jump host? Hay un concepto de jump host que es que tenés un servidor que está en una red.
Juan (18:27)
Ok
Douglas (18:29)
publica con acceso a internet y por medio de él te conectas a ese servidor y él hace proxy a tus servicios internos. Alguien puede decir, ¿por qué no solo usas un jump host, verdad? Para hacer ese tipo de, de, poder hacer despliegue. Y es que hay, hay, empresas que por cuestiones de seguridad interna necesitan que ese tipo de procesamiento pase en su red privada. No puede pasar en la nube aún un build.
de nuevo porque no pueden compartir ni siquiera un secret con ni siquiera un secret en la nube aunque esté guardado de manera segura, políticas, bancos piden mucho ese tipo de cosas y hay otro tipo de empresas con ese nivel, empresas gubernamentales tienen eso entonces es bastante común.
que ocupe hacer varios builds, verdad, en tu propia red privada o en tu propia nube para que desde ahí se hagan los despliegues. Y eso, se conectan, es fácil la conexión, verdad, pero se conectan y se vuelven parte de tu infraestructura de CICD. Otro ejemplo, puede ser, hay gente, ya lo he visto, hay personas que tienen sistemas bien legacy, por ejemplo, corriendo en la actualidad en Centro E7.
Entonces, si hacen build en versiones nuevas, hay dependencias que no les funcionan y el build tiene que pasar en Cento de Siete.
en ningún servicio de nube puedes crear una instancia con Cento E7 porque es súper vulnerable. en su data center privado han creado las VMs con Cento E7. Y entonces desde ahí el runner llama y hace el despliegue hacia ahí, ¿verdad? También hay otro motivo por el cual puede necesitar un runner que lo he visto bastante hoy en día es pipelines con procesos de machine learning que ocupan bastante de GPUs.
Entonces, si agarras eso directamente con los runners de GitHub Actions u otros runners, es súper caro. mejor pagan su propia instancia en la nube o mejor tienen eso en su data center y ahí crean esos runners para que se ejecuten esos procesos de CI que son bien fuertes, bien pesados en GPU para Machine Learning.
Juan (20:14)
⁓ sí.
carísimo.
Douglas (20:39)
entonces eso eso es otro y otra opción ya que está eso Juan, está runners efímeros que es bien importante por ejemplo si tenés Kubernetes, lo podés conectar un clóset de Kubernetes como runner y entonces a medida necesitas trabajo Kubernetes puede escalar y estarte dando pods que funcionan como un runner cada pod verdad y a medida deja esto es para para
Juan (21:04)
ok
Douglas (21:08)
sea y sea desconcurrido, ¿va?
Y a medida va dejando de usar runners, entonces va quitando los pods y por ende Kubernetes va desescalando, va quitando las réplicas. Y entonces de esa manera estás, no tengo 20 runners que uso el 60, 70 % del tiempo, pero el otro 30 % me están, están subutilizados y estoy perdiendo el dinero, mejor uso Kubernetes para que escale y desescale. Y eso por ejemplo lo hago yo en Fuel con una de las instancias de,
Juan (21:11)
Sí.
Douglas (21:40)
de GitHub que tenemos. un runner con Kubernetes porque realmente que tenemos muchos builds corriendo de manera concurrente en todo momento en nuestra instancia, ¿verdad? tener Kubernetes como runner nos permite esos runners efímeros ir agregando, ir quitando porque a medida va agregando pods, va agregando instancias y podemos tener builds de...
Juan (21:42)
Ok
Douglas (22:08)
builds de ARM verdad o builds AMD 64 y entonces los runners son esa pieza que se usa todo build usa un runner pero normalmente no nos damos cuenta verdad entonces si como programador alguien que es programador está teniendo tal vez su su su build ocupa más recursos entonces puede pedirle a la gente de sistemas que le den un runner con más recursos o pueden de repente pedirle a la gente de
que haga algo efímero que esté agregando y quitando. de nuevo, ya has interactuado con Runners One porque te ha tocado poner ese Runs On Ubuntu Latest, pero tenías la idea de que esas son las razones por las cuales muchas veces ocupamos Runners fuera de la nube.
Juan (22:58)
Bueno, tenía la percepción y el conocimiento de que a veces por motivos de seguridad y privacidad es necesario un runner en una red privada, pero no conocía los puntos más precisos y específicos que nos estás compartiendo. La verdad es que eso es algo que yo hubiese pensado que casi nadie utiliza, o no casi nadie, pero muy pocas veces se utiliza.
Sin embargo, lo que escucho entonces es mucho más común de lo que hubiese esperado. Sí he visto donde los utilizan diferentes runners y aquí tal vez estoy equivocado, pero esta es la manera en que yo lo recuerdo. Donde diferentes servicios o microservicios están agrupados por namespaces.
y esos namespaces o ciertos namespaces se ejecutan con otros runners, asumo, porque recuerdo que tenían diferentes recursos y no afectaban al resto del stack. Entonces asumo que probablemente esta es una de las formas en las que lograban organizar y administrar los recursos para que no se caer al sistema porque algo estaba utilizando demasiado y necesitábamos hacerlo en otros lados.
Muy interesante el concepto la verdad porque se escucha muy complicado. Se escucha bastante complicado para los que no tenemos experiencia. Pero para los que lo utilizamos, es una maravilla porque ya simplemente todo corre en lo que está ahí ya configurado y ya no me tengo que preocupar.
Douglas (24:40)
Y justo ese Juan es el takeaway como dicen o justo esa es la enseñanza para alguien que tal vez no está en la parte de sistemas, operaciones, que si tu build o tu deploy, verdad, tu despliegue tiene requerimientos específicos que parecieran extraños, normalmente se pueden resolver con un runner.
estratégico, ⁓ Y la enseñanza para las personas de sistemas es que pueden incrementar sus recursos o salvar sus recursos utilizando runners. Si están pensando en implementar un CI-CD pipeline o el proceso de CI-CD en general en su empresa, van a tener que interactuar con runners y configurar runners sí o sí.
Juan (25:22)
ahora una consulta, un runner tiene que ser específicamente una instancia porque mencionaste hace un momento lo de utilizar docker con contenedores o un runner puede ser un contenedor
Douglas (25:37)
un runner no puede ser un contenedor de manera directa pero si tu runner, si vos ponés que tienen algo que se llama executor verdad o el ejecutador del runner y vos le puedes decir que el ejecutador es en linux y corre un VM con linux y quiere decir que lo que va a hacer
lo va correr dentro de una terminal dentro de ese sistema operativo Linux, ¿verdad? Pero otro executor o ejecutador le puede decir que es Docker. Entonces tiene que ser una VM que tenga Docker instalado. Y lo que va a hacer es que cuando un job se corra en ese runner, te va a crear un contenedor. Y dentro de ese contenedor va a correr tu trabajo.
¿Para qué sirve eso? Si tenés bastantes tecnologías, si tenés Python, Java y Golan, ¿no? Pero no tenés tanto flujo, puedes tener un solo runner con Docker
y va a correr en la misma VM y lo que va a hacer es los builds de Golang va a levantar un contenedor con Golang, los builds de Java va a levantar un contenedor con Java porque vos lo especificas en tu CICD file, en tu workflow file de GitLab, en tu GitLab, Jamal, lo que sea, Bueno, así es cuando es Docker. Tiene que ser una máquina física que tenga Docker corriendo, pero él, cada job, en vez de correrlo dentro de la
Juan (26:52)
Sí, con toda la dependencia.
Douglas (27:13)
va a levantar un contenedor con la imagen que vos le digas y ahí lo va correr. De lo mismo está el executor o el ejecutador Kubernetes que es similar a Docker solo que en funcionalidad solo que en lugar de una instancia con Docker es un clúster de Kubernetes y la ventaja de este es que como Kubernetes escala, agrega y quita instancias de acuerdo a los recursos, te permite que te va a asignar un pod que es...
Juan (27:23)
Ok
Douglas (27:41)
es que en lugar de un contenedor, que un pod puede tener uno o varios contenedores, te va a signar un pod y si vas teniendo bastantes trabajos, solo va a agregar instancia y le va a mandar a trabajo a la otra, y si ocupa más agrega otra instancia y le va a mandar trabajos y al dejarse de utilizar va a ir quitando las instancias, las va a ir resumiendo, de esa manera es que interactúa, vos le decis un execute, qué tipo de ejecutador, pudieras tener un runner en Mac.
porque ocupas correr test que ejecuten en Mac, puedes tener un runner en Windows, no sé por qué lo quisieras, pero a veces se necesita un runner en Windows, pero así es como funciona.
Juan (28:22)
¿Tiene licencia un runner de Mac? ¿De Mac o es?
Douglas (28:25)
Fijate que he usado uno en nube, entonces no se ha tenido que pagar licencia, pero como Mac solo corre en hardware Mac, no pagas sobrevalorado por el hardware que ya te trae el software, entonces...
Juan (28:31)
Ok
mmm es cierto
Douglas (28:44)
Entonces no es necesario,
tal vez si hay otra manera ahí en que se ejecutan, como no tengo tanta experiencia necesitando esos runners más que usar servicios que los proveen, tal vez no te podría contestar. Acá valida esa pregunta. Pero bien.
Juan (28:59)
Sí, es un diente.
Douglas (29:00)
Perfecto, perfecto, me alegra que vaya aclarándose el camino en eso y que vayamos conociendo los runners. Ahora, otro elemento dentro de un CACD pipeline que muchos no saben que utilizan, pero si lo hacen es el caché. El caché, Juan, es parte de la infraestructura de un pipeline y es probablemente una de las más importantes.
porque lo que ocurre es que cuando en tu local vos corres un npm install, se descarga un tercio del internet en tu local dentro del directorio node-models, ¿verdad? Entonces eso es un poquito gente debate, tiene pros y contras, ya lo sabemos, pero lo que ocurre es...
Juan (29:39)
Sí.
Douglas (29:46)
que la siguiente vez que corres en pm install lo que ya está en ese directorio no lo vuelves a bajar, es una de las maneras en las que funciona el cache o igual si das un docker build queda guardado en cache los steps o los pasos del docker build que no cambiaron y solo hace los anteriores pero qué pasa si cada vez que corres en pm install o
Juan (29:55)
Ok.
Douglas (30:11)
Docker Build lo haces en un workspace o un espacio o un directorio nuevo porque aunque tengas un runner privado de manera interna donde ahí se van a correr todos tus Docker Builds ese directorio privado lo que hace GitHub cuando se conecta a él, lo que hace GitHub cuando es GitLab, perdón, cuando se conecta a él es que crea un workspace, crea otro directorio donde hace un checkout y mira los logs de un GitHub Actions por ejemplo.
vas a ver que de los primeros steps vas a hacer un checkout del código para que esté ahí en local. Entonces está fresh, está nuevo.
Juan (30:41)
Sí, sí.
Douglas (30:47)
y quiere decir que cada vez que corras en PM install van a volver a descargar todos los módulos en cada build y muchas veces eso se vuelve tardado es ineficiente, si lo tenés tu red privada pagas más internet, más bandwidth, más tardado tus pipelines, más tiempo de que esté corriendo un job, más computing power, ¿qué pasa Juan? la arquitectura de un CICD pipeline puedes aprovechar el cache
Juan (30:55)
Sí.
Douglas (31:17)
y por ejemplo agarrar un bucket de S3 y configurarlo para que guarde el cache ahí y si vos ves algunos pipelines dice que al finalizar de algunos jobs dice que está guardando en cache porque lo que hace es que los módulos que vos les específicas por el en el caso de un npm install va agarrar el dot models y lo va a guardar en S3 en ese cache y cuando pase al siguiente job
Juan (31:41)
Sí.
Douglas (31:44)
Solo va a jalar el caché y va a continuar con los demás pasos. O la siguiente vez que corraje ese job.
ya va a tener ese caché ahí guardado y no va a volver a bajar paquetes que ya bajaste una vez y hay maneras de estar limpiando ese caché, hay maneras de estarle diciendo cada cuánto se va a renovar, etcétera, ¿no? y si se llegara a perder pues lo peor que puede pasar es que el siguiente job va a volver a tardar un buen rato hasta que vuelva a bajar todo pero los jobs que siguen van a ser más rápidos porque ya está el caché ahí entonces de nuevo, solo imagínate que cada vez que vos corres
Juan (32:18)
Mm-hmm.
Douglas (32:21)
install en tu local tuviera que hacerlo desde cero sería terrible, entonces es aún más terrible en un pipeline porque el tiempo es pagado, el bank dude es pagado y es crítico, entonces es muy común Juan y aquí lo con lo que yo he trabajado al menos a nivel personal es con S3
se usa S3 para que se guarde el cache y de esa manera pueda estarse pasando entre jobs porque eso es algo que la gente no sabe, cada job es como una instanciación del código otra vez, como una instancia otra vez, es verdad, entonces cada job aunque sea del mismo pipeline vuelve
Juan (32:56)
Sí.
Douglas (33:02)
a bajar el código y hacer a menos que vos configurez que con el cache pase de un lado a otro, verdad, entonces aún dentro del mismo pipeline es indispensable usar el cache para aprovecharlo de esa manera, entonces ¿habías trabajado ya con el cache? ¿Sabías Juan que funciona de esa manera un pipeline?
Juan (33:12)
ok
Bueno, te diré que aquí el que me quiera juzgar tiene razón porque sí lo conozco pero nunca me he detenido a configurar el cache en los GitHub Actions. Normalmente un Action de las aplicaciones que he hecho en Go o en Vue, Vue.js normalmente tardan de 1 a 2 minutos. Así que...
no sobrepaso tampoco el límite del plan gratis así que pues por eso nunca me puse a configurarlo pero sí sé que se puede poner el caché y debería hacerlo pero no nunca me he puesto a configurarlo de tal manera de hecho no sabía que se podía hacer con buckets de s3
según yo solo era con el mismo contexto de github así que eso pues está interesante porque significa que debería tener compatibilidad con cualquier otro tipo de buckets no solamente el de amazon lo cual pues dependiendo de la empresa, dependiendo de lugares eso puede ser muy muy ventajoso pero sí la verdad es que no nunca lo he configurado en su momento hace mucho tiempo atrás lo revisé y
tenía menos conocimientos al respecto así que no entendí la manera o sea por algún motivo no no hacía clic en mi cabeza así que no seguí indagando en eso y preferí pues dedicarle tiempo a otra cosa lo que sí he notado es que o la ventaja que se me ocurre que también a veces es necesario
que se vuelva a descargar todo para asegurarte que no haya algo que quedó en caché y que querés que se vuelva a probar como si fuese la primera vez. Por ejemplo, si me ocurre que perfectamente podría tener yo que se guarden caché todos los builds que sean en el ambiente de testing y tal vez en el ambiente de producción podríamos decir, ok, aquí sí quiero que vuelva a descargar todo en caso que el dinero no sea un problema, El ancho de banda y todo esto.
eso es que se me ocurre como punto positivo entre comillas de no dejarle el caché pero bueno en un ambiente un poco más concurrido donde tenemos todos los diferentes departamentos de programación están lanzando nuevas versiones sí tiene que ser bueno es indispensable tener caché de todo lo que se hace y lo comparo mucho con cómo funciona bueno por ejemplo Go en la máquina local eso es lo que hace
yo descargo una dependencia para un proyecto y se guarda en un directorio principal y luego voy a otro proyecto y vuelvo a descargar utiliza el cache de mi máquina. Básicamente es eso mismo lo que hacen. Muy muy bueno la verdad. Pero no, nunca lo he hecho definitivamente. Debería serlo.
Douglas (36:26)
Si mira justo eso que decís es lo que hace y en respecto al comentario que hiciste de tal vez en producción no querés que baje, use el caché por seguridad y eso. Me gusta tu enfoque, tu mentalidad alrededor de ello. Sin embargo te recuerdo que ese tipo de cosas de limpiar el caché y eso son pasos de troubleshooting. No pasos cuando ya está todo bien definido y establecido. ¿Verdad?
Juan (36:49)
Ok
Douglas (36:54)
Normalmente cuando estamos tal vez comenzando con un nuevo pipeline, yo comienzo con un nuevo pipeline si no configuro el cache que prevalezca porque estoy probando el build, estoy viendo que todo me funcione como quiero y que cada build va a ser consistente. Cuando terminé mi troubleshooting y sé que todo funciona como quiero, confío totalmente en el cache porque ya no se está en una etapa de troubleshooting, ya se está en una etapa de producción donde
Juan (37:17)
Ok
Douglas (37:24)
le sacamos provecho a esas cosas eso sería como producción que le quita redes un rato para asegurarnos que no hay problema de caché entonces en producción no hacemos eso lo hacemos en desarrollo o en mi local si estoy creyendo que eso puede hacer un problema entonces te digo me gusta tu mentalidad porque no estás fuera de concepto sin embargo es que no aplica ahí porque no se está troubleshooting nada
Juan (37:31)
Sí, sí, tiene sentido.
Douglas (37:51)
ya está en producción y más bien queremos el caché para que avance rápido, para los bills y reducir tiempo y por supuesto en pipelines pequeños o cuando hay pocos proyectos estas cosas no suelen ser un...
un deal breaker como decimos algo complicado no mi bill toma dos minutos máximo pero es bueno que traten de verdad y este es mi consejo a los desarrolladores es bueno que traten de hacerlo porque cuando tengan que trabajar en un pablan o en empresas que son bien concurridos o que el bill es más intenso no y que llegar a hacer yo he estado trabajando con bills que han tomado 40 minutos reducirlo a
cuatro seis minutos y es muchas veces simplemente con caché y con saber ordenarlos en stages, cuántos trabajos pueden ir en paralelo, se ahorra un gran parte del tiempo.
Juan (38:37)
Wow.
Douglas (38:50)
Entonces sí, los animo a que comiencen a trabajar con ellos. Y las personas de operaciones y sistemas, si su pipeline no tienen cache que sea compartido de esa manera, exploren la posibilidad de configurarlo. Como dijo Juan, es un S3-like bucket, o sea, quiere decir que cualquiera otro similar, yo lo he hecho tanto con el S3 de AWS.
también lo he hecho con los buckets de DigitalOcean, fíjate, entonces mientras sea Object Storage va a funcionar bien.
Juan (39:17)
Ok
Sí, muy bien. verdad es que
después de esto voy a regresar a los actions que tengo por ahí a ver si los puedo implementar en el cache.
Douglas (39:33)
Sí, y de hecho fíjate que el caché lo uso para reemplazar muchas veces algo que es el tercer punto de la infraestructura, ¿verdad? Y ya te voy a mencionar cómo lo uso. El tercer punto de la infraestructura, son los artefactos o los artefacts. Artefactos se le dicen en español. Es mi entendimiento. Yo siempre lo he trabajado como artefacto en inglés para quienes sepan qué es un artefacto.
es tu aplicación ya construida, lista para ser desplegada, verdad. Si es en Golland, pues tu Artifact es tu binario ya listo.
para operar o si tu aplicación tiene el binario más un config file, entonces va a tener ese directorio con el binario del config file listo para que sea publicado. tu aplicación es, se corre en un Docker container, entonces el artifact va a ser la imagen de Docker donde va a estar tu código, ¿verdad? Pero el artifact.
Juan (40:22)
Ok.
si es una aplicación
de Android, el Artifact sería el .apk
Douglas (40:41)
Sí, sí, solo que Android, fíjate que no he hecho nunca un pipeline que publique de un solo al App Store, bueno, al Google Play desde el CICD, verdad, entonces en esa parte no tengo la experiencia directa como para responder a tu pregunta tal cual, pero pues sí, sería un APK.
Juan (40:43)
o no.
pero como pensando
como en el ejemplo que das es lo asimilo como que es el bundle que hace que ese programa funcione es como el directorio que tenga el ejecutable más archivo de configuración o directamente el binario ese sería el artifact
Douglas (41:24)
Si, es lo que tu pipeline va a desplegar, ese es el artefact, ese conjunto ya listo, pero eso te digo, tu aplicación, si tu pipeline solo hace despliegue del binario de Golang, pues tu artefact solo es el binario, pero si tu pipeline hace despliegue del binario y también cambia con config file, entonces probablemente va a tener un zip file con todo eso y ese es tu artefact. Si tu pipeline lo que está haciendo es un plugin,
Juan (41:29)
ok
Ok.
Douglas (41:53)
por ejemplo, entonces va agarrar el directorio, va a ser el build del plugin, va a agarrar el directorio y ese va a ser tu artifact y el despliegue va a ser crear un release, un tag y un release en GitHub para que esté la nueva versión del plugin disponible. Pero en ese concepto el artifact es...
Juan (42:07)
ok
Douglas (42:14)
lo que se va a desplegar a donde sea que va a ir. te di un ejemplo de algo que va a ir a un servidor como una aplicación de Golan o de algo que va a ir a la nube como un plugin que es un nuevo tacky, release en GitHub, Entonces eso es un artefacto.
Entonces, los artefact, Juan, de nuevo, pues, pueden ser, si tenés solo Jenkins ahí, él los va a guardar ahí en Jenkins de manera local. Pero si tenés alta disponibilidad o si tenés runners que están privados y luego no pueden accesar o bajar el artefact porque no aceptan el llamado al endpoint del artefact de adentro, vas a tener problemas, ¿verdad? Entonces, idealmente, ponemos un.
lugar centralizado.
Lo que nosotros usamos en field son de nuevo buckets de S3 y entonces un bucket de S3 ahí configuramos para que ahí vaya el artifact y cuando esté listo para ser desplegado de ahí lo agarra y lo manda. Pero también hay servicios en la nube, uno que es vigente que fue el primero que trabajé por cierto verdad que lo puede ser en el local o en la nube es JFrog Artifactory se llama no sé si lo escuchaste Bojvan
Juan (43:09)
Ok
Qué buen nombre.
Douglas (43:33)
porque
fue de los primeros que probamos cuando vos y yo trabajamos con microservicios. JFrog Artifactory. También hay uno de Sonat Type que se llama Nexus Repository que es muy utilizado para quienes usan este tipo de servicios fuera de los Street Buckets. AWS tiene uno que se llama Code Artifact que lo puedes utilizar para eso también. Google tiene el suyo y hay otros muchos, ¿verdad? Pero, ¿cómo manejar los Artifacts
de manera centralizada es otra pieza de la infraestructura de CICD que tenés que tener en consideración para tu disposición porque muchas veces ese mismo artefacto lo puedes publicar a diferentes lugares o muchas veces ese mismo artefacto lo puedes publicar a tus servidores de hosting pero también luego va a tener otro proceso de testing o de QA o de revisión donde querés accesar a él y bajar ese artefacto el mismo código tal cual
fue generado para ser publicado, muchas veces para troubleshooting la aplicación está dando un problema y vos ves que el código está bien, vos ves que los bills pareciera que todo se le dio bien, entonces uno dice que se publicó al servidor, voy a ir al pipeline, voy a agarrar el artefact, lo voy a bajar en mi local y lo voy a inspeccionar.
para ver que se publicó, Pero entonces el Artifact va a un lugar centralizado y es otra parte que muchas veces no se conoce de la infraestructura. Y antes de darte la palabra aquí donde voy a dar un tip, verdad, muchas veces entre jobs, entre el job del Build y el job del Deploy, en lugar de usar Artifact,
Juan (44:54)
Ok.
Douglas (45:14)
En Github Actions, lo que hace es que toma un tiempo en subirlo a un lugar que a veces está muy largo y luego bajarlo de otro lugar muy largo, yo uso caché. El caché que te dije, En el step anterior donde hice el build, lo pongo como caché.
Juan (45:29)
Ok
Douglas (45:35)
Y en el job que sigue, lo descargo como caché, que eso es súper más rápido y el deploy o el despliegue es más rápido porque no tarda tanto en descargar el artefacto y no tarda tanto en subir el artefacto, ¿verdad? Ahora, esto solo funciona en casos en los que no necesites un historial de artefactos, un historial de artefactos, ya sea para travel shooting o para rollback porque muchas veces es otra ocasión.
por la que se necesita Juan, querés hacer un rollback verdad y el caché es más volátil mientras que los artifacts sí son más permanentes verdad entonces si tenés una regla de rollbacks pues usas los artifacts pero cuando no ha sido así cuando solo build y deploy, build y deploy usa caché en lugar de artifact pero bueno con respecto a los artifacts Juan los has trabajado los has visto o solamente vos le das que build y deploy
Juan (46:09)
Sí.
Bueno, es que no sé si es lo mismo porque casi siempre he trabajado con containers. Entonces el concepto que se me viene a la mente son los registry. Pero veo que estos son como otro tipo de repositorio donde están los artefacts. Entonces no sabría decirte. Creo que no, no, no, no tenía el. Bueno, de hecho no tenía el concepto en la mente, no lo conocía.
y no sé si lo he trabajado directamente para hacerte honesto. Me llama la atención porque bueno, eso lo que estaba pensando mientras hablabas el hecho de poder hacer rollback. Me parece muy fácil y muy beneficioso el hecho de tenerlo en un punto en específico, porque ya me ha pasado el hecho de hacer un deployment y algo pasó. Entonces hacemos rollback y bueno, esa imagen o esa
ese binario que estamos deplegando, tiene que estar en un lugar, ¿no? No me había detenido a pensar exactamente de dónde viene. En mi mente creo que lo asumía, en el caso de Argo CD, pues asumía que tal vez estaba dentro del mismo Argo CD, no sé, no lo había analizado. ¿Hay alguna ventaja, por ejemplo, con esta otra que mencionas como JFrog Artifactory, versus...
tenerlo en los buckets por ejemplo los buckets que sería más más barato tal vez o
Douglas (48:12)
Si un bucket es mas barato, supuesto, obviamente va a ser un poco mas lento, todo depende de que tanta velocidad necesites. También si algo como Artifactory o cualquiera de estos, lo que ya te ofrece AWS, no tenes que mantenerlo, verdad, es manejado por ellos y esa es otra de las ventajas en ese sentido. Y fijate que obviamente tu experiencia ya nos lo has contado, pero normalmente
vos trabajas en tu experiencia que como objetivo final, como producto final perdón, suelen ser bien empaquetados o es un binario o es un contenedor, verdad, pero te quiero poner en este contexto porque obviamente vos entendés muy bien cómo funcionan las aplicaciones web y sé que también has trabajado con aplicaciones web aunque tu mayor experiencia esté en microservicios, pensa
Juan (48:54)
Sí.
pero es las webs también
las manejo con contenedores normalmente. Se me ha hecho más fácil.
Douglas (49:11)
sí
sí sí pero y es lo que yo recomendaría también hoy en día pero pensá que tengas un cluster con cuatro servidores web donde tenés toda tu aplicación, archivos HTML, una aplicación de Node.js, vos sabes lo que contiene entonces supone que haces el build y haces el despliegue
pero ocupas hacer un rollback hacia dos versiones anteriores. Entonces, ¿cómo haces eso con archivos separados que tiene una aplicación web? Porque no estás corriendo en contenedores. Recordar que de ahí se origina esto, ¿verdad? Entonces, antes, estos artefactos lo que eran, hacían el build y era un seed file.
Juan (49:48)
Sí, sí.
Douglas (49:58)
de toda la aplicación lista y muchas veces el paso del deploy, muchas veces ocurría o en un runner que luego descomprimía ese artefact para desde ahí hacerle R-Sync a los servers o copiaba ese artefact en un directorio temporal del web server y desde ese directorio temporal hacía R-Sync al directorio que está en producción, ¿verdad?
Juan (50:01)
Sí.
Douglas (50:25)
pero tenerlos empaquetados en un zip era lo que permitía hacer rollback a dos versiones anteriores o una anterior, porque sí, es necesario y era la única manera de hacerlo.
De igual manera funciona con contenedores o con binarios si lo querés hacer, ¿verdad? Por eso es importante, tener ese lugar centralizado para los artifacts porque queremos accesar a ellos cuando sea necesario también hacer rollbacks, ¿verdad? Entonces.
Juan (50:59)
Sí.
Douglas (51:00)
Si, espero que esa ilustración haya dado a entender por que es necesario, por que es importante, de donde viene. Si bien es cierto, se usa menos cada vez menos, tener que crear artefactos para aplicaciones web que están en un zip file con todo el contenido. Verdad, si lo seguimos haciendo para otro tipo de...
aplicaciones y el artifact sigue siendo y seguirá siendo parte de la infraestructura de nuestro sistema de CI-CD Piblum. Y el último que quiero tocar hoy, Juan, es justo el que acaba de comentar, que es el Registry de Contenedores, o tu Container Registry, porque muchas veces, muchas personas, ya lo mencionaba, muchas empresas pueden solamente hacer su
subirlos al Docker Hub, ya sea privado o público, pero muchas veces en realidad no es así.
querés mantenerlo de manera, porque tu código es privado y no querés que esté expuesto al mundo y aunque usés algo privado en Docker Hub o aunque usés ECR de AWS o GitLab tiene también sus propios registros de contenedores, querés tenerlo de manera privada y eso sea, o ya sea, un servicio externo.
Juan (52:20)
Sí.
Douglas (52:23)
como lo que ya mencioné, o que de manera privada vos lo tengas y lo estés manejando como se pudiera hacer en GitLab por ejemplo, es parte de la infraestructura que tenés que conectar porque lo que ocurre es que al momento del build...
y al momento de push la imagen, tienes que autenticar contra estos servicios. Y en GitHub Action yo creo que tal vez has visto que existe un action para hacer un login al registry y de ahí se publica, ¿verdad? Pero hay diferentes maneras de hacerlo si estás interno en otro tipo de contenedores, ¿verdad? Por ejemplo, GitLab lo que hace es que cuando el job corre genera un token temporal.
Juan (52:42)
Sí.
Douglas (53:05)
Y ese token temporal como está ya enlazado con el registry de contenedores, ese token temporal le da acceso a que pueda hacer el push al registry, pero cuando el pipeline termina, ese token caduca. Entonces si alguien encuentra esos logs por ahí y quiere usar ese token, no le va a servir. Pero si usas el GitHub Actions.
con el Docker Login para conectarte al Registry, ya sea el mismo Registry de GitHub, porque GitHub tiene su propio Registry, lo tiene porque es parte de la infraestructura de la columna vertebral de un CICD, Si usas el Docker Login para eso, entonces va a ocurrir lo que te digo, ¿no? Que si alguien se liquea esa información o alguien tiene acceso a los logs, va poder hacer un Login.
Juan (53:37)
Sí.
Douglas (53:57)
en lugar de usar un usuario y password para eso, puedes usar en GitHub Actions siempre el Action de Docker Logging.
pero usa el token que genera de manera temporal que lo guarda la variable GitHub, yo bajo token, creo que se llama la variable, hay que similar a lo que hace GitLab que genera un token temporal que cuando termina el pipeline ese token expira, ¿verdad? Pero el Registry One por sí solo, si vuelvo a manejar de manera interna es otro monstruo por completo porque puedes hacer que las imágenes terminen en un Street Bucket también, ¿verdad?
Juan (54:19)
jajaja
jajaja
Douglas (54:38)
pasa por el registry y termina con un street bucket, o pueden estar almacenadas de manera diferente en el registry muchas veces dependiendo de la aplicación y si lo manejas interno, quieres que tener cierta retención, o sea, las últimas 30 versiones.
porque nunca vas a hacer un rollback a la versión hace 31 versiones, de las últimas 30 o 60 versiones. A diferencia del Docker Hub, si vos ves imágenes ahí que tienen desde como el 2016, 2017, tienen imágenes y nadie baja allá esas imágenes, pero ahí siguen gastando recursos, gastando almacenamiento en la nube de imágenes que probablemente ya no son utilizadas por nadie. Entonces cuando lo tenés de mano, mira.
Juan (54:57)
Wow.
Sí.
Hablé por eso más caro
en Docker Hub.
Douglas (55:27)
Por eso comenzamos a dockerhop, correcto. Pero por sí solo mantener el registry es más trabajo, pero es más seguro.
Muchas empresas, casi toda empresa que se preocupa por seguridad tiene su registry interno, ¿verdad? Y eso se vuelve parte de su CI-CD Pipeline. Entonces, mira Juan, yo sé que con registry si tenés mucha experiencia trabajando, pero más allá de todo, quiero que me des tus palabras finales para ir concluyendo el tema, ¿verdad? Respecto a toda la infraestructura que hay de un CI-CD Pipeline mencionamos runners, que pueden ser uno o muchos runners, ¿no? Y pueden ser en Docker o
pueden ser en Kubernetes, el cache para que esté persistiendo entre diferentes jobs del mismo pipeline y entre nuevos jobs cuando sea necesario, los artefactos o el artefacto, el lugar centralizado y por qué son importantes para que diferentes jobs lo puedan bajar para hacer rollbacks, para que esté guardado en un lugar centralizado para hacer rollbacks y el registro de contenedores para que cuando nuestro artefacto sea un contenedor que vaya ahí, verdad, Juan hay más elementos
hay como manejar seguridad, como manejar secrets, muchas veces tus runners ya tienen esos secrets ahí, verdad, y hay otros elementos, los, sistema de escaneo.
Por ejemplo, si estás haciendo scan por virus, scan por vulnerabilidades, y también está de manera interna y se conectan, pero pues ya esos son situacionales. Pero, pero runner para hacer el build, caché. Y el artifact, ya sea artifact de un zip file con tu código o contenedor que también cuenta artifact, esos están en la gran mayoría de los pipelines y son esenciales y fundamentales. Entonces, dame tus pensamientos finales ahora.
Juan (56:59)
Sí.
Douglas (57:19)
que conoces esto, que hay detrás en infraestructura y que sabes que conociendo eso también puedes pedirle a la gente de operaciones si tenés builds lentos, tenés problemas con caché, si tenés problemas con rollbacks, ¿verdad? Me gustaría tus palabras finales en eso.
Juan (57:37)
Bueno, lo que te puedo mencionar es que ya con esto que nos has explicado me hace más... como que empiezo a entender un poco mejor algunos de los pasos que suceden en los builds de las aplicaciones en las que trabajo. Y de hecho es... mientras hablaba muchas cosas empezaban a cruzar por mi mente como, ah, ok, estos problemas que hemos tenido probablemente sea por esto, estas otras cosas que hemos hecho tal vez se pueden mejorar con esto u otro.
y bueno, definitivamente es algo que quiero tener un poco más en cuenta y conocer un poco más para ver qué se puede hacer, al menos yo lo que saco con este tipo de pláticas Douglas es, o lo que siempre pienso es que puedo implementar, ya sea en mi trabajo principal o en mis proyectos que estoy haciendo aparte, porque si bien no me toca a mí hacerlo directamente, como ya bien lo mencionaste, pues conocerlo me permite dar ideas.
y siempre trato de hacer eso, dar alguna idea, mencionar algún comentario aunque la decisión no la voy a tomar yo pues al menos mi responsabilidad siento que es mencionarlo. Lo otro que me queda muy claro es que definitivamente correr un CI-CD pipeline pues lleva mucho mucho trabajo y requiere mucha planeación incluso.
estoy seguro que muchas cosas van surgiendo sobre la marcha porque así es así funciona a veces tenemos un plan y luego van cambiando cosas pero definitivamente es algo que hay que tener en cuenta y saber cómo lo vamos a manejar con las empresas que tienen mucho más mucho más cuidado con la privacidad pues sí tienen que tomar en cuenta este tipo de cosas hace tiempo había visto sobre eso sobre los runners en los guido actions recuerdo alguien que mencionaba eso estaba haciendo
un motor de videojuegos y por muchos motivos él se mudó y empezó a ejecutar todos los runners en su servidor de la casa entonces ahí recuerdo que fue la primera vez que empecé a entender un poco cómo funcionaba eso aunque no con el nivel de detalle con el que nos estás dando creo que si alguien está pensando en iniciar en este mundo de SRE, sistemas
y administrar ese tipo de pipelines pues yo creo que probablemente se sientan emocionados porque toca saber un poco de todo, ¿no? Tenés que aprender a configurar muchas cosas desde el servidor, cómo se van a comunicar, tenés que saber muchas cosas de cómo se va a comportar la aplicación. Así que eso me llama mucho la atención. Creo que ya le he mencionado que...
que siempre he tenido ese respeto y a veces incluso lo considero de pasarme a hacer esrari o algo así. verdad es que me parece muy entretenido y este tipo de pláticas la verdad es que sí, por eso las valoro mucho de tu parte, Douglas. verdad es que sí, venís a compartir mucho conocimiento que realmente no lo he visto.
en internet, al menos no de una manera tan clara. que sí, muy bien. Ojalá que los developers que nos hayan estado acompañando hasta aquí piensen igual y traten de verlo de la misma manera, Que se puede aprender de todo un poco en esto.
Douglas (1:01:04)
Qué bueno, Juan, qué bueno. Me alegro porque esa es la intención de la conversación, ¿no? De informar y despertar el interés tanto en las personas que trabajan en sistemas o que quieren trabajar en el área de sistemas y operaciones de que se entienda lo que cuesta realmente mantener el sistema donde corren los pipelines, ¿verdad? Y para los desarrolladores que se informen, o sea, informarles cómo funciona, tratar de enseñarles un poquito y que eso se transforme en que ahora que entienden un poco
más sepan qué pedir a la gente de sistemas, este comentario lo he hecho como por cuarta vez ahorita pero es parte de la de mi opinión del valor que se puedan llevar que sepan qué pedir a la gente de operaciones si están teniendo problemas con pipelines lentos, verdad. Me alegra eso es lo que queríamos compartir hasta hoy agradecerles por su atención como siempre y nos veremos en un nuevo episodio de este podcast de Deep & Ops.
Juan (1:01:38)
jajaja
Bye.