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.
Juan (00:00)
algo que siempre se menciona en Docker es el hecho de que elimina esa frase, esa famosa frase de mi máquina funciona. Y creo que la gran mayoría de personas que trabajamos en este ambiente nos ha pasado que...
hacemos algo, funciona en nuestra computadora pero cuando subimos eso al repositorio, en nuestros cambios otra persona lo descarga y ahora en el de él ya no funciona entonces con Docker eliminamos todo eso porque
como mencionabas, nos empaqueta todo, lo contiene, lo conteneriza y ese pequeño contenedor debería contener todo lo que necesita nuestra aplicación. que eso es algo que estoy seguro que todos han escuchado, pero es que es cierto, realmente eso es algo que nos ayuda muchísimo.
Bienvenidos a todos a los que nos acompañan con día con día en nuestros episodios. Hoy nos toca una plática más con mi amigo Douglas, donde vamos a hablar de algunos temas interesantes, un tema muy interesante en específico. Douglas, ¿cómo estás? Para mí es un placer tenerte aquí nuevamente un día más. ¿Qué tal?
Douglas (01:12)
Juan, ¿qué tal? ¿Cómo estás? Yo muy bien, gracias a Dios. Y como siempre, listo para discutir estos temas tan interesantes y compartir nuestras experiencias personales alrededor de estos temas.
Juan (01:24)
Excelente, excelente. verdad es que aquí esta va a ser otra plática donde creo que nos va a aportar una perspectiva muy interesante para los que solo somos desarrolladores. No lo digo de manera perspectiva, el solo.
Pero si es cierto que cuando nos enfocamos en el desarrollo nada más a veces perdemos de vista ciertos aspectos del total de nuestro mundo de IT y de tecnología. Así que vamos a entrar de lleno, pero antes como ha sido costumbre me gustaría agradecer a todos ustedes los que nos están viendo en estos episodios, a los que se suscriben a nuestros canales de YouTube,
Douglas (01:56)
mmm
Juan (02:12)
Spotify, Apple Podcasts y todas las plataformas en las que estamos lanzando, muchísimas gracias porque, nuevo, eso nos impulsa a seguir mejorando día con día. Esa es nuestra recompensa, ¿no Douglas?
Douglas (02:30)
Absolutamente,
infinitamente agradecido por el apoyo. Un like, ver, aunque sea una porción de estas charlas que tenemos, para nosotros es un gran apoyo. Y de nuevo, nuestra intención es compartir algo de valor para aquellas personas que nos ven y nos escuchan.
Juan (02:47)
Correcto. Estas son pláticas bastante largas de temas que a veces son complejos. Hemos tocado algunos temas que no son tan fáciles de digerir, con lo que ustedes nos apoyan nos da mucha alegría. Así.
Douglas (03:01)
Y qué gracioso, ¿verdad
Juan? Porque cuando comenzamos esto y decíamos, bueno, no creo que pasemos de 30 a 40 minutos platicando. Y más bien resulta que tenemos que controlarnos un poco al final y empezar a aterrizar porque la plática fluye bastante. qué bueno, entre más compartimos, más valor se transmite o esa es nuestra intención al menos. Y aquí estamos.
Juan (03:08)
Sí.
Sí, sí.
Sí, correcto. De hecho, si no tuviéramos un límite, creo que estaríamos todo el día platicando. Pero bueno, vamos a entrar de lleno al capítulo de hoy, a nuestro tema que nos compete para hoy. Y ese es uno que me gusta mucho en lo personal. ¿Por qué los profesionales de IT deberían aprender sobre contenedores? Y acá estamos hablando de todos los profesionales de IT, no solamente los sysadmin no solamente los backend, todos.
Douglas (03:27)
Sí.
Juan (03:53)
los contenedores y de hecho para aclarar no la mayor parte de la plática creo que vamos a ir encaminados hacia lo que es docker y los que no sepan
que es Docker, que creo que van a ser muy poquitos, pero los que no tengan muy claro que es Docker, sí vamos a dar un resumen, Pero también dejar en claro que no estamos, lo que queremos hablar no va específicamente con Docker, por eso decidimos utilizar el término de contenedores, ¿no? Que es lo más correcto, dejarlo más abierto a todas estas otras tecnologías que existen y que pueden llegar a existir. En estos días ya no se sabe, Douglas,
mañana pues surge la nueva, el docker killer entonces por eso lo vamos dejar así
Douglas (04:41)
AI containers, una
cosa así.
Juan (04:49)
No probado, pero bien. Así que, bien. Ese es el tema. que... Me gusta más siempre partir de una explicación simple, No voy a ir a darte algo extensa.
Douglas (04:50)
modelo, sí, sí es cierto.
Juan (05:13)
eso me gustaría simplemente para que se queden con la idea para los que muy poquitos que no sepan que es contenedores que es docker, bien básicamente creo que aquí tenemos que partir de algo anterior que era ⁓
Si, anterior, las VMs, las máquinas virtuales. Una máquina virtual te generaba un sistema operativo dentro de otro sistema operativo. Y podíamos tener varios, sin embargo estas máquinas virtuales venían con todas sus dependencias, con todo lo que necesitaba el sistema operativo. Y requerían muchos más recursos, de nuevo, necesitaban parte de nuestra RAM, del host, el procesador y todo. En cierto momento aparecieron con los cont
con esta nueva tecnología, en este caso Docker. Y ahora Docker, para hacer una analogía muy, muy simplista, es como tener una máquina virtual chiquitita, donde simplemente nos enfocamos en tener nuestra aplicación corriendo y pasamos de tener una VM con un tamaño de gigabytes en nuestro sistema, ahora tener un contenedor.
que solo pesa unos cuantos megas. De hecho, el contenedor más pequeñito, creo que es Alpine, anda por los 5 megas, si no me equivoco, algo por ahí. Y lo interesante de esto es que los contenedores, como dije, no son como una máquina virtual donde tiene todo. Aun así, podemos utilizar todas las funcionalidades o todos los beneficios de un sistema operativo, sea, podemos ingresar al contenedor y instalar más aplicaciones, dependencias, etcétera.
Entonces, la forma más simplista que yo puedo darle a alguien es que los contenedores es como una máquina virtual pequeñita y donde solo está corriendo nuestra, idealmente solo está corriendo nuestra aplicación. Pero Douglas, yo creo que tal vez tenés algo, un concepto más amplio o algo que quisieras añadir a...
Douglas (07:15)
No,
Sí, soy muchas veces en contra de que profundicemos en conceptos de temas tan populares como contenedores, aunque tal vez habrá uno dos que no ha escuchado mucho el tema. Al final contenedores y sobre todo con Docker es un tema bien popular y el Internet está lleno de lo que es la historia de los contenedores porque en realidad es un concepto bien viejo, ¿verdad? Desde hace varias décadas atrás y Docker lo que vino a hacer es... ⁓
es popularizarlo por diferentes herramientas y las interfaces que puso y la forma de compartir, etcétera. Docker lo vino a popularizar de esa manera y gracias a ellos por eso, definitivamente. Pero en lugar de invertir tanto tiempo en explicar cosas que ya están en internet, yo prefiero compartir experiencias y dar valor. Sin embargo, estoy muy de acuerdo con vos en que es válido...
Juan (08:03)
Sí.
Douglas (08:14)
dar el precedente, la base de donde partimos y que son contenedores. Vos diste una definición bien simplificada, súper simplificada y realmente creo que es lo necesario para continuar con la conversación. Si algo le voy a agregar porque el contenedor en realidad opera a nivel del kernel en el sistema operativo y es aquí donde, por eso no me gusta mucho a veces ahondar en temas populares, si fuera un tema no tan popular...
Juan (08:27)
Mm-hmm.
.
Douglas (08:41)
sé que mucha gente le va a recibir más valor, pero el kernel es básicamente el núcleo de Linux, ¿verdad? Y esto es lo que creó el Linux Torbo cuando él creó Linux, en realidad es el kernel, y las diferentes distribuciones se basan en ese kernel para crear su distribución, valga la redundancia. Pero, ¿cuál es el nivel del kernel? Pero, en resumen, vos dijiste como una máquina virtual pequeñita, para hacerlo todavía más simple es...
Juan (08:48)
Sí.
Douglas (09:10)
algo que contiene tu aplicación. Agarra tus dependencias, los paquetes que necesita tu aplicación, agarra los servicios que va a necesitar tu aplicación y los empaqueta y los aísla de los demás contenedores o los demás servicios que están corriendo en el contenedor. Si nos vamos al sistema operativo que está ajustando los contenedores y vos listas los servicios,
El sistema operativo va a ver todos los servicios que están corriendo en todos los contenedores.
Juan (09:40)
Sí.
Douglas (09:41)
pero tu contenedor va a ver solamente el servicio que está empaquetado en él. Entonces, de nuevo, no es la definición del libro tal cual y no vamos a hablar de la historia de los contenedores, pero para resumirlo y agregarle a lo que vos dijiste es un producto que empaqueta todas las dependencias y todos los servicios, el código, etcétera, que necesita mi aplicación o una aplicación en general para correr.
Juan (09:50)
No.
Excelente, sí. Correcto, totalmente de acuerdo con lo que mencionabas. Por eso me gusta cuando aportas extra lo que yo digo. Porque yo suelo simplificar mucho, suelo hacerlo de esa manera, para no complicarme mucho y enrollarme en conceptos. Yo suelo olvidar fechas, nombres, entonces por eso lo hago así.
Pero, pero bien, básicamente de ahí es donde parte todo esto. ¿Y por qué queremos hablar sobre los contenedores y Docker? Creo que es algo que vino a revolucionar mucho todo el ambiente de desarrollo y...
incluso los ambientes de producción y es que como mencionabas, Docker nos permite aislar nuestras aplicaciones, permite aislar los servicios que estamos instalando y eso nos da, creo yo, que abre muchas posibilidades de muchas cosas. Entonces, en Docker...
nos da mucha, sin embargo, a pesar de que nos restringen muchas cosas, también nos da flexibilidad porque nos permite montar lo que se le llaman los volúmenes, nos permite crear redes entre contenedores, nos permite ir versionando las imágenes de los contenedores, la imagen es básicamente la instrucción de cómo va a crearse el contenedor.
Y todo esto viene empaquetado en Docker y eso nos permite a nosotros empezar a desarrollar aplicaciones de otra manera, de una forma que es muy diferente a lo que teníamos antes. Yo recuerdo que cuando yo empezaba a programar por mi cuenta, fuera de la universidad, fuera de lo académico, empecé mucho con PHP.
entonces podrás recordar que había que instalar SAM o WAMP y todas estas cosas y no era tan complejo pero sí había que tener en cuenta muchas cosas dentro de sistema operativo y lo que a mí en lo personal no me gusta que ahora es lo que me encanta de Docker es que una vez yo terminaba de programar
Douglas (12:10)
Sí.
Juan (12:28)
todo seguía corriendo en mi computadora. que ahora lo que yo hago ya con Docker, cuando no estoy programando...
pues quito todo lo que no necesito entonces mi computadora podríamos decir que respira ya no necesita estar gastando recursos en un montón de bases de datos y dependencias y esto y lo otro no ahora simplemente es mientras los necesito ahí es donde levanto todo y es mucho más fácil de lo que era antes así que aquí me gustaría ir entrando un poco dublas en en esto no en cómo
desarrollar aplicaciones como crear un ambiente de desarrollo utilizando Docker.
Douglas (13:10)
Fijate Juan,
y disculpa que te interrumpa, pero quiero tal vez agregar por qué lo que dijimos cuando definimos brevemente qué es Docker y ahorita que vamos a hablar de las capacidades de contenedores. Docker es quien lo popularizó, pero las funcionalidades y las capacidades que tienen los contenedores y las redes entre ellos y los volúmenes, pero...
Juan (13:20)
Uhum.
Sí.
Douglas (13:36)
cuando mencionamos que contiene servicios y dependencia de tu aplicación, eso es tan grande y tan importante porque vos mencionaste que en tu ambiente local y vos comenzaste con PHP y creabas el famoso Wamp, donde en aquel tiempo era Apache, instalabas MySQL y instalabas PHP, etcétera, y vos mencionaste algo importante, no era tan complicado, verdad, y está bien.
Juan (13:57)
a
Douglas (14:06)
Pero, ¿qué ocurre? También tenías que instalar en tu computadora Python.
para correr algunas herramientas, comandos, servicios. También tenías que instalar Ruby para correr comandos y servicios de Ruby. Entonces, a medida vas instalando cada vez más cosas, hecho de tener ese montón de ambientes corriendo al mismo tiempo es complejo. Entonces, tener algo como los contenedores que me los separa porque al final no está instalado en mi sistema operativo,
Juan (14:14)
Mm-hmm.
Douglas (14:41)
empaquetado en un contenedor, empezar a tenerlos por separado, eso es poderoso, eso es bastante grande y bastante importante. Y lo menciono como para que se sienta el impacto, se sienta lo que realmente significa cuando decimos empaquetar una aplicación o servicio. Y ya que empaquetamos, eso es como cuando vas a la casa de tu mamá de visita y ella hizo almuerzo y sobró comida y lo empaquetas.
Juan (14:43)
Sí.
Douglas (15:10)
¿Cuál es el beneficio de eso? Que te lo llevas para la casa. Entonces lo siguiente es la portabilidad. hecho de que lo vos empaquetaste me lo mandas a mí y yo lo uso para desarrollar la portabilidad fácil, incluso que ya cuando lo usamos en flujos grandes, vamos viendo incluso a veces ambientes de prueba, desarrollo, hasta que lleguen ambientes de producción.
Sé que no queríamos ahondar mucho en conceptos, sin embargo, sí creo yo aclarar, por si alguien no lo ha terminado de entender, esas las razones por las cuales es tan poderoso y tan importante y tan usado, y por eso lo estamos recomendando para cualquier profesional en cualquier área de IT.
que si aún no sabe o no tiene experiencia, aprenda con tenedores y vos ahorita me dijiste de empezar a en ambientes de desarrollo y es que los con tenedores tienen su curva de aprendizaje casi sin importar el rol que tenés, el uso que vos le das como programador.
Juan (16:13)
Sí.
Douglas (16:17)
no va a ser necesariamente el uso que yo le doy como alguien de sistemas. Y mucha gente puede creer que yo como alguien de sistemas el uso que le doy es solamente configurar en servidores. Y no es cierto. A medida avanza la conversación...
vamos a ir dando ejemplos ambos y vamos a poder demostrar que más allá de configurar servidores, yo en el área de operaciones también lo uso como herramienta. quería aclarar esas cosas, me parece importante por si alguien no lo ha terminado de entender, que sepa por qué lo estamos recomendando.
Juan (16:49)
Sí, sí, correcto. parece muy bien que lo hayas aclarado. Y también creo que nuestra plática, o al menos mi intención, va a ser tratar de convencer a las personas que aún el día de hoy no utilizan Docker en su ambiente de desarrollo. Sé muy bien que hay personas que siguen trabajando sin utilizar contenedores y estoy seguro que algunos me van a decir, bueno, sí, pero es que no lo necesito.
tal vez, o tal vez sí. Entonces, por ahí vamos a ir tratando de dar nuestro punto de vista, el por qué yo hablo muy bien de los contenedores y por qué Douglas también. Douglas hace cosas muy interesantes y nos va a ir compartiendo sus casos. ⁓
Pero en el ambiente de desarrollo es importante, Douglas,
porque algo que siempre se menciona en Docker es el hecho de que elimina esa frase, esa famosa frase de mi máquina funciona. Y creo que la gran mayoría de personas que trabajamos en este ambiente nos ha pasado que...
Douglas (17:51)
Mm-hmm.
Juan (18:00)
hacemos algo, funciona en nuestra computadora pero cuando subimos eso al repositorio, en nuestros cambios otra persona lo descarga y ahora en el de él ya no funciona y puede ser porque estamos en sistemas operativos diferentes puede ser porque estamos en versiones de nuestro sistema operativo diferente o porque tenemos dependencias diferentes tal vez yo tenga una versión de Python vos tenes otra versión más actualizada entonces con Docker eliminamos todo eso porque
como mencionabas, nos empaqueta todo, lo contiene, lo conteneriza y ese pequeño contenedor debería contener todo lo que necesita nuestra aplicación. que eso es algo que estoy seguro que todos han escuchado, pero es que es cierto, realmente eso es algo que nos ayuda muchísimo.
Douglas (18:37)
Mm-hmm.
Juan (18:54)
Creo que...
definitivamente es algo que cambió la forma en que desarrollamos, o al menos para mí cambió mucho cómo yo manejo las dependencias, cómo yo instalo dependencias en el momento en que yo necesito instalar una dependencia que está digamos de manera global en mi computadora ya desde ahí yo ya genero un rechazo porque sé que va a ser más complicado
al momento de contenerizar dicha aplicación. Entonces ya va cambiando mi forma de ver todo lo que conlleva mi aplicación. Así que creo que eso es algo con lo que podemos iniciar siempre que vamos a hablar de contenedores. Es que elimina las dependencias rotas entre diferentes compañeros.
Douglas (19:26)
sin.
Juan (19:46)
Creo que ya lo mencioné en un capítulo anterior pero al menos para mí la primera vez que yo tuve una experiencia con Docker fue cuando yo estaba buscando cómo instalar Windows Server en Mac OS y me topé con que no se podía. No sé si hoy en día se puede, no estoy tan al tanto, no vuelto a utilizarlo pero en aquel entonces no se podía y pues no supe qué hacer hasta que por ahí en un foro
alguien decía pues esta está aquí está la imagen de docker 2018 más o menos si no suena tan lejos pero si ya han pasado unos cuantos si es bastante
Douglas (20:20)
¿Cómo qué año fue eso Juan?
Ok, ok.
7 años en tecnología son 7 décadas.
Juan (20:40)
Y esa es la cuestión que tal vez antes no había también tanta... No se hablaba tanto de Docker Pero bien, para mí en ese momento empecé a saber sobre esto Y eso fue mi primer acercamiento No creé una imagen de Docker, no instalé un ambiente, no Simplemente utilicé algo en una máquina donde no se podía Porque estaba Dockerizado, así que no importaba que fuese un Windows Server
y de ahí para allá pues empecé a investigar y pues me abrió los ojos cómo funcionaba. Yo creo que para vos, tal vez Douglas, me imagino que la sorpresa o la impresión fue un poco diferente porque al menos yo no tenía esa experiencia de estar, digamos, configurando una máquina virtual. Así que no entendía muy bien las comparativas.
Pero vos ya tenías un poco más de experiencia en tu camino profesional. Así que me imagino que cuando empezaste a ver a Docker, debe haber sido como, wow, esto es increíble, me imagino. O tal vez tuviste rechazo, ⁓ no sé.
Douglas (21:55)
No, para nada. que realmente Juan trato de tener una mente abierta ante la tecnología y yo soy de los que piensan que cada herramienta tiene su nicho o su grupo de personas a quien le sirve. Y a veces nos sorprendemos y somos nosotros mismos en los que en algún punto nos beneficia o nos sirve. Cuando yo comencé a ver Docker...
no tenía todavía el Dockerfile como tal definido, sino que vos tenías que correr la imagen, instalabas todo, si era apt install, los dependencias y configurabas y luego corrías un comando para, en base a lo que hiciste ahí, generar la imagen. Casi como un snapshot de un AVM.
donde antes te metías manualmente y creabas un snapshot y ese snapshot se volvía imagen para replicarla bien. Así comenzó, luego Docker implementó lo es el Dockerfile para con instrucciones y poder salvar en version control en tu repositorio de Git reproducir la imagen. cuando yo, respondiendo a tu pregunta...
Juan (22:41)
Sí... Ajá...
Sí.
Douglas (23:04)
Yo traté de verlo con mente más abierta y comencé a verle de a poco el uso. Sin embargo, me sentía un poco celoso de ponerlo en producción, pero era más que todo inicialmente la falta de conocimiento. Jamás voy a poner algo en producción que yo no entiendo 100%.
Juan (23:26)
Ok,
ok.
Douglas (23:27)
Sin
embargo, de a poco fui adaptando. Pero sí siento, fíjate Juan, que entre las personas que somos de sistemas, sysadmins o DevOps, engineers, a veces existe un poco más...
mente abierta en cuanto a adoptar nuevas tecnologías comparado con developers. Al menos eso ha sido mi experiencia, no quiero ofender a nadie, no quiero que nadie se sienta atacado. Eso ha sido mi experiencia y no que tengan una mala actitud, sino que son como más recelosos y más cerrados en su tecnología. Y a veces hasta compiten entre lenguajes los programadores que dicen, no, que Ross es mejor o que Golland es mejor o que...
Juan (23:47)
Ok.
Sí.
Douglas (24:09)
de nuevo, yo creo que cada lenguaje tiene su aplicación y su rubro, pero entonces en cuestión de contenedores yo recuerdo y también lo mencionaba en un episodio anterior cuando en este trabajo donde vos y yo nos conocimos y empezamos a implementar contenedores, yo me volví un evangelista.
Juan (24:20)
Mm-hmm.
Douglas (24:25)
de Docker y digo evangelista de Docker porque tuve la oportunidad de ir a un DockerCon que son las conferencias de Docker como tal y entonces yo pregunté cómo hacer para que todos se montaran al bus de implementar contenedores y la sugerencia que me dieron fue ser evangelista de Docker y eso es lo que yo hice y realmente que...
Juan (24:41)
Mm-hmm.
Douglas (24:51)
los developers eran como que los más cerrados en tratar de entender los beneficios para su ambiente de desarrollo justo por lo que vos decías. Si me corre bien instalar manual el lamp en mi local, ¿por qué voy a invertir tiempo en contenedores? Y si vos haces algo en un minuto y eso está súper bueno, pero si yo te digo que lo puedes hacer en 10 segundos, ¿por qué no tomarlo? sea, vos decís, en un minuto ya acabó mi día.
Juan (25:13)
Sí.
Douglas (25:19)
Sí, está bien, no estás equivocado, pero ¿por qué no hacerlo en diez segundos si es posible hacerlo en diez segundos? Y tal vez es lo que yo trataba de pensar. Estoy usando el tiempo como ejemplo aquí, pero sí en mi... No, por supuesto. Por supuesto, pero solo lo menciono como una métrica. Al final sí es fácil, pero si lo puedes hacer más fácil, se te va a mejorar la colaboración, etcétera. Entonces...
Juan (25:25)
Mm-hmm.
Sí, hay más factores aparte del tiempo también. Hay muchos, sí, Una métrica.
Douglas (25:48)
En mi experiencia yo trate de verlo con mente más abierta, me tomó años llevarlo a producción, quiero aclarar, me tomó años. Sin embargo la adopción propia sí fue relativamente rápida y me volví ese evangelista mayormente con programadores y creo yo que fueron muy poquitos de un grupo bien grande, a vos te consta Juan, de un grupo bien grande de programadores.
fueron contados los que empezaron a utilizarlo más y los que empezaron a montarse al bus de contenedores en ese momento.
Juan (26:24)
sí, yo tengo unas ideas de por qué mucha gente no le gusta tal vez podemos ir dando algunos ejemplos sí, muy interesante
Tu perspectiva, no lo había pensado, Douglas, en cómo los desarrolladores a veces son renuentes a este tipo de cambios. A veces se da porque, como decís, como que tienen... Yo siempre lo comparo como ser fanático de un equipo de fútbol. Y es el hecho de esto es lo que hay y de aquí no me mueve nadie. Nadie va a venir a decirme que lo otro es mejor. Pero bueno, es parte de ir...
Douglas (27:07)
Sí, sí,
Juan (27:11)
de ir cambiando. Ahora, para las personas que en este caso los desarrolladores que tal vez aún así están pensando, no, a mí no me funciona, yo trabajo digamos en front-end, así que no es igual que en backend, la verdad es que es lo mismo para todos. El primer ejemplo que les puedo dar es como el que acabo de mencionar, donde yo tenía una dependencia, una base de datos.
si soy frontend, ya sea de frontend web o frontend mobile, muy probablemente me tengo que conectar a un backend, muy probablemente me tengo que conectar a S3, a diferentes servicios, ¿no? Me tengo que conectar y es un poco complicado tener que trabajar todo en la nube, se puede, yo he trabajado mucho donde todo me conecto al... solo tengo mi servicio o aplicación que estoy trabajando y lo demás está en la nube, pero...
A veces es mejor, en lo personal a veces prefiero trabajar todo local y simplemente con Docker yo levanto mis dependencias. que imagínense el hecho de yo estar trabajando en mi aplicación en React y...
todas las demás dependencias, ya sea el backend, s3 y cualquier otro servicio lo podemos contenerizar lo levantamos y ahora yo puedo hacer llamados desde mi aplicación frontend hacia estos servicios que claro, esto estaría lo ideal es que esté controlado
a través de variables de entorno donde yo le puedo indicar cuál es la url en vez de ir hacia el servidor en la nube ahora va hacia mi local pero la idea aquí es que
tenemos un ambiente que se mantiene por sí solo y digamos que sucede algo, Se va el internet, no tenemos conexión, entonces yo aún así puedo seguir trabajando en lo que estoy. Así que eso es algo que de entrada yo creo que nos ayuda muchísimo en nuestro ambiente de desarrollo. Podemos ir profundizando más en los diferentes métodos que existen para el ambiente de desarrollo, pero creo que con eso...
cualquier persona puede empezar y nos elimina el hecho de tener que tener todas estas dependencias, como decía antes, que están corriendo en nuestra computadora. Son muy pocas las personas que pueden tener una computadora solo para trabajo y otra para su uso personal. que el 99 % de nosotros utilizamos la misma computadora para todo.
y más los que trabajamos de manera remota tenemos que utilizar la misma computadora y pues es más cómodo de esa manera donde tengo mis dependencias corriendo y sólo tengo lo más puntual instalado en mi computadora sólo algunas cositas lo demás está en cóndor en docker
Douglas (30:13)
Sí, me gustó lo que dijiste, Juan, y el ejemplo que pusiste es que tal vez alguien dice, no, yo solo soy front-end developer, yo solo necesito React y JavaScript, HTML, CSS, etcétera. No necesito tanto, pero en realidad a veces pueden ser los más beneficiados. Y es que todos nos beneficiamos de ello porque, como vos mencionás, podemos replicar de manera local.
pero a la vez de manera aislada, sin afectarlo que tengo corriendo en mi computadora, toda la aplicación y las diferentes piezas de la aplicación. Incluso yo como alguien de sistemas, porque a veces eso creo yo que de las cosas que existen los developers, fíjate Juan y eso capto, que sienten que la parte de contenedores lo tiene que hacer el de sistemas porque ellos no van a configurar el sistema operativo.
Juan (31:08)
⁓ sí.
Douglas (31:08)
Ellos solo van a desarrollar
el código. Y de nuevo, yo creo que es una mentalidad errónea. Tenemos que conocer la capa de arriba y la capa de abajo. Yo lo he mencionado antes de lo que trabajamos. Pero fíjate que yo como alguien de sistema, y te voy a dar un ejemplo rapidito, en alguna ocasión estaba trabajando con, me pidieron hacer unos redirects en NGINX.
Pero había funcionalidades en el código y eso fue para un sitio de WordPress por cierto. Había funcionalidades en el código que podían ser afectadas. yo descargue, cloné el repositorio, hice todo el proceso de build y lo instalé local con Docker como estaba ya preparado el repositorio para hacerlo. Y entonces pude tener todo funcionando y probar mis redirects.
Juan (31:36)
Ok.
Douglas (31:58)
para que la parte de NGINX luego mandara a WordPress y asegurarme de que iba a funcionar como tendría que ser. No soy programador. Cualquiera diría, no tengo la necesidad de tener el ambiente local de desarrollo de ese sitio web.
Juan (32:05)
Sí.
Douglas (32:13)
porque yo no voy a desarrollar código. Pero me sirvió tanto que tuvieran los developers dockerizado el ambiente de desarrollo, ¿verdad? Y en minutos, o sea, cuando te digo minutos, como en 20 minutos máximo, y porque estuve a prueba y error unas cositas ahí, tenía el ambiente local de desarrollo corriendo, trabajé mis redirects, y en efecto me topé con ciertas cosas que pude corregir y luego pude publicar a los diferentes ambientes de prueba hasta que llegó a producción.
Entonces estoy dando este ejemplo porque es más fácil. Vos dijiste el front end developer, en lugar de esperar que me den permiso al API del ambiente de prueba, lo corres local y empezás a programar, no te atrasás. Entonces eso quería, me gustó eso que mencionás y lo quiero resaltar más de que en realidad...
Juan (32:56)
Sí.
Douglas (33:08)
No importa que área está, más nos beneficia porque rapidito nos corre local todas las piezas de la aplicación, todos los diferentes componentes de la aplicación y me permite a mí enfocarme en mi trabajo. Y eso creo yo que vale la pena resaltarlo.
Juan (33:22)
Sí.
Si, si, correcto, verdad es que nos trae más solamente beneficios. Claro, hay ciertos, ¿cómo decirlo? Tal vez contratiempos o ciertos contras, ¿no? Al momento de dockerizar, pero en su mayoría son ventajas. Y probablemente hay muchas personas que trabajan todo conectándose a la nube. Veas que tal vez utilizan un serverless, servicio serverless. Sin embargo, yo he trabajado
también de esa manera y lo que a mí no me gusta en lo personal de Ulas de trabajar conectado a una base de datos en la nube o cualquier cosa es que si estamos en un equipo de trabajo que ya tiene dos o tres más personas utilizando el mismo recurso ya eso me limita a mí la cantidad de cambios que puedo hacer porque si yo
Vamos a dar el ejemplo, estoy trabajando con una base de datos que está en la nube y otras personas se conectan a la misma base de datos, cada quien trabajando su feature aparte.
Pero el hecho de que estamos utilizando la misma base de datos, yo no puedo ir y borrar todos los datos. O no puedo ir y cambiar una columna porque quiero hacer ciertos cambios. En cambio, si lo tengo de manera local, yo puedo hacer y deshacer todo y puedo ir probando diferentes casos de uso. Tal vez yo quiero probar qué sucede cuando no hay datos en la base de datos. Así que esa es una gran ventaja de
Douglas (34:45)
Sí.
Juan (34:59)
de tener todo dockerizado y en un ambiente local. eso me refería. Ahora, la otra, digamos que dando el siguiente paso.
de este tipo de ambientes y aquí Google así voy a admitir ante la audiencia que no soy el más fanático de trabajar así con Docker, sin embargo existe la opción y lo he utilizado en ciertas ocasiones y es que ya no sólo tenemos las dependencias en Docker sino que nuestro
digamos así, nuestro ambiente, véase si estás trabajando en front-end, sería todo lo que es el Node.js o si yo estoy trabajando con Go, todo lo que es Go está contenerizado. Todo eso está contenerizado y lo único que hacemos es hacer un mount, básicamente es mapear un directorio de mi PC hacia un directorio dentro del contenedor.
Y de esa manera ya, digamos que no tengo nada instalado en mi computadora excepto Docker. Esa es otra forma en la que podemos, para mí es como uno de los escalones más altos en los que podemos trabajar de esta manera. Tiene sus contratiempos, tiene sus debilidades, pero también tiene muchos beneficios. de nuevo, lo he utilizado en un par de ocasiones y sí tiene como mencionaba,
Douglas (36:07)
Mm-hmm.
Juan (36:32)
muchas ventajas al momento más que todo al momento de tener que utilizar diferentes versiones y quieres probar diferentes versiones por ejemplo en go al menos hoy en día si ya se puede instalar diferentes versiones de go en tu misma computadora
pero antes no era tan fácil así que con contenedores podrías tener un contenedor con una versión y luego utilizar otro contenedor de una versión más alta y empezás a hacer pruebas de, necesito actualizar mi versión de Go pero lo voy a probar aquí para ver si todo funciona y hay muchos casos de uso que se pueden hacer de esta manera pero sí requiere un poco más de entendimiento como trabaja Docker, cuáles son las limitantes y cómo organizar todo, ¿no? pero se puede hacer
Douglas (37:16)
Sí.
Juan (37:18)
se puede hacer de esa manera. Y no solo funciona con Go, se puede hacer con cualquiera, ¿no? Python. Creo que Python es un gran ejemplo porque muchas veces, o sea, tenemos instalado Python en nuestra computadora y las versiones de Python generan muchos problemas a veces, más cuando no lo configuramos bien en nuestro ambiente de desarrollo, Pero con los contenedores funciona.
Douglas (37:27)
Sí.
Sí, en Linux, perdón, pudiera
quebrarte ciertos comandos.
Juan (37:45)
Sí,
Douglas (37:46)
que vienen en Linux, que en realidad son
Juan (37:46)
me ha pasado.
Douglas (37:49)
scripts en Python. Y si vos actualizas a una versión de Python para X funcionalidades, si estás desarrollando en Python, pudieras quebrar incluso la funcionalidad del sistema operativo. Y ahí es donde aún, como vos decías, Python ha implementado cosas como los ambientes virtuales, los virtual environments, para que aisles, ¿verdad? Y eso es muy bueno en Python, pero en contenedores todavía mucho mejor.
Juan (37:59)
Sí.
Sí.
Sí, es mucho más fácil de cierta manera, ¿no? Pero bien, se puede hacer de esa forma. bien, lo otro hablando nuevamente de tener todo tu ambiente. En este caso, yo me refiero a tener todo el stack.
Douglas (38:19)
Sí.
Juan (38:32)
en contenedores. Creo que aquí lo que yo siempre recomiendo, no sé que me puedes decir dudas, pero yo siempre recomiendo tener todo en Docker Compose. Bueno, ahora es más fácil porque antes tenías que escribir docker-compose, ahora ya lo simplificaron a solamente compose.yml.
En los compose files podemos tener, para los que no estén muy familiarizados, podemos tener las instrucciones de todos los servicios que necesitamos y podemos especificar cuál es la imagen que vamos a utilizar, cuáles son las variables de entorno, cuáles son los mounts, que no encuentro una palabra en español para mounts, pero...
cuáles son los puertos que vamos a exponer porque algo que no mencionábamos pero por si acaso si bien los contenedores están aislados podemos también exponer partes de nuestro contenedor hacia la máquina host, este caso nuestra computadora como lo que son los puertos
Douglas (39:40)
u otros contenedores.
Juan (39:41)
otros contenedores, hacer que un contenedor sea visible para otros en otros puertos y así. Pero lo más fácil es tener todo en un Docker Compose File porque número uno, tenemos a la vista todo lo que necesita el servicio y número dos, es más fácil de gestionar las versiones en Git o cualquier otro gestor de versiones, de archivos.
así que sí, Docker Compose también es algo que se le fue añadiendo y ha ido evolucionando hoy en día es mucho más fácil que lo que estaba antes y tiene muchas, muchas fácil, perdón, funcionalidades y capacidades que tiene el Compose File.
Douglas (40:29)
Sí, ahí Juan, a nivel personal y de nuevo en esta parte de evangelista de Docker, yo creo que no hay mejor herramienta que Docker Compose. Lo que vos mencionabas, el hecho de levantar los diferentes servicios, levantar bases de datos, levantar API.
Juan (40:40)
Sí.
Douglas (40:48)
front-end, incluso si querés tener un proxy encima para simular cómo serían los balas en la producción, levantás esos cuatro servicios que están en un archivo Jaml que se puede publicar al tu Git Repository y eso lo que me ayudó a mí en el ejemplo que yo di, a levantar todo el ambiente de desarrollo en 15 minutos y hacer mis pruebas, pero como lo trae todo tan junto y encima de estos beneficios que acabo de decir, creo que de los más grandes y más importantes es
Juan (41:08)
Mhmm.
Douglas (41:19)
que permite que los servicios separados se comuniquen entre ellos por el nombre del servicio. A la base de datos le puedes poner como nombre de servicio literalmente base de datos.
Juan (41:24)
Sí.
Sí.
Douglas (41:29)
Entonces dentro del servicio
de API, en las credenciales de conectividad, base de datos, le pones base de datos porque así se llama el servicio y él sabe cómo comunicarse. Al API le pones API. Entonces en el front-end, los llamados al API, vos solo pones API como dirección, como URL en lugar de IP.
Juan (41:44)
siempre
y cuando estén dentro del mismo ambiente, que esté contenerizado
Douglas (41:53)
Si, el mismo docker compose file,
por eso te digo que docker compose, lo que vos estas sugiriendo, mi opinión también es la mejor forma de hacerlo, porque como es el mismo docker compose files, dentro de todos los servicios que levantes ahí, te referís al otro y te comunicas con el otro por el nombre del servicio, entonces...
Eso facilita tanto las cosas para desarrollo, developers, aislando y yo voy a dar un poco más de ejemplo de esto más adelante, por si trabajas con Python y esta aplicación tiene Python 3.12 y estás trabajando con otra aplicación más adelante que tiene Python un poco más antiguo, 3.9.
los tenés todo el stack separado y fácilmente switchás de versiones de Python, dependiendo de qué aplicación trabajás con tu Docker Compose file.
Juan (42:46)
Sí, creo que claro, hay otras alternativas para poder levantar todos los servicios. Podríamos tener un Bash Script que haga todo, instale todo en nuestra computadora. Pero cuál es el punto de diferencia, al menos para mí como desarrollador.
Yo no conozco tan bien cómo funcionan los bash script, el scripting en bash. En cambio, en un compose file es fácil leer la sintaxis porque está hecho con Jaml.
así que es más descriptivo y aún si no entendemos lo que hace cada uno de los servicios que están descritos va a ser muy fácil pues leerlo y saber que estamos levantando una base de datos, una API, un frontend y es muy muy fácil y esto nos permite hacer muchas cosas, muchas cosas yo aquí
como desarrollador por lo que he visto en mi experiencia yo lo que siempre trato de hacer con los compose files es tenerlos agruparlos tal vez no vamos a haber tentado en tener un solo compose file y esto nos permite solamente correr un comando en la terminal docker compose op pero creo que lo mejor es irlos separando en
al menos yo lo veo como por dominios o por lo que es la similitud entre cada uno de los servicios claro tal vez esto va más para aquellos sistemas que son muy grandes donde tenemos que te puedo decir un compose file que tiene cinco servicios y tal vez tenemos 10 docker compose files entonces cuando tenemos eso creo que vale mucho la pena tenerlos agrupados
porque nos permite manejar mucho mejor este aislamiento del que estábamos hablando al inicio. En cambio, si los tenemos en un solo Docker Compose, pues podríamos generar una red que se hable entre todos ellos. Y tal vez no es eso lo que queremos. ¿Qué hay formas de hacerlo? Hay formas de crear redes dentro del ambiente de Docker y que estas redes puedan ser utilizadas por diferentes contenedores y así pueden,
entre ellos y así lo necesitamos. Pero... No, no, sí.
Douglas (45:10)
Fíjate Juan, y disculpa que te interrumpa porque posiblemente voy
a discrepar con vos, posiblemente, pero quiero preguntarte cómo va orientado tu consejo. Pues te estás refiriendo a separar el Docker Compose por cada aplicación o por cada repositorio prácticamente. O sea, si yo estoy front-end...
Juan (45:17)
Ok.
Douglas (45:33)
y tengo mi... trabajando el sitio X, ¿verdad? Entonces el Docker Compose Files me tiene una versión del API, me tiene una versión de la base de datos, me tiene una versión del front-end y entonces ahí trabajo. Entonces vos estás diciendo tener como que un Docker Compose por proyecto o por repositorio prácticamente.
o dentro de un mismo repositorio, si tiene bastantes componentes, varios Docker Compose files. ¿Hacia dónde va dirigido tu consejo ahí?
Juan (46:07)
va a depender de cómo está estructurado cada uno de los proyectos, claramente, ¿verdad? Pero va más orientado a cuál es la cercanía de estos servicios. Por ejemplo, si tenemos unos servicios que son los que corren de dependencia para todo. Y claro, aquí estoy hablando a nivel de desarrollo...
local, no estamos hablando de la nube o producción. Entonces en mi local yo necesito, vamos a dar un ejemplo, necesitamos traffic o engine X, necesitamos un contenedor que simule S3 y necesitamos un contenedor para Kibana y todas estas cosas. Todo eso ya que no pertenece a un servicio como tal, a una aplicación como tal,
yo preferiría agrupar esos en un docker compose la idea al menos para mi y lo que me ha funcionado es tener los compose files que cada uno de ellos sea lo más independiente posible si yo quito o elimino un compose file perdón si yo eliminó el stack con un docker compose down
eso no debería afectarme a otros servicios que están corriendo. Entonces, yo suelo agruparlos de esa manera, suelo agrupar los servicios que entre ellos tiene sentido que estén en un solo compose file, pero que si están junto con otros, tal vez esto me permite a mí...
apagarlos y encenderlos, sin afectar a los demás. Y aquí no importa tanto si están en un solo repositorio o si están en múltiples repositorios, lo normal es que por cada repositorio haya un compose file. Pero cuando tenemos un monorepo... ⁓
sí podríamos irlos agrupando de esa forma porque a veces es incómodo tener que levantar todo un Compose File que tiene cinco servicios pero a mí el que me interesa es solamente uno entonces yo podría apagar esos otros
y solo dejar el que realmente me interesa y por eso es complicado agruparlos de una manera que tenga sentido pero vale la pena dedicarle un tiempito y no tenerlos todos en uno solo cuando es posible, ¿no? de nuevo, depende del tamaño del proyecto
Douglas (48:38)
Sí,
que mira, hay donde haya ciertas áreas donde discrepo porque yo la recomendación que yo daría es no tener el Docker Compose File del ambiente de desarrollo en mi local. Eso es algo que tendría que ir al repositorio.
Juan (48:42)
Uh-huh.
Claro.
Douglas (48:59)
Aunque
solo yo, poné que hay cuatro developers trabajando en el mismo aplicación y yo soy el único que tiene dockerizado su ambiente de desarrollo. Los demás no van a usar Docker Compose. No importa, yo voy a subirlo al repositorio porque para mí mismo, cuando cambie de computadora o si ando de viaje y agarre otra computadora, me va a servir montón que haya estado ahí, ¿verdad? Mientras que si lo tengo en mi computadora aparte...
Juan (49:13)
Sí.
Douglas (49:28)
y no está en el repositorio, pierdo version control de cambios, el historial de cambios, pierdo ese tipo de cosas y lo tengo aparte. Entonces uno, al estar en el repositorio significa que el Docker Compose va a tener todo lo que necesito para trabajar con ese repositorio. A ese punto ya es la agrupación necesaria. No veo otro nivel de agrupación
dentro de ese mismo repositorio. Mencionaste el ejemplo de los monorrepos, ¿verdad? No soy tan fanático de los monorrepos, sin embargo existen tanto y comprendo por qué existen tanto. Pero un monorrepo, si varias aplicaciones están publicándose del mismo monorrepo, ahí pudiera segmentar. Pero en realidad ahí resulta que son...
Juan (50:04)
Sí.
Sí.
Douglas (50:27)
diferentes aplicaciones que están en un mismo repositorio. Comparten componentes torales, pero están en un mismo repositorio. ahí pudieras hacer algo como eso. cuando vos diste el ejemplo de que debería de poder apagar uno sin afectar a los otros, me daba la impresión a mí de que levantaba uno y ese le compartía ciertos servicios al otro. Pero si ya no quería este, lo puedo pagar.
y sin que afecte al otro. No sé si me explico. yo siento que cuando lo pones en el repositorio, ya eso es el nivel de agrupación suficiente que deben de tener. Y esa es la recomendación que yo siempre doy.
Juan (50:59)
Sí.
Douglas (51:10)
ponerlo en el repositorio porque ya a ese punto ya está ahí, aunque se hace el único en tu equipo que tenga su ambiente local en Docker, ponelo ahí, ¿verdad? Yo me he topado con repositorios, por ejemplo, en cuestión de CI, CD, que tienen un Jenkins files, que tienen el de GitHub Actions, que tienen el de GitLab, porque tal vez en su local o en ambientes de prueba, diferentes developers prueban en otras áreas y ellos meten el...
Juan (51:18)
Sí.
Sí.
Sí.
Mm-hmm.
Douglas (51:40)
meten
el file, el archivo ahí, es muy válido. yo recomiendo cuando lo pones en el repositorio, te quita esa, mantener ese registro propio. Y de nuevo, a ese punto Juan, si vos lo manejas aparte, estás perdiendo una de las...
Juan (51:43)
Y es válido, Sí.
Douglas (52:00)
bondades de los contenedores que es la portabilidad porque aunque está muy bueno tener la segmentación, la separación o lo que lo contiene en un paquete, ese lo tenés pero no lo puedes portar porque si no tenés tu laptop no te va funcionar porque no tenés el Docker Compose. ⁓
Juan (52:19)
Sí, no,
en ese aspecto creo que estamos de acuerdo. Sí, el Docker Compose tiene que ir dentro del repositorio. Ahí no hay para dónde. Sin embargo, probablemente mi consejo va más orientado a los monorepos. Sí, creo que tal vez últimamente he estado trabajando más de esa manera. Pero también yo he visto mucho, ¿cómo decirlo? He visto...
Douglas (52:27)
Mm-hmm.
Ajá, sí. De acuerdo.
Juan (52:46)
He sentido muchos beneficios ⁓ en poder...
separar algunas cosas. Un ejemplo que te puedo dar muy claro es que para mi servicio, una aplicación, una nada más, probablemente tengo la dependencia de RabbitMQ. Este servicio puede estar escuchando. Entonces lo normal es tenerlo en el mismo compose file, poder levantar RabbitMQ. Pero a veces no quiero testear nada que tenga que ver con RabbitMQ. Entonces en ese caso...
Yo puedo decidir si levanto o no. RabbitMQ Entonces...
Douglas (53:24)
Déjame darte un consejo ahí.
Porque también lo he visto pasar con un layer de caché. Pues sabes que en producción hay caché, entonces tenés tu Docker Compose para hacer la prueba final como si fuera producción. Pero en realidad mientras desarrollas lo deshabilitás el caché y no lo quedes corriendo. Entonces el consejo que te voy a dar es Docker Compose tiene parámetros que vos le puedes decir no levantes ese servicio.
Juan (53:32)
Ajá, también.
Sí.
Douglas (53:53)
o tal vez levantó todo, pero ya que levantó apagame este servicio. Pero eso va a hacer que se haga siempre el mismo archivo, en lugar de mantener varios archivos. Yo quiero que la gente tenga esto en mente y dando el ejemplo del monorrepo, la razón por la cual existen los monorrepos que a no me gustan, pero lo entiendo, es porque hay partes torales que son la misma. Pero entonces, si vos tenés dos Docker Compose...
Juan (54:16)
Sí.
Douglas (54:19)
uno con RabbitMQ y el otro sin RabbitMQ. Ahorita estoy usando el que no tiene RabbitMQ y ocupo cambios al contenedor de la base de datos y se lo hice solo a ese. ¿Por qué se me olvidó? Porque soy humano, se me va olvidar.
Juan (54:29)
No tanto.
Douglas (54:36)
La siguiente vez que levanta el stack con el que si tiene RabbitMQ, ahí no le hice los cambios de la base de datos y no empieza a funcionar igual y me empiezo a quebrar la cabeza y a veces pueden ser 15, 20 minutos, 3, 5 horas. Me ha pasado, Juan. Estoy seguro que a vos porque a todos los profesionales nos ha pasado. Hacer debugging por horas, por un punto coma, por un flag que se nos olvidó agregar. Entonces cuando tenés varios Docker Compose...
Juan (54:59)
Sí.
Douglas (55:04)
excepto, es propenso a error humano. Entonces, el consejo que yo voy a dar y explorenlo programadores ustedes a su criterio, usen siempre un solo Docker Compose file, pero a la hora de correr el comando que levanta el servicio, si ahorita no ocupan uno o dos servicios, los apagan con el mismo comando de Docker Compose y así mantienen un solo file. Un solo file se vuelve the source of truth, la fuente de la verdad.
Juan (55:08)
Sí.
jajaja
Pero fíjate que no lo tenía, bueno no me refería tanto a tener dos ComposeFiles donde uno le incluye y el otro no. Sino más bien a tener un ComposeFile con este tipo de dependencias como en este caso RabbitMQ y el otro ComposeFile con la aplicación. Ahora mi pregunta aquí sería tal vez si la conoces.
porque yo lo conloque me he visto y por eso he empezado a este tipo de cosas es que a veces lo que quiero testear es levantar mi Compose File con mi aplicación y estar corriendo y mientras está corriendo levantar o apagar el RabbitMQ entonces no sé si se puede hacer con el mismo comando de Docker Compose
Si se puede, creo que voy a empezar a cambiarlo y tratar de utilizarlo más de esa manera.
Douglas (56:27)
Sí,
sí se puede. Puedes apagar uno o dos servicios o la cantidad de servicios que querrás. Igual puedes tener un Docker Compose con 15 servicios y al darle up, querer levantar solo uno de los 15.
Juan (56:40)
interesante.
Douglas (56:41)
puedes hacerlo perfectamente y tal vez por eso es que yo recomiendo en la medida de lo posible un solo archivo. De nuevo, o sea, es factible y te ha funcionado. Sin embargo, explora un poco esa área, Juan, es mi recomendación, verdad, porque aunque sea tener un Docker Compose aparte solo para RabbitMQ, te toca mantenerlo al hacer cambios. ¿Qué tal si le cambiaste el nombre al
Juan (56:56)
sí
Douglas (57:11)
servicio de API por middle tier, ponele, verdad? Y entonces se te olvidó cambiarlo en el de RabbitMQ. Al final es una dependencia siempre, verdad? Y te toca ir que cambió un puerto, ya no es el puerto X, ahora es el puerto Y, entonces hay que ir al otro a cambiar el puerto, aunque no llame el mismo servicio, me explico. Entonces ese tipo de cosas, van a haber escenarios y de nuevo creo que el de Monorepo es uno de los escenarios donde muchas veces
van a ver más de un Docker Compose para desarrollo local. Sin embargo, yo recomiendo en la medida de lo posible un solo Compose File y usar estos diferentes flags, estos diferentes comandos para levantar solo los servicios que necesito si es el caso para las aplicaciones en las que aplica.
Juan (58:00)
¡Qué excelente! Por eso me encanta traer este tipo de temas porque yo también sigo aprendiendo cosas para que vean lo que nos están escuchando que cuando menciono que Douglas trae otro punto de vista que nos va a beneficiar es en serio porque realmente ya ahora que lo mencionas que se puede hacer pues no lo había explorado y definitivamente lo voy a empezar a implementar porque
si definitivamente tener varios compose files me ha servido pero también tiene sus ventajas como las mencionaba que que que interesante interesante y me imagino que tenés tal vez tú las más consejos de este tipo no como si sat min utilizas docker de como ya lo mencionaba de hecho lo utilizas de otra forma
Douglas (58:49)
Uh-huh.
Juan (58:54)
de otra manera que los developers a veces pasamos por alto a veces los developers yo trato de indagar lo más que puedo en docker pero sí es cierto que a veces lo que utilizamos es muy simple hacer un docker file levantar nuestros servicios, setear los puertos y no más que eso de vez en cuando un volumen pero
Douglas (58:54)
Sí.
Juan (59:20)
No sé, no sé si nos pudiera dar algún tipo, o hablar más que todo, cómo lo suelo es utilizar en este otro ambiente de docker.
Douglas (59:30)
Sí, aclarando que no es que lo que el developer hace es muy simple, en realidad que el uso de los contenedores como tal, una vez que el entendece vuelve simple, sobre todo para lo que te quita y lo sentís simple porque estás acostumbrado, pero no es minimizar, por el contrario es una decisión muy inteligente en mi opinión.
Juan (59:44)
Sí, sí, creo que eso es.
Douglas (59:52)
Pero ahondando en tu pregunta como sysadmin o como devops, alguien más del área de devops, sorry, yo uso los contenedores como una herramienta para agilizar el trabajo y aquí quiero separar porque mucha gente cree que mi experiencia con contenedores o mi trabajo con contenedores es configurarlo en los servidores que van a correr las aplicaciones. Y si es parte de...
Juan (1:00:18)
Se tienen las variables
de entorno y ya.
Douglas (1:00:21)
Sí,
exacto. es parte de mi rol, ¿no? Instalar contenedores, orquestrador de contenedores, etcétera, para ambientes de producción. Sin embargo, los contenedores como tal, para el trabajo de mi día a día, son una herramienta de bastante valor. Te voy a dar un par de ejemplos. Una de ellas es instalar aplicaciones empaquetadas, como se dice.
Juan (1:00:42)
Mm-hmm.
Douglas (1:00:48)
aplicaciones que no estás desarrollando tu equipo, sino que son un open source, ¿verdad? Y tienen la opción para self-hosting o instalarlo en tu propio servidor. Puedes adquirir el servicio de ellos y pagar una cuota mensual o puedes instalarlo en tu propio servidor y vos lo corres. Entonces, para estas aplicaciones empaquetadas, yo recomiendo...
Juan (1:01:09)
Sí.
Douglas (1:01:13)
instalar en un servidor, si va a ser una instalación sencilla, con Docker Compose. Normalmente, aquí quiero aclarar, no recomiendo y mucha gente no recomienda Docker Compose para producción. Sin embargo, una aplicación, y voy a poner como ejemplo, yo uso bastante Rundeck. Para quienes no saben, Rundeck es una aplicación que ejecuta trabajos.
Juan (1:01:29)
Sí.
Douglas (1:01:41)
ejecuta diferentes tipos de trabajo, da una interfaz gráfica y entonces el project manager puede correr un trabajo para clonar contenido, para limpiar caché de una aplicación, el developer puede tener trabajo que ejecuta comandos en los servidores de prueba, etc. Rundeck es una aplicación ya empaquetada. En lugar de poner... y es en Java, ¿verdad?
Entonces, en lugar de ponerme a instalar Java en el servidor y luego Nginx y una base de datos y hacer toda la conexión, yo lo corro con Docker Compose, ¿verdad? Y eso me facilita. yo sé que esto sigue siendo un poco de la mano con lo primero que dije, que la gente cree que solo estamos instalando, que solo interactuamos con contenedores en los servidores.
pero lo resalto porque no lo estamos haciendo para una aplicación creada por el equipo.
o una aplicación propia, sino que es para una aplicación empaquetada y en lugar de ponernos a instalar todo manual, yo uso Docker Compose. Entonces, eso es una de las formas en que lo uso, pero otra, que aquí se vuelve más interesante, es para instalar comandos con dependencias complicadas. ¿Vos mencionabas el ejemplo de, o lo hablábamos antes, el ejemplo de Python?
Juan (1:02:42)
Mm-hmm.
Sí.
Douglas (1:03:06)
hay
un comando servbot. Este servbot es este comando que usamos para generar certificados de seguridad con lesson creep para mi aplicación y cualquiera que ha seguido un tutorialito para instalar un servidor web, ya sea para WordPress, ya sea para Go, o para cualquier aplicación.
Ahí nos enseñan cómo instalar servo en el servidor y utilizarlo para generar certificados y cómo correr un cron job para que esté auto renovando el certificado. Este comando, como depende de Python, suele tener...
muchos problemas y complicaciones cuando se actualiza el servidor porque hay una vulnerabilidad y actualizamos Python y nos quebró la instalación de Serpod y entonces no se renovaron los certificados, dolor de cabeza. Entonces, hace dos años y medio, tres años creo, decidimos instalar estos comandos con Docker. ¿De qué manera?
con un alias. El comando servo en linux en lugar de instalarlo es un alias que hace docker run al contenedor con servo y le pasa el comando servo y las instrucciones que yo le di. Entonces si yo le doy servo renew.
Juan (1:04:11)
Ok.
Douglas (1:04:25)
Entonces lo que está haciendo en realidad es un docker run montando el directorio local, lo que vos no decías, el directorio en el que estoy lo monta dentro del contenedor y le pasa el comando servos renew dentro del contenedor.
Juan (1:04:32)
Sí.
Douglas (1:04:40)
De esa manera, yo puedo mantener el servidor actualizado sin preocuparme de que voy a actualizar la versión de Python y lo va romper. Y si necesito una nueva versión de servo, solo voy y actualizo el alias y le pongo la imagen de la versión nueva de servo. Y hacemos eso con muchos otros comandos, pero estoy poniendo un comando como ejemplo. Pero cualquier comando que tiene dependencias complejas o que suele afectar una dependencia con la otra.
Juan (1:05:09)
Mm-hmm.
Douglas (1:05:10)
También lo hacemos de esa manera, es un alias que atrás de ello lo que está haciendo es un Docker Run. Lo hacemos también para comandos de CLI internos que dependen de versiones distintas de PHP.
o de versiones distintas de Composer, es esta herramienta que en otro episodio les había hablado que es como el NPM de PHP, entonces algunos son Legacy y son Composer 1, y otros son más recientes y tienen la versión de Composer 2, entonces usamos este truquito con alias...
Juan (1:05:33)
Sí.
Sí.
Ok
Douglas (1:05:52)
que detrás de bambalinas, como se dice, lo que está haciendo es un Docker run para ejecutar el comando en diferentes versiones y nos arregla la vida. Entonces, es una herramienta que tenemos las personas, los sysadmin, y que lo pueden implementar programadores en su local si están teniendo dependencias con diferentes versiones. Pueden implementar algo como eso para reposar comandos.
Juan (1:05:55)
Sí.
Sí, yo definitivamente
voy a intentar utilizar esa manera de gestionar las dependencias. Definitivamente, tal vez es por lo que no estoy muy familiarizado con Python, siempre es el que más problema me da cuando estoy instalando diferentes aplicaciones y diferentes servicios o dependencias. Y me gusta esa manera tan ingeniosa que tenés para poder manejar ese tipo de cosas.
Y esto, ahora, ¿los guardas el Docker Compose dentro del proyecto o estos los tenés aparte? ¿Cómo gestionas este tipo de...? Solo como curiosidad, ¿no?
Douglas (1:06:58)
Buena No, no, no, buena pregunta
porque en este ejemplo primero, Juan, es un comando. Entonces ya existe un contenedor oficial de Certbot. De hecho, Certbot, como está renovando certificados de SSL Certificate, tiene diferentes formas de autenticar.
Juan (1:07:05)
Sí.
Douglas (1:07:19)
una de ellas es por DNS y si tu DNS está en Cloudflare, tiene uno que está ligado a Cloudflare con tus keys de Cloudflare para crear los records y estar renovando el certificado. O uno son con Route 53 de Amazon, si lo haces por DNS y tiene diferentes proveedores o lo puede hacer por medio de email. ya existe en el Docker Hub la imagen de Serbot para...
Cloudflare, la imagen de Zerbot para Route 53, entonces en realidad sólo es un Docker Run, no estoy construyendo una imagen, existen los imágenes oficiales ya de Zerbot y lo mismo funciona con estos otros comandos, existe la imagen oficial y lo único que estoy haciendo es un alias, verdad, correcto, para quienes no sepan en los sistemas operativos Linux, Unix, se puede crear un alias, yo puedo crear mi propio comando.
Juan (1:08:02)
Sí, para el rapper.
Douglas (1:08:12)
que el alias detrás de en el bucket lo que está haciendo es un comando reales que tiene el servidor instalado entonces yo puedo crear mi propio comando dooc, Douglas y entonces ese comando lo que va a hacer es realidad ponerle copiar un file de un lugar a otro entonces va a ser copy archivo x al lugar y entonces eso es un alias entonces lo que hacemos en lugar de instalar servo
Juan (1:08:40)
como una macro,
tal vez podría ser una comparativa
Douglas (1:08:42)
Es como una macro. ⁓ Me parece
una buena forma de ejemplificarlo, como una macro. Entonces lo que estoy diciendo es que en lugar de instalar servo, creo un alias que cuando se escriba servo, le corre el contenedor, monta el directorio local dentro del contenedor y le pasa los parámetros que yo mandé.
Juan (1:08:51)
Ajá.
y supongo
que al final pues le indicas que ese contener se elimine cuando termina la instrucción o ya viene por defecto.
Douglas (1:09:07)
se elimina,
correcto, en el alias tiene un Docker run con el flag, guion, guion, rm, que eso hace que cuando termina de ejecutarse el contenedor lo elimina. La imagen queda pero el contenedor se elimina para que no esté creando basura, pero sí, es muy cierto, se hace de esa manera. Ahora, se lleva más allá, cuando lo uso, lo usamos las personas de sysadmin,
Juan (1:09:15)
ok
que cool.
Douglas (1:09:34)
para scripts que tienen más funcionalidades y más dependencias que no queremos instalar. Ejemplo, tenemos un servidor de base de datos y está corriendo María de B. Entonces todos los días hace un backup y lo manda a un bucket de S3.
pero no querés instalar el AWS CLI en tu servidor porque de nuevo depende de Python, verdad? Y tenés MariaDB corriendo ya ahí y todo eso. Entonces lo que hago es, ahí sí creo un Dockerfile y tengo un repositorio aparte donde está, donde instalo el AWS CLI, instalo las dependencias, creo un script como Entry Point.
Y el script es el que va a hacer, se conecta a la base de datos, jala el DOM file, hace el zip, ¿verdad? Lo comprime y luego agarra las credenciales que le voy a pasar y lo manda a S3, ¿verdad? Entonces eso lo agarra el EntryPoint y queda como una imagen.
que yo creé y tengo un repositorio que la está creando y entonces vcrunjob en lugar de correr esos comandos manuales hace un docker run y llama el entry point con los parámetros que le di usualmente uso variables de entorno para configurarlo
verdad, si quiero que lo mande al bucket llamado x, entonces le pongo bucket igual a x, uso variables de entorno para configurarlo, pero de esa manera pudo correr scripts complejos que están...
Juan (1:11:10)
Sí.
Douglas (1:11:19)
tienen dependencias complejas o tienen dependencias de diferentes versiones lo uso bastante en backups y mantenimiento para sitios de WordPress o sitios en PHP que tal vez algunos están en PHP 8.1 y otros en PHP 8.2, verdad, entonces tengo un contenedor que tiene las dependencias de 8.1 el otro de las dependencias de 8.2 y corre tal vez dentro del mismo servidor porque están en contenedores y entonces
de nuevo, en lugar de estar instalando cosas y estar dependiendo de ellas, escribo el Dockerfile, le dedico algo de tiempo, no tarda mucho tampoco, al EntryPoint, que es ese script que se ejecuta primero y él tiene las diferentes instrucciones de qué es lo que va a hacer y se corre con un cron job, igual con el flag de que al terminar de ejecutar se elimine el contenedor.
pero esa es otra manera en la que yo como sysadmin lo uso como herramienta, verdad, no dentro de un servidor para que corra una aplicación de producción sino como herramienta para mí, para que me facilite la vida porque esa ventaja de contener y empaquetar
le saco provecho, le saco el jugo para que no me afecte lo demás que está corriendo en el servidor y la portabilidad también le saco el jugo porque el mismo contenedor que cree para hacer ese backup de base de datos y que luego la manda a S3 lo puedo publicar en las diferentes aplicaciones que tenemos corriendo o las diferentes bases de datos. Entonces uso ambos beneficios de los más grandes de los contenedores el empaquetado o el aislamiento y la portabilidad.
Juan (1:12:31)
Sí.
qué excelente porque realmente, bueno estaba pensando en este momento
los pasos que estás describiendo claramente se podrían hacer con un script, un bash script o Python o cualquier cosa, ¿no? Pero el hecho de poder tener diferentes versiones aisladas eso sí, solo con un contenedor, con Docker lo vas a poder lograr, ahí es una herramienta tan interesante. Y la verdad no, estoy seguro que, así como yo, hay muchos que no se nos había siquiera cruzado por la mente en utilizarlos de esa manera, ¿no?
Douglas (1:13:10)
Exacto. Exacto.
Juan (1:13:34)
bueno amigos lamentablemente Douglas tuvo un problemita y no va poder continuar para finalizar el episodio. Sin embargo, creo que nos ha compartido mucha información que es increíblemente útil para todos. En lo personal yo voy a empezar a utilizar muchos de los consejos que le ha dado y voy a empezar a...
y tratar de implementar las ideas que nos ha compartido el día de hoy. Esperaría que también ustedes le den una oportunidad a Docker, al menos de esta manera. Yo, por mi parte, les puedo tratar de enfatizar en que Docker es una gran herramienta que si no la estás utilizando en tu ambiente de desarrollo, probablemente te estás perdiendo de una automatización o de un ambiente de desarrollo mucho más.
fácil de reutilizar y tal vez va a ser mucho más fácil de trabajar con otros compañeros en tu equipo. como último dato para cerrar, me gustaría mencionar que Docker también yo lo suelo utilizar no sólo en mi trabajo sino también en el día a día en mi computadora para instalar otro tipo de aplicaciones. De manera rápida les puedo mencionar que una aplicación que suelo utilizar que es Ollama
Lama, la cual me permite correr otros modelos de lenguaje, yo lo suelo utilizar con Docker.
También tengo instalado en mi casa un Raspberry Pi que tiene corriendo un Pi hole. Esto es un servidor de DNS y también funciona como ad blocker a nivel de red. bueno, así también suelo instalar muchas otras cosas como un servidor multimedia y diferentes automatizaciones para lo que son los smart devices.
A lo que voy con esto es que con Docker se me facilita mucho poder instalar todas estas aplicaciones o todos estos servicios porque me permite elegir específicamente cuál es la versión que yo quiero y el momento en que necesito actualizar simplemente tengo que ir al Docker Compose y cambiar el número de la versión de la imagen. Y al mismo tiempo me permite pues reutilizar las configuraciones, me permite tener todo
un solo archivo con todas las instrucciones que yo necesito para las variables de entorno, cuáles son los directorios que yo quiero montar, etcétera. Así que de nuevo Docker creo que es una gran herramienta que en nuestro ambiente tanto el ambiente de desarrollo, ambiente de producción e incluso si le das la oportunidad también en tu ambiente personal creo que Docker es una herramienta que te va servir y te va a impulsar mucho en tu
en tus tareas, que definitivamente Docker es una gran herramienta que espero que no te la estés perdiendo. Sin más que agregar, espero que les haya gustado el episodio de hoy, espero que les haya hayan aprendido algo, al menos una cosita, y de nuevo muchísimas gracias por acompañarnos hasta este punto, gracias por compartir, por los likes, por todo el apoyo que nos dan. Muchísimas gracias y nos vemos a la próxima.