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)
Yo estoy concuerdo con vos, que agradecerle a GitHub Actions que le ha permitido a más developers entrar en lo que tiene que ver con CI-CD porque antes, han existido siempre Juan, bueno no siempre, pero desde hace mucho tiempo, servicios.
en la nube por decirlo de esta manera de CI CD estaba CircleCI por ejemplo GitLab también tenía sus pipelines online y otras herramientas Beanstalk y otro montón por ahí pero GitHub Actions como los programadores ya tenían su repositorio normalmente en GitHub comenzaron a integrarse en eso entonces tenemos eso que agradecerle a GitHub a Microsoft como tal como comunidad verdad los GitHub Actions
Juan (00:24)
Ok
Douglas (00:50)
Hola a todos y bienvenidos a otro episodio de Dev & Ops, su podcast favorito de desarrollo, tecnología, DevOps y su cultura en general. Y como es costumbre en cada episodio, le doy la bienvenida a mi amigo y co-host Juan Ramos. Juan, ¿qué tal estás? Bienvenido a un episodio más.
Juan (01:09)
Hola Douglas, me encuentro muy bien. Un día muy bonito el día de hoy y muy agradable para tener estas pláticas de tecnología que solemos tener semana y semana aquí contigo.
Douglas (01:22)
Sí, me alegro, me alegro. Yo igual también estoy disfrutando de que el día está un poco fresco hoy. Por eso ando con mi suetercito, ¿no? Aprovechando lo fresquito, lo que es inusual aquí en esta ciudad en la cual yo vivo. Juan vive en otra ciudad, pero compartimos el mismo clima ya que estamos cerca de la costa. De hecho, Juan está más cerca de la costa de lo que yo estoy. Pero bueno, aprovechemos esta situación, Juan, para hablar con comodidad. Entonces, del tema que tenemos hoy.
Juan (01:45)
Sí.
Douglas (01:52)
hoy tenemos un tema bien interesante y es que hoy queremos compartir algunos comandos de Linux indispensable para CI-CD pipelines. En un CI-CD pipeline, Juan, yo sé que tal vez vos como desarrollador tu interacción directa con ellas es menor a lo que probablemente yo estoy expuesto a CI-CD pipelines en mi día a día, ¿verdad? Sin embargo, siempre la idea de un CI-CD pipeline es que tanto desarrolladores
como de gente de operaciones o sistemas colaboren, el CIC pipeline lo que normalmente tenemos disponible es la terminal de Linux. Cualquiera distribución que esté corriendo en los runners, ya sea que estés en GitHub Action, que estés en GitLab, que estés en Jenkins, donde sea que corran tus pipelines, lo que tenés a disposición es la terminal de Linux del distro que estés utilizando.
Juan (02:47)
Windows Server.
Douglas (02:48)
Sí, correcto. O a los servidores a los cuales está conectando el CI-CD pipeline, correcto. Pudieras Juan, pudieras, quiero aclarar, alguien tener un runner list o con su lenguaje de programación si estás usando PHP, un runner list o una imagen de un contenedor que tenga las herramientas de PHP o tus herramientas de Python, tus herramientas de Ruby, lo que sea que necesites. Lo que pasa es que no es tan común porque entonces ahora tenés un runner que está
manteniendo con estas diferentes versiones y herramientas. Entonces no es tan común realmente hacerlo de esa manera y lo que tenemos a nuestra disposición de nuevo es la terminal de Linux.
Y entre más sabemos, y entre mejor la podemos aprovechar, obviamente vamos a hacer cosas, trabajos más complejos. Y es lo que estamos intentando, ¿verdad? Y pues para aclarar, Juan, vamos a estar hablando, compartiendo comandos, no bas scripts. No vamos a compartir scripts como tal, sino que comandos tampoco vamos a usar statements como un if statement o loops, como while or for.
como hacerlos en batch, sino que comandos específicos que podamos llamar.
desde nuestros trabajos dentro del CI-CD pipeline, ¿verdad? Y por supuesto vamos a hacerlo de una manera en la que las personas que solo nos escuchan puedan recibir valor porque hemos discutido esto con Juan bastante, pudiéramos tratar de buscar la manera de compartir pantalla en un episodio y las personas que nos ven puedan tener ese valor extra al poder ver lo que estamos haciendo, ejecutando o leyendo, pero de una manera
que
las personas que solo nos escuchan puedan entender el 100 % de lo que estamos haciendo y no puedan perder el contexto. por esa parte, no Juan, el balance es un poco complejo. Entonces, la idea es que nos vamos a mencionar los diferentes contextos en los comandos que les vamos a sugerir en este episodio. Ustedes puedan ver que estos comandos ahí encajan. Y una vez que ustedes identifiquen este
Juan (04:47)
Sí.
Douglas (05:04)
este comando yo estoy teniendo este problema en el pipeline o necesito resolver esto en un pipeline este comando me sirve que ustedes vayan por su cuenta a investigar un poquito más de él con respecto a la sintaxis con respecto a los diferentes usos verdad pero pero estamos convencidos que la forma de cómo lo vamos a llevar va a ser de valor para ustedes entonces Juan antes de arrancar con el primer comando
Contarnos un poquito tu experiencia con CI-CD pipelines desde tu perspectiva de desarrollador. Yo sé que todos los desarrolladores van a tener un enfoque diferente y yo siempre digo, al momento de hacer un pipeline, yo siempre le pido perdón al equipo de desarrollo, deme los comandos para hacer el build de la aplicación. ¿Cuáles son los comandos? Aunque sea Node.js y el 99 % de los proyectos son npm install.
empien install, empien build siempre siempre lo pregunto porque pudiera haber un flag diferente pudiera haber un llamado externo o cualquier otra cosa en el build en la aplicación en particular y esas instrucciones vienen del desarrollador así que yo sé que mínimo mínimo ese es lo que se involucra un desarrollador en un pipeline aunque no lo ejecutó de forma directa es decir estos son los comandos que hacen el build
de mi aplicación, pero contanos de experiencia Juan por favor.
Juan (06:36)
Hoy en día es cada vez menos, la verdad. Por ejemplo, el caso de cómo ejecutar aplicaciones y todo, la verdad es que yo, pues, guardo lo que es el Dockerfile del microservicio y listo, Ahí ya simplemente es ejecutar el Dockerfile. Y lo que sucede también es que ya cuando tenés múltiples microservicios ya se empieza a dar una serie de patrones y estándares que sigue el mismo equipo.
y ya se sabe en qué puerto es el va a estar corriendo internamente, se sabe algunos parámetros. Así que hoy en día no es menos, es mucho menor más allá de revisar que cuando algo falla dentro de los test, me ingreso a Jenkins, reviso aquí, reviso allá. Antes, de hecho la primera vez que tuve una interacción y supe lo que era un CI-CD Pipeline,
fue con un proyecto donde un catedrático de la universidad nos ayudó a configurar todo lo que era Jenkins para el proyecto. La verdad es que yo no hice nada, pero con solo el hecho de ingresar a la consola y revisar y aunque ahora que lo pienso creo que sí tuve que configurar algunas cosas de Laravel para para el Jenkins. Ya fue hace mucho tiempo, ya mi memoria no da tanto.
Y luego lo que más he utilizado ha sido pues los GitHub Actions. Los GitHub Actions han venido a realmente han venido a ayudar a los developers que no teníamos mucha experiencia, seteando un Jenkins server desde cero. Pues ahora sólo nos preocupamos por una serie de pasos y son pasos que bueno, ya que tenía experiencia con Docker y cómo hacer imágenes de Docker, pues también como que mi cerebro lo empieza a
asimilar de cierta manera igual, es una serie de pasos secuenciales aunque en los GitHub Actions te permite hacer branches dependiendo de una cosa te vas a otra pero para proyectos aparte si he tenido que setear esto los GitHub Actions y a lo más que he logrado hacer Douglas ha sido que cuando termina GitHub Actions hacer el trigger de un webhook
que tengo configurado en mi servidor remoto y ese servidor remoto se encarga de recibir el webhook y actualizar todo lo que tenga que actualizar. Así que no han sido trabajos tan pequeñitos pero creo que han sido simples dentro de lo que cabe. Y bueno, pero hasta ahí ha llegado mi interacción más directa. De ahí pues hoy más que todo como un usuario, Un consumidor de los pipelines ya creados.
Douglas (09:19)
Ya.
Ya, pero me gusta bastante lo que está diciendo y voy a degustar un poquito para que las personas que nos vengan y nos escuchan, sobre todo aquellos que están en desarrollo e interactúan poco con pipelines, tengan esto en mente mientras avanzamos en los diferentes comandos que vamos a sugerirles. Uno de ellos no es...
Yo estoy concuerdo con vos, que agradecerle a GitHub Actions que le ha permitido a más developers entrar en lo que tiene que ver con CI-CD porque antes, han existido siempre Juan, bueno no siempre, pero desde hace mucho tiempo, servicios.
en la nube por decirlo de esta manera de CI CD estaba CircleCI por ejemplo GitLab también tenía sus pipelines online y otras herramientas Beanstalk y otro montón por ahí pero GitHub Actions como los programadores ya tenían su repositorio normalmente en GitHub comenzaron a integrarse en eso entonces tenemos eso que agradecerle a GitHub a Microsoft como tal como comunidad verdad los GitHub Actions
Juan (10:10)
Ok
Douglas (10:33)
pero también me gustó
lo que decís, yo mencioné antes todo desarrollador mínimo se involucra en los comandos que son para hacer el build de la aplicación, pero también luego idealmente mínimo revisas la salida, el output del pipeline y que te despliega tal versión, el build fue exitoso, la versión es la versión número tal, se desplegó al cluster de Kubernetes, el Helm, la versión tal.
verdad o se publicó la imagen con el tag tal y eso es esa información hay que saberla configurar en tu job para que la muestre y eso se vuelve o aún cuando hay un error no si hay un error falló por esto en particular y prestar atención a x cosas en tu build, tu test, en lo que necesites entonces esos ese resultado se construyó con comandos o con scripts
Y eso es ahí donde se vuelve interesante y tengamos eso en mente a medida vayamos viendo el uso de los comandos que le vamos a sugerir.
Juan (11:42)
esa información
es bien útil de hecho yo suelo incluirlo cuando se puede dependiendo del proyecto que cuando tenemos nuestro endpoint de health check o health o como se llame que me devuelva la información de cuál es el tag o el commit que está corriendo en esta versión que está corriendo en el servidor es algo que a mí me ha servido mucho para
debuggear diferentes situaciones o cuando fue la última vez que se actualizó la versión que está corriendo en el servidor porque bueno a mí me ha pasado que a veces pues pareciera que todo está bien pero por algún motivo la versión que está corriendo no es la que yo esperaba son de esos casos muy esporádicos que a veces sucede pero a raíz de eso pues ya uno empieza a adquirir estas mañas de ir agregando estos detalles pero que
De igual manera son muy útiles. Es información muy útil.
Douglas (12:41)
Sí, cuando son necesarios son extremadamente útiles, ¿verdad? Y si no están implementados, a veces es algo tan simple se vuelve un dolor de cabeza porque ya pasó el tiempo y cuando lo implemento ya no puedo ver la información anterior, Entonces sí, muy de acuerdo con vos. Y si te parece, comencemos con el primer comando, ¿verdad? Para que entremos en materia aquí. El primer comando es...
Juan (13:02)
Ok
Douglas (13:08)
si url o curl como lo quieran llamar algunos curl si yo suelo decirle curl o si yo le digo bastante también si url porque le digo si url porque para los que solo nos escuchan a la palabra a las siglas url que son las que usamos para dar una url no pónganle la letra c al principio no que es como del comando
Juan (13:14)
¡Yo le digo curro!
No,
Douglas (13:35)
y esta herramienta jugando en palabras sencillas le permite a un pipeline interactuar con servicios externos al pipeline ¿Verdad? ¿Por qué no? Porque te permite interactuar
ya sea con un MPI externo para recibir el estado de algo o también te permite descargar cosas externas en tu pipeline porque si URL miralo como tu navegador web pero en la terminal, un navegador web con la terminal en el cual podemos escoger en particular que queremos mostrar o que queremos desplegar porque si URL Juan nos permite
incluso imprimir solo los headers si queremos de un request y a veces pudieras hacer un llamado y validar de que si el llamado incluye el header X, hacer algo.
o agarrar el valor de ese header y con ese valor hacer algo, ¿verdad? O en el contenido, en el body de la respuesta, en el cuerpo de la respuesta, hacer algo con ellos. O muchas veces, Juan, el simple status de la respuesta. Si recibo un código 200, exitoso, entonces hacemos algo. Si me da un error 404, no existe algo, cosa. Entonces, miremoslo como nuestro navegador web en la terminal.
Juan (14:48)
Sí.
Douglas (15:01)
obviamente no vamos a ver videos o imágenes, pero para tratar de explicar la idea, es el navegador web en el terminal que me permite desplegar la información que quiero de un request. Ejemplos.
Juan (15:14)
yo con ese es el que hacía
lo que te mencionaba al inicio de hacer el trigger de un webhook le enviaba la petición mediante post con curl y listo muy muy fácil muy simple el comando
Douglas (15:28)
Y me gusta que lo hayas dado porque fíjate que justo ese es el primer ejemplo que yo tenía en un pipeline. Normalmente llamas el health check o algo de la aplicación que está corriendo. Muchos escenarios donde yo lo visto, bien similar al tuyo, con scroll o con CURL, se llama y se ve la versión que está corriendo en producción. Y entonces puedo validar que si esa versión es igual o menor,
Juan (15:32)
jejejeje
Douglas (15:57)
Perdón, sí, igual o menor que la que yo voy a publicar.
perdón me equivoqué igual lo mayor ahí está igual lo mayor que la que yo voy a publicar que no publique porque esto es importante o si vos tenés en producción la versión 1.5 y yo voy a publicar la 1.4 hay algo malo porque voy a publicar una versión menor alguien se equivoca con algo o alguien está corriendo mira qué importante alguien está corriendo sin querer un job viejo que ya publicó
Juan (16:01)
No aboná.
⁓
Douglas (16:28)
y entonces han corrido 2, 3 jobs adelante de este, pero alguien por error lo ejecutó y entonces vas a publicar una versión vieja y ahí generaría un problema, vas a publicar una versión anterior. Entonces un simple llamado con un CURL, ves la versión, la comparas y si es igual, porque si es la misma, ¿para qué vas a publicarlo? Si es igual o menor, no voy a permitir que se ejecute el despliegue o la publicación. Lo que yo voy a publicar...
que ser estrictamente mayor a lo que está ocurriendo en el servidor para que me deje hacerlo. una validación tan simple como esa Juan, verdad, o a veces si dependo de un servicio externo para publicar a mi aplicación con CURL puedo solamente llamar el endpoint y si me devuelve 200 está vivo, continuo con lo demás. Entonces
Este es como uno de los usos más comunes, curl no sirve para eso. Otro ejemplo Juan es para notificar servicios externos. Puede ser llamar a un webhook para triguerear un job externo, triguerear un, no sé, un clear del cache en Cloudflare o en tu CDN o en otro servicio. O algo muy común es mandar una notificación, perdón, por Slack.
yo lo uso bastante para eso Juan, mandaron una notificación por Slack que el despliegue terminó y ya sea que terminó bien o terminó con errores.
Juan (17:51)
Sí.
Douglas (18:00)
Entonces, cURL con el flag X mayúscula me permite escoger el método del request. cURL con el flag X mayúscula, post en mayúscula, de ese punto en adelante me deja enviar un post request. Y con el flag H mayúscula le envío los headers. Con el flag D minúscula, el cuerpo del JSON que le manda a Slack. Y de esa manera envío el request.
entonces, CURL en ese momento se vuelve muy útil y otro de los los los usos bien comunes, Juan, en pipelines también, es descargar artefacts o paquetes ya sea de internet o de otro servicio. Cuando vuelve a dar a CURL el flag o mayúscula, le está diciendo que el contenido en vez de mostrarlo en pantalla lo descargue.
Entonces, obviamente si es una página HTML, te va a bajar la HTML. Pero si estás descargando un tar, un zip, una imagen, te lo va a bajar en ese formato en lugar de desplegarlo en pantalla. Yo lo uso mucho, por ejemplo, cuando hubo builds para WordPress, ¿verdad? Ya mencionado en episodios anteriores, Juan, que en WordPress lo que tenemos en repositorio es lo que está dentro del directorio WP, Dash Content. Eso es lo que normalmente hacemos, es hacemos el build de los plugins.
build de los temas y build de todo lo que se necesita, pero cuando lo vamos a desplegar a un contenedor o a servidores, entonces con c url dash o mayúscula bajo la versión de WordPress que quiero.
la bajo local, la descomprimo, la sincronizo con el build de los temas y los plugins y con eso genero el artefact final todo el directorio de WordPress usando la versión de WordPress que está en línea, usando CURL para hacer la descarga de la aplicación. CURL nos sirve mucho para eso, algunos truquitos que les puedo mencionar, uno de ellos es usar cuando solo quiero saber el estado de
la respuesta, es un código 200, es un código 500, un código 400, algo, con el flag de menos S.
eso lo vuelve silencio, significa que no te muestra lo que viene, solamente va si el código 200 el comando se va a ejecutar de manera exitosa y el pipeline continúa, pero si el código no 200 va a ser un código diferente y probablemente va a haber un error por ahí, verdad, pero CURL1 es ese comando que en pipelines que de nuevo solo tenemos una terminal de Linux a nuestra disposición nos permite interactuar cosas que normalmente
de alguien como programador, inmediatamente piensa en una librería, verdad, o en algún código para hacer este tipo de interacciones y este tipo de cosas, con CURL lo podemos hacer con un solo comando o un par de comandos dentro de los jobs en el pipeline y obtener este tipo de resultados. Entonces, ya nos mencionaste vos Juan que ese CURL es que utilizabas.
Juan (21:15)
Sí.
Douglas (21:19)
para validar el health del servicio. No sé si los otros ejemplos que mencioné los había visto o escuchado antes en pipelines en específico con CURL.
Juan (21:31)
No mucho, el de Silence sí lo he escuchado por ahí. Lo que pasa es que como Curl tiene tantas... es muy versátil, un código, es un programa que te permite hacer muchas cosas, diferentes flags que se le pueden hacer. Bueno, buscamos información en internet y te dice, bueno, descarga esto, ya te dan el snippet code que dice Curl y con varios flags. Y pues yo confío en que los flags están bien y lo copio.
Douglas (21:56)
Sí, sí. Sí.
Juan (22:01)
Pero si suelo utilizarlo, nunca me he puesto a investigar mucho los flags que hay porque también otra forma en que lo suelo utilizar es para probar cuando estoy desarrollando, probar endpoints. Si bien hoy en día existen herramientas como postman y diferentes clones de postman, a veces pues solamente necesito revisar una llamada y no se será
No sé por qué, pero el hecho de abrir toda una aplicación que se tiene que conectar y loguearme me da pereza. Entonces con el curl llamo el endpoint, me muestro la respuesta y listo, sigo probando. sí, la verdad es que tiene muchas opciones. Ahora me surge una duda que no tiene nada que ver Douglas, pero nunca me la había cuestionado y no sé si vos tal vez sepas algo. ¿En qué se diferenciarían?
¿Cuál sería la ventaja o desventaja entre Curl y WGet? Que veo que siempre a veces también se muestran los ejemplos. Y pues como te digo nunca lo he analizado pero no sé, ¿qué sería?
Douglas (23:10)
Sí, Dol.
Sí, fíjate que puedes usar para WGET es mayormente para descargar el contenido en su gran mayoría, mientras que curl de nuevo podés verlo, es más como un browser en comando que WGET de nuevo es como para descargar contenido como tal. pudieras usar cualquiera de los dos en algunos escenarios, pero si vas a interactuar con APIs, por ejemplo, vas a hacer
Juan (23:25)
todo
Douglas (23:44)
un llamado a la API o inclusive si querés hacer un post.
método post un método delete y este tipo de métodos curl es la herramienta que necesitas para eso si lo que quieres es meramente descargar wget te va funcionar wget no está en la lista que damos hoy que bueno que lo mencionas normalmente sugerimos curl por la razón de que muchas veces estos comandos nos aseguramos de que estén instalados antes de correrlos en nuestros en nuestros pipelines entonces con curl tengo tanto para interactuar con lpi
diferentes métodos y también para descargar. Mientras que se usara curl solo para interactuar con comandos y wget para descargar, tengo que validar que dos comandos estén instalados. Entonces, por eso normalmente curl lo van a ver mucho más en CI-CD pipelines, pero esa es la diferencia mayormente. Ya si ocupas diferentes métodos, un pose, un delete, un patch, a la hora de interactuar con un API, con wget no es la herramienta correcta para eso.
Juan (24:48)
Si ahora que lo decís ya pues tiene sentido W y V, get, ese es método get y listo.
Douglas (24:54)
Sí, sí, sí,
No, pero qué bueno, qué bueno que se aclaró. Y de nuevo, Juan...
Curl es otro comando que yo uso mucho para troubleshooting cuando quiero probar endpoints, desde el contexto de un pipeline, ¿verdad? Es súper grande, pudiéramos pasar autenticación si lo necesitamos, ya sea al mandar un header con la autenticación o mandar un basic auth, usuario y password. Hay tanto que se puede hacer. Entonces, si necesitan esa interacción en su pipeline...
curl, c-url es el comando que necesitan, les recomiendo busquen el manpage, pídanle a la IA que les dé ejemplos que con él van a poder resolver todo llamado HTTP que necesiten hacia afuera, Entonces ese es el primero, si te parece Juan pasemos al segundo comando para que vayamos avanzando.
El segundo comando es, yo no sé cómo dicen esto en inglés, consideremos que no hablaba muy bien inglés cuando usaba estos comandos hace muchos años, este es el comando AUG.
Juan (25:55)
No,
Douglas (25:58)
OOG es a veces que hace uno como S o en ingles es, yo lo suelo decir AWK, yo es que yo escucho gente que dice OOG y gente que dice AWK en español es AWK, porque este comando es super importante en CI-CD pipelines y bastante utilizado a nivel personal yo lo uso y lo ven en muchos pipelines por ahí.
Y es que de nuevo, ya que en un pipeline lo que tenemos a nuestra disposición es una terminal de Linux, todo funciona con texto, ya sea logs que estamos viendo, el contenido de archivos, el resultado, el output de un comando o de una herramienta, todo funciona con contexto. Y es ahí donde AWK se vuelve una gran herramienta porque nos permite agarrar ese output y darle formato.
utilizar el valor una columna en específico que yo quiero que hace lo que wk 1 es agarrar cada línea y la divide en columnas por defecto lo que él usa para separar cada columna es un espacio entonces si vuestra una una línea que diga el bill se completó satisfactoriamente entonces la columna uno va a tener el valor de él
espacio es el separador, la columna 2 va a tener build ¿Verdad? espacio, la tercera columna va a tener C entonces él va agarrar cada espacio y va a poner eso en una columna y usando una variable yo le puedo decir imprimime la columna 4 entonces en ese caso el build se completó entonces me va a imprimir la palabra completó en ese caso ¿Verdad? pero con el flag menos F mayúscula yo le puedo decir que cambie ese
ese divisor de columnas por otro carácter. Por ejemplo, si estoy trabajando con un CSV, archivo, verdad, separado por comas, yo le puedo decir que en vez de espacio como separador utilice coma con el flagmen F mayúscula. Entonces puedo interactuar con un CSV.
con el flag-f e imprimir si en la columna 6 está el tamaño del build por ejemplo, le digo que imprima la columna 6. O a veces Juan, puedo tener un montón de key values en la misma línea. Entonces yo le puedo decir que en lugar de que usa espacio con la f mayúscula, que el divisor sea el signo igual.
¿Verdad?
utilizando el signo igual, entonces me las ingenio para que encuentre el valor que yo quiero que quiera encontrar. Entonces, ¿cómo usamos esto en un pipeline? Uno de ellos es para imprimir en la salida un valor en específico. De nuevo, corre un build de Golang, ejemplo, corre el binario y al final te genera un montón de información. El build se completó satisfactoriamente para
para un distro, no sé, ARM, digamos que estás haciendo un build para ARM, entonces...
Me voy a esa línea y utilizo AWK ya sea con espacios o ya sea con signos igual, analizo cuál es el resultado y le digo que me imprima la línea de versión. Entonces luego al final en mi job yo le puedo poner un resultado final que sea fácil para troubleshooting. La versión de Artifact que estamos deployando es la versión tal.
que con awk puse ese valor antes en una variable, yo creo que me estoy explicando, puse la variable, perdón, versión a publicar igual a, el output del build y usé awk para que parte en específica de esa línea le quiero asignar el valor y luego yo uso eso como output.
Ahora, haciendo eso mismo, Juan, yo puedo, por ejemplo, hacer una validación. Digamos que ya generaste el artefact que vas a publicar. Digamos que es una imagen de Docker. No vos trabajas mucho en Golan. Entonces, haces un build de la imagen y la tenés lista. Haces Docker build en el local. Pero has tenido problemas de que a veces no se completa bien o...
a no está todo listo o a veces alguien olvidó subir assets o olvidó subir algo y eso termina en producción. Entonces pues sabes que el tamaño mínimo de esa imagen es digamos por decir algo 12 megas. Pongámosle una verdad entonces yo puedo ser un Docker.
image ls a la imagen que estoy haciendo y me va a poner el tamaño en una de esas en una columna verdad entonces con a wk puedo agarrar la columna con el valor del tamaño del archivo del peso asignarlo una variable y entonces con eso en mi pabla yo puedo hacer una validación si el tamaño es menor a 12 megas no publicar y reportar un error porque algo no está bien ya sé por experiencia que lo mínimo tiene que ser 12 megas
por x o y emotivo entonces awk awk es esa herramienta que me permite separar el texto cada línea en columnas y entonces así poder agarrar
texto en medio de una línea y ya sea utilizarlo de nuevo para imprimirlo como resultado de un job lo cual de un trabajo en CICD lo cual es muy importante cuando estamos haciendo troubleshooting vos nos dijiste que te vas a los outputs de los pipelines para asegurar que corran bien los tests, el build y todo eso o también para agarrar ese valor en medio de una línea asignarlo a una variable y en base a eso hacer algo y de nuevo aquí hay muchos ejemplos muchas veces así agarro
el tag de una imagen, por ejemplo, con AWK, que un comando me da el tag de esa imagen, con AWK me aseguro de escoger únicamente el valor que quiero, asignarlo a una variable, y luego lo reemplazo en mi Helm Value, si estoy publicando Kubernetes, o en mi Docker Compose, si es un Docker Swarm, ¿verdad? Entonces, hay muchas estrategias, pero si lo que ustedes quieren es, en una salida de un comando, en una salida de una herramienta, agarrar valores que están en medio,
del texto o al principio incluso puede ser en cualquier parte de una línea porque lo estamos tratando como diferentes columnas, AWK es la herramienta que necesitan en su CI-CD Pipeline. No sé si habías interactuado o Juan con esta herramienta o la has visto en función, sobre todo en CI-CD Pipelines.
Juan (32:52)
No, debo admitir que esta herramienta si no la conocía, aunque la he visto en series de comandos que uno suele ejecutar para algo. Ya que yo utilizo Linux como mi computadora principal, pues muchas veces me veo utilizando estos comandos sin saber el trasfondo de cada uno de ellos. Yo solamente sé que si corro esto tengo que recibir esta respuesta.
y voy revisando, me parece muy interesante de hecho lo estaba revisando mientras hablabas en la terminal y te da incluso ejemplos, la misma herramienta te da ejemplos como utilizarla muy interesante la verdad, me parece de esas herramientas que la verdad no la había considerado porque pues no sé si la vas a mencionar pero también otra muy muy usada es grep y me parece
no es igual obviamente pero es similar, el hecho de poder como filtrar lo que quiero obtener aunque aquí es la base es columnas por lo que te voy entendiendo es en base a columnas y eso pues puede ser mucho más ventajoso dependiendo de lo que estamos trabajando pero sí definitivamente no la conocía a dubla me parece muy muy interesante esta herramienta que me imagino que ya viene por defecto instalada aquí en Linux
Douglas (34:20)
Sí, sí, es lo común, viene en nativo en Linux, de la misma manera, Grep, que la mencionaste, no la tengo en la lista, Grep es muy utilizada, Grep nos ayuda a filtrar líneas o a mostrar líneas con cierto valor en ellas. Muchas veces, y esto es un pro tip, ya que lo mencionas, con Grep podemos en un archivo grande, en nuestro pipeline, identificar la línea que queremos. Por ejemplo, quiero la línea que tenga la versión del archivo. Entonces, yo puedo hacer un cut,
o un grep directamente al log del build por ejemplo, al archivo con el log del build por ver, v e r equal por ejemplo. yo sé que eso me va a desplegar la línea únicamente donde está la versión del archivo con más cosas, pero la versión del build y a ese después de haberle hecho grep con un pipe le paso el awk para que me escoja solo la versión del archivo. Entonces ese es un protip.
Juan (35:00)
jajaja
ese texto.
Douglas (35:20)
se suele usar bastante combinado con Grep, de nuevo aunque no lo tengo acá, y esta herramienta Juan AWK, los ejemplos que di son más orientados a pipeline, como vos dijiste es súper poderoso, porque yo con AWK yo le puedo decir a la línea una vez que tengo imprimirme la columna 5 y la columna 8 y la columna 10 y esto me sirve mucho cuando estoy haciendo logs por ejemplo.
Estoy viendo log files y solo quiero ver la IP de quien hizo el request y quiero ver que pad llamó y quiero ver el código si fue 200, 302 o lo que sea. Entonces yo solo le digo que me imprima solo esas líneas y no tengo que estar lidiando con todo lo demás texto de log files sino que solo esas líneas y lo hice con AWK. Y AWK tiene otras cosas súper importantes, por ejemplo puedo validar campos.
Le puedo decir, si en la columna 8, por decir algo, está el status quo, ¿verdad? Entonces yo le puedo decir que si el status 8 es mayor a 499...
quiere decir que es de 500 para arriba y son server errors, son errores a nivel de servidor. Si el status code es mayor a 499, imprimime esa línea. Entonces de esa manera tengo solo el mensaje de errores que tienen errores en el servidor. Mientras que si hubiese usado grep y le doy grep 500, si el resultado es 502 o 503 o 504 no lo miro porque grep me targuetea
Juan (36:41)
errores de servidor.
Douglas (36:55)
específicamente solo eso. Entonces es una herramienta súper poderosa que podemos hacer todo un live, si les interesa déjenlo en los comentarios, solo con esta herramienta en particular, pero los ejemplos que les di al principio son normalmente como se usan en un CI-CD pipeline, se ocupan alguna funcionalidad como la que mencioné ahorita, pues también se puede incluir ahí.
Entonces, qué bueno Juan, no sé si te parece que avancemos entonces, ¿verdad? Ahora quiero juntar en uno solo dos comandos que son bien similares, muy similares, solo cambian el formato, ¿verdad? Que son jq y yq, o en español jq e yq. Aquí en mi país a la y le decimos también ye.
Juan (37:24)
Sí, claro.
por uno.
Douglas (37:45)
y q pero me confundo mucho porque jq en inglés es jq verdad y si al y q le digo y q y q perdón me voy a confundir demasiado y yo creo que ahorita con todo esto que dije confundí a las personas que son solo me escuchan juan así que lo voy a lo voy a repetir las herramientas son jq así esas dos letras y la otra y la otra herramienta es y q que hacen simple sencillamente nos ayudan jq
nos ayuda a parciar archivos con formato JSON, y Q nos ayuda a parciar e interactuar con archivos de formato Jamf ¿verdad? ¿Cómo es esto importante en un pipeline?
Pues cuando hemos usado, y aquí se complementa un poco, cuando hemos usado cURL, que fue el primer comando que les mostramos, para un API, por ejemplo, la lista de release de la lista de builds que tiene la aplicación, entonces eso nos va a venir el resultado en formato JSON. Entonces luego uso el comando, le paso ese JSON al comando jq.
y él me va a ayudar a parciar Jason. Aquí no voy a entrar mucho en detalles Juan porque básicamente es una sintaxis para interactuar con Jason, pero si tenemos por ejemplo el Jason nos trae builds y dentro de builds tiene una lista de cada uno de los builds, ¿verdad? Y dentro de cada uno de los builds tiene nombre, descripción en la lista y uno de ellos es la versión. Entonces yo voy a agarrar con JQ ese Jason y le voy a poner
punto builds, punto entre corchetes, entre brackets, porque como es una lista y entonces entre brackets le voy a poner cero, builds, entre bracket cero que significa que es el primer elemento de una lista, punto versión y entonces así me va a desplegar la versión del primero en esa lista.
o si le doy builds entre brackets uno va a ser el segundo elemento. Y entonces es una de maneras en que se interactúa. La idea es que eso nos va ayudar a parciar la respuesta a JSON para interactuar con ellas dentro de un pipeline, ¿verdad? Y de nuevo, esto es muy importante cuando estamos interactuando con endpoints de health check, cuando estamos interactuando con endpoints de cualquier información que estemos solicitando desde afuera por medio de un pipeline.
mismo con YQ, ¿verdad? Hace lo mismo. Muchas veces se utiliza para ver el contenido de, o cambiar el contenido en archivos de values files de, o yo lo uso así, De diplomas con Helm en Kubernetes o archivos y configuraciones de Docker Compose para Docker Swarm, ¿verdad? Ya sea que le pase la respuesta o le digo me vas a cambiar, por ejemplo, service.
Porque así es en Docker, para quienes entienden Docker Compose, ¿no? Y vos conocés la jerarquía, sé que me vas a entender, Service punto, digamos, php punto, ¿verdad? O punto tac.
punto y ya cambio ese valor. Haciendo eso, usé la jerarquía para cambiar el tag del servicio PHP dentro de Docker Compose. Estos son súper importantes, súper críticos. interactuamos con APIs, JQ es el campeón, es el rey. Cuando interactuamos con archivos de configuración, normalmente es YQ, porque suelen ser en JSON.
en Jaml, aunque si tenemos archivos de configuración en JSON pues usamos JQ, pero pues si, yo a nivel personal Juan nunca he visto un API que retorne a Jamls, antes retornaban a XML, ya no he visto en muchos años un API que me retorne a XML, ahora solo JSON, pero en fin, esta herramienta nos permite parcear estas respuestas e interactuar de una manera más eficiente y más clara con ellas en un job de CI-CD y de nuevo
Juan (41:43)
Sí.
Douglas (42:08)
Juan la pregunta, ¿había visto este comando, esta herramienta en CI-CDs?
Juan (42:14)
No, no, para nada. había visto el comando jq en diferentes scripts para los prompts de inteligencia artificial para indicarle correctamente a la IA que lo que queremos que haga, Pero fuera de eso no lo conocía. Me parece muy interesante el hecho de poder...
interactuar directamente. Algo que le recomiendo a la gente que nos está escuchando, si están escuchando en una computadora, vayan intentando escribir los comandos porque bueno, eso lo que estoy intentando yo mientras nos estás hablando Douglas y pues aquí tenía un archivito, un Docker Compose ahí random y me parece muy interesante el hecho de poder interactuar con él directamente desde la terminal. Algo que pues normalmente, bueno como programador ya lo dijiste del inicio
Uno piensa en bueno voy a descargar una librería que me permita hacer esto, permite hacer lo otro pero ya lo trae bueno las las instancias de Linux, verdad? Si están en Windows supongo que pueden utilizar WSL para probarlos pero bueno si realmente no los había visto en Pipelines como te decía pues ya no interactúo casi con eso sin embargo me parece muy interesante conocerlo porque
El valor que yo veo Douglas como desarrolladores, conocemos estos trucos, estas herramientas, es que podemos aportar valor al momento de, no sé, un brainstorming o está pasando algo en el servidor y no sabemos, entonces podemos sugerir, Y revisaron esto, revisaron lo otro, qué tal si utilizamos esta otra cosa. De nuevo, tal vez no es mía la responsabilidad de decidir si se hace o no.
Douglas (43:50)
Exacto,
Juan (44:05)
pero pues ahí lo suelto como una idea y tal vez, tal vez funciona ¿no? Muy interesante, me han gustado esos dos comandos y de hecho creo que los voy a tratar de utilizar un poco más en mi desarrollo aquí en local porque yo casi todo lo hago en la terminal, desarrollo y programa en la terminal y me navego todo en la terminal a pesar de que pues también tengo la parte gráfica. Muy buenos los comandos.
Douglas (44:33)
Si, primero gracias por el tip que dices de aconsejar a las personas que solamente nos escuchan que vayan buscando los comandos, Igual para las personas que también nos ven porque no tenemos ningún apoyo visual para esto, para ser justos con las personas que solo nos escuchan, me gusta ese tip, vayan buscándolo en su terminal, vayan probando, vayan buscando el manual en internet, ustedes escriben el comando y a la par la palabra man, m-a-n, no es, no se refiere a hombre, ¿verdad?
Juan (45:01)
No,
Douglas (45:03)
abreviación de manual en inglés, entonces pueden ir haciendo eso y los escribiendo y sí, por supuesto, verdad, lo que dijiste también Juan, la intención es esa, que el programador sepa qué herramientas hay de exposición.
al momento de trabajar en un CI-CD pipeline, al momento de trabajar con test, con builds, con despliegues, ¿verdad? Con el manejo de errores, con enviar notificaciones. Ya saben que es posible descargar un artifact que está en Internet en tu build. Ya sabes que es posible enviar una notificación con el resultado. Ya saben que es posible modificar archivos de... formato JSON o Jaml en un pipeline y esa es la idea, ¿no? Para quienes necesitan trabajar pipeline,
ya saben lo el poder que tienen con estos comandos de linux y para quienes solamente desarrollan pueden aportar pueden ya saben que su build proceso de build si pueden desplegar el resultado en un json en un jamal o de con key values más interactivos para que sea más fácil para el de operaciones que está haciendo el pipeline manipular esa operación y de eso se trata juan me gusta que lo haya mencionado entonces si te parece por tiempo
avancemos, verdad, tengo un cuarto comando, considerando que jq y q lo estoy poniendo como uno solo, un cuarto comando sería, este Juan, la pronunciación que yo digo es end, substitution, así lo pronuncio, end de environment y substitution de sustituir, pero se escribe
ENV SUBST en inglés o ENV de environment SUBST es como la abreviación así lo pronuncio yo, verdad ENV o environment substitution, verdad. Este comando que hace Juan, reemplaza variables de entorno dentro de archivos. ⁓
Juan (47:03)
Sí.
Douglas (47:12)
Para quienes no sepan, el sistema operativo tiene variables de entorno que existen en tu entorno. Existen esas variables.
Juan (47:19)
Sí.
Douglas (47:19)
por ejemplo la variable shell con mayúscula tiene la terminal que estás usando ya sea bash perdón ya sea seed sh o la terminal que sea dentro de tu entorno hay una variable que se llama pwd todo en mayúscula y esa siempre es igual al directorio en el que estás actualmente y también está la variable user que es igual al usuario en que estás y de la misma manera
hay más variables de entorno, entonces cuando ejecutamos este comando, substitution, eso lo que hace es que en el documento en que estoy, que obviamente lo llame con el comando, no es que va a ser en todos los documentos que existen, no, llamo el comando y le digo que documento es, y va a reemplazar las variables que encuentre dentro de ese documento,
y si esa variable existe en el entorno la va a reemplazar entonces si yo tengo un documento, un archivo de texto que diga hola mi nombre es variable user en mayúscula y actualmente estoy en el directorio variable $pw porque así hacemos referencia a una variable $pw si yo tengo eso y entonces yo corro el comando
in substitution y le doy ese archivo me va a mostrar en pantalla que en vez de user va a salir, va a desplegar lo mismo, hola mi nombre es Debaraona y estoy en el directorio home pleca de Debaraona por decir algo, va a reemplazar ese contenido dentro de la variable esa es la forma más sencilla en que lo puedo explicar espero que se esté entendiendo Juan así solo hablando al respecto verdad, ¿cómo se usa este comando? sí
Juan (49:16)
solo no sé si
lo podría repetir reemplaza el valor que está en un archivo en y también la variable de entorno o sólo lo que está en la variable de entorno a nivel de shell
Douglas (49:20)
.
sí, buena pregunta, ¿reemplaza las variables que encuentra dentro del archivo? de nuevo, tienes que encontrarlas con el mismo nombre, ¿no? dólar, el nombre, dentro del archivo, ¿replaza esas variables? si la variable existe en tu entorno, si la variable existe en tu entorno, vos haces una sesión, esa sesión carga variables de entorno, si la variable existe en tu entorno, entonces la vas a reemplazar dentro del archivo, si en el archivo están.
Pues déjame darte un ejemplo funcional a ver si con esto.
Juan (49:58)
No
va a reemplazar la que está en el entorno.
Douglas (50:06)
No, no, no, la reemplazan el archivo, la reemplazan tu output, sino la reemplazan el entorno, la reemplazan tu output, porque lo que querés es modificar tu archivo, ¿no? o modificar tu output, o crear uno nuevo, porque normalmente se usa con templates, con templates intermediarios. Entonces, voy a ponerte un ejemplo.
Juan (50:14)
si, si, si, correcto
Douglas (50:23)
Tienes un template de un Docker Compose, se llama Docker-compose.tpl.yaml, TPL que es por template, verdad. Entonces esto es template y vos tenes tu servicio de Nginx, con Nginx y luego abajo tu servicio de Go, con tu aplicación Go, verdad. Entonces vos tenes tag de la imagen igual a
y pones una variable todemayúscula image y en bajo tac pero le vas a poner a tu template $image y en bajo tac porque estás haciendo una variable y digamos que vos para hacer un deployment ⁓ y digamos que también en el Docker Compose luego le mandas al contenedor variables de entorno pero eso es para que la mandas al contenedor entonces vas a tener una variable dentro de tu Docker Compose que se llama env igual a
CI-VLD, ENV perdón, que es el environment que vas a definir en tu proceso de CI, en tu pipeline, entonces vas a tener esa variable ENV igual a $CI-ENV, mayúscula, verdad, entonces vos tenés tu template, entonces vos venís en tu pipeline y vos vas a hacer, para correr, vas a hacer export,
Juan (51:29)
Sí.
Douglas (51:46)
⁓ image y abajo tag igual a el tag que acabas de crear lo capturaste con awk antes venimos usando los comandos lo capturaste antes con awk entonces ahora vos vas a hacer export el export lo que hace es que va mandar esa variable a donde? mi entorno porque recordemos que env substitution va a reemplazar lo que está en el entorno si no está en el entorno no lo reemplaza ⁓
Juan (51:56)
Sí.
Douglas (52:16)
Entonces, de nuevo, entonces yo voy a hacer export para que la mande el entorno, image tag iguala la variable que con AWK agarra de la imagen, verdad. Y luego yo voy a hacer export a ci-env iguala digamos producción, porque sé que estoy corriendo desde producción. Entonces hice estos dos export y seguido yo voy a hacer el comando inf substitution.
Le voy a pasar el template como entrada y le voy a decir que la salida sea un Jaml file. Y entonces eso lo que va a hacer es que en el nuevo Jaml va a haber ya reemplazado, en lugar de mostrarme las variables, me va a mostrar los resultados.
que yo le dije, no sé si me está siguiendo en este contexto Juan, esperaría que sí, estoy tratando de hacerlo más descriptivo y claro que puedo, verdad, pero la idea es que usamos este comando para dentro de un template reemplazar variables y de esa manera de forma dinámica usando variables de entorno, o environment variables como se dice en inglés.
modifiquemos archivos de acuerdo a lo que necesitamos, así actualizamos la imagen, actualizamos la versión, así actualizamos el ambiente o lo que sea de manera dinámica usando este comando de environment substitution, verdad, o ENV sub-ST, así se escribe el comando. Este Juan es más complicado, da más miedo escucharlo que realmente lo que es. Es súper simple, solo tengo que asegurarme que las variables
expuestas al entorno eso es clave eso es clave porque a veces cuando estamos trabajando con jobs creamos variables locales
Juan (53:57)
Mm-hmm.
Douglas (54:02)
variables locales para tu job, no, tiene que estar en el entorno, solo exporto las variables al entorno y luego con el comando las reemplazo dentro del archivo, y así me queda un archivo final para utilizarlo para builds, para deploys, para utilizarlo para luego desplegarlo al usuario, si así lo quiero, porque con este comando Juan puedo desplegar solo al usuario un valor final, no quiero luego convertirlo en archivo, pero en fin, así funciona este comando.
Juan (54:02)
CC
Douglas (54:32)
y es el utilizado para trabajar de manera dinámica, para insertar de manera dinámica el contenido de variables en mis archivos. No sé si me expliqué, Juan, y si lo has visto en acción.
Juan (54:47)
No, para nada, para nada. verdad es que sí se escucha, como dijiste, un poco intimidante porque como que tiene muchos requerimientos y hay que hacer muchos pasos, pero... Pero sí, creo que al momento de empezar a utilizar estos comandos pues ya las personas uno se va como acostumbrando y ya sabes cómo es el trámite, ¿no? Como decimos. La verdad es que me parece interesante. El hecho de reemplazar valores en templates es algo que sí...
he visto que se hace mucho, yo no lo he hecho directamente por ejemplo algo que suele pasar es que vos lo explicaste la vez pasada pero olvidé los términos correctos donde tenemos la configuración de nuestro Helm o de nuestro servicio y estamos comparando si eso cambió entonces se trigue
el nuevo deployment o te dice que hay un nuevo deploy entonces supongo que esta es una opción de cómo hacer ese cambio de las configuraciones que hay y bueno si me gusta mucho seré honesto todavía me cuesta como entender en qué contexto es el correcto porque también lo que se me ocurre es que en vez de utilizar esto que requiere que esté en el entorno
pues se podría simplemente inyectar el valor, sería otra opción, bueno, cada cosa tiene su uso dependiendo del contexto en el que estamos y ahí pues ya es el hecho de que no tengo la experiencia pero sí, muy interesante el comando
Douglas (56:30)
Sí, sí, sí. Esto, tal cual está inyectando el valor, ¿verdad? Es una forma diferente. Mucha gente usa el comando set, por ejemplo, el set requiere de más cosas. Y en esto, en esto usando el environment substitution, este comando, si vas a hacer tu template, en el espacio donde pusiste la variable, solo ese espacio va a ser modificado. No tenés que preocuparte.
porque otro contenido hay en el archivo porque ahí puse yo la variable solo por ende solo ese comand, solo ese espacio va a ser modificado mientras que míralo de nuevo míralo no sé como como una plantilla de html y vos pusiste variables en medio verdad y entonces esas variables van a ser populadas con el el contenido que parcias del buckle míralo de esa manera si querés pero con archivos dentro de un de un
Juan (57:02)
Ok.
Sí.
Douglas (57:29)
de Linux, verdad, y en lugar de ser un backend o una base de datos que te trae los resultados, esto lee las variables de entorno de la sesión. Miralo de esa manera. Si usas, inyectaras concept, tenés que estar pendiente de poner un placeholder o de que no vayas a targetear más secciones del archivo que cumplan lo mismo y estás reemplazando más partes que no querías, ¿no? ¿Verdad? Entonces, en este...
Juan (57:55)
Sí.
Douglas (57:57)
de nuevo el que te sirva según tu contexto pero este
Haces un template con variables, pones las partes que quieres cambiar, de nuevo ideal para values files de home, ideal para manifestos de Kubernetes, ideal para Docker Compose, ideal para config files que queramos desplegar a aplicaciones. Hacemos el template, ponemos las variables donde queremos y el paso anterior, el único requisito de nuevo, el paso anterior es darles un export para que estén en el entorno. Ese es el único paso anterior, ¿verdad?
listo tengo el resultado final en base al template que yo tenía garantizando que nada más se va a modificar dentro de ese documento dentro de ese archivo más que la variable que yo puse específicamente ahí.
Juan (58:46)
si creo que con eso que dijiste ya me hizo click el hecho de que solo ese valor se va a reemplazar porque con Zed pues a veces puede pasar que si no hacemos bien la sintaxis va a ser otra cosa incluso con el AWK aunque es muy poderoso tenemos que saber de antemano cuál es la columna donde está el valor para obtenerlo aunque aquí no estamos modificando y con este pues simplemente es un template que está modificando el valor exacto ok creo que si ahora me queda mucho más claro
Douglas (59:14)
Exacto y me alegro si vos lo entendiste quedó más tranquilo porque sé que entonces se entendió y de nuevo si tienen esta necesidad en sus pipelines busquen el manual de cómo se utiliza el comando busquen ejemplos en línea pregúntenle a la inteligencia artificial porque esta es su mejor solución si quieren un template constante que no falla independientemente de que le agreguen o que le quiten al template, este es su solución ¿Verdad?
Entonces si te parece Juan, terminar tengo un comando más, de nuevo miren hay muchos, pero estos son como los, me parece que no todos son tan públicos, no todos se hablan de esta manera. Pero el último que voy a dar es el R-Sync, ¿verdad? R-Sync o R-Sync de sincronización, robo-sincronización. Lo que hace es, como su nombre dice, me sincroniza.
el contenido entre dos destinos, entre un, perdón, sí, en dos lugares, un destino, un origen, perdón, y un destino.
me sincroniza el contenido de un origen a un destino. Este archivo One R Sync utiliza el protocolo SSH para comunicarse con servidores remotos. Sirve para local, quiero aclararlo, pueden ser dos directorios que tengas en tu local y entonces no ocupas SSH, lo hace de manera local, pero es más común utilizarlo, aunque voy a dar ejemplos de los dos, es más común utilizarlo para hacer publicaciones
Remotas, este es el comando por excelencia Juan que se utiliza para publicar a servidores físicos, ya sean VMs o sean servidores físicos, pero al OS físico específicamente, que tenés tres web servers sirviendo tu contenido y cuando publicás a él, con R-Sync, le mandás el contenido a cada uno de estos archivos porque no tenés Docker o no tenés otro tipo de artefact, sino que los files directamente ahí instalados, ¿verdad? Entonces...
aclarando, este usa el protocolo SSH para comunicarse, entonces nuestro pipeline tiene que tener obviamente haber cargado llave de SSH o configuraciones de SSH para que se puedan conectar a los servidores que van a recibir los archivos sin password, pero esto es muy común, o sea, de nuevo, este es el comando usado mil por mil, la preferencia de todos, la comunidad desde hace más de una década,
porque yo tengo más de una década de usar este comando para publicar, es una práctica común, solo aclaro esto de SSH1 porque pues no es magia, hay una manera de conectarse de manera segura. Ahora, ¿qué otra bondad tiene R-Sync y por qué se prefiere comparado con otros comandos de copiar? R-Sync te permite enviar sólo la diferencia o sólo los archivos que han cambiado.
Juan (1:01:57)
jajaja
Douglas (1:02:14)
y no copiar todo de nuevo. Si vos estás en tu laptop, tu PC y vos agarrás un archivo, le das copy y le das pegar en el otro lugar, ya sea entre servidores en red o local, impenetratamente te aparece una alerta.
quiere reemplazar el contenido que está porque lo que hace es borrar lo que está y lo vuelve a copiar de nuevo entonces imagínate eso con algo que pese 120 megas en un pipeline que toma tiempo imagínate eso con algo que pese 5 gigas o que pese mucho más entonces
tomaría demasiado tiempo volver a copiar todo desde nuevo, no es eficiente, consumimos más ancho de banda, gastamos más ancho de banda por haber hecho eso, verdad, mientras que arcing, si a la hora que yo hice mi build, solo cambiaron tres archivos de 2000 que hay en el servidor, entonces él va mandar solamente esos tres archivos, obviamente los lee todos, mira cuál es el estado de este, mira cambió allá, no, no cambió, este, mira el estado acá, cambió allá, no,
cambió y así solo va a copiar lo que necesita y por eso Arsync es muy poderoso. Otra cosa que tiene Arsync Juan es que me permite a mí si en el origen un archivo se borró
también lo borran el destino y esto es otra de las razones por la cual es muy importante usarlo en mira es peligroso pero normalmente en tu código en tu código si vos hiciste algo y borraste digamos un plugin, eliminaste un plugin quieres que también se borre de tus servidores porque tu nuevo artifact lo tiene
Juan (1:03:43)
Suena bien peligroso eso.
Douglas (1:04:00)
Si lo vemos al ejemplo que te puse de trabajar en Windows o en Mac, donde vos le das copiar y pegar y te dice que querés reemplazar, eso te borra todo y te copia lo nuevo.
Juan (1:04:00)
Ok, sí.
Douglas (1:04:12)
entonces al final vos querés un comportamiento así, pero como R-Sync solo va a copiar lo nuevo y va a borrar lo que no existe, solo básicamente solo trabaja con lo que cambió. Igual esto es un flag, yo puedo quitarle el flag, es el flag guion guion delete.
es el que va a ser que también elimine en el destino lo que yo elimine acá. Si no lo pongo, nunca va a estar. Y también R-Sync One tiene un flag que se llama ____ dry ____ run, ¿verdad? Que es un dry run básicamente lo que hace es darme una lista de los archivos que van a cambiar, ya sea los que va a copiar o los que va a eliminar.
Juan (1:04:31)
Sí.
Es opcional.
No.
Douglas (1:04:57)
Entonces esto normalmente en despliegues críticos o sensitivos lo que se hace es que primero se corre el R-Sync en modo Drive Run que no va a hacer nada más que darme la lista y me la muestra en el pipeline, y miro todo lo que va a cambiar. Y si estoy...
tranquilo con lo que va a cambiar, entonces manualmente le doy click al job que hoy si va a ser el R-Sync definitivo, verdad, esa es la manera más común en que se utiliza en producción, en ambientes de prueba de stage, pre-prod, normalmente no hacemos eso, queremos que un solo haga el R-Sync, si algo falló, ⁓ pues es un ambiente de prueba, lo reparamos luego en producción, obviamente no queremos hacer eso, entonces en producción tenemos ese, el job suele llamarse de deploy prod drive run.
verdad y miro la lista estoy conforme entonces ya me voy al que dice solo deploy run y ya lo ejecuto y ya lo va a hacer y otra manera en la que usa que en la que se usa bastante R-Sync dentro de un pipeline es para construir el artefact final ahí local yo te mencioné que usaba CURL en WordPress que hacemos el build del directorio WP Content verdad y que entonces con CURL bajamos WordPress
Y luego sincronizamos el build de WP Content dentro del WordPress que acabo de bajar. Y entonces el comando que usamos ahí.
o el correcto usar en un pipeline es R-Sync para copiar de manera local el WP content dentro del artefacto de WordPress que acaba de bajar. De nuevo porque más rápido, más eficiente y si llegara a fallar él va a continuar desde donde quedó, no va a continuar desde el principio porque R-Sync solo copia lo que ha cambiado, ¿verdad? No vuelve a copiar todo desde el principio. Entonces de nuevo, eficiente en tiempo y super eficiente con el
ancho de banda y es por eso que R-Sync es el comando más utilizado. Entonces Juan este era el último comando yo creo que este me atrevo a decir espero no ponerte mal aquí pero me atrevo a decir que con este o si lo ha visto en pipelines o capaz que si lo ha si has trabajado con R-Sync.
Juan (1:07:07)
He intentado hacer mis configuraciones de backups con R-Sync También con el otro, con R-Clone Que si no estoy mal, R-Clone, la diferencia es que R-Clone trabaja en paralelo Mientras que R-Sync es secuencial o no se si es que solo utiliza un núcleo de procesador No recuerdo muy bien, pero mucha gente hablaba que con R-Clone también se puede hacer cosas en paralelo
Pero si, he intentado R-Sync nunca en un proyecto profesional, la verdad es que no. Pero si, si conozco el concepto y si conozco como se utiliza. Muy interesante como el ejemplo que das con Warpers. Realmente no sabía, ni siquiera lo había intentado copiar en un mismo ambiente local. Me imagino que es más eficiente que un simple copy, un CP.
banda CP.
Douglas (1:08:06)
Fíjate que no solo es más eficiente, Juan, sino que también el R-Sync me va a dar como te da una lista de cada archivo que copió. Entonces cuando yo quiero ir al output para un troubleshooting, alguien dice, fíjate que no se publicó tal cosa. Entonces con R-Sync yo puedo ver si el problema fue al momento de copiar interno dentro del artefact. Porque si no está en esa lista, quiere decir que no lo copió. O si sí está en la lista.
Juan (1:08:14)
Ok.
Sí, claro.
Douglas (1:08:32)
Ya sé que no fue ahí el problema y continuo con mi investigación. Mientras que un copy solo te dice que terminó, pero no te dice que fue lo que copió. Tendrías que tal vez listar los archivos antes y listar después. Aun así esto es más eficiente de nuevo porque me dice qué archivos me va a mostrar ahí solo los que cambiaron.
Entonces, definitivamente mucho más utilizado, mucho mejor, súper, súper recomendado, recordando que para ARSING hay que previamente, pero esto se hace solo una vez, tener ese HKEY listos instalados en el servidor. Cuando se copia local no se ocupa para nada, pero entre servidores, tenerlo listo, ¿verdad? Porque también con ARSING puedo hacer la copia, Juan, de un servidor a otro. Muchas veces hay gente que tiene un ambiente de pre-producción y ya publicó ahí antes. Y luego para asegurar que el
Juan (1:09:21)
Sí.
Douglas (1:09:22)
código de preproducción es, usan un arcing para que desde el CI de preproducción mande a los otros servidores, verdad, entonces por eso tiene esta connotación, pero bueno Juan miraba estos son los comandos que yo quería compartir, nos extendimos un poco porque estoy tratando de dar el mayor contexto posible, quiero para quienes solo nos escuchan, quiero recordarles,
Douglas (1:09:47)
Perdón, un pequeñito problema técnico. Pero bueno, Juan, como decía, ya estamos concluyendo, ¿verdad? Yo quiero recordarles si ustedes ven que uno de estos comandos identifican que en su flujo de trabajo uno de estos comandos solventa, soluciona el problema que están teniendo o el reto o la idea que tuvieron pero que tal vez no lo implementaron porque no sabían cuál era la mejor manera de ponerlo en práctica, ¿no? Escuchando el nombre del comando y tal vez el contexto en el que se utiliza.
tomes el tiempo de irlo a buscar por internet, ir a buscar ejemplos, estoy seguro que les va a hacer de mucho valor. Además estos comandos Juan...
muchos de ellos son antiguísimos, ¿verdad? Pero son comandos que en la actualidad los pipelines modernos los utilizan, ¿verdad? Así que esto es algo que en 2026 o en el momento en que lo escuchen les garantizo que seguirá siendo utilizado de manera estándar en la industria. Juan, para cerrar, sé si algún mensaje final, algún pensamiento final de tu parte.
Juan (1:10:51)
Simplemente para las personas que son programadores y que nos están escuchando, como decíamos al inicio, esto es de mucho valor porque normalmente no tenemos este acceso o no estamos involucrados en este tipo de procesos y esta información. Así que realmente vean el valor que nos está aportando el conocer estos comandos para saber muy bien cómo está. Y así podemos desarrollar aplicaciones que pueden integrarse mejor.
con estos comandos o que vayan a poder ser aprovechados por estos comandos y así puedes tener una mejor integración con todo el equipo, verdad es que vale la pena.
Douglas (1:11:27)
Me gusta, me gusta. Gracias por tus palabras finales. Gracias a las personas que nos ven y nos escuchan y llegaron hasta esta parte. Esperamos que hayan podido recibir el valor el cual teníamos o tenemos la intención de transmitirles. Nos veremos en el próximo episodio de Deben Ops. Bye.
Juan (1:11:45)
Nos vemos.