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)
el desarrollador tiene que encargarse...
programáticamente qué va a utilizar su aplicación y cómo consumir, ya sea una variable de entorno o un archivo de configuración. Cada uno tiene sus retos.
distintos al momento de programar y cada uno tiene sus ventajas y desventajas al momento de codificarlo y de la misma manera nosotros en la parte de operaciones tenemos que asegurarnos que existan ya sea el archivo de configuración o las variables de entorno cómo se van a estar creando, manteniendo, cuáles van a ser las diferencias dependiendo del entorno si estás en un ambiente de desarrollo o de pruebas o si estás en un ambiente de producción cuál va a ser la diferencia.
y hay que mantenerlo, este es un tema en el que sí o sí tiene que existir una colaboración cercana entre los desarrolladores y las personas de sistemas o operaciones,
Hola a todos y bienvenidos a Dev & Ops, este es su espacio favorito en el cual hablamos de desarrollo, tecnología, DevOps y su cultura en general. Y como siempre con mi amigo y co-host Juan Ramos a quien le doy la cordial bienvenida a este nuevo episodio. Juan, ¿qué tal estás?
Juan (01:20)
Hola,
me encuentro muy bien un poco cansado el día de hoy para hacerte muy honesto y honesto con la audiencia el día de hoy creo que mi hija tenía batería extra así que requirió jugar un poco más no que otros días pero pero muy ansioso muy contento de la plática que vamos a tener el día de hoy creo que va a ser muy interesante bueno ya no lo creo ya lo sé porque las pláticas anteriores hasta ahora han sido muy buenas
y me han gustado algo que tal vez mucha gente no sepa bueno no tiene por qué saberlo pero me pasa muy seguido y se lo comentaba Douglas también la vez pasada cuando estamos editando vídeos estoy editando y se me pierdo porque me quedo escuchando la plática que hemos tenido
me entretiene la plática que acabo de grabar y la queda escuchando. Y creo que esa es buena señal para nosotros, al menos a nivel personal Douglas, porque estamos haciendo un contenido, como dijimos al inicio, un contenido que nos gustaría nosotros ver y hasta el momento lo estamos cumpliendo.
Douglas (02:34)
Sí, al menos esa parte, a mí me pasa igual, lo hemos comentado vos y yo Juan, y al menos esa parte gracias a Dios lo hemos cumplido, estamos creando contenido que a vos y a mí nos gustaría consumir.
Decíamos en nuestro interés, obviamente, que también para nuestra audiencia sea no solo educativo, le genere valor, sino que tal vez de cierta manera también entretenido. Cuando estás escuchando algo de lo cual estás aprendiendo, de lo cual estás recibiendo valor, te entretiene y pues es lo que buscamos. Y a pesar de días como hoy en los cuales estás cansado yo también por razones diferentes, pero pues con el ánimo de...
Juan (03:13)
Sí.
Douglas (03:13)
llevar
estas pláticas y eso es lo bueno y aquí estamos dándole para adelante como se dice y yo creo Juan que la plática de ahora va a ser muy entretenida y es que vamos a hablar de qué es mejor para manejar configuraciones o archivos de configuración o variables de entorno y normalmente vas a usar uno o el otro en tu aplicación
Y yo creo que este tema va a ser muy bueno y muy interesante, porque realmente nos compete tanto a ustedes en desarrollo como a nosotros en la parte de operaciones lo que tiene que ver con la configuración de la aplicación, ya sea usando archivos de configuración o variables de entorno, porque el desarrollador tiene que encargarse...
programáticamente qué va a utilizar su aplicación y cómo consumir, ya sea una variable de entorno o un archivo de configuración. Cada uno tiene sus retos.
distintos al momento de programar y cada uno tiene sus ventajas y desventajas al momento de codificarlo y de la misma manera nosotros en la parte de operaciones tenemos que asegurarnos que existan ya sea el archivo de configuración o las variables de entorno cómo se van a estar creando, manteniendo, cuáles van a ser las diferencias dependiendo del entorno si estás en un ambiente de desarrollo o de pruebas o si estás en un ambiente de producción cuál va a ser la diferencia.
y hay que mantenerlo, este es un tema en el que sí o sí tiene que existir una colaboración cercana entre los desarrolladores y las personas de sistemas o operaciones,
entonces creo que por esa parte Juan vamos a tener la atención de todos los que nos ven y nos escuchan independientemente de cuál sea su inclinación o cuál sea su rol dentro del ciclo de vida de una aplicación.
Y en cuanto al tema, como siempre me gusta saber de tu parte, qué vibras te transmite este tema, es algo en lo que te encontrás conflicto, es algo en lo que estás 100 % inclinado, ya sea para los archivos de configuración o las variables de entorno, cómo lo manejas normalmente. Entonces, de manera inicial, ¿qué te transmite este tema?
Juan (05:32)
Definitivamente me transmite mucha emoción de hablar de un tema que a simple vista pareciera que es algo simple, pero ya vamos a ir viendo que conlleva, cada una de estas soluciones, cualquiera que sea que decidas utilizar en tu aplicación, conlleva sus pros y contras, ¿no? Como todo en la vida y más en programación, todo se basa en cuál es el beneficio y cuál es el desafío, ¿no? Al momento de implementarlo. A mí me gusta mucho
mencionar este tipo de conflictos o temas a personas que vienen empezando en programación porque normalmente cuando estamos programando no pensamos mucho en cómo se va a configurar la aplicación eso es algo que a mí me pasó en sus inicios me enfocaba mucho en la funcionalidad y en que haga lo que tiene que hacer lo cual está bien, es correcto pero hasta mucho tiempo después es que
Empecé a preocuparme y a tomarme en serio el ok ahora cómo lo configuro estas variables de la conexión a la base de datos una conexión a un servicio externo y parámetros que podemos ir cambiando no el el timeout que le queremos dar a un llamado en específico todo esto cómo lo vamos a configurar y desde dónde eso creo que es un tema que muchas veces no se habla o se toma muy a la ligera pero
Douglas (06:53)
y no es un poco claro, pero es una buena idea, es una y es una buena idea.
Juan (07:02)
pues vale la pena mencionarlo. Así que me gusta mucho el tema,
Douglas (07:06)
Si
fíjate que esto Juan es algo, yo lo miro, yo lo relaciono con lo que tiene que ver automatizar para la gente de operaciones, la gente de sistemas, en el caso de ustedes como programadores, lo que tiene que ver la configuración de la aplicación, para nosotros en operaciones cualquier profesional de IT en general debería de ser así, pero para nosotros de operaciones es un sí o sí.
donde vemos oportunidad de automatizar hay que hacerlo. Es la forma eficiente de trabajar. Y toca ser intencional y ponernos a pensar cada cuanto se va a repetir algo, de qué manera, para venir y aplicar la automatización. Y en los desarrolladores tienen que ver qué valores van a ser configurables, qué valores van a ser distintos con respecto a cada ambiente.
Juan (07:35)
Claro, sí.
Douglas (07:59)
va a cambiar la conexión de base de datos porque no es la misma en un ambiente de prueba que en el ambiente de producción. El API key va a ser diferente probablemente en el ambiente de prueba porque te pegás a un endpoint de prueba, no es el mismo de producción. Entonces, ¿qué valores van a ser distintos por ambiente? Pero también hay valores...
que van a ocupar, quererlos modificar en el camino, modificar sin la necesidad de un redeploy, de un commit de código, verdad, para hacer un feature branch, un commit, hacer el merge y hacer el deploy para...
cambiar un timeout, como dijiste, probablemente no es la manera más inteligente de hacerlo. Entonces, el developer, en ese caso, tiene que ser intencional al momento de pensar qué cosas pueden ser configurables para tenerlas de manera dinámica, ya sea en un archivo de configuración.
o en variables de entorno, qué cosas me van a estar evitando estar publicando constantemente para cambiar algo pequeño si lo puedo hacer en un archivo de configuración. yo encuentro esa similitud en cuestión de mentalidad, no obviamente el trabajo distinto, pero en cuestión de mentalidad yo encuentro ese como un sí o sí de un developer, asegurarse de...
tener de manera configurable todo valor que lo amerite. Entonces, ahí no sé si vos lo ves de esa manera.
Juan (09:30)
Sí.
Sí.
Creo que se va dando a medida teniendo experiencia con ciertas situaciones. Es normal que al inicio no pensemos en este tipo de cosas porque no nos ha sucedido, no nos ha pasado, que queremos cambiar un valor y ahora para cambiar ese valor tenemos que pasar por todo el ciclo de desarrollo, CI, CIB y muchas veces queremos evitar eso. También se puede, he visto casos donde se
se encuentran exploit en eso y podemos hacer todo un deployment extra inyectando valores, pero...
Douglas (10:10)
mmm
Juan (10:12)
pero en general lo que se busca es encontrar este tipo de parámetros que creemos que pueden llegar a cambiar más o menos frecuentemente, más o menos con cierta irregularidad o en ciertas situaciones que queramos testear algo o escalar algo, ¿no? Por ejemplo, ¿qué pasaría si estoy yo procesando dos tareas concurrentes?
pero veo que mi sistema debido a los recursos debido al tráfico que estoy obteniendo puedo incrementar esa concurrencia a en vez de dos tareas cuatro tareas
y lo podríamos hacer de manera manual. Aquí no estamos hablando tanto de cómo lo hace Kubernetes, cómo lo hacen estas reglas, sino algo que nosotros intencionalmente sabemos que podemos bajar o subir en ciertas ocasiones. O incluso también se puede de manera automática, cambiamos ese valor de manera automática. Pero tenemos que tener cierto, ¿cómo llamarlo? Intuición, o tenemos que saber qué parámetros pueden ser cambiados
en el futuro o qué parámetros van a requerir que sean configurables más allá de la conexión a base de datos, la conexión a servicios externos y todo eso.
Douglas (11:38)
Si, si no muy de acuerdo y a veces a veces Juan pueden ser cosas que se van a cambiar muy pocas veces en la existencia de una aplicación o un servicio tal vez una sola vez pero cambiarlo significaría ir a muchos lugares tal vez un ejemplo puede ser la URL
llamado un API y un desarrollador que recién comienza puede pensar, bueno si el API que estoy llamando es de mi misma empresa, es de mi mismo equipo, esa URL nunca va a cambiar, puedes pensar, yo creo que ahí está, ahí está el primer error, pensar eso y entonces comenzás a llamar, a hardcodear como se dice porque va a hardcoding, ese llamado cada vez que necesitás ese endpoint.
Juan (12:12)
Grave error. Sí.
Mm-hmm.
Douglas (12:27)
en tu código y de aquí a tres años que si cambió y tal vez no va a volver a cambiar pero cambió esa vez si no hiciste bien tu trabajo te va a tocar ir a todos los lugares donde hiciste el llamado a hacerlo mientras que cuando ese archivo de configuración o variable de entorno te fuerza a definir una variable al inicio y eso es que yo no soy programador pero yo lo sé, ¿no? te fuerza a definir una variable al inicio de tu código
para igualar, o ya sea, el llamado dentro del archivo de configuración o el llamado a la variable de entorno, ¿verdad? Y esa parte, como tal, en sí mismo te ayuda a implementar buenas prácticas. Pero sí, es cosa que le da el tiempo y estamos dando como una introducción al tema, un preámbulo de por qué es importante y por qué nos involucra de manera directa a ambos desarrolladores y los de sistemas.
pero hoy no vamos a hablar necesariamente de cómo identificar esas áreas o esos valores que tienen que ser agregados en los archivos de configuración en variables de entorno, esos configurables si lo queremos llamar de esa manera, sino que vamos a ⁓ discutir un poco más qué método preferimos usar, qué método es mejor, si es que hay uno mejor, hay uno peor, o archivos de configuración.
o variables de entorno y para una descripción corta, comencemos con archivos de configuración si te parece Juan, un archivo de configuración es tal cual como lo dice su nombre, es un archivo que contiene estos valores configurables de tu aplicación, es un archivo que es externo a tu código fuente aunque puede ser agregado en tu repositorio.
Juan (13:52)
Está bien.
Douglas (14:11)
va a estar agregado en tu repositorio porque al ser un archivo se pudiera obviamente meter a version control lo puedes cometer a tu git sin embargo es fuera de tu código si no estuviera ahí con tal que el archivo exista al momento que corra el código funciona no es necesario para el build de la aplicación y si tuvieras un archivo de configuración
que es necesario para el build de la aplicación lo estás haciendo mal. Juan nos puede dar más consejos en ese sentido porque él es un programador pero aún desde alguien que trabaja en operaciones yo sé que si necesitás un archivo de configuración al momento de hacer el build algo estás haciendo mal. por eso decimos que son fuera del código aunque se pueden agregar en tu código. Los formatos comunes Juan Jaml
El formato YAML, el formato JSON y también tenemos INI y TOMO que son esos formatos sencillos con key value tenés base URL igual el valor, pero el INI tiene que entre brackets puedes definir settings, puedes poner entre brackets puedes poner database.
y lo que pongas allá abajo son las configuraciones para la conexión a base de datos y en el otro puedes poner, no sé, users y lo que pongas allá abajo son configuraciones para los usuarios, ¿verdad? Y eso lo que, eso tiene, de esa manera funciona el IN y el TOML son similares, el TOML lo hace para crear como arrays también en la configuración.
Juan (15:54)
Si, lo he visto cuando
estoy configurando algún servicio o algún programa que descargue o por ejemplo, Traffic, Traffic tiene Toml, soporte para Toml pero bueno hasta el momento me he rehusado Douglas a aprender esos otros formatos yo me he quedado con JSON y Jamel y voy a resistir lo más que pueda hasta que me toque
Douglas (16:21)
Sí, yo creo que mira,
no tenés que resistirte, realmente que de hecho casi que la industria se ha quedado en JSON y Jamo, yo en lo profesional prefiero Jamo y si no pues JSON, sin embargo muchas veces si tu aplicación es sencilla, a veces ni siquiera tiene que ser ninguno de estos formatos.
puede ser una lista de key values y vos aseguras tu aplicación que lo lea. Sin embargo, usar uno de estos formatos te permite usar una librería preexistente, ya sea del mismo lenguaje que estás usando. Estoy seguro que Go tiene de manera nativa las librerías que pueden leer esos formatos y muchos otros lenguajes lo tienen. A que si yo creo mi propio tipo de formato de archivo de configuración me va tocar a codificar cómo leerlo, hacerle parse.
parsing o parciarlo, verdad, como se usa la palabra en spanglish pero en fin, estos son como los formatos más comunes alguna ventaja que quiero mencionar Juan aquí, una de ellas, si vos me vas a decir qué pensás es que tiene como una claridad y legibilidad inicial, o sea, con verlo
Juan (17:13)
Sí.
Douglas (17:39)
vos tenés una idea de qué es, mientras que si tenés variables de entorno, sobre todo al momento que las ves en el sistema operativo, y ya vamos a hablar un poco más de ellas si alguien no tiene la definición clara, pero te aparecen en cualquier orden.
Cualquier orden te van a aparecer. A veces pienso que es en orden alfabético, pero luego miro bien y no están en orden alfabético. A veces ni yo mismo entiendo cómo las ordenó el sistema operativo para desplegarlas. en fin, el archivo de configuración normalmente me genera una mayor visibilidad porque si tenés un JSON vas a comenzar que dice arriba Settings y luego lo siguiente dice Database y dentro de Database tenés la jerarquía, ¿no? El usuario, el password, el puerto.
Juan (18:15)
Mm-hmm.
Claro.
Douglas (18:23)
el método que usés. Entonces son más legibles. No sé si eso para mí como alguien de operaciones, cuando el desarrollador me dice este es el archivo de configuración que necesito, para mí es fácil entender. Cuando me dicen cambiar el puerto de la base de datos en el archivo de configuración, ya sé dónde ir, es fácilmente legible. No ocupo que me digas cómo se llama.
Mientras que con las variables de entorno, me tienen que decir, si no me va costar encontrarlas, me tienen que decir cómo se llama la variable en particular. Entonces, esto es algo que para vos como developer es un valor significativo para decidirte a utilizar archivos de configuración por sobre variables de entorno o es algo que es irrelevante.
Juan (18:55)
Sí.
Sí, definitivamente.
tienen un peso más grande para mí los archivos que las variables de entorno. Aunque también se puede tener un archivo .env y hay muchas librerías que leen ese archivo y lo pasan a variables de entorno. Lo cual nos brinda esta visibilidad que mencionabas. Por ejemplo, hay muchas librerías que descargamos o herramientas que podemos descargar de GitHub y en el repositorio podemos
Douglas (19:37)
Muy cierto,
Juan (19:47)
que tienen un archivo llamado .env.example y ese es el archivo donde tenes toda la lista de las variables disponibles o las variables que espera el sistema o la aplicación perdón con los posibles valores eso por un lado
Sin embargo, aún así, bueno, no sé si vamos a hablar sobre las, o vamos a hablar sobre las ventajas y desventajas, pero de antemano yo puedo anticipar que prefiero los archivos de configuración porque para mí es más fácil predecir cómo va a venir la información. Y en esto me refiero tanto a la estructura, la jerarquía que mencionabas, como a los tipos de datos.
En las variables de entorno, al final del día, todos son texto.
Douglas (20:38)
Sí.
Juan (20:39)
En cambio con los archivos YAML uno puede definir los tipos numéricos y tenemos los dos objetos que son estas jerarquías y eso nos da como una mayor estructura al momento de utilizarlas. Así que eso mi me permite obtener esos valores, estructura, ingresarla en una estructura de datos del sistema y luego esa estructura de datos yo la puedo utilizar como utilizaríamos cualquier
cualquier clase o con settings.baseurl algo así eso me permite utilizarlo claro hay otras desventajas claro que sí hay desventajas no lo voy a negar pero para mí eso me hace preferir los archivos a nivel de o al menos desde el punto de vista de programación que puedo tener este objeto que puedo referenciar y más se utiliza
utilizamos librerías de inyección de dependencias es fácil pasar estas variables, estos objetos de configuración como dependencias y las podemos utilizar en diferentes partes del sistema. Pero bueno, ya vamos a ir hablando sobre ventajas y desventajas. Sin embargo, cuando yo tengo el control del sistema o aplicación que estoy desarrollando, normalmente voy a ⁓ configurar mi sistema para que trabaje con
archivos de configuración. ⁓
Douglas (22:11)
Sí,
fíjate que sí lo entiendo y puedo ver lo que estás diciendo. Como para hacerte mención con lo del archivo .en es cierto, es una manera visual de entenderlo, sin embargo variables nuevas yo las puedo agregar en cualquier orden. Muchas veces me pasa que un archivo .en es bien extenso y me dicen agregate este nuevo valor y es una variable que se llama...
ZRX-Token ¿El token de que es eso? pues no se yo lo agrego al final y va funcionar entonces a la hora de la legibilidad no se que le compete a que mientras que en un YAML o un JSON o un INI vos me vas a decir en la sección de base de datos agregas esta variable entonces es parte de la configuración de base de datos entonces siempre es
Juan (22:46)
Sí.
Claro,
Sí.
Tendrán la estructura.
Douglas (23:07)
la estructura, correcto, que es lo que vos decía, esta estructura la que te permite luego llamar y venir y decir settings.database.name y lo referencias así, al igual que podés forzar el tipo de valor, texto, numérico, lista, array, etcétera, para un valor específico y si no te va a retornar un error el cual lo puedes retornar al momento que cargas la aplicación.
si le tenes un process pero bien me gusta eso que decís obviamente eso lo vuelve fácil de al hacer un archivo se puede incluir de nuevo aunque no es parte del código porque no tiene que ser parte de tu build ni de tu paquete final no puede ir en un paquete en un deployable en un
binario si estás en GoLang, o en un paquete, es un Python, por ejemplo, no puede ir ahí el archivo de configuración, pero al ser un archivo puede estar en version control para que se maneje por ahí. Obviamente eso,
Juan (24:12)
Sí.
Douglas (24:14)
hay que tenerle el cuidado de no tener credenciales ahí. Y hoy en día esto es más crítico porque cada vez hay más información que aunque no sean credenciales se considera información sensitiva, información delicada. A veces con saber el nombre de...
de la base de datos, si yo lo tengo en un archivo de configuración y la base de datos se llama basededatos1, esa es información, si alguien tiene acceso al repositorio es una información que a alguien malicioso ya sabe qué base de datos llamar.
Aunque no tenga las credenciales, pero ya le quitamos ese trabajo o como se llama el endpoint, información, hoy en día no se quiere, se quiere que se publique lo menos posible de información. Si hay cosas, todo lo que se pueda ver desde el navegador web, si vos le das desde los developer tools.
todo lo que se pueda ver desde ahí, al final del día, ese tipo de información puede ir en un repositorio porque se vuelve información pública de cualquier manera, O sea, no estás como tal ocultando nada.
Pero sí, lo que no se vea desde los developer tools, normalmente queremos mantenerlo privado y es ahí donde a veces el archivo de configuración ponerlo en version control, verdad, no es como la mejor solución o la mejor idea si lo queremos poner por ese lado. Ahora vos hablaste de otras ventajas en código Juan, a mí se me ocurre una en código y vos me vas a decir si hay más.
Juan (25:50)
No,
Douglas (25:54)
pero sé que una de ellas es porque yo trabajo un poco con Python y también prefiero los archivos de configuración, yo por mi parte tengo varios motivos que los vamos a ir dando, pero una de ellas es que tenés que asegurarte de abrir un archivo, de cargar el contenido, de cerrar el archivo, de que no quede abierto ahí al momento que la aplicación ya no lo necesita o estar corriendo, o sea, es algo más de lo que hay que estar pendiente.
no es algo del otro mundo, no, no lo es, pero es algo de lo que tengo que estar pendiente y si me llego a descuidar cada vez que lo llame puedo estar abriendo otra vez el archivo.
Juan (26:23)
Sí.
Douglas (26:33)
Y otra vez, y otra vez, sobre todo si no se manejarlo, como decís, agarrar la información y guardarlo en memoria, en una estructura, en una variable, etc. Entonces, de mi lado, conozco el programador, pero que trabajo con Python y archivos de configuración, sé que es una de las cosas que tengo que tener en mente. No sé vos si te referías a eso o a otras cosas cuando mencionabas que le encontrás ciertas desventajas también.
Juan (26:58)
Sí, esa yo creo que es la más fuerte, la desventaja más fuerte, ¿no? El hecho de que pues tenemos que manejar un archivo, un archivo que existe en nuestro servidor y bueno, todo lo que conlleva eso, ¿no? El hecho de tenemos que parciar ese contenido, necesitamos, esperamos que tenga una estructura, pero pues tenemos que tener este cuidado de no estar...
ya sea creando múltiples veces o leyendo múltiples veces el mismo archivo lo ideal es tener inicializarlo una sola vez y lo leemos y luego solo lo referenciando dentro de la aplicación y también está el problema que mencionabas de qué pasa si lo abrimos y no cerramos el archivo dependiendo del lenguaje pero no estoy muy seguro si hay algún lenguaje que cierre el archivo automáticamente lo normal es que
abrimos el archivo hacemos una operación de IO y luego tenemos que cerrarlo porque si no pues empezamos a tener leaks de memoria lo cual no es nada bonito otra desventaja que yo la encuentro no es tan grande pero sí es una desventaja comparado con los variables de entorno al momento de leer un
valor de una variable de entorno en la mayoría de los lenguajes es una instrucción muy simple por ejemplo en go la instrucción es os.getenv eso lo que está indicando es que voy a leer un valor de variable de entorno y le digo bueno getenv y le paso el nombre de la variable muy simple y más allá de los simples me permite utilizar esa instrucción, ese comando
parte de mi aplicación ya sea que estoy en la capa de repositorio en la capa de presentación etcétera etcétera lo puedo hacer en cambio con los archivos de configuración lo ideal como decía es inicializarlo una sola vez pero qué pasa si yo necesito esa variable de configuración en otra parte del sistema mucho más abajo en la digamos en las capas no de nuestra aplicación
Entonces tengo que pasar ese valor y ahora ¿qué pasa? yo necesito pasar ya sea una sección del archivo o de la estructura de configuración o tal vez necesito pasar la estructura completa.
En lo normal, lo que hago, ya que utilizo ciertas librerías de inyección de dependencia, es que yo paso la referencia entera. Tal vez estoy configurando un servicio o algo que está en la capa del Business Logic. La lógica de negocio, ahí yo necesito una URL de un servicio externo. Yo me podría, me puedo haber tentado a simplemente recibir esa URL como mis parámetros.
pero como yo estoy utilizando inyección de dependencia lo más común es que yo recibo el objeto entero de configuración y ya desde ese objeto yo accedo a la url ojo estoy hablando solo al momento de la inicialización de todo el sistema ya cuando está corriendo esa variable yo debería tenerla guardada en la estructura de esa capa de lógica de negocio pero bueno eso es una
Douglas (30:21)
y no es una cuestión de que lo tengamos sea un rollo o un rato. Y si no es una de que que tengamos sea es una de que lo tengamos sea un rollo
Juan (30:42)
una de las desventajas que puede ser un poco tedioso o menos conveniente que las variables de entorno. El hecho de estar manejando y estar pasando esta referencia de un lado para otro, a veces se vuelve un poco tedioso, pero dependiendo de las dependencias o librerías que estemos utilizando, dependiendo de las librerías, puede ser más fácil o más manejable.
Douglas (30:48)
es para la experiencia de gente. Y es que es para la de la la experiencia de la gente, la de la Y es que es para la experiencia de gente.
Juan (31:12)
pero sí, esas dos son las que se me vienen a la mente que pueden ser desventajas al momento de utilizarlos
Douglas (31:21)
Sí, que son desventajas Juan, por otro lado, desventajas en lo tedioso, en lo tedioso, que se convierten fortalezas en otro sentido, normalmente lo que es tedioso suele ser robusto, lo tedioso es de ventaja porque es delicado mantenerlo y con cuidado, pero es robusto en el sentido de que por lo que te decía, por ejemplo, el archivo tiene que tener una estructura.
Juan (31:27)
Sí.
Douglas (31:47)
si el JSON o el YAML está mal formateado, ahí vas a tener un error inmediatamente, verdad, y si un valor tiene que ser numérico, tiene que ser numérico, mientras que la variable de entorno aguanta lo que le pongas y no vas a tener problema, y muchas veces se valida únicamente que...
Juan (31:53)
Sí.
Sí.
Douglas (32:06)
que la variable exista y que no esté vacía, esa es normalmente la validación, ya luego si la variable de entorno le querés agregar que verifique que el dato es correcto, es más lógica al momento de hacerlo, pero muchas veces con el hecho de que el YAML esté estructurado, eso de por sí solo te hace saber que la estructura del contenido viene bien.
y eso es algo fuera del lenguaje propio, Pero desde que él llama a lo del JSON no me dan error en su formato, eso ya me dice algo.
Juan (32:28)
Sí.
Douglas (32:37)
ya tenés mayor facilidad de validar el tipo de archivo porque viene incluido en el YAML o el JSON o el verdad que estás haciendo entonces por ese lado se vuelve robusto ese tipo de cosas y la validación es más rápida, más eficiente te aseguras de que tenés el tipo de valor que esperás entonces de nuevo
es lo que suele ocurrir, lo que vuelve fuerte a algo le genera ciertas ventajas, tal vez en el mantenimiento, pero puedo perfectamente ver lo que decís.
Juan (33:14)
sí, sí,
otro de nuevo en ese rango de es tedioso no es tanto un problema sino que se vuelve algo tedioso es que el archivo de configuración necesitamos tener un path una ruta específica donde esperamos que esté ese archivo entonces ya eso se sale de la lógica de la aplicación como tal sino que ya se vuelve una regla que tenemos que
definir de antemano que yo espero que mi archivo de configuración esté qué se yo en el root en el directorio raíz de mi proyecto o esté en el directorio punto config en linux de nuevo son cositas que cuando trabajamos al momento de desplegar hacia un servidor linux no es tan complicado pero cuando trabajamos con aplicaciones cli que se pueden ejecutar ya sea en mac linux o windows
ahí es donde tenemos que empezar a validar en qué ambiente estoy y dependiendo de eso es donde voy a ir a leer ese archivo que con la variable de entorno es más simple la variable de entorno en solo leo el valor y listo pero de nuevo está en esa línea de no es un problema como tal sino es algo poco ergonómico por decirlo de alguna forma
Douglas (34:39)
Sí, al final lo tedioso sí es una desventaja, que te genera otra ventaja, sí, pero pues es algo a considerar y puede ser que una aplicación más simple eso te lleve a mejor usar variables de entorno porque es pequeña y decidas usar eso. La solución que yo puedo sugerir es que no usen Windows, sino que usen Linux, no mentira, es mentira, es una broma.
Juan (34:43)
Sí.
Correcto. Sí.
Apoio a la emoción.
Douglas (35:03)
Sí, pero bueno, me gusta que vayamos viendo cómo fortalezas por un lado se vuelven de ventajas en otro y ya vamos a ver más adelante lo que implica los diferentes ambientes y cómo van variando esos valores según el ambiente. Pero pasemos ahora a las variables de entorno, ¿verdad? Y las variables de entorno de manera simple son variables que están corriendo en el sistema operativo.
Juan (35:23)
Perfecto.
Douglas (35:32)
en el runtime del sistema operativo y pueden ser inyectadas en cualquier momento, solo que son variables que dependen de cada sesión, que es una sesión, cada vez que te conectas a un servidor creas una sesión para vos y esa sesión va a tener variables de entorno cargadas. Los sistemas operativos dependen de esas variables de entorno para muchas de funciones, verdad, de...
sus tareas de día a día, por así decirlo. Hay una variable de entorno para ver en qué directorio estoy ahorita, una variable de entorno para ver qué tipo de terminal estoy utilizando y hay variables de entorno para ver quién es el usuario que está conectado. Hay muchísimas variables de entorno que están a disposición del sistema operativo por cada sesión. Entonces yo las puedo inyectar nuevas variables de entorno para el runtime. ⁓
puedo usar diferentes scripts para hacer, asegurarme de que esas variables de entorno estén siempre cada vez que exista una nueva sesión, verdad, porque como son para el runtime, si la agrego solo en el momento, cuando creo una nueva conexión no va a estar disponible esa variable de entorno o cuando reinice la computadora no va a estar disponible, pero hay manera de hacerlas permanentes, que cada conexión...
vuelve a generar la misma variable de entorno, pero una variable de entorno es un key value pair que está disponible a nivel del sistema operativo y vos nos mencionabas Juan que por eso en Golang la manera de llamarlo es os.getemp porque el olos es una librería que interactúa con el sistema operativo en Python igual es la librería del sistema operativo la que utilizas para llamar las variables de entorno.
Juan (37:05)
que no
Douglas (37:19)
al igual que los archivos de configuración están separadas de tu código, verdad, pero y son y las vuelve dependientes del sistema operativo, al igual que los archivos de configuración porque están en el sistema operativo y no están en tu código o dependientes de tu código, las variables de entorno también, eso es intencional, pero eso es lo que es una variable de entorno.
ventajas, hemos ido mencionando, verdad, entre palabras, que son fáciles de agregar, fáciles de manejar, menos tediosas, más fáciles de llamar en el código, verdad, mientras la mantengamos de que se inicialicen en cada conexión o en cada sesión.
Juan (38:09)
Sí.
Douglas (38:09)
que se inicialicen.
Fuera de lo que hemos mencionado Juan, ¿se te ocurren otras ventajas para usar variables de entorno?
Juan (38:18)
Si creo que la más grande, la ventaja más inmediata es la simplicidad. Como ya lo mencionaba, si la aplicación solo requiere uno o dos valores para configurarlos, pues las variables de entorno pueden servir. Por ejemplo, estas variables de entorno pueden servir tanto para el funcionamiento de la aplicación como en algunas ocasiones incluso para la construcción de la imagen Docker.
Creo que aquí nos estamos saliendo de lo que hablábamos, pero estas variables de entorno, su mayor atractivo sería que son fáciles de configurar. ⁓
eso creería yo y pues al momento de trabajar con ellas en la programación también las puedo utilizar desde cualquier parte sin tener que haber inicializado una clase o un struct o cualquier cosa solamente la mando a llamar, solo la obtengo del sistema operativo va ligado a la simplicidad entonces eso lo hace muy atractivo pero bueno ya mencionábamos anteriormente los problemas que pueden
con esto, que es un texto, texto plano.
Douglas (39:35)
Si, correcto, si es un texto plano ya te requiere agregar otras cosas Fíjate que yo le voy a agregar una ventaja más Juan y que es el dinamismo de la variable de entorno porque como nos dabas ejemplos normalmente donde la necesitas llamas os.getend el nombre de la variable y va a ir al sistema la va a jalar y va a ver cuál es el valor y entonces eso puede hacer que en el camino ajuste ese valor
y ya lo está reconociendo automáticamente, verdad, muchas veces puede ser que con eso se resuelve, mientras que un archivo de configuración, aunque es dinámico, se carga normalmente al inicio, porque no lo vas a estar leyendo cada vez que necesites ese valor, eso se vuelve eficiente y está generando I.O. en disco duro, entonces normalmente hay un proceso de inicialización
y luego guardas esa estructura en una variable, en otra estructura interna y si haces cambio al archivo de configuración no lo vas a ver en runtime porque ya están cargados. Entonces toca reiniciar el servicio. No ocupas volver a publicar, no ocupas nada de eso, pero normalmente toca reiniciar el servicio para que el servicio vuelva a inicializarse con el nuevo valor en la...
⁓ de configuración, ojo a veces pasa con las variables de entorno quiero decirlo porque como ya les mencioné las variables de entorno son por sesión, entonces si tenés digamos una aplicación en Node.js, esa aplicación cuando se ejecuta ese proceso crea una sesión para sí mismo, sólo porque cambia el valor de la variable de entorno para mi sesión no significa que la sesión
del proceso de Golang va a haber ese cambio, porque esa es la parte donde se vuelven, las variables de entorno son por sesión y eso hay que tenerlo claro. Entonces a veces puede ser de que tenga que cambiar las variables de entorno en mis scripts que inicializan la variable cada vez que se inicia una nueva sesión y me toque siempre reiniciar el servicio.
para que la nueva sesión que se cree para el nuevo servicio vea ese nuevo valor, o a veces siempre se puede requerir, ¿no? Pero al menos, por ejemplo, con PHP, yo desde el archivo de configuración le pude inyectar variables de entorno al proceso para hacerlo y entonces lo hace normalmente más dinámicos que los archivos de configuración, no sé si te has topado con ese tipo de cosas,
Juan (42:20)
Para serte honesto, no estaba muy al tanto sobre las sesiones, el hecho de que pueda que no cambie automáticamente. Normalmente trabajo con los archivos de configuración, entonces tal vez por eso no he tenido que explorar mucho esa parte. Pero bueno, lo voy a notar mentalmente. ⁓
Sí, el dinamismo es también muy importante. Pero también quisiera darte un contrargumento. No estoy diciendo que no esté de acuerdo con lo que decís. Pero un contrargumento podría ser que eso depende. Puede ser que tal vez la variable de entorno que yo estoy cambiando nunca más la vuelva a leer. Así que tiene que ser un proceso en específico
yo de antemano ya haya pensado en que cada vez que se ejecute eso voy a leer la eso por un lado, por el otro los archivos de configuración también pueden ser recargados de hecho en Go hay una librería llamada Viper, Viper como de la serpiente
Douglas (43:33)
mmm
Juan (43:36)
y es para el manejo de los archivos de configuración y tiene una funcionalidad muy interesante que me permite a mi observar si hay cambios en la configuración así que también, no la he utilizado de esa manera pero hasta donde tengo entendido me permite a mi cambiar el archivo de configuración y debería recargar todo automáticamente
así que bueno nuevamente esto lo que quiero dar entender es que va de la mano con la lógica que estemos implementando la lógica que va a determinar si yo quiero de a futuro poder cambiar los valores que se cargan automáticamente cuando son servicios o aplicaciones que van a correr en un contenedor docker por lo general no tenemos que preocuparnos tanto por eso ya que la idea es que
necesito cambiar algo de la configuración o de la variable de entorno lo cambio y luego solo reinicio el contenedor porque el contenedor debería ser efímero y no tener ningún estado pero si es algo que también dependiendo de lo que necesitemos se puede hacer
Douglas (44:48)
Sí,
fíjate que estoy muy de acuerdo con tu... lo dijiste contra argumento, en realidad que me parece un argumento válido y estoy muy de acuerdo con él. Yo creo que estamos, y vale aclarar para las personas que nos ven y nos escuchan, estamos tocando como de manera general, ¿no? Hoy en día con los contenedores, la mayoría de este tipo de cosas no son realmente un problema tan serio porque en cada despliegue...
se levanta un nuevo contenedor y eso es rápido y ya sabemos que un nuevo contenedor es como haber levantado una nueva máquina virtual por completo desde cero y eso pasa en segundos. Entonces muchas de estas cosas realmente no son una complicación con contenedores más allá de que es importante que entendamos cómo funciona y por supuesto ya vamos a ver un poquito de eso pero en contenedores, un archivo de configuración
Juan (45:21)
Sí.
Douglas (45:42)
no va a ser un archivo dentro de tu contenedor, sino que se tiene que montar luego, ¿verdad? Y eso trae otros retos. sí, sería mayormente un problema si corriera en máquinas virtuales. Ahí tal vez sería un problema más a considerar que en contenedores. Pero sí.
Juan (45:59)
Sí.
o cuando estamos trabajando con herramientas,
por ejemplo, un CLI, una herramienta CLI, también, y que está con un archivo de configuración, ahí vale más la pena de estar pendiente de si cambió no.
Douglas (46:15)
Sí, el tipo
de aplicación cuenta, ¿verdad? Y estoy muy de acuerdo con ello. Me llama la atención eso que decís de recargar y es un concepto que ya he escuchado, sin embargo, no lo he visto puesto en práctica, ¿Recargar la configuración, cómo funcionaría eso? ¿Cómo que crearías un endpoint, asumiendo que esto es una API, crearías un endpoint que genere, que vuelva cargar la configuración o cada cierto tiempo volvés a leer la configuración? Porque sé que no lo vas a hacer en cada request, sino... ⁓
Yo como alguien de sistema, si vos me decís que tenés una aplicación que en cada request va a leer el archivo de configuración, probablemente no creo que te lo aceptes mucho, ¿verdad? Pero ¿cómo funciona en ese sentido implementar eso?
Juan (46:59)
depende mucho de cómo va a funcionar obviamente, siempre la respuesta inmediata es depende. Pero asumiendo que lo que queremos es que la configuración sea dinámica, yo lo que haría es que en vez de cargar estas configuraciones, por ejemplo,
Douglas (47:06)
Sí, sí, sí.
Juan (47:21)
lo que te mencionaba, la cantidad de tareas que podemos realizar de manera concurrente. Digamos que inicialmente tiene un valor de dos tareas. Yo lo que haría es que en vez de cargar ese valor al momento de inicializarlo y guardarlo dentro de, digamos, la clase de concurrencia, tengo una clase que tiene las tareas. En vez de guardar ese valor en una variable de la clase, lo que haría es que cada vez que quiera ⁓
decidir cuantas tareas voy a ir a leer a una variable global de la configuración entonces podríamos tener por ejemplo un paquete llamado settings dentro de nuestro sistema y settings tiene de manera pública o expuesto el valor de la cantidad de tareas así que eso lo que me permite a mí es que si yo cambio ese valor pues como cada vez que
yo necesito decidir cuántas tareas, estoy yendo a leer esa configuración, entonces ya ahí sería de manera dinámica. Ahí lo que tendríamos que tener en cuenta es que si bien yo estoy decidiendo cada vez, perdón, cada vez que estoy decidiendo, estoy yendo a leer al package de settings, el paquete de settings como tal no tiene que estar abriendo y cerrando el archivo constantemente. Es solo que va a abrir y
y cerrar el archivo cuando detecte que hay un cambio. Y ahí podría estar simplemente viendo si hay un cambio en el archivo como tal, tiene una referencia y así. Esto ya lo hacen muchas librerías, eso yo recomendaría no hacerlo directamente nosotros. Pero...
Douglas (49:10)
Si, no reinventar el agua hervida ahí.
Juan (49:12)
sí, sí, sí, sí, es lo mejor pero por lo general pues lo que se hace sería eso, yendo a un punto central de la configuración en vez de tener los valores ya en la clase solita, como que tiene
Douglas (49:31)
Sí, no,
interesante, interesante, como te digo, es obviamente un concepto por el cual ya ha cruzado enfrente de mí, por así decirlo, sin embargo, no le había prestado atención a cómo se implementa y me parece interesante.
Juan (49:44)
son muy contados
los casos creo yo donde en tiempo de ejecución ahí podemos cambiar la configuración entonces es normal que uno no lo haga
Douglas (49:55)
Sí, no, es que lo que decís que la respuesta depende realmente es la respuesta correcta, depende porque normalmente, como te digo, sobre todo hoy en día con contenedores no necesitas estar yendo a leer constantemente o hacer cambios tan dinámicos porque recrear los contenedores, los pods, ya es bastante dinámico como para querer agregar tanta complejidad, ¿no?
Juan (50:08)
Mm-hmm.
Douglas (50:24)
el depende significa que van a haber casos en los que si querés que sea súper dinámico y ahí donde implementas ese tipo de cosas y bueno, me has dado esa guía hoy.
Juan (50:32)
Sí. Es que...
siempre me esfuerzo y esto lo digo en general para cualquier developer que está escuchando me gusta forzarme a pensar fuera del ambiente de desarrollo web creo que normalmente nosotros pensamos en términos de un servidor de linux en la nube y me conecto y microservicios etcétera pero hay muchos otros tipos de aplicaciones entonces para estos otros tipos de aplicaciones hay otros desafíos
y otras formas de hacer las cosas
Douglas (51:10)
Si, si no puedo
afrontar un CLI como que es una aplicación web porque el CLI en cada ejecución se inicializa de nuevo, ¿no? Se inicializa y termina, es un programa que se inicializa y termina con cada comando, cada ejecución. Entonces ahí es totalmente diferente a un servicio web que va a estar constantemente corriendo y ejecutando. Entonces si, no, comparto eso, me gusta.
Juan (51:14)
correcto
si, si,
Mhmm.
Douglas (51:37)
Para avanzar Juan, voy a decir una desventaja en mi opinión de las variables de entorno, sobre todo comparado con archivos de configuración y es que en mi opinión, Juan esta es una opinión mía, yo no sé si esto lo vas a encontrar en libros por ahí, en otros blog posts porque es algo que nunca he tenido que buscar porque esta es mi opinión y es que cuando saque mi libro, pendientes, 2030.
Juan (52:00)
Va a estar con dosa, que es tu libro.
Douglas (52:08)
pero yo creo que, estoy convencido que son un poco más inseguras en comparación con el archivo de configuración, ¿en qué sentido? Y quiero dar un poco de una aclaración y como contexto, yo siempre he dicho que en cuanto a seguridad, si alguien accesa a tu sistema, ya sea tu servidor, tu contenedor, si alguien llega a accesar hasta ahí, realmente que tenés un problema más serio.
que la vulnerabilidad es que puedan tener tu aplicación. sea, alguien ya llegó hasta ahí, casi, o sea, vos puedes tener los archivos encriptados, pero como se conectó a tu servidor o a tu pod, en runtime no van a estar encriptados. Entonces, ya ahí la encriptación y todo eso no contó porque alguien ya entró a tu sistema. Entonces, no es una perspectiva de inseguridad desde ese sentido.
Y verdad, porque si alguien entra en tu sistema, ya está complicado. A veces dicen, tenés servicios en redes privadas. No son redes públicas, redes expuestas. Y quieren que encryptes la conexión entre las redes privadas. Y es una buena práctica, está bien, está muy bien, es una buena práctica. Pero de nuevo, si vos tenés un attacker que tiene la opción de estar en medio de la comunicación en una red privada, tenés otro problema serio. Entonces, hazelo por...
Juan (53:30)
Sí, ya el cifrado
pasa a segundo plano.
Douglas (53:32)
Sí, sí, sí,
verdad, sí encriptarlo siempre, pero lo más seguro es que si alguien llegó, logró ponerse entre la comunicación de los servicios internos, es muy probable que no le cueste mucho entrar de un solo a uno de esos sistemas, ¿no? Pero habiendo dicho eso, en la comparación de variables de entorno contra archivos de configuración, como ya lo mencioné, están en runtime corriendo, todos estos lenguajes de programación,
tienen una forma de accesar a todas las variables de entorno y a desplegarlas a hacer un dump de todas las variables de entorno. Vos no dijiste que el os.getemv y le das una variabilidad específica, ¿no? Pero hay una manera, estoy seguro, en Golang de os.algo y que te va a hacer el dump de todas las variables de entorno que existen. Lo mismo pasa con Python, con PHP, con Ruby, con el lenguaje que usés. De la misma manera que tienen forma de accesar a ellas,
tienen forma de saberlas hacer un dump, entonces si alguien logra hacer un code injection en tu aplicación web, esta es la perspectiva web, si alguien logra hacer un code injection
puede hacer una inyección de ese comando, de esa directiva en el lenguaje de programación que esté escrito para hacer un dump de todas las variables de entorno. No necesita saber cómo se llama la variable de entorno. Yo no necesito saber cómo se llama la variable de entorno donde tenés el token para conectarte a un servicio crítico o donde tenés la información de bases de datos. Si yo logre hacer el code injection para que me despliegue todas las variables de entorno,
con esa información ya tengo lo que necesito para hacer un ataque más dirigido, verdad. Mientras que con archivos de configuración alguien puede decir bueno, pero puedes decirle que te despliegue el contenido del archivo de configuración, sí es cierto, pero tienes que saber dónde está físicamente ese archivo o si guardó eso en una estructura, el contenido del archivo en una estructura, una variable.
tiene que saber cómo se llama esa variable, estructura para poder mostrarla porque no hay un comando que diga hace un dump de todas las variables que tenés en memoria, no existe eso pero las variables de entorno sí mientras que para el archivo de configuración tengo que saber cómo se llama o dónde está ubicado cuál es el nombre de la variable si quisiera hacerlo entonces ya es mucho más difícil poder hacerlo.
Yo sé que puede sonar algo, alguien puede decir, puxa, pero te estás buscándole el detallito, la manchita negra en la pared blanca. Sí, puede ser, pero cuando se trata de seguridad, nos toca hacer eso. Entonces, yo siempre digo, si alguien ya accesó, el problema es más serio, pero algo como un code injection, si nos corresponde a nosotros, tanto los desarrolladores en la seguridad de su aplicación, como nosotros los de operaciones y sistemas. Entonces...
Por esa parte también es una de las razones por las cuales yo preferiría archivos de configuración contra variables de entorno. No sé si te... Lo hemos discutido antes nosotros, ¿verdad? Yo lo recuerdo muy bien haber mencionado estas cosas, pero si eso es parte de las razones por las cuales al final...
Juan (56:53)
Sí.
Douglas (56:59)
porque ya nos dijiste que vos preferís los archivos de configuración mayormente, no sé si eso cuenta entre las cosas por las cuales vos decidís usar archivos de configuración contra variables de entorno.
Juan (57:11)
es un gran motivo la verdad para utilizar los archivos de configuración porque es muy posible recibir un ataque de inyección siempre existen exploits que no conocemos y que pueden los atacantes pueden utilizar y desplegar las variables aun si no es con un comando en específico a veces en Go o en cualquier lenguaje de programación podemos ejecutar
comandos de shell por ejemplo en go hay una forma donde podemos utilizar mandarle ejecuciones por ejemplo en mi computadora o en el servidor está instalado docker entonces desde go yo puedo utilizar el comando docker le paso esa instrucción al sistema operativo y lo ejecuta que pasa que esas instrucciones son como son de tipo texto son strings
así que dependiendo de la aplicación podría ser que recibamos algún parámetro y lo poni lo se lo pasamos a esta instrucción como parámetro extra pero podría haber un tipo de inyección ahí que no esté al que no estemos al tanto y de esa manera podríamos imprimirlo de hecho se le recomiendo a las personas que lo intenten abran una terminal y escriban la palabra en en v pequeña y eso le va a mostrar toda la
la
variable de entorno que están cargadas en su ambiente de escritorio en este momento. Así que sí, ese es de los motivos más grandes y más determinantes al momento de utilizarlos. Otro motivo que...
como que eso fue el motivo que me orilló a empezar a explorar los archivos de configuración y fue una solución que nosotros implementamos recuerdo en su momento recuerdo que hablábamos, bueno, donde va a este secret, como vamos a hacer el rotation y todas estas cosas pero otro motivo que es el que me hizo a mi más utilizarlo más seguido en diferentes tipos de aplicaciones es cuando estoy trabajando con CLIs cuando yo estoy haciendo mi propio CLI para mi
personalmente es mucho más cómodo guardar todas las configuraciones en un archivo en específico en linux lo como el estándar es que las configuraciones se guardan dentro de un directorio llamado punto config dentro de punto config vamos a encontrar las configuraciones de las diferentes aplicaciones que tenemos instaladas así que yo puedo guardar esa configuración ahí y mi cli mi binario lo puedo estar leyendo de
de esa parte. ¿Y qué me permite eso? Pues me permite que en el CLI muchas veces tenemos los comandos de init, setup, configure, por ejemplo AWS es AWS configure y ya nos empieza a pedir los parámetros para configurar nuestro perfil y los tokens, etcétera. Así que con los CLIs eso es muy conveniente poder estar cambiando estos valores
Douglas (1:00:21)
y el proceso es que se pierda muy bien el Y el proceso es que se pierda muy bien el tiempo.
Juan (1:00:29)
y no estar seteando variables de entorno que también se puede, también es válido pero cuando tenemos muchos archivos
Douglas (1:00:29)
Y el proceso es que pierda bien el Y el proceso es que bien el tiempo.
Juan (1:00:37)
de configuración eso puede ser muy cómodo aparte que de nuevo como es una ruta en específico que ya conozco se vuelve un poco fácil para mi ir a ese directorio buscar el archivo de configuración y modificarlo si así yo lo quisiera de manera externa
Ese para mi es uno de los motivos por los que me he vuelto fan de esta manera de configuración.
Douglas (1:01:08)
Sí, sí no y lo comparto, lo comparto con vos en todo sentido la idea y de nuevo, no que estemos diciendo de que usar variables de entorno está mal o quien lo está usando está mal, por el contrario es uno de los estándares en la industria, o sea, usas archivos de configuración o usas variables de entorno según el caso
Juan (1:01:27)
Sí.
Douglas (1:01:32)
va a haber una mejor que el otro, al final del día, cuál preferís es acorde a tus necesidades, acorde a tus preferencias. Y de hecho, Juan, hay ciertos casos en los que no puedes evitar usar variables de entorno. No tenés la opción de un archivo de configuración, por ejemplo, en serverless, ¿verdad?
en serverless o en estos servicios de SaaS, de software as a service, no tenés la opción de inyectar un archivo de configuración, a menos que lo hagas dentro de tu build y que quede dentro del contenedor, lo cual es una mala práctica, ¿verdad? Es una mala práctica. Ya les dije, ¿verdad? Si necesitan un archivo de configuración.
al momento de un build quiere decir que hay algo malo pero a menos que sea así realmente lo que es con serverless o con software as a service como Heroku o estos servicios que te dan ese tipo de cosas no tenés la opción de archivos de configuración ellos pero si te dejan inyectar variables de entorno entonces en ese tipo de en ese caso es tu única opción y no estarías haciendo algo malo verdad
Juan (1:02:21)
Sí.
Douglas (1:02:47)
solo porque estaba usando variables de entorno y no archivos de configuración. por esa parte, ahí no hay nada que discutir. O es variables de entorno o es variables de entorno. No hay otra alternativa. Entonces, sí.
Juan (1:03:04)
si,
si, tampoco hay que ser extremistas y no estamos diciendo que las variables de entorno están mal o desfasadas o nada que ver aunque ya veo que van a haber comentarios de personas diciendo de que como estamos, como nos atrevemos a recomendar una cosa sobre la otra pero la verdad es que no en mi día a día utilizo variables de entorno constantemente es solamente desde nuestra perspectiva si tuviésemos
Douglas (1:03:21)
Sí.
Juan (1:03:34)
elegir una opción o la otra pues como ya han visto pues preferimos un archivito de configuración
Douglas (1:03:41)
Sí, nuestra perspectiva
y nuestra preferencia, que también tenemos derecho a preferencias, ¿verdad? Entonces, que nos respeten esa parte. Y de hecho, Juan, sobre todo cuando hablás de CLI o incluso servicios, yo honestamente prefiero que soporte a ambos.
Juan (1:03:44)
Sí.
Sí, sí,
No,
Douglas (1:04:01)
que lea el archivo de configuración, pero que si existe la variable de entorno tome el valor de ahí, porque tal vez para una ejecución en particular quiero probar un valor nuevo, o quiero apuntar a otro lado sin necesidad de cambiar el archivo de configuración. Vos mencionaste por ejemplo el CLI de AWS, que cuando le das configure, vos pones los valores y en realidad lo que hace es que crea el archivo de configuración por vos o lo modifica, ¿verdad?
Juan (1:04:01)
Sí.
Excepto.
Douglas (1:04:27)
Pero aunque exista el archivo de configuración, si yo le paso la variable del key y el secret, él va usar esos valores para autenticar en lugar de lo que tenga mi archivo de configuración. como para un trouble shooting, una prueba corta, hasta prefiero más bien que soporte a ambos, ¿verdad? Yo voy a preferir el archivo de configuración, pero para el dinamismo, cuando lo necesite.
voy a preferir el archivo de configuración y eso más bien me da lo mejor de los dos mundos, a la vez me da las vulnerabilidades de los dos mundos, pero a pesar de que me da también las vulnerabilidades de ambos, de poder inyectar una variante de entorno y tratar de modificarlo, yo en lo personal prefiero tener las dos ventajas, pero sí, normalmente me inclino por el archivo de configuración.
Juan (1:05:19)
Eso lo he visto en los GitHub Actions. Yo personalmente, Lo he visto en los GitHub Actions de herramientas que me permiten a mí configurarlas de otra manera. Pero al momento en que se ejecutan dentro de un GitHub Action, utiliza las variables de entorno. Entonces eso me permite a mí ir a la configuración del repositorio, crear el GitHub Secret y ese Secret es el que va a utilizar como variable de entorno. Eso lo he visto también.
Douglas (1:05:19)
por ese tipo de asuntos.
sí sí sí sí pero bueno son las opciones que hay ahora habiendo mencionado cómo se usan como que sus pros y contras me gustaría que hablemos un poquito no necesariamente a profundidad pero un poquito de cómo llegan esos valores a tu sistema recordamos recordemos que la intención de esto es la parte configurable de tu aplicación o de tu sistema
Juan (1:06:07)
Ok.
Douglas (1:06:14)
Son áreas configurables que queremos que se puedan estar cambiando sin necesidad de estar cambiando el código fuente. Son áreas configurables, pero ¿cómo llegan a nuestro sistema? Ya hemos mencionado de que en un ambiente de prueba son diferentes las credenciales que necesitamos para base de datos que los que ocupamos en el ambiente de producción. Incluso va cambiando por ambiente. ¿cómo llegan estos valores de configuración, ya sea archivos de configuración o variables de entorno?
a tu sistema y entonces yo creo que lo que es relevante discutir de manera breve Juan sería entre un ambiente de contenedores y un ambiente de máquinas virtuales porque ya dijimos que cosas como
serverless y SaaS, pues necesitas varios entornos y te lo da la interfaz, te da un dashboard y ahí lo incluís y pues es bastante fácil y va a depender de cuál es la plataforma pero al final lo haces desde una interfaz gráfica. Pero en cuestión de despliegue de aplicaciones que vos controlas en tu infraestructura, de nuevo, ya sea para...
Juan (1:07:04)
Sí.
Sí.
Douglas (1:07:25)
máquinas virtuales o para contenedores y en una máquina virtual si nos vamos con los con las variables de entorno pues normalmente son agregadas por el sysadmin o por la persona de operaciones ya sea el desarrollador o el project manager o el arquitecto alguien sabe cuáles son los valores finales para cada ambiente se los da de manera segura al
al de sistemas y él va y se asegura de que esas variables de entorno existan, ¿verdad? En esto estamos hablando de archivo, de sistemas que corran en máquinas virtuales en instancias. Y es lo mismo con los archivos de configuración. El arquitecto, el programador, se los da a la gente de sistemas y alguien va y los agrega, se asegura que el archivo exista.
va a cambiar los valores que tenga que cambiar por cada ambiente, en el ambiente de prueba va agregar el archivo de configuración con los valores del ambiente de prueba o las variables de entorno con los valores del ambiente de prueba y lo mismo en cada ambiente de producción, etc. Entonces, en la mayoría de los casos ese es el flujo. ¿Hay ciertas formas de automatizar? Sí, sí las hay.
a veces se puede hacer, por ejemplo, en ambientes de nuevo, recordemos que estamos hablando de ambientes de máquinas virtuales, ¿no? Se pudiera hacer como en un CI-CD pipeline que genere el archivo y lo inyecte. La negativa de eso es que cuando el CI-CD pipeline hace eso y genera un archivo, eso se vuelve como un artefacto.
Y ese artefact a veces queda guardado dentro de tu sistema de CI-CD Pipeline por un tiempo y está al riesgo de que alguien pudiera accesar a él. De nuevo, todo eso debería ser protegido con usuarios y autenticación, two factor authentication y todo ese tipo de cosas. Sin embargo, queda guardado como artefact cualquier archivo que se genera. Pero si lo queremos automatizar, control de esos archivos
en un ambiente virtualizado podemos usar un CI CD pipeline para hacerlo, pero normalmente es así, Juan, y yo recuerdo que conversaciones que en algún momento tuvimos vos y yo con otras personas, alguien decía es que si si si el archivo está ahí en el servidor o la variable de entorno y se conecta a alguien y lo ve, va a poder tener acceso a ellas
Y mi respuesta en eso siempre ha sido bueno, alguien tiene que saber esos secrets, ¿no? O sea, esa información alguien la tiene que saber porque de alguna manera tiene que llegar. No la puedo crear de la nada y ya, que se empiece a pasar a todos lados y nadie la va saber. Alguien lo tiene que saber. Entonces por esa parte hay que asegurarnos de tener un flujo de que solo las personas necesarias lo sepan. Porque yo no tengo por qué saber los secretos de otra...
de una aplicación que yo no manejo, no es que yo voy a tener mala intención si lo supiera.
porque no es así, pero una persona más que lo sepa es un riesgo más y en ese caso es un riesgo innecesario porque yo ni necesito saberlo para que vas a correr ese riesgo de que de alguna manera a se me escape sin querer, esa es la manera que normalmente llegan las variadas de entorno o los archivos de configuración a sistemas que corren en máquinas virtuales, se me escapa alguno, vamos a conocer de otro.
Juan (1:11:01)
No estoy muy seguro, que... Ahora, esto referente a lo que hablábamos en un episodio anterior sobre Configuration Management, ¿aquí es donde entraría Ansible? ¿O no?
Douglas (1:11:18)
Sí, sí, me gusta que lo menciones porque mi respuesta ha sido como alrededor de lo tradicional y genérico, recordemos. Si lo querés poner de esa manera, como forma manual, como te digo puede ser un CI-CD Piblant donde lo tengas ahí, se puede manejar con Configuration Management en sistemas grandes, normalmente yo lo haría con Configuration Management.
Juan (1:11:31)
de forma manual, digamos.
Douglas (1:11:47)
ya toca manejar la información sensitiva con secretos de forma segura y vamos a hablar un poquito de eso también de forma breve pero esa es otra manera en la que puedes estar asegurándote de estar pasando el archivo entonces es la forma en la que yo lo hiciera sin embargo siempre hay Juan pues alguien va a saber, alguien tiene que saber cuál es ese valor para ponerlo en tu configuration management
y luego que el Configuration Management haga el despliegue. Por eso te digo, esa parte alguien tiene que saber esos valores sí o sí, pero me gusta que hagas la pregunta, en realidad de manera preferible esos valores se van a manejar con Configuration Management.
Juan (1:12:15)
Sí.
Sí.
pero si me llama la atención y me saltan las alarmas y tengo muchos recuerdos de cosas que he visto cuando decís pasa los valores de manera segura porque cuántas veces no hemos visto que se pasan las credenciales de algo por medio de Slack en el mejor de los casos. Hay empresas que utilizan WhatsApp para la comunicación
interna
entonces sí podríamos podríamos tener todo súper seguro nuestro sistema y están cifradas los valores pero en nuestro sistema de comunicación está en texto plano entonces es muy importante saber manejar esos secretos
Douglas (1:13:23)
Sí, es que ese es un tema por sí solo Juan, ¿verdad? Porque yo puedo tener el implementado en el departamento, en el equipo, la manera más segura y eficiente para movilizar esa data sensitiva entre sistemas, entre desarrolladores, entre usuarios, etcétera. La manera más segura posible, pero si cuando yo la recibo, la agarro y la copio en texto plano en mi laptop.
Juan (1:13:27)
Sí.
Douglas (1:13:53)
Ahí estoy exponiéndolo a que cualquiera pueda tener acceso a ella. Y toda esta seguridad que se implementó allá, vine a vulnerarla yo de manera fácil. Y alguien puede pensar, sí, pero ¿quién la va a sacar de mi laptop? Bueno, esa es la mentalidad que los hackers quieren que tengas. Si pensás así, estás bien alineadito con los hackers, con las personas con mala intención. Entonces, de nuevo, ese es un tema por sí y solo.
Juan (1:13:57)
Un sticky note.
mmm
Sí.
Sí.
Douglas (1:14:23)
pero más allá de ello lo que se busca es de manera segura con configuration management copiarla y hacer el despliegue porque por ejemplo Ansible te va tirando el output de lo que va haciendo y si no sabe que esa es información sensitiva te puede tirar el password o el token en el output y para quienes no sepan ese resultado, ese output que está viendo en tu terminal queda guardado en texto plano en tu computadora.
el historial y eso queda guardado en texto plano en tu computadora, entonces hay manera de accesar a ello, aunque vos lo diste clear y borrar, hay manera de accesar a ello por un tiempo, tampoco querés que se despliegue, o igual si estas en CICD y lo querés inyectar como secreto, si no lo haces de esa manera, en el output del CICD va a quedar ahí, cuál es el password, cuál es el token, etcétera, entonces el manejo de los secrets
Juan (1:14:55)
vlogs
Mm-hmm.
Douglas (1:15:19)
es un tema por sí solo, al final del día lo que tenemos que saber es que alguien va a saber esos valores y tiene que asegurarse de inyectarlos de forma segura, ya sea manual, cuando se trata de instancias, porque recordemos que estamos todavía hablando de instancias, ya sea manual o ya sea automatizada con CI-CD o de preferencia que es lo que yo uso y busco usar siempre, es Configuration Management.
Juan (1:15:21)
Sí.
Sí, siempre
las máquinas virtuales, por eso hemos transicionado a otro sistema de despliegue, sí las máquinas virtuales tienen estos desafíos, ahora los veo como desafíos, antes era la norma.
Douglas (1:16:02)
Sí,
igual de un lado como developer pues lidia menos con ellos, de mi parte me toca, hay servicios bases de datos, normalmente siguen corriendo en máquinas virtuales, clúster grandes para caching.
Juan (1:16:08)
Sí.
Douglas (1:16:19)
muchas veces se prefiere que corran máquinas virtuales. Entonces toca siempre lidiar con ese tipo de cosas. Igual mantener un cluster de Kubernetes, aunque nos toca interactuar de manera directa con los nodos, hoy en día cada vez menos, por lo final son máquinas virtuales y tengo que asegurarme que tengan seguridad acorde. Pero bueno, esa es la manera. Y hablando de eso, pasemos ahora a cómo se maneja esa información en ambientes de contenedores.
Juan (1:16:23)
Sí, es cierto.
Douglas (1:16:48)
ya sea las variables de entorno o los archivos de configuración y es en esta parte Juan donde qué manejes vos por tu cuenta en tu código si variables de entorno o archivos de configuración cuando es con contenedores de la parte administrativa
se vuelve un poco menos relevante a veces, a veces, verdad, de la parte de código pues no, siempre van a haber las diferencias marcadas existen independientemente de donde corra, de la parte administrativa no existe mucha diferencia, la parte de seguridad si se mantiene, lo que dije, no, de que es más fácil sacar un DOM de todas las variables de entorno que encontrar cuál es el archivo de configuración.
Pero, ¿por qué? Porque en contenedores el archivo de configuración se inyecta, por ejemplo, en Kubernetes lo inyectas ya sea con un config map. Un config map es un recurso de estos Kubernetes que le puede dar de contenido muchas líneas y generarte con ello un archivo, ¿verdad? Un mapa de configuraciones es la traducción literal, correcto. Y también tienes secrets dentro de Kubernetes que son...
Juan (1:17:55)
mapa de configuraciones.
Douglas (1:18:03)
idealmente donde guardamos información sensitiva y como se llama, e igual, puede traducirse a que eso genere un archivo dentro de tus contenedores y ese config map se monta dentro de cada contenedor en el directorio donde el código espera que exista el archivo de configuración, verdad.
Cuando el developer, el arquitecto, me da a mí, como alguien de sistema, el archivo de configuración que quiere, yo creo el config map o yo creo el secret dentro de Kubernetes y me aseguro de montarlo en el directorio que lo necesita. Hablando de manera manual, ¿Verdad? Me aseguro de montarlo en donde lo necesita. Y lo mismo con las variables de entorno. Dentro de Kubernetes o dentro de DockerSorm, le digo que quiero estas variables de entorno definidas.
y se las creo, ¿verdad? Y desde ahí las estoy modificando y de esa manera es como terminan o las variables de entorno o los archivos de configuración en un ambiente de contenedores.
Juan (1:19:11)
o sea desde tu perspectiva ya sea variable de entorno o archivo de configuración ambos representan el mismo nivel de esfuerzo
Douglas (1:19:22)
Mira que no te olvido lo que dije, no mira me gusta que preguntes porque tenía pensado aclararlo no sé si necesariamente el mismo nivel de esfuerzo puede que algo inicialmente sea tedioso verdad pero porque si vos me das un archivo de configuración para mí va a ser relativamente simple crear el config map y montarlo dentro del contenedor
Juan (1:19:39)
OK.
Douglas (1:19:52)
¿Verdad? Pero, como normalmente se trabaja dentro de Kubernetes específicamente, se trabaja con algo como Helm ¿Verdad? Que en Helm lo que hace es que genera templates de los manifestos de Kubernetes. Normalmente no se trabaja con el manifesto por sí solo porque entonces se vuelve tedioso, sobre todo cuando tenés muchas aplicaciones del mismo tipo.
¿Verdad? Entonces, tendría que ir a cambiar el manifesto de cada aplicación y tener manifestos por cada aplicación. Mientras que con Helm, el Helm templetiza por usando un solo file como referencia que es el values file, templetiza para cada aplicación. Entonces, de nuevo, si vos me decís que es un config file, yo voy a poner en Helm que cree el config map o el secret dependiendo si es información sensitiva.
y que eso lo monte en un directorio específico que es donde lo espera tu aplicación. Ahora, si tu aplicación es con variables de entorno, yo voy a crear siempre el config map, ¿verdad? Pero Kubernetes tiene una forma de crear variables de entorno en base al config map, ¿verdad? Entonces, yo le voy a decir a Kubernetes, OK.
Juan (1:21:14)
ok
Douglas (1:21:19)
la variable de entorno en mayúscula de bague en bajo user va a ser igual a el config map de aplicación 1 y dentro del config map la variable que se llama de bague en bajo user y entonces así le asigno a la variable de entorno un valor que está en un config map o un valor que está en un secret y de esa manera le monto todas las de entorno
sacándolas de un config map, ¿verdad? De hecho, una de las mejores prácticas que se suele hacer en los con Helm, ya dije yo que crea los templates basados en un solo archivo, que es el values file. Es un Jamf file con un montón de valores. Entonces, en ese values file vos podés pasarle, digamos, el nombre que son parte de un archivo de configuración. El nombre de la aplicación, la URL, ¿verdad?
Juan (1:22:04)
Sí.
Douglas (1:22:18)
en que va escuchar, si quieres que tenga un cron job corriendo, entonces vos le pasas esos valores a un archivo de configuración, entonces yo los puedo poner en el values file del jamman y lo que voy a hacer atrás yo con help es que voy a agarrar esos valores y con esos valores voy a crear un config map.
aunque sea con config map lo tuyo, voy a ganar esos valores del values file, voy a crear un config map y luego voy ganar ese config map para ya sea inyectarlo como config map si así lo querés o para crear las variables de entorno del config map si así lo querés.
Juan (1:22:43)
Sí.
O sea el
punto de entrada siempre sería el config map de Kubernetes y ya después eso se puede convertir ya sea en variables de entorno o un archivo de configuración.
Douglas (1:23:13)
Exacto, va a ser o ConfigMap
o Secret, si es sensitivo. Entonces eso significa que si vos tenes un archivo de configuración, yo siempre voy a crear un ConfigMap con key values probablemente. O formo el archivo de configuración porque el ConfigMap puede ser un JSON, puede ser un Jaml, puede ser un Tomo, lo Mini, puede ser un Bascript.
Juan (1:23:17)
secret
Ok
Douglas (1:23:42)
puede ser un config file de NGINX, eso es lo que se usa para inyectar configuraciones en NGINX, por ejemplo, con Help, dentro de Kubernetes, perdón, un config map de Kubernetes. Pero entonces, al final del día, para inyectar eso dentro de los contenedores, ya sea por variable de entorno o como config map, el punto de pivoteo va a ser o un config map dentro de Kubernetes o ⁓ un...
secret de Kubernetes, es en esa parte donde si el esfuerzo varía un poco pero al final del día yo tengo que crear un config map o un secret y esa es la parte en la que te digo que para ya en contenedores en cuestión operativa no hay tanta diferencia por así decirlo sobre todo una vez que tenés listo el Helm Chart y que eso va a empezar a repetirse si usaste variables de entorno o
Juan (1:24:23)
Ok
Douglas (1:24:40)
de configuración para mí se vuelve casi que irrelevante de nuevo más allá de los beneficios pros y contras en cuestión de seguridad verdad más allá de eso dentro de contenedores se vuelve menos relevante y por eso mencionaba al inicio que muchas de las ventajas y desventajas que estamos dando es como de manera general verdad como para incluirlos a todas las personas que trabajan en diferentes ambientes
pero la versatilidad de los contenedores ha venido a remover muchas de esas cosas que antes se tomaban mucho tiempo y ya anulando ciertas desventajas y lo queremos ver de esa manera.
Juan (1:25:17)
Sí, bueno es que los contenedores han venido a cambiar mucho en industria. Bueno, ya cambiaron la industria.
Douglas (1:25:26)
Sí, sí, sí,
pero bueno, la verdad yo creo que eso Juan, para concluir el tema, yo creo que solo nos falta discutir de manera breve un poco el manejo de esos secretos, yo creo que sí vale la pena mencionarlo porque si trabajas con archivos de configuración y tenés información sensitiva, pues como ya lo dijimos, no puedes subir eso a version control, ¿verdad? No puedes subir eso a tu git.
no lo podés pasar por un mensaje de Slack, no lo podés mandar por correo, Dios santo, créeme que he visto gente que manda por correo credenciales porque piensa que es temporal, entonces no es temporal, mañana lo borro, pues es que mañana no llegue, yo creo que por eso creo que vale la pena cuando trabajamos de la parte de configuración, el manejo de secretos,
Y yo creo que la mejor práctica en ese sentido, es usar una herramienta específica para manejar secretos. ¿Cuáles son las comunes que existen como de las más usadas? Está HashiCorp, que son los mismos creadores de Terraform. HashiCorp tiene su propia solución que se llama HashiCorp Vault. O la bóveda de HashiCorp.
ellos manejan, tienen una forma, este es un lugar centralizado, ¿verdad? donde se agregan los secretos de manera segura y se comparten a los sistemas si le das los permisos para accesarlo, ¿verdad? Luego, a nivel de código o a nivel de configuración siempre necesitas una manera para autenticar de manera segura contra este servicio y poder extraer el secreto.
Y ya con el secreto ahí lo inyectas en tu archivo de configuración o lo inyectas en tu variable de entorno de la manera en que decidiste trabajar con ello. esta es una manera centralizada donde puedes mandar las diferentes configuraciones. AWS tiene AWS Secret Manager. Sé que el de Google también se llama Secret Manager. Y en Kubernetes están los Kubernetes Secrets. Algo importante para los que trabajan con Kubernetes.
en Kubernetes uno sube el valor en B64. codificado en B64 lo que significa que se puede decodificar. Entonces solo porque lo tengo en Kubernetes, en un secret en B64 no significa que lo puedo subir al repositorio.
porque lo puedo decodificar fácilmente, alguien puede decir bueno si se puede decodificar fácilmente de qué me sirve tenerlo en Secrets dentro de Kubernetes y la respuesta mía sería la misma que di con respecto a a encriptar de manera interna el file system es si alguien entró a tu cluster de Kubernetes tenés otro problema.
verdad, tenés otro problema más serio que tu aplicación, entonces Kubernetes no te permite hacer secrets que no se puedan decodificar, tiene solo Kubernetes secret, pero te permite integrar, vos puedes integrar HashiCorp Vault, puedes integrar AWS Secret Manager, puedes integrar otros herramientas que manejan secretos dentro de Kubernetes, que al final, quiero aclarar esto, al final Kubernetes lo que va a hacer es...
convertir el recurso tuyo a un secret de Kubernetes. O sea, siempre va terminar en un secret de Kubernetes porque esa es la manera en que Kubernetes sabe cómo interactuar con él al momento de montarlo en un bot, ¿verdad? Que son los secrets de Kubernetes. No va a saber cómo interactuar con él directamente desde Secret Manager o de HashiCorp Vault para montarlo en su contenedor. Solo sabe cómo trabajar con él desde los secretos. Entonces...
Al final va a terminar en un secreto de Kubernetes con las herramientas que yo he trabajado, es. Pero es importante que usemos un Secret Manager para administrar estos secretos de manera segura. O si va a ser el sysadmin o el de operaciones, que va a ir a crear el secreto de manera directa, ya sea en las máquinas virtuales o en los contenedores, ¿verdad?
que esa información llegue a él de manera segura, manera encriptada, nada de texto plano para el manejo de credenciales. Entonces no sé qué opinión te merece este tema de los secretos y la información sensitiva,
Juan (1:30:18)
es complicadísimo porque...
va de la mano con las herramientas que utilizamos junto con la mentalidad de la empresa como ya dijiste anteriormente de nada nos sirve tener herramientas más sofisticadas y luego estamos copiando y pegando en cualquier parte así que bueno si es yo lo veo uno de esos temas que es muy complicado de manejarlo bien no tanto porque no existan las herramientas sino porque
requiere tener cierta madurez. Para mí los las credenciales y los secretos son las de las piezas de información en una empresa que requiere ser tratada con la mayor
no se como decirlo pero el mayor cuidado es como si hay que hacerte cuenta que todo el mundo quiere obtener ese valor así tenemos que verlo y de esa manera tenemos que protegerlo es como lo que decías cifrar mi información las laptops es buena costumbre considero yo que nuestro disco duro este cifrado asi si se lo roban pues esta mas protegido
Entonces, con los secretos viene siendo lo mismo, es hacer de cuentas que estamos cuidando ahí el tesoro más valioso del mundo, sea la credencial para un servicio ahí que nadie conoce, así es como se tiene que tratar. Entonces, yo lo veo de esa manera que requiere tener cierta madurez al momento de utilizarlos.
Douglas (1:32:02)
Sí, es que mejor la mentalidad de paranoia en ese sentido, es que alguien puede pensar, ¿quién va a querer robarle la laptop a Juan? Alguien puede pensar eso, ¿no? Pero si yo sé que Juan trabaja para la empresa tal, para el banco tal,
Juan (1:32:19)
Sí.
Douglas (1:32:22)
me interesa necesariamente y perdón Juan que te use como ejemplo en esto, pero no me interesa necesariamente lo de valor que Juan pueda tener en cuestión monetaria él hacia mí, si no la información que puedas tener de la empresa para la que trabajas, sobre todo cuando ya sé que trabajas ahí, entonces te puedo robar la laptop y voy a, aunque no tenga tu password, voy a intentar sacar el disco duro
Juan (1:32:33)
Si no te interesa los memes que tengo guardados
Douglas (1:32:48)
y montarlo con uno de estos software que recuperan información para querer extraer esa información privada. Pero si tenés tu disco duro cifrado, si lo tenés encriptado, no voy a poder hacer eso. Entonces cuando lo pongo desde la perspectiva, yo que ya lo he compartido muchas veces, yo trabajo para una empresa que se llama Field, anteriormente llamada Tenop, si alguien no va a querer robarme a mí, no les interesa,
Juan (1:32:51)
Sí.
Douglas (1:33:14)
No tengo la pinta de tener nada, ¿no? Pero la gente sí sabe que Fuel va a tener algo importante, va a tener clientes importantes. Entonces, al hacer eso van a querer atacar a la empresa para la que trabajo y no a mí, aunque sea mi laptop, ¿no? Entonces, aquí nos desviamos un poquito de lo que es el uso de los secretos para archivos de configuración o variables de entorno, pero creo que sentí la necesidad de aclararlo ya que mencionaste el tema. Al final es cuestión de cultura y al final es cuestión de estar a la defensiva siempre.
Juan (1:33:27)
Sí.
Douglas (1:33:44)
en todo lo que tiene que ver con ciberseguridad. Pero bueno, no sé si... Yo creo que es tiempo que vayamos concluyendo y realmente que he disfrutado mucho esta conversación. Me alegra que pesar de que hoy estés cansado.
Juan (1:33:46)
Sí.
Douglas (1:33:59)
Y para quienes no saben, pues, porque esto sale, lo puedes estar viendo y escuchando a cualquier hora del día, pero para quienes no saben, estamos grabando de noche. Entonces, Juan, te agradezco que te hayas tomado el tiempo porque he disfrutado mucho de la conversación, he aprendido de vos, tu perspectiva como developer, y sobre todo esta parte de la estrategia de desarrollo en código, poder refrescar lo
archivos de configuración, y tal vez yo para mis palabras de cierre para los que nos ven y nos escuchan es espero que esto les haya sido de valor también a ustedes, no es nuestra intención inclinarlos hacia archivos de configuración y que no usen variables de entorno, verdad, sino que nuestra idea es compartirle nuestra experiencia.
trabajando con ambos, para quienes son nuevos, sobre todo en desarrollo, que sepan que hay que tener la mentalidad de tenerlo configurable en un lugar central y que sea fácil de modificar sin necesidad de publicar código, de desplegar código, ¿verdad? Entonces espero que les haya sido de valor. Juan, no sé con qué palabras nos querés dejar en este episodio.
Juan (1:35:11)
Bueno, solo quiero mencionar que también lo he disfrutado mucho el episodio, a pesar de que sí, venía un poco cansado, aún así, me mantenía muy entretenido todo lo que estamos hablando y ojalá que las personas también encuentren ese valor que estamos tratando de dejar aquí. Como dije al inicio, pareciera que es un tema muy simple, muy sencillo, es variables de entorno o un archivo de configuración, pero como ya vimos, involucra muchas partes, muchas cosas que hay que tomar en
más cuando estamos hablando de aplicaciones que se pueden escalar de manera muy muy grande ahí es donde requiere un mayor cuidado y bueno nada más quiero agradecerles a las personas que llegaron hasta el final de nuevo les agradecemos cuando comparten nuestro vídeo cuando le dan like y mucho más si desean dejarnos algún comentario a veces tardamos un poquito en responder pero siempre
siempre tenemos el cuidado de intentar responderles a la mayor cantidad de personas. que muchas gracias en ese aspecto.
Douglas (1:36:19)
Sí, muy
de acuerdo. También extiendo tus palabras y también los animo a que puedan interactuar compartiendo nuestro contenido y dejando sus comentarios. Y de nuevo, gracias por su tiempo, gracias por su atención. Nos veremos hasta el próximo episodio. Adiós.