WEBVTT 00:00:06.960 --> 00:00:09.880 Nelson, empezamos ¿Qué tal? 00:00:09.880 --> 00:00:11.602 ¿Qué tal estás? ¿Qué tal estás? 00:00:12.280 --> 00:00:15.660 Bien, bien muchas gracias por la invitación. 00:00:16.340 --> 00:00:20.007 Acá haciendo una pausa en el trabajo y aprendiendo un poco a usar… 00:00:20.500 --> 00:00:25.260 Por favor, a ti, a ti voy a poner a la gente en antecedentes. 00:00:25.560 --> 00:00:30.000 Nos conocimos en Las Vegas, en el Cloud World, porque no nos habíamos conocido antes. 00:00:30.040 --> 00:00:36.180 Antes sí habíamos hecho, había hecho un podcast con Edelweiss sobre Machine Learning 00:00:36.180 --> 00:00:41.260 y tal, pero nunca nos habíamos conocido hasta Las Vegas y pude asistir, tuve el lujazo 00:00:41.260 --> 00:00:46.680 de asistir a tu charla sobre Kubernetes en el SPU en Madrid. 00:00:48.050 --> 00:00:55.240 Y ahí te dije, pues es que tenemos que hacer, tenemos que hablar. 00:00:56.810 --> 00:01:03.970 Es muy lindo esto en la comunidad ahora, que es lo que tiene, hay mucha gente haciendo 00:01:03.970 --> 00:01:09.030 cosas todo el tiempo y, bueno, pasan estas cosas porque yo también había escuchado que 00:01:09.030 --> 00:01:15.250 vos estabas haciendo cosas en España, pero tampoco nos habíamos cruzado antes y, bueno, 00:01:15.290 --> 00:01:16.570 qué suerte que nos cruzamos. 00:01:16.610 --> 00:01:19.610 Pues ya estamos, ya estamos tomándonos un café juntos. 00:01:20.070 --> 00:01:23.890 La gente que está en la audiencia puede participar si quiere, puede levantar la mano 00:01:23.930 --> 00:01:25.486 y de lo que vayamos hablando 00:01:26.470 --> 00:01:32.390 Pues eso, pues le podemos dar paso porque este es un formato abierto y voy a contar dos 00:01:32.390 --> 00:01:37.110 cosas, voy a contar dos cosas: una, ¡vaya pedazo de charla te marcaste sobre Kubernetes 00:01:37.150 --> 00:01:43.770 en Madrid! Me quedé flipado, lo voy a contar, es decir, él iba contando, yo estaba con 00:01:43.770 --> 00:01:49.340 los ojos como platos y él iba diciendo todo esto es muy sencillo, bueno, estáis viendo 00:01:49.340 --> 00:01:52.960 todos estos comandos pero en realidad todo esto es muy sencillo, todos los comandos de 00:01:53.000 --> 00:01:59.160 la instalación, todos los exis de cómo montar con Kubernetes toda la instalación que 00:01:59.160 --> 00:02:03.440 estabas haciendo y luego después fuera de la conversación que te dije no he trabajado 00:02:03.480 --> 00:02:09.780 nunca con Kubernetes, qué interesante y me dijiste dos cosas porque además estábamos 00:02:09.780 --> 00:02:15.340 hablando de un proyecto que estoy haciendo de si instalaba con Raspberry Pi, Docker y 00:02:15.340 --> 00:02:21.120 tal y me dijiste pues esto sí puede hacerse y muy interesante me dijiste también, y automatizar 00:02:21.120 --> 00:02:24.840 procesos de base de datos con Ansible, ¿no? 00:02:25.200 --> 00:02:30.350 Y dije, bueno, bueno, bueno, tenemos que hablar de ello, tenemos que hablar de ello. 00:02:30.570 --> 00:02:36.370 Entonces, haz un repasito así para los que no estuvieron en Madrid y no se lo saben, 00:02:36.510 --> 00:02:39.330 de lo que contaste de Kubernetes en Madrid. 00:02:40.200 --> 00:02:45.980 Sí, bueno, lo de Madrid fue parte de un tour que se hizo de grupos usuarios por Europa, 00:02:45.980 --> 00:02:51.260 entonces yo apliqué con propuse un par de estas dos charlas es de las que vos dijiste 00:02:51.260 --> 00:02:58.540 y bueno el de kubernetes vino porque hace un par de años cuando ahora 00:02:58.540 --> 00:03:06.200 que empezó a trabajar en crear un operador para kubernetes con ahora que yo bueno Siendo 00:03:06.200 --> 00:03:11.260 director este cada tanto hablo con los bien y me dijeron a ver si quería ser parte del 00:03:11.260 --> 00:03:18.220 beta testing, entonces estuve probando todo lo que ellos hicieron antes de que se liberara 00:03:18.220 --> 00:03:23.480 y, bueno, y después también escribí algún blog y escribir poco, no lea tener que haber 00:03:23.480 --> 00:03:28.220 escrito más, pero dediqué mucho tiempo a probarlo, por eso termina haciendo la presentación, 00:03:28.260 --> 00:03:32.780 este esta es la segunda versión de esa presentación sobre Cuba Net es que había dado 00:03:32.820 --> 00:03:37.890 una cuando todavía no era producción, cuando era todavía beta. 00:03:39.340 --> 00:03:46.680 Y, bueno, lo interesante es, a mí cuando doy charlas técnicas me gusta mostrar ejemplos 00:03:46.680 --> 00:03:52.280 y los comandos para que si alguien lo quiere reusar después tenga todo el detalle de 00:03:52.280 --> 00:03:56.669 lo que necesita hacer, además de haber aprendido de qué se trata la tecnología. 00:03:57.240 --> 00:04:01.960 Lo malo, lo que yo siempre veo como un defecto de mis charlas es que tienen mucho contenido. 00:04:02.000 --> 00:04:08.620 Entonces, a veces me estoy muy apurado siempre tratando de poner más cosas, pero bueno, 00:04:08.680 --> 00:04:13.180 quizás sea mucho para prestar atención en el momento. 00:04:13.360 --> 00:04:16.760 Lo importante es que después se pueden bajar las slides, tenés todo el material ahí para 00:04:16.800 --> 00:04:21.280 usarlo y reproducirlo con tu propio usuario y demás. 00:04:21.560 --> 00:04:23.180 Es buenísimo, es buenísimo. 00:04:23.220 --> 00:04:30.960 Hiciste todo un despliegue de Kubernetes desde la instalación hasta la creación, 00:04:30.960 --> 00:04:37.720 despliegue. Sí, exacto. Todos los pasos, porque en general lo que tienen, cualquier cosa 00:04:37.720 --> 00:04:43.800 que queramos hacer con tecnología en general, por más simple que sea, siempre involucra 00:04:43.800 --> 00:04:50.820 muchos pasos y a veces pasa de que algo falla o algo necesita una cosita más de 00:04:50.820 --> 00:04:54.640 lo que dice el manual y los manuales en general te dicen, bueno, esto tenés que ir a 00:04:54.680 --> 00:04:56.420 otro lado y no te cuentan los detalles. 00:04:56.460 --> 00:05:01.780 Entonces, a mí me parece interesante cuando se quiere mostrar algo completo que incluya 00:05:01.780 --> 00:05:03.391 todas esas cosas extras, ¿no? 00:05:03.640 --> 00:05:08.860 Pero también, bueno, es lo que lo hace Medio pesado después para que entre en el tiempo 00:05:08.860 --> 00:05:11.638 que se tiene una charla que es medio cortito, ¿no? 00:05:12.240 --> 00:05:18.770 Y bueno, sí Sí, bueno, y aparte siempre hay muchas charlas interesantes al mismo tiempo 00:05:18.770 --> 00:05:24.830 y estás en un día donde hay 6, 7 charlas o sea, 7 horarios para escuchar cosas entonces 00:05:24.830 --> 00:05:29.870 capaz que podés prestar mucha atención en una, dos, tres pero llega un momento que estás 00:05:29.870 --> 00:05:35.570 cansado también pero bueno, es parte del desafío de estas cosas, yo cuando voy a a los 00:05:35.570 --> 00:05:39.950 eventos me gusta engancharme a las cosas bien técnicas, pero sí a las 3, 4 de la tarde 00:05:39.990 --> 00:05:43.050 ya estás muerto no puedes prestar mucho más atención. 00:05:43.510 --> 00:05:46.050 Sí, sí, las becas fue una maratón. 00:05:47.550 --> 00:05:52.530 Exacto, es lo que tiene eventos como esos de varios días, físicamente son muy exigentes. 00:05:53.170 --> 00:05:57.390 Decía que hablaba con Roy Salazar sobre estos eventos. 00:05:57.390 --> 00:06:02.570 Claro, Roy tiene el de DATA, el de DBSAT y él cada vez lo va ampliando, ampliando, ampliando, 00:06:02.590 --> 00:06:06.310 entonces su charla cada vez es más contenido, más contenido, más contenido y dice y cada 00:06:06.350 --> 00:06:08.128 vez lo tengo que dar más rápido. 00:06:08.470 --> 00:06:10.530 Digo, guau. Eso está interesante. 00:06:11.430 --> 00:06:16.990 Mantener un mismo tema es una cosa rara, pero también es interesante porque le permite 00:06:16.990 --> 00:06:20.712 hacer eso, de cada vez ir mejorándolo y agregándole cositas nuevas. 00:06:22.390 --> 00:06:28.950 Como siempre, hay mil temas de los que uno se enfrenta todos los días y quisiera poder 00:06:28.950 --> 00:06:32.770 ver más en detalle. A mí en general también me gustan las cosas originales, pero tienen 00:06:32.810 --> 00:06:35.710 como contra de que la gente todavía no las está usando. 00:06:35.750 --> 00:06:42.790 Entonces, capaz que es mucho más práctico hablar de temas que son más, digamos, 00:06:43.690 --> 00:06:48.510 más de entrada, más de principiantes, donde también siempre tienen público. 00:06:49.660 --> 00:06:54.900 Y bueno, ese de seguridad es algo que todo el tiempo todo el mundo tendría que estar 00:06:54.900 --> 00:06:57.289 actualizándose, o sea que es un lindo tema. 00:06:58.200 --> 00:07:03.500 Bueno, y Ansible cuéntame lo de la automatización, ¿qué es lo que sueles hacer? 00:07:04.480 --> 00:07:06.320 ¿Y cómo funciona la Ansible? 00:07:07.560 --> 00:07:12.840 Lo que hice en esta presentación, que di también acá en el tour, es que intenté hacerlo 00:07:12.840 --> 00:07:19.450 no solamente enfocado en Ansible, sino más en base de datos Oracle, como una especie 00:07:19.450 --> 00:07:22.400 de tratar de mostrar a alto nivel 00:07:23.450 --> 00:07:28.228 todos los desafíos que hay cuando hay que automatizar y poniendo ejemplos con Ansible. 00:07:28.450 --> 00:07:34.250 Eso porque, como en todos los temas de tecnología, ya hay mucho material sobre cómo hacer 00:07:34.250 --> 00:07:41.550 de Ansible. Uno busca información, bueno, es como el 00:07:41.550 --> 00:07:46.410 doble filo de internet, que uno siempre dice, bueno, uno no se puede guiar por lo que 00:07:46.410 --> 00:07:50.170 encuentra en internet, pero al mismo tiempo están todos los manuales de todos los productos 00:07:50.210 --> 00:07:55.660 que usamos. O sea que en realidad lo que uno no puede hacer es a ciegas guiarse por lo 00:07:55.660 --> 00:07:56.440 que encuentra en internet. 00:07:56.480 --> 00:08:03.180 Uno tiene que saber un poco, bueno, de dónde viene la información, porque al final todos 00:08:03.180 --> 00:08:07.860 trabajamos remoto, todos consumimos el soporte de Oracle que está en internet. 00:08:08.620 --> 00:08:14.000 Entonces hay que tener cuidado cuando decimos algunas palabras porque pueden malinterpretarse 00:08:14.000 --> 00:08:19.980 el tema que con ansi hay muchísimos ejemplos de una comunidad enorme de gente que lo 00:08:19.980 --> 00:08:25.200 usa que es una herramienta para automatizar tareas y sirve para cualquier tecnología 00:08:25.200 --> 00:08:32.890 y digamos que lo que que viene a hacer es ayudar 00:08:33.080 --> 00:08:40.400 a manejar o codificar las acciones que uno quiere hacer, 00:08:40.540 --> 00:08:48.040 ejecutar un programa, analizar una salida de un programa, de un comando y poner 00:08:48.040 --> 00:08:55.020 todo eso en una especie de guía, se le llama, Ansible le llama playbook al código que 00:08:55.020 --> 00:08:59.040 ejecuta, pero bueno la idea es que uno escribe digo como una guía de bueno quiero seguir 00:08:59.080 --> 00:09:05.340 estos pasos y tiene bueno manejo una cierta sintaxis se permite más o menos programar 00:09:05.340 --> 00:09:11.060 este en algunas estructuras de control clásicas pero con una sintaxis Distinta no tenéis 00:09:11.060 --> 00:09:18.200 tienes condiciones tenés este variables y bueno con esa forma simple de describir 00:09:18.200 --> 00:09:23.780 la idea de por qué se hizo popular es porque tiene un lenguaje descriptivo, no, donde 00:09:23.780 --> 00:09:31.540 tiene una simpleza bastante grande, al mismo tiempo le da mucha flexibilidad y, 00:09:31.540 --> 00:09:35.860 bueno, de a poquito todos los vendedores de software empezaron a agregarle sus propios 00:09:35.900 --> 00:09:43.380 formas de, o digamos, empezaron a crear código para que Ansible pudiera manipular 00:09:43.380 --> 00:09:44.880 recursos que ellos crean. 00:09:45.320 --> 00:09:50.042 Entonces, así fue como se fue extendiendo y hoy en día se puede usar para lo que sea. 00:09:50.100 --> 00:09:53.540 Entonces podemos usar Ansible para ejecutar en el lugar que queramos. 00:09:53.580 --> 00:09:57.160 El otro que tiene es que es muy fácil de instalar porque es un ejecutable solamente. 00:09:57.200 --> 00:10:02.160 Uno va, si está en Windows, un .exe, en Linux un binario y ya está. 00:10:02.760 --> 00:10:06.700 Después es ir al manual y fijarse, bueno, se aprecia este archivo de configuración que 00:10:06.740 --> 00:10:08.462 tiene que tener ciertas reglas. 00:10:09.320 --> 00:10:17.160 Y lo potente, además de la simpleza, lo potente es que uno puede configurar, 00:10:17.160 --> 00:10:23.800 configurar, se usen muchos servidores y al ejecutar, se ejecutan todos esos servidores 00:10:23.800 --> 00:10:27.380 al mismo tiempo. Entonces, ahí es donde está la potencia, ¿no? 00:10:27.740 --> 00:10:34.900 Uno automatiza ciertos pasos, maneja con estructuras de control, qué hacer cuando pasa 00:10:34.900 --> 00:10:36.060 esto, cuando pasa aquello. 00:10:36.100 --> 00:10:42.520 Lo que termina siendo, está pronto para ser ejecutado en miles de servidores. 00:10:42.760 --> 00:10:47.590 Es una locura, ¿no? Y por eso es popular, ¿no? 00:10:47.590 --> 00:10:52.010 Con la aparición de la cloud, de todos los proveedores de cloud hace un poco más de 10 00:10:52.050 --> 00:10:59.150 años, esto fue como una necesidad porque las granjas de servidores empezaron 00:10:59.150 --> 00:11:06.270 a aparecer más accesibles a todo el mundo, porque antes solamente tenías que estar en 00:11:06.270 --> 00:11:07.970 una empresa grande para poder ver estas cosas. 00:11:08.010 --> 00:11:15.050 Ahora hoy en día este lo que sé con tu cuenta donde te conectas a tu cloud bueno solo 00:11:15.050 --> 00:11:18.450 tuyo, pero si trabaja por una empresa nuevamente tiene muchos servidores están todos 00:11:18.490 --> 00:11:23.630 ahí y bueno esa fue como la motivación de por qué han sido empezó a crecer y se empezó 00:11:23.630 --> 00:11:28.630 a extender, no. Entonces yo trabajo por una empresa que hace consultoría entonces este 00:11:28.630 --> 00:11:31.430 en mi rol dentro de la empresa 00:11:32.750 --> 00:11:37.450 Trabajo en proyectos de tecnología Oracle y hacemos un poco de todo. 00:11:37.810 --> 00:11:42.050 Somos especialistas en Oracle, base de datos en particular. 00:11:42.310 --> 00:11:49.780 Y lo que yo vi en los últimos años es que mi trabajo se está convirtiendo más en hacer 00:11:49.780 --> 00:11:52.340 otras cosas que solamente administrar base de datos. 00:11:52.380 --> 00:11:58.400 Entonces me pareció interesante hablar en las presentaciones que di este año sobre este 00:11:58.400 --> 00:12:03.360 tema por el hecho de que desde hacía, yo creo que Larry fue el que empezó con esto, Larry 00:12:03.360 --> 00:12:08.040 Ellison hace como, no sé, en un open world allá por el 2009, creo que fue que dijo que 00:12:08.080 --> 00:12:11.960 al principio se reía un poco de la cloud y después cuando ahora que se subió la cloud 00:12:12.000 --> 00:12:17.560 dijo, ya los devianos se van a precisar, y como que todo el mundo empezó con ese miedo 00:12:17.560 --> 00:12:23.800 de que, bueno, ¿por qué? Vamos a quedar todos sin trabajo, y yo creo que esto, que sin 00:12:23.800 --> 00:12:27.640 querer, no sé, que todos estamos viendo estos días de cómo ha cambiado nuestro trabajo, 00:12:27.680 --> 00:12:34.220 es una muestra de que en realidad los DBA siguen siendo necesarios, pero están haciendo 00:12:34.220 --> 00:12:35.520 cosas distintas hoy en día. 00:12:35.560 --> 00:12:40.740 Y quizás, bueno, si son puristas, claro, de repente ya estás haciendo otras tareas y 00:12:40.740 --> 00:12:43.620 no son exclusivamente DBA, pero yo creo que lo que está pasando es que simplemente el 00:12:43.660 --> 00:12:51.120 rol de alguien que se especializa en base de datos está extendiendo y estamos incorporando 00:12:51.120 --> 00:12:56.340 más Herramientas en nuestro trabajo diario, porque la necesidad de hacer lo que hacíamos 00:12:56.340 --> 00:13:02.100 antes es menor. Entonces, eso no quiere decir que la gente que era DBA tiene que seguir 00:13:02.100 --> 00:13:03.960 siendo solo lo que hacía antes. 00:13:04.140 --> 00:13:08.760 Yo creo que simplemente se está dando en la práctica que se están extendiendo a hacer 00:13:08.800 --> 00:13:10.980 más cosas, incluyendo automatizaciones. 00:13:10.980 --> 00:13:15.647 Entonces, antes esto lo hacían solamente la gente que trataba con sistema operativo, 00:13:15.720 --> 00:13:20.600 los isops, los devops, hay muchos nombres y términos. 00:13:22.210 --> 00:13:28.110 Y mismo hoy en día están saliendo todo el tiempo roles nuevos dentro de la industria, 00:13:28.150 --> 00:13:35.250 como los data ops, los ml ops y arquitecto, nos estamos metiendo 00:13:35.250 --> 00:13:39.990 más en todo lo que tiene que ver con la arquitectura. 00:13:42.030 --> 00:13:49.820 El diseño, sí, sí, claro, por eso no es solamente el diseño de las tablas y cómo 00:13:49.820 --> 00:13:55.720 hacer mejor uso, optimizar los recursos del servidor y demás, sino que es la de cierto, 00:13:55.720 --> 00:14:00.780 nos metemos en más, bueno, este, cómo está configurada la red, cómo están configurados 00:14:00.780 --> 00:14:07.880 los enlaces, sí, sí, cosas que de repente eran más cosas de otros 00:14:07.880 --> 00:14:12.100 roles, como el CISAMIN, seguramente, o el encargado de la red. 00:14:12.620 --> 00:14:18.180 Pero para mí es parte de lo que está pasando hoy, que es, yo creo que no es solo exclusivo 00:14:18.180 --> 00:14:23.069 del DBA, yo creo que toda la tecnología, lo vemos todos los días, aparecen cosas nuevas, 00:14:23.220 --> 00:14:28.900 hace que las cosas empiecen a ser más simples, las viejas aparecen temas nuevos. 00:14:29.420 --> 00:14:35.040 Y todos los roles se van adaptando a ser menos de lo que se hacía antes y más de otras 00:14:35.040 --> 00:14:38.720 cosas nuevas. Y por ahí viene, me parecía a mí, interesante, ¿no? 00:14:38.820 --> 00:14:45.900 Sí, que se hacen estas tareas un poco más monótonas, sí es mucho más fácil quizá eso, 00:14:45.960 --> 00:14:51.400 ¿no? Automatizarlas o quizá ya no es tan crítico que haya alguien poniendo inteligencia 00:14:51.400 --> 00:14:58.400 humana en las tareas. Y eso es lo otro, cuando queremos hacer 00:14:58.400 --> 00:15:04.560 algo así, yo lo vi en este año, el año pasado con clientes que nos venían a pedir distintos 00:15:04.560 --> 00:15:12.750 tipos de automatismos, que había como una o sigue habiendo una especie de expectativa 00:15:12.750 --> 00:15:19.590 de la gente que quiere meterse a hacer estas cosas de que esto es algo simple o que esto 00:15:19.590 --> 00:15:24.410 debería ser algo simple para la gente que ya sabe, entonces como que decir, bueno, nosotros 00:15:24.450 --> 00:15:31.270 no sabemos nada de esto y queremos que alguien nos ayude a automatizar esto y como nosotros 00:15:31.270 --> 00:15:35.370 ya sabemos hacer eso que queremos automatizar, sabemos que lo que ustedes van a hacer 00:15:35.410 --> 00:15:40.720 es algo chiquito, van a agregar y dos otras cositas y va a quedar andando, pero bueno, 00:15:40.720 --> 00:15:46.180 al final ese trabajito no es tan simple, ¿no?, tiene ciertas complejidades, entonces 00:15:46.180 --> 00:15:50.100 eso fue lo que me interesó mostrar y si ustedes ven la slide, si quieren después les 00:15:50.140 --> 00:15:54.420 pongo el link, yo la subí y por ahí a Slideshare en su momento, está pública. 00:15:55.080 --> 00:15:56.500 Hace menos cuento un poco eso, ¿no? 00:15:56.540 --> 00:16:02.900 Los desafíos que hay y cómo encararlo y bueno, y en particular con ejemplos de Ansible 00:16:02.900 --> 00:16:06.340 de código, ¿no? Mostrando un poco de código de dónde aparecen 00:16:07.920 --> 00:16:12.031 Complejidades, digamos, porque no son problemas, pero por ser tan flexible 00:16:13.200 --> 00:16:17.020 Permite que se hagan muchas cosas que después pueden traer problemas, ¿no? 00:16:17.060 --> 00:16:18.960 Entonces es como que, como todo, ¿no? 00:16:19.000 --> 00:16:25.020 Cuando uno programa en C, el primer programa que hizo seguramente sea horrible y lo reescribe 00:16:25.020 --> 00:16:29.800 cada vez. Y la última versión siempre tiene miles de líneas de código, anda más rápido, 00:16:29.840 --> 00:16:31.840 usa menos memoria, ¿no? Cosas así. 00:16:32.200 --> 00:16:36.080 Vamos a poner un caso práctico, por ejemplo, ¿vale? 00:16:36.940 --> 00:16:40.680 Porque evidentemente, vamos a poner un caso práctico, por ejemplo, ¿no? 00:16:40.720 --> 00:16:46.380 De algo que podríamos hacer de forma manual, pero que con Anselo, por ejemplo, podríamos, 00:16:46.480 --> 00:16:49.880 o sea, así, por encima, ¿no? 00:16:51.110 --> 00:16:54.770 Sí, bueno. Aplicar los PSUs, por ejemplo, aplicar el... 00:16:55.570 --> 00:16:59.190 Exacto. Por ejemplo, a 200 servidores, ¿no? 00:16:59.510 --> 00:17:00.954 ¿Cómo lo haríamos? Exacto. 00:17:02.800 --> 00:17:04.660 Aplicar un parche, por ejemplo, ¿no? 00:17:04.700 --> 00:17:11.800 Entonces, por un lado tenés que Oracle tiene el manual que te dice, bueno, esta parte 00:17:11.800 --> 00:17:17.840 se liberó, tenés que seguir estas instrucciones, te dice primero baja el software, fíjate 00:17:17.840 --> 00:17:25.700 que la base, no sé si estás usando RAC o no, tenés un camino distinto, quizás 00:17:25.700 --> 00:17:31.840 tengas que primero asegurarte que los otros nodos se bajen, si querés aplicarlo en Rolling 00:17:31.840 --> 00:17:38.980 Upgrade, este después tenés que ejecutar este comando por cierta sintaxis fijarte que 00:17:38.980 --> 00:17:44.600 el resultado no de ningún error y después continuar con nosotros no si tuvieras rack, 00:17:44.600 --> 00:17:50.940 no, así muy alto nivel tenés como 56 pasos y en realidad tenemos los pasos porque lo 00:17:50.940 --> 00:17:56.470 dice el manual este, así que alguien comenta que alguien está creando cuáles con ansiedad, 00:17:56.470 --> 00:18:03.750 si eso es pico que está interesante, todo lo que uno hace al 00:18:03.750 --> 00:18:08.220 final se puede hacer con ansiedad claramente, pero para redondearlo con este ejemplo 00:18:08.260 --> 00:18:14.700 entonces si alguien si ustedes hoy quieren decir bueno el siguiente parche lo voy a aplicar 00:18:14.700 --> 00:18:20.420 con ansiedad este como hago lo primero es ir a leer el manual el manual te te va a decir 00:18:20.420 --> 00:18:22.180 todas las cosas que hay que hacer, ¿no? 00:18:22.220 --> 00:18:25.980 El manual del parche. Te dice las instrucciones. 00:18:26.120 --> 00:18:32.030 Entonces, lo único que tenemos que hacer es codificar esos pasos en comandos dentro de 00:18:32.030 --> 00:18:35.450 Ansible. Bueno, parece medio obvio, pero al final Es, bueno, 00:18:36.610 --> 00:18:41.850 ¿cómo copio, cómo me bajo el archivo del PCU? 00:18:41.950 --> 00:18:46.339 ¿Me lo bajo yo? ¿Me conecto a soporte para que automáticamente me lo descargue? 00:18:47.940 --> 00:18:54.980 Este si tengo que hacer eso qué pasa con las credenciales como las almaceno también permite 00:18:54.980 --> 00:19:01.280 usar wallets o sea que sus propios cuales no son los cuales de oracle entonces ahí hay 00:19:01.280 --> 00:19:06.940 algunas definiciones han sido lo que tiene es una tarea es la unidad mínima donde uno 00:19:06.940 --> 00:19:11.610 le dice bueno qué tipo de tarea es en estos casos lo típico que uno diga bueno es una 00:19:11.650 --> 00:19:16.530 tarea tipo shell y ejecuta un comando de Linux, para poner un ejemplo simple 00:19:17.810 --> 00:19:22.090 El tema que hay con ese tipo de tareas es que no tienen mucha inteligencia dentro de 00:19:22.130 --> 00:19:25.630 Ansible, porque Ansible lo único que hace es abrir una shell y ejecutar lo que nosotros 00:19:25.670 --> 00:19:29.503 escribimos; entonces tenemos que nosotros poner la sintaxis correcta. 00:19:30.350 --> 00:19:35.183 Por ejemplo, si quisiéramos crear primero el directorio donde vamos a copiar el archivo 00:19:35.230 --> 00:19:41.970 podríamos decir mi tarea Ansible va a ser una shell que hace MD para que me cree el directorio 00:19:41.970 --> 00:19:48.970 o podríamos usar algo más elaborado que ahí está lo bueno de Ansible que es usar 00:19:48.970 --> 00:19:56.130 un módulo que trata con los directorios, entonces le decimos usando ese módulo 00:19:56.130 --> 00:20:03.670 en este path yo quiero que el estado de ese path que te pongo sea existe, entonces Ansible 00:20:03.670 --> 00:20:09.930 se encarga de validar si el directorio no existe lo crea, y bueno y tiene 3 o 4 parámetros 00:20:09.930 --> 00:20:14.819 ese comando de Ansible o esa definición de ANSYL, porque no es un comando, es una tarea, 00:20:14.910 --> 00:20:20.750 donde dice, bueno, para este módulo que es directorio de sistema operativo, en este path, 00:20:21.010 --> 00:20:28.050 quiero que el destino sea existe, quiero que si existe el usuario sea tal, el grupo 00:20:28.050 --> 00:20:29.772 sea tal, los permisos sean tal. 00:20:30.280 --> 00:20:33.940 Y ANSYL se encarga de crear el comando para que eso pase. 00:20:34.720 --> 00:20:41.520 Puede ser chown, chmod, mkdir, o sea, Y si estás en Windows también lo hace bien, porque 00:20:41.520 --> 00:20:47.540 no es solo para Linux. Esa es la potencia de Ansible, es basarse en módulos. 00:20:48.000 --> 00:20:52.520 En general, cuando uno trabaja en un solo sistema operativo para una infraestructura 00:20:52.560 --> 00:20:55.500 propia y demás, uno no se preocupa mucho de esas cosas. 00:20:55.540 --> 00:20:58.920 Uno siempre va y dice, bueno, yo lo voy a hacer para que me funcione a mí. 00:20:58.960 --> 00:21:01.460 Yo trabajo con Linux, lo hago todo con Linux. 00:21:01.720 --> 00:21:05.440 Lo que me resulta más fácil es pongo comandos, hardcodeo cosas. 00:21:05.980 --> 00:21:12.070 Al final eso también puede jugarnos en contra, se vuelve más complicado mantener, como 00:21:12.070 --> 00:21:20.010 todo, a medida que uno empieza a crear automatismos así, la 00:21:20.400 --> 00:21:23.100 idea es que la siguiente va a salir mejor. 00:21:23.100 --> 00:21:29.220 Sí, entonces Nelson, la idea es dedicar mucho tiempo a esa primera instalación, a esa 00:21:29.220 --> 00:21:35.200 definición de esa tarea en Ansible para definir el estándar que tú tienes en tu compañía 00:21:35.200 --> 00:21:37.180 o cómo funciona tu parque. 00:21:37.180 --> 00:21:43.520 Es decir, si tú tienes un estándar basado en, no sé, en tener solamente single instance 00:21:43.520 --> 00:21:49.220 y rack, por ejemplo, pues para que se adapte al rack como funciona en tu rack, que se 00:21:49.220 --> 00:21:53.940 adapte a la single instance en la plataforma que tienes y a partir de ahí, ¿no? 00:21:54.420 --> 00:21:59.980 Dedicando ese tiempo y haciendo pruebas de un despliegue, probar el despliegue de forma 00:21:59.980 --> 00:22:07.000 universal, ¿no? Exacto, en general es así, vos trabajás para uno solo, o 00:22:07.000 --> 00:22:11.200 sea, te creás la conversión de Azure con un solo servidor, que es el que usás para probar, 00:22:11.240 --> 00:22:15.160 creás esta codificación, la ejecutás mil veces hasta que no tiene ningún error, porque 00:22:15.200 --> 00:22:20.360 lo importante acá es que cada pasito que vos haces, lo siguiente también validás cosas, 00:22:20.360 --> 00:22:27.350 porque no es solo que pones creo el directorio, copio el binario, lo descomprimo, ejecuto 00:22:27.350 --> 00:22:30.910 un installer, porque quizás en el medio te pueda dar error, capaz que te quedaste sin 00:22:30.950 --> 00:22:37.450 espacio en el disco y quizás la copia falló y de repente, bueno, en algunos casos fáciles 00:22:37.450 --> 00:22:41.270 Ansible aborta y te dice, ops, falló acá y listo. 00:22:41.270 --> 00:22:46.030 Pero en otros casos no y sigue adelante y te esconde un poco esos mensajes, porque el 00:22:46.030 --> 00:22:50.808 error, según cómo hayas configurado la ejecución de la tarea, a veces eso puede pasar. 00:22:52.090 --> 00:22:57.070 Entonces como que uno tenés que poner también pasos de control donde decís, bueno, valido 00:22:57.070 --> 00:22:58.610 la salida del comando anterior. 00:22:58.650 --> 00:23:04.350 Si hay algún archivo de log, por ejemplo, la instalación en la aplicación del parche, 00:23:04.430 --> 00:23:10.910 yo ejecuto seguramente o patch o patch auto, uno de esos dos, bajarán archivos de log, 00:23:11.130 --> 00:23:15.850 quizás tengo que analizar el archivo log para estar bien seguro de que no hubo una excepción 00:23:15.890 --> 00:23:20.610 rara, que quizás tenga que buscar algún string en particular que diga suces adentro del 00:23:20.650 --> 00:23:24.730 log, sabiendo que es el último comando que escriben en el log, ¿no? 00:23:24.730 --> 00:23:29.090 ¿no? Cositas así eso es lo que lo terminan jarcodeando la ejecución, ¿no? 00:23:29.110 --> 00:23:33.610 Porque como que al final uno hace la tarea bien específica. 00:23:34.350 --> 00:23:37.810 Lo que tiene Dos cosas, digamos. 00:23:37.950 --> 00:23:41.330 La cosa buena es que uno realmente sabe lo que está haciendo, ¿no? 00:23:41.370 --> 00:23:46.037 Tiene que estar Bien familiarizado con el comando que va a ejecutar, con el proceso, 00:23:46.630 --> 00:23:51.270 para saber anticipar todos los posibles problemas, para evitar que mañana vos vas a decir, 00:23:51.310 --> 00:23:55.550 bueno, terminé con uno, lo voy a correr en 100 servidores, y de repente te falla en 20. 00:23:55.590 --> 00:23:56.910 ¿Y por qué te falla en 20? 00:23:56.950 --> 00:23:57.990 Y tenés que ir uno por uno. 00:23:58.030 --> 00:24:04.390 Bueno, si ya el código está un poco más robusto y maneja excepciones y demás, te va a 00:24:04.390 --> 00:24:09.170 andar siempre más o menos bien, o te va a anticipar y testear que, bueno, si el lecterio 00:24:09.210 --> 00:24:11.321 no existe, primero lo tiene que crear. 00:24:11.470 --> 00:24:15.914 Si no hay espacio libre, que te pare ahí, no pierda tiempo haciendo otras cosas. 00:24:18.100 --> 00:24:23.060 Digamos que por ahí viene algo que por acá comenta Hanoi, el concepto de idempotencia, 00:24:23.060 --> 00:24:29.680 eso está bien interesante, sí, que también es algo que también está con cuando uno usa 00:24:29.680 --> 00:24:35.100 Terraform, o sea que se usa es otro utilitario para automatizar la creación de infraestructura, 00:24:35.100 --> 00:24:42.280 la idea es que cuando el ejecutar un playbook en Ansible este, si 00:24:42.280 --> 00:24:48.460 uno ejecuta de vuelta, tiene que dar el mismo resultado, no este, y entonces Ansible 00:24:48.460 --> 00:24:55.960 se va de alguna forma de unas variables internas o unos estados, digamos, para 00:24:55.960 --> 00:25:01.160 saber identificar si esto está igual, si no está igual, este, no volver a hacerlo, pero 00:25:01.160 --> 00:25:09.600 eso es una cosa un poco en general es así, pero por ejemplo cuando tenemos que descomprimir 00:25:09.600 --> 00:25:14.540 el parche, copiamos el archivo, lo descomprimimos. 00:25:14.600 --> 00:25:21.720 La copia, si usamos los módulos de Ansible que dicen el archivo quiere usar el módulo 00:25:21.720 --> 00:25:26.460 archivo, el archivo tiene que estar ahí, o el módulo que dice copy from server, hay muchos 00:25:26.500 --> 00:25:32.360 módulos. Eso funciona, pero si uno manualmente pone los comandos en Linux, Ansible confía 00:25:32.360 --> 00:25:33.880 en lo que nosotros ponemos y lo ejecuta. 00:25:33.920 --> 00:25:40.600 Entonces, ahí perdemos, no tenemos la idea en potencia porque le estamos diciendo a Ansible 00:25:40.600 --> 00:25:44.800 ejecutame esto. Y ahí es donde se empieza a complicar porque hay cosas que queremos hacer 00:25:44.840 --> 00:25:51.810 que quizás son complejas depende si el módulo lo maneja o no y terminamos Enredándonos 00:25:51.810 --> 00:25:58.670 en cosas que bueno por esto no debería hacerlo y no lo hace y si es de lo que tiene cuando 00:25:58.670 --> 00:26:05.660 por ejemplo nosotros en la persona que trabajo hicimos varios este desarrollo con con 00:26:05.660 --> 00:26:12.580 ansiedad para hacer instalaciones patching de oracle en distintas variedades y termina 00:26:12.580 --> 00:26:17.880 siendo miles de líneas de código este cientos de directorios de sus directorios creados 00:26:17.880 --> 00:26:24.880 en el donde tenemos el código de ángel porque se incluyen este se permite 00:26:24.880 --> 00:26:30.480 rehusar no hace él permite rehusar código entonces bueno uno cuando programa aprovecha 00:26:30.480 --> 00:26:35.040 y usa eso para decir bueno cuando instalo tías rack o si es inglés insta la creación 00:26:35.080 --> 00:26:38.980 del licen es el el mismo código, no tengo que escribir dos veces lo mismo pero bueno, 00:26:39.020 --> 00:26:43.660 le agrega complejidad a todo esto y al final empiezan a pasar estas cosas que terminas 00:26:43.700 --> 00:26:50.940 ejecutando Un modulito que hace una tarea simple como patchear unos datos y termina demorando 00:26:50.940 --> 00:26:56.020 como 40 minutos porque tenés un rack de tres nodos y tiene que copiar los binarios a 00:26:56.020 --> 00:26:59.131 tres lugares, tiene que ejecutar un zip en tres lugares. 00:27:00.720 --> 00:27:05.780 Validar que tuve requisitos, primero ejecutar después, y después revisar que esté todo 00:27:05.780 --> 00:27:10.440 bien. Bueno, entonces, estoy imaginando aquí, yo que soy así como un poco pesimista, 00:27:10.480 --> 00:27:12.360 estoy imaginando las tragedias, ¿vale? 00:27:12.400 --> 00:27:14.844 Te voy a decir algunas tragedias: imagínate, 00:27:15.240 --> 00:27:18.260 despliegas Ansible sobre 100 servidores, por ejemplo, 00:27:19.360 --> 00:27:22.440 van justos de disco y, cuando hacen el unzip, 00:27:23.540 --> 00:27:27.940 revientan disco y tienes de pronto de 100, tienes 80 caídos, ¿no? 00:27:28.960 --> 00:27:34.180 ¿Te pasa algo así? ¿Te toca ir a todos o hay alguna forma de decir ¡eh! 00:27:35.460 --> 00:27:43.210 Rollback hace un deshacer o tienes que crearte con ansible o la mancha atrás también 00:27:43.210 --> 00:27:50.390 sería crear la marcha tenés que crearla así si no hay una forma automática de retomar 00:27:50.390 --> 00:27:57.010 en errores como que vos tenés que programar cierta lógica donde crees le agregas este 00:27:57.010 --> 00:28:01.910 algo que se llaman tags entonces vos podés ejecutar diciendo, bueno, salteate estos tags 00:28:01.910 --> 00:28:05.090 y cosas así. O sea, que se vuelve medio complejo. 00:28:05.370 --> 00:28:09.703 Tiene una funcionalidad a partir de cierta versión, hay agregado algo de hacer 00:28:11.010 --> 00:28:14.290 Resum, pero se basa en estados, es medio complejo. 00:28:14.790 --> 00:28:19.623 Digamos que depende un poco de las versiones que uses, como quizás respuesta más fácil, 00:28:19.690 --> 00:28:21.579 ¿no? Pero sí, siempre es complejo. 00:28:21.730 --> 00:28:26.563 Cuando aparecen problemas, lo difícil es que cuando estás probando no pasa nada, porque 00:28:26.990 --> 00:28:31.710 en mis pruebas, en mi manejo, pero Pero cuando eso lo vas a ejecutar contra servidores 00:28:31.750 --> 00:28:37.490 productivos, bueno, eso no puede fallar, ¿no? 00:28:37.590 --> 00:28:43.330 Y lo que sea que te hayas comido de implementar, de validar, de lo que fuera, si lo haces 00:28:43.330 --> 00:28:47.970 en muchos servidores al mismo tiempo, después la gente que está trabajando son pocos, 00:28:48.010 --> 00:28:52.270 ¿no? No podés tener 100 manos para conectarte a todos los servidores. 00:28:52.970 --> 00:28:55.570 Sí, acá Harold comenta que sí, que hay un comando de dry run. 00:28:55.610 --> 00:29:01.130 Sí, pero también el Ray -Ran está bueno, pero depende mucho de los módulos que usaste, 00:29:01.290 --> 00:29:07.990 ¿no? Entonces, hemos tenido, es parte un poco de la proligidad, seguramente cuando terminaste, 00:29:08.150 --> 00:29:13.330 cuando sabes mucho, lo vas a hacer mucho mejor y vas a incluir todos estos detallitos, 00:29:13.410 --> 00:29:16.310 pero se te pueden colar ahí cositas que no vayan bien. 00:29:16.350 --> 00:29:22.060 Sí, sí. Pero lo interesante es que es muy potente. 00:29:22.960 --> 00:29:30.980 La empresa que creó HashiCorp, que es la que creó Ansible, tiene certificaciones, tiene 00:29:30.980 --> 00:29:33.340 buena documentación, buenos training. 00:29:33.340 --> 00:29:40.550 Entonces como que y bueno para antes que eso ha sido es una forma no hay 00:29:40.550 --> 00:29:46.850 Otros utilitarios por ahí entonces el espectro es muy grande acá como que no estamos 00:29:46.850 --> 00:29:52.930 achicando y decimos bueno tan me elegí esta herramienta entonces me ahora me caso con 00:29:52.930 --> 00:29:58.790 esto y que automatizó ahí pero puedes cruzarte con otras y también son un poco distintas 00:29:58.790 --> 00:30:03.860 y cada una de sus particularidades y lo bueno todo esto es que, bueno, es parte del trabajo 00:30:03.860 --> 00:30:07.060 actual, ¿no? El trabajo actual es tratar con todos estos utilitarios. 00:30:07.100 --> 00:30:11.822 Oye, Nelson, una cosa, ¿qué infraestructura se necesita para montar Ansible en una... 00:30:12.830 --> 00:30:14.230 Pues en una empresa? No, nada. 00:30:14.270 --> 00:30:18.310 Es un binario. Pero necesita ser un servidor que controle 00:30:20.050 --> 00:30:22.230 Los despliegues, los procesos... 00:30:24.220 --> 00:30:27.260 Bueno, hay alguna gente que le gusta tener... 00:30:28.000 --> 00:30:31.220 digamos... Todo siempre puede ser muy elaborado o no. 00:30:33.500 --> 00:30:38.320 En principio es un binario que vos lo pones donde quieras, lo corres y chao. 00:30:39.780 --> 00:30:45.540 Ahora, cuando vas a ser en un ambiente empresarial y querés tener procesos y validaciones 00:30:45.540 --> 00:30:50.480 y evitar que nadie sin querer haga cosas que no tiene que hacer, a veces se empieza a 00:30:50.480 --> 00:30:56.360 complicar porque tenés que agregar seguridad, tenés que agregar alguna forma de controles 00:30:56.360 --> 00:30:57.960 de acceso que no sean por línea de comando. 00:30:58.000 --> 00:31:04.820 Hay utilitarios, interfaces, webs que permiten hacer eso. 00:31:04.920 --> 00:31:10.280 Nosotros trabajamos con algunos clientes que tenían eso muy bien elaborado y que se veía 00:31:10.280 --> 00:31:14.720 muy bien, pero, claro, te agrega mucho más complejidad, más mantenimiento, ¿no?, este 00:31:14.760 --> 00:31:21.900 porque es como a alto nivel está frente un workflow de tareas 00:31:21.900 --> 00:31:29.840 este donde podría llegar a retomar la ejecución de cada una si fallan este entonces 00:31:29.840 --> 00:31:34.260 podrías llegar a tener un panel de control web donde si es bueno que está junto bien 00:31:34.300 --> 00:31:40.100 no apretó un botoncito y la retoma pero eso con ansia en realidad es complejo porque 00:31:40.100 --> 00:31:46.020 no tiene módulos que son archivo de texto y les ejecuta polinesia comanda entonces digamos 00:31:46.020 --> 00:31:52.340 que hay mucho para hacer mismo así el clásico que es bueno como comentaba por acá hanoi 00:31:52.340 --> 00:31:58.280 que fue comprado por riesga creo por lo visto vamos a invitar a hanoi a que a que suba 00:31:58.280 --> 00:32:00.000 a tomarse café aquí con nosotros ¿te parece? 00:32:00.040 --> 00:32:07.280 vamos a invitarles y, claro, sí y es van y también está activa está diciendo que está 00:32:07.280 --> 00:32:08.420 preguntando ¿podemos tener? 00:32:08.460 --> 00:32:14.820 Un ambiente local de juego para cazar real o sea podríamos tener un ancho y claro lo 00:32:14.820 --> 00:32:21.830 difícil del ambiente claro lo difícil elemento del juego es que han sido el 00:32:21.830 --> 00:32:27.150 por si es un ejecutable que tiene archivo configuración que dice dónde se conecta entonces 00:32:27.150 --> 00:32:31.410 el ambiente de juego tendría que ser servidores virtuales que creamos que pueden ser 00:32:31.450 --> 00:32:38.470 bien war puede ser de docker como uno nos guste en la la cloud donde en 00:32:38.470 --> 00:32:43.130 la configuración de ángel le ponemos ese cip en estos servidores de prueba pero en el 00:32:43.170 --> 00:32:49.270 fondo tenemos que nosotros preocuparnos por crear esos servidores de prueba en general 00:32:49.270 --> 00:32:56.590 las pruebas las hago así no me creo algunas maquinas con no tanto con con virtual 00:32:56.590 --> 00:32:59.110 box sino con este hoy en día con 00:33:00.190 --> 00:33:05.510 con virt, pero no en el comando virt, pero bueno ejecutas la línea de comando y ya te 00:33:05.510 --> 00:33:10.750 crea automáticamente el virtual box, te crea todo, ejecuta todo lo importante es eso, 00:33:10.830 --> 00:33:14.450 uno puede crearse en alguna ambición de ansia y decirle, bueno, usame estos servidores 00:33:14.490 --> 00:33:15.934 que son los míos de prueba 00:33:16.340 --> 00:33:17.840 Hanoi, cuéntanos, ¿qué tal? 00:33:18.260 --> 00:33:19.927 Hola, buenas tardes, ¿qué tal? 00:33:21.060 --> 00:33:22.893 Pues el micro es tuyo, cuéntanos. 00:33:24.040 --> 00:33:27.680 Nada, simplemente aportar ahí un poco mi granito de arena, 00:33:28.640 --> 00:33:35.240 porque porque, bueno, nosotros sí que llevamos trabajando bastante tiempo con Ansible. 00:33:37.460 --> 00:33:42.480 Y, bueno, la problemática que tenemos resuelta es que tenemos muchísimos servidores, 00:33:43.680 --> 00:33:50.020 Muchas bases de datos Oracle y cualquier cambio que hacemos, por ejemplo, en scripts 00:33:50.020 --> 00:33:55.500 de configuración y demás, pues lo hacemos todo por ahí, porque si no es que sería inviable, 00:33:55.640 --> 00:34:02.680 vamos. A nosotros sería imposible con la cantidad de servidores que tenemos entonces 00:34:02.870 --> 00:34:10.420 nos viene muy bien es bastante simple pero en el momento que vas entrando un 00:34:10.420 --> 00:34:18.110 poco en script más elaborados y demás por las cosas va complicando la verdad que el fundamento 00:34:18.110 --> 00:34:23.640 es simple pero se puede llegar a complicar bastante y nada la verdad que está muy interesante 00:34:24.340 --> 00:34:30.520 Ah claro, que la idea a mí me gustaba más que nada que la gente tome conciencia de la 00:34:30.520 --> 00:34:36.440 complejidad que se puede tomar al tratar de hacer estas cosas porque me parece que hay 00:34:36.440 --> 00:34:42.580 un mensaje como muy simplista sobre que la automatización es algo fácil que está en todos 00:34:42.580 --> 00:34:46.750 lados, que todo lo podemos hacer pero que bueno, hay que dedicarle un poco de tiempo, 00:34:46.790 --> 00:34:53.970 es como todo es como, digamos, cualquier tarea compleja que uno trata de hacer sin mucha 00:34:53.970 --> 00:34:59.410 experiencia siempre lleva un poco de tiempo, y me pareció como que en la automatización 00:34:59.410 --> 00:35:02.630 y en particular con Ansible había mucha gente que se estaba tratando de hacer cosas y 00:35:02.670 --> 00:35:09.530 bueno que se estaba complicando y hay templates hay comunidad que vaya haciendo así como 00:35:09.530 --> 00:35:15.130 templates, hay alguna comunidad de Oracle que Saque templates para aplicar PSU que diga, 00:35:15.230 --> 00:35:17.530 mira, adapta esto más o menos a como lo tengas. 00:35:17.570 --> 00:35:24.590 Ah, sí, sí. Dentro de Oracle hay tres o cuatro referentes 00:35:24.590 --> 00:35:28.110 de, históricamente, usuarios que han hecho mucho, ¿no? 00:35:29.170 --> 00:35:30.350 Inclusive mucho antes que Oracle. 00:35:30.390 --> 00:35:38.350 Que está este hora virt de finlandia creo que él empezó como hace 00:35:38.350 --> 00:35:43.970 más de diez años con todo esto y fue de los primeros que se metió con ansi el que yo 00:35:43.970 --> 00:35:47.990 que yo encontraba referencias me acuerdo cuando todos empezamos estudiar mismo tim hall 00:35:48.030 --> 00:35:56.000 empezó después que él no a meterse en estas cosas o sea y él creó pila de documentación 00:35:56.000 --> 00:36:01.980 de ejemplos de código a los años recién ahora que les acogió ejemplos y que más o menos 00:36:01.980 --> 00:36:08.020 hacían lo que él hacía entonces cuando uno va a aplicar a un parche no hay nada oficial 00:36:08.020 --> 00:36:14.920 de hora que no ahora que tiene algunos ejemplos y ya pero muy simples este entonces si 00:36:14.920 --> 00:36:22.260 uno las puede usar rehusar y a partir de ahí este hacer la versión propia pero que 00:36:22.260 --> 00:36:28.000 está faltando eso de repente no una especie de repositorio de días bueno para el pc utal 00:36:28.740 --> 00:36:32.180 apliquen este código anselm que es el que ya está recontra validado y todo el mundo lo 00:36:32.220 --> 00:36:39.640 usa y funciona bien y pero y también tenés este si no quiero dejar pero 00:36:39.640 --> 00:36:45.010 hay tres o cuatro no el otro grande es el de a mí se me dan los nombres no se tenía que 00:36:45.010 --> 00:36:50.430 tener atado para referenciar los fritz fritz holligan él hizo mucho laburo con este con 00:36:50.430 --> 00:36:54.970 automatismo de aplicación De parte cuando cuando trabajaba en Enquitec hace varios años. 00:36:55.010 --> 00:37:01.750 También, él tiene unos códigos, miles y miles de señales, el código para cada versión, 00:37:01.830 --> 00:37:06.870 con cada parche. Mirá, esos códigos son una locura de la cantidad de detalles que tiene, 00:37:06.990 --> 00:37:10.670 lo que te muestra el tiempo que se le dedicó a hacer todo eso, ¿no? 00:37:10.710 --> 00:37:12.210 Es lo que tiene Ansible, ¿no? 00:37:12.250 --> 00:37:18.090 O sea, si querés aplicar parches en todas las versiones de todos los parches, tenés que 00:37:18.090 --> 00:37:22.090 probarlo. Tiene que funcionar y el código tiene que no dar errores, ¿no? 00:37:22.130 --> 00:37:28.290 Bueno, y una cosa, a ver, Ansible versus Cloud Control para parcheo, por ejemplo, o para 00:37:28.290 --> 00:37:33.530 automatismos. Porque Cloud Control también tiene, digamos, una parte para desplegar, 00:37:33.530 --> 00:37:39.170 te prueba el parche, te prueba el prereqs, te hace el análisis, digamos, de los requisitos. 00:37:40.470 --> 00:37:43.930 Sí, sí, con el automatismo es lo que tenés, ¿no? 00:37:44.330 --> 00:37:48.510 En todas las Cloud te ofrecen sus propias versiones de los automatismos, ¿no? 00:37:48.550 --> 00:37:49.970 Oracle también tiene eso. 00:37:49.970 --> 00:37:55.030 Tratamos justo de los parches de oracle así que te aplica bien pero como norma general 00:37:55.030 --> 00:38:00.510 cuando vas a una cloud te enfrentas a que bueno ellos tienen su propia versión de la 00:38:00.510 --> 00:38:06.130 de los utilitarios que hay que usar no y si lo que tiene buena civil es que funciona 00:38:06.130 --> 00:38:13.220 con todo entonces este es más portable y demás muy bien 00:38:13.220 --> 00:38:19.140 muy bien si alguien quiere preguntarnos algo estamos aquí tomando damos un café con todos 00:38:19.140 --> 00:38:25.000 hoy es muy interesante mira yo sé dónde conocí conocían según en noruega yo estaba trabajando 00:38:25.000 --> 00:38:32.260 en el departamento de salud y allí se utilizaba para el tema automatismos de servidores 00:38:32.260 --> 00:38:39.300 y eso se utilizaba el sol pero para lo que era base de datos yo yo lo hice todo con cloud 00:38:39.300 --> 00:38:46.600 control lo de crear golden image de por ejemplo de los agentes toda esa parte la dice 00:38:46.600 --> 00:38:53.800 dice así. Pero me encontré por ejemplo que con el despliegue de racks, el despliegue 00:38:53.800 --> 00:39:00.320 de los binarios de rack y la preparación un poco y el despliegue de software, me encontré 00:39:00.320 --> 00:39:04.440 con mucho problema de que estaba muy cerrado el tema de automatismos con Cloud Control 00:39:04.480 --> 00:39:08.940 y sé que resolvieron con Ansible la parte de 00:39:11.860 --> 00:39:19.160 Futuros despliegues y también la parte de de parches de parche 00:39:19.160 --> 00:39:26.220 o yo yo llegué a parchear con con con cloud control y como era un 00:39:26.220 --> 00:39:31.860 estándar muy muy homogéneo era prácticamente la misma versión misma misma versión de 00:39:31.860 --> 00:39:36.420 linux misma versión de base de datos mismo componente para todo pues fue fácil decir 00:39:36.460 --> 00:39:42.480 desde claro control agregó todos los destinos y hago el patch desde desde el mismo cloud 00:39:42.480 --> 00:39:48.820 control no pero sí claro que todo el resto de componentes se parcheaban ahí con Anzio 00:39:49.700 --> 00:39:54.310 Sí, El Cloud Control se sigue usando también todavía 00:39:57.840 --> 00:39:59.640 Enterprise Manager en particular 00:40:01.040 --> 00:40:03.818 Eso es lo otro que tiene Oracle, que tiene tantas. 00:40:05.780 --> 00:40:07.940 Herramientas que automatizan cosas. 00:40:09.310 --> 00:40:11.290 Que a veces presentan un poco 00:40:14.490 --> 00:40:19.270 De dudas de que bueno que cualquier camino me conviene tomar no me pongo a hacer por 00:40:19.270 --> 00:40:26.510 mi cuenta algo o mejor uso una herramienta que se tiene ahora que la trata de 00:40:26.510 --> 00:40:30.630 usar hasta lo máximo que pueda para evitarme el trabajo de tener que mantenerla yo no 00:40:30.670 --> 00:40:34.290 y en ese camino por ejemplo está lo del este 00:40:35.750 --> 00:40:40.470 Esta herramienta que sacó hace unos años ahora que para manejar los homes golden images 00:40:40.510 --> 00:40:43.630 y demás más, ¿no? El Fleet Provisioning and Patching. 00:40:43.790 --> 00:40:48.130 Sí, primero se llamaba el Rapid Home Provisioning and Patching y ahora han cambiado el 00:40:48.170 --> 00:40:49.790 nombre. Rapid Home Provisioning. 00:40:49.830 --> 00:40:50.510 Ahora han cambiado el nombre. 00:40:50.550 --> 00:40:53.990 Se llama Fleet Provisioning and Managing. 00:40:54.660 --> 00:40:56.380 Fleet Provisioning and Patching, sí. 00:40:56.420 --> 00:40:58.500 Entonces, esa es una alternativa. 00:40:58.540 --> 00:41:03.080 Lo único Trae todo, digamos. 00:41:03.140 --> 00:41:08.800 O sea, un repositorio central donde uno almacena una versión de los binarios, donde los 00:41:08.800 --> 00:41:16.240 pueda patchear y después distribuir a muchos servidores; lo que tiene, si querés, 00:41:16.240 --> 00:41:19.684 de contra es que está pensado como para instalaciones grandes. 00:41:19.740 --> 00:41:26.240 Si uno tiene un rack de dos nodos, usar un servidor de FPP implica crear un servidor 00:41:26.240 --> 00:41:33.220 de repositorio, mucho espacio en disco para tener las imágenes; es como que te agrega 00:41:33.220 --> 00:41:36.720 un overhead extra de mantenimiento. 00:41:38.140 --> 00:41:45.040 Fíjate Fíjate, te iba a preguntar una cosa, te iba a decir, ¿en qué casos no recomendarías 00:41:45.040 --> 00:41:54.720 el coste de desplegar ANSI o de aprender ANSI para prepararse todo un despliego, 00:41:54.720 --> 00:41:58.080 todo un automatismo respecto, digamos, al beneficio? 00:41:58.080 --> 00:42:01.460 ¿En qué casos dirías, mira, es que para hacer algo así no valdría la pena? 00:42:01.500 --> 00:42:06.220 Que quizá, evidentemente, cuando es algo muy específico en un servidor, pero ¿en qué 00:42:06.220 --> 00:42:12.800 tareas has echado para atrás y has dicho, mira, lo vamos a hacer con Ansible, pero mejor 00:42:12.800 --> 00:42:16.200 no, mejor vamos a terminar antes si lo hacemos a mano? 00:42:16.780 --> 00:42:19.100 ¿En qué casos te has encontrado el caso opuesto? 00:42:19.140 --> 00:42:26.210 Yo creo que es como dijo Hanoi, que ahora volvió con nosotros acá, es 00:42:26.210 --> 00:42:31.090 que cuando tenés volumen, o sea, cantidad de servidores, en general la ecuación te da 00:42:31.090 --> 00:42:34.490 bien de decir, invierto en automatizar. 00:42:34.490 --> 00:42:41.110 Si tengo poquitos servidores y me pongo a automatizar tareas complejas, a menos que las 00:42:41.110 --> 00:42:46.740 vaya a ejecutar muy seguido, es difícil que me rinda porque hay que invertir mucho tiempo 00:42:46.740 --> 00:42:48.640 para tener una automatización funcionando bien. 00:42:48.680 --> 00:42:56.130 Bien y sobre todo porque cambia las cosas no si voy a hacer imagínate no cambiar 00:42:56.130 --> 00:43:01.050 la clave de un usuario y me hago un escrito antes del chiquito que me conecta la base 00:43:01.050 --> 00:43:07.490 crean wallet le pone la paja vieja la nueva bueno capaz que puede estar interesante como 00:43:07.490 --> 00:43:13.610 ejercicio pero cuántas Veces le andar usando eso yo que sé una por año en un servidor 00:43:13.610 --> 00:43:19.930 ahora tengo 50 servidores capaz que que me sirven pero siempre este tipo de detalles 00:43:19.930 --> 00:43:24.970 es muy difícil de estimar porque de repente de entrada uno se genera expectativas que 00:43:24.970 --> 00:43:29.710 no son alineadas con la realidad porque uno se puede inventar la película decir bueno 00:43:29.710 --> 00:43:34.250 yo esto le gustan después a futuro millones de veces acá y ella y termina se gastando 00:43:34.290 --> 00:43:38.910 en diciendo haciendo una cosa enorme que lo usaste tres veces o cuando tienes un parque 00:43:38.950 --> 00:43:44.230 muy heterogéneo quizá si tienes muchas versiones y si las son mucho seguros operativos 00:43:44.230 --> 00:43:50.370 distintos y muchas arquitecturas distintas quizá el coste de eso analizar tantísimo y 00:43:50.370 --> 00:43:57.340 el momento que dices ya paremos la personalización implica dedicarle el mismo tiempo 00:43:57.340 --> 00:44:03.720 porque en general poco lo que puede usar si hay mucho que puede usar bueno capaz que 00:44:03.720 --> 00:44:10.480 te sirve pero este si mismo los comandos no sé que se está haciendo exadata el comando 00:44:10.480 --> 00:44:15.340 para porque un parche distinto hace en la cloud el comando no un gran manager services 00:44:15.340 --> 00:44:20.400 de los de ahora que el comando distinto entonces está bien capaz que te puedes rehusar 00:44:20.400 --> 00:44:25.920 la partecita de decir copio el binario pero no sé todo todo lo demás va a ser tan distinto 00:44:25.920 --> 00:44:30.880 que va a ser difícil no que te rinda al hilo esto que decís quería comentar una Cosa 00:44:30.880 --> 00:44:38.210 sobre un concepto también importante en archivo el que es el tema del inventario el 00:44:38.340 --> 00:44:45.430 inventario lo que hace archivo les digamos manejar grupos de servidores en 00:44:45.430 --> 00:44:51.760 un concepto de inventario el inventario es bastante potente porque permite organizar 00:44:51.760 --> 00:44:58.830 y viores en grupos y a su vez grupos en sus grupos Entonces tú luego 00:44:58.830 --> 00:45:07.190 los roles o los playbooks que quieres desplegar, puedes desplegarlos 00:45:07.190 --> 00:45:09.468 sobre un grupo de servidores en concreto. 00:45:09.700 --> 00:45:11.580 Entonces esto también da muchísimo juego. 00:45:11.620 --> 00:45:15.900 No sé si esto Nelson también lo has encontrado tú. 00:45:17.220 --> 00:45:21.960 Sí, sí, claro. Para mí eso, yo no quise entrar en muchos nombres, pero es parte de la 00:45:21.960 --> 00:45:28.340 configuración. Cuando configuras, la configuración en general es esos detallecitos de 00:45:28.340 --> 00:45:30.200 cuáles son los servicios en los que me voy a conectar. 00:45:30.240 --> 00:45:37.070 Y lo que tiene interesante el inventory es que vos podrías tener en mi misma instalación 00:45:37.070 --> 00:45:42.720 de prueba, puedo tener distintos archivos de inventario para ejecutar pruebas distintas. 00:45:43.950 --> 00:45:49.090 Entonces, eso es algo que nosotros hacemos a veces para decir, bueno, voy a probar este 00:45:49.090 --> 00:45:51.210 RAM book contra un single instance. 00:45:51.210 --> 00:45:56.690 Este mismo rambo contra un rack pero los sobredotes de racks un grupo de sobredotes distintos 00:45:56.690 --> 00:46:01.050 porque no quiere usar los mismos entonces mismo que mismo para crearlos es más fácil 00:46:01.090 --> 00:46:09.250 de otra forma entonces ahí los archivos de inventario distinto tiene variables que 00:46:09.250 --> 00:46:16.710 se pueden digamos configurar por estos grupos que comento pues esto también te 00:46:16.710 --> 00:46:22.490 da mucho juego para aplicar por ejemplo una una cosa específica para un grupo de servidores 00:46:22.490 --> 00:46:24.879 que podría tener un Oracle 11, por ejemplo. 00:46:26.470 --> 00:46:28.950 Sí, sí, tal cual. Qué bueno. 00:46:29.800 --> 00:46:34.100 Es bastante potente. Sí, yo lo uso un poco. 00:46:34.200 --> 00:46:38.040 Digamos que... Bueno, no lo uso, quiero decir. 00:46:39.840 --> 00:46:42.280 Sí, pero porque no tienes muchos servidores. 00:46:42.320 --> 00:46:47.230 Si tuvieras muchísimos servidores, vamos, estás 90 % obligado a usarlo. 00:46:47.530 --> 00:46:51.910 Claro, y cuando tengo son esos, son clientes distintos, sistemas 00:46:53.050 --> 00:47:00.130 cada uno y claro de un instalador distinto pero si me parece poder nosotros es que 00:47:00.130 --> 00:47:07.250 tenemos nosotros tenemos un cloud privado en el que tenemos muchas instalaciones de oracle 00:47:07.250 --> 00:47:11.540 para cada cliente o sea para cada cliente tenemos un oracle por decirlo alguna forma 00:47:11.580 --> 00:47:17.120 una instancia entonces tenemos muchas bases de datos y cuando tenemos que configurar 00:47:17.120 --> 00:47:23.440 de configurar en todas a la vez que aplica una una mejora, pues un script que hacen en 00:47:23.440 --> 00:47:26.884 Ansible y se aplican todas las bases de datos de los clientes. 00:47:27.060 --> 00:47:29.460 Qué bueno, qué bueno, qué bueno. 00:47:29.940 --> 00:47:31.900 Pues está muy bien para eso, sí. 00:47:33.230 --> 00:47:35.050 Pues muy bien, ¿qué dices? 00:47:35.110 --> 00:47:36.570 ¿Tú siempre usas? ¿Qué dices, Nelson? 00:47:36.610 --> 00:47:38.110 ¿Que usas siempre el de...? 00:47:38.870 --> 00:47:41.690 Ah, sí, estaba siguiendo con Bani. 00:47:41.790 --> 00:47:46.710 Por los virtuales, ¿no? Por el hecho de que para usar máquinas virtuales uno siempre 00:47:46.710 --> 00:47:48.490 puede ir a VirtualBox y crearlas a mano, ¿no? 00:47:48.530 --> 00:47:53.430 Pero InHop, él publica siempre, cada vez que sale una versión nueva, él crea la configuración 00:47:53.470 --> 00:47:55.850 background, ahora con un comando 00:47:56.840 --> 00:48:03.280 ejecutás y ahí te crea la virtual, te instala el software y todo y él se ha preocupado 00:48:03.280 --> 00:48:08.420 de mantener todo ese software durante el tiempo ahora que también publica background 00:48:08.420 --> 00:48:16.050 boxes se llama Pero bueno, como Tim lo ha dicho antes y aparte Tim publica dentro 00:48:16.080 --> 00:48:19.358 de esas configuraciones también le agrega más cosas le pone 00:48:21.820 --> 00:48:28.640 Se pone developer, le pone todo, entonces ya te bajás eso y ya te sirve no solo para 00:48:28.640 --> 00:48:32.580 hacer datos, sino también si querés desarrollar un desarrollo chico, incluye en Apex, 00:48:32.620 --> 00:48:39.980 RDS. Qué bueno, qué bueno 00:48:39.980 --> 00:48:45.280 que vuelve. Y es también otro ángulo de la automatización, la automatización no es solo 00:48:45.280 --> 00:48:52.680 una herramienta, la creación de una virtual ejecutando todo es otro aspecto esos 00:48:52.680 --> 00:48:59.710 scripts enormes Larguísimos si se ponen a revisar los códigos, todo 00:48:59.710 --> 00:49:08.810 tiene muchas horas de trabajo atrás, pero reaprovechadas nosotros que 00:49:08.810 --> 00:49:10.810 solo los copiamos los usamos seguro. 00:49:12.540 --> 00:49:19.240 Pregunta Miguel si queda grabado el café claro que sí lo grabamos y lo subimos al podcast 00:49:19.240 --> 00:49:27.100 y tenemos estás nelson en el episodio 2 de la temporada 3 así 00:49:27.100 --> 00:49:34.160 que sí o no es largo que te parece pues nada pues eso es el tercer año que 00:49:34.160 --> 00:49:42.020 estamos no digo que el hecho de poder escuchar este los 00:49:42.020 --> 00:49:47.340 pocas después también está bueno sí porque también es que que a las horas a las horas 00:49:47.340 --> 00:49:51.260 en las que a veces a lo mejor no está todo el mundo a veces hay gente que está pues está 00:49:51.300 --> 00:49:58.340 trabajando o está en su casa pues hay mucha gente me decía oscar garcía que él 00:49:58.340 --> 00:50:05.900 escucha el podcast siempre conduciendo pero está muy bien está muy bien oye 00:50:05.900 --> 00:50:11.540 pues es que es muy interesante te digo es decir la parte que conocía es algo así no sé 00:50:11.540 --> 00:50:15.580 hasta qué punto me me interesa aprender... 00:50:15.580 --> 00:50:18.720 Yo soy muy así, soy principio de economía máximo. 00:50:19.060 --> 00:50:25.680 ¿Hasta qué punto me interesa aprender una tecnología, un componente, por el beneficio 00:50:25.680 --> 00:50:31.320 si más o menos hasta ahora me he estado capeando con Cloud Control, por ejemplo? 00:50:31.620 --> 00:50:35.280 Es decir, descargar scripts, por ejemplo, en todas las bases de datos, pues me lo hago 00:50:35.320 --> 00:50:38.820 un job, un job con Cloud Control y lo planifico y lo despliego. 00:50:39.340 --> 00:50:42.240 Ya todo esto que dices tú, esa personalización, 00:50:43.440 --> 00:50:46.740 O poder hacerlo estándar, no solamente para Oracle, es decir, que en un momento puedas 00:50:46.780 --> 00:50:52.460 hacer una parte con Oracle y otra parte en otro componente, o otra parte en otro aspecto, 00:50:52.460 --> 00:50:57.900 digamos, con un asistente operativo, con SQL, ya digamos, una herramienta muy general 00:50:57.900 --> 00:51:02.940 o genérica como Cloud Control no te permite ir tan a lo fino, ¿no? 00:51:03.020 --> 00:51:07.300 Y quizá ya Ansible sí es mucho más potente para este tipo de cosas, ¿no? 00:51:07.300 --> 00:51:14.330 Y aparte Cloud Control es propietario de Oracle y tenés que tenerlo instalado y 00:51:14.330 --> 00:51:17.290 tenés que mantenerlo en versiones 00:51:18.500 --> 00:51:25.680 Ancible es como una cosa más genérica más liviana que la podés poner 00:51:25.710 --> 00:51:31.880 a andar en muy poco tiempo y lo otro es que el código porque las cosas que podés hacer 00:51:31.880 --> 00:51:39.380 con Ancible es como digamos es como un lenguaje donde puedes escribir por 00:51:39.380 --> 00:51:43.240 tareas lo que quieras. En el Cloud Control, en realidad, estás limitado para las opciones 00:51:43.280 --> 00:51:44.220 que tiene el Cloud Control. 00:51:44.260 --> 00:51:46.220 Sí, mucho, la verdad que sí. 00:51:46.660 --> 00:51:49.260 Yo creo que es un intento de hacer algo... 00:51:49.860 --> 00:51:57.410 Es útil. Es un intento como de hacer algo así como automatismos, 00:51:57.410 --> 00:52:01.870 pero decir, bueno, que nuestra herramienta estándar de monitorización, por lo menos lo 00:52:01.910 --> 00:52:06.190 haga y haga algo así. Y gestione las golden copies, ¿no? 00:52:06.310 --> 00:52:09.650 Y se puedan Provisionar homes y a ciertas cosas. 00:52:09.650 --> 00:52:11.330 Decir, bueno, no nos es tan complicado. 00:52:11.370 --> 00:52:15.110 Poder implementar un Pequeño Ansible. 00:52:15.110 --> 00:52:21.330 Para poder Desplegar cosas, pero claro, la herramienta de Cloud Control es como para 00:52:21.330 --> 00:52:23.663 muchas otras cosas más, de monitorización. 00:52:25.350 --> 00:52:28.400 Y no te olvides que también tiene, ¿cuánto? 00:52:28.400 --> 00:52:34.280 20 años. Bueno, capaz que menos, 15 Cloud Control, o sea que estaba haciendo estas cosas 00:52:34.280 --> 00:52:35.360 desde hace mucho tiempo atrás. 00:52:35.400 --> 00:52:37.200 Y de última Ansible es bastante 00:52:38.600 --> 00:52:45.240 Moderno como una cosa que surgió después o sea tampoco es muy justo decir que ahora hay 00:52:45.240 --> 00:52:50.080 una cosa moderna que hace todo mucho mejor y más rápido pero bueno es más específica 00:52:50.080 --> 00:52:55.280 porque digamos si es posible solamente para automatizar claro un poco cloud control es 00:52:55.280 --> 00:53:01.920 como gestión de toda la monitorización automatización gestión de backup gestión de digamos 00:53:01.920 --> 00:53:05.240 a universal para ¿Para abatado de base de datos? 00:53:06.120 --> 00:53:08.140 Exacto pero solamente a eso, claro. 00:53:08.640 --> 00:53:13.960 Era para tu base de datos todo lo que quisieras hacer con tu base, pensado en Oracle, 00:53:14.260 --> 00:53:16.580 y bueno, sí, tiene sus ventajas. 00:53:17.060 --> 00:53:21.740 Quizás hoy en día también se está notando más de que, bueno, no es la realidad de todo 00:53:21.780 --> 00:53:27.080 el mundo, ¿no? Pero yo que hago consultoría, hay muchas empresas que tienen entornos 00:53:27.080 --> 00:53:32.580 más heterogéneos. No tienen solo Oracle entonces herramientas como estas que se pueden 00:53:32.580 --> 00:53:38.340 usar contra con cualquier otro motor o para otras actividades son más valiosas porque 00:53:38.340 --> 00:53:44.320 son de múltiples propósitos y no como que acá contra que sólo te sirve para ahora entonces 00:53:44.320 --> 00:53:50.190 es doble fil igual porque cuando quieres hacer en parte para ahora que tiene que ser 00:53:50.190 --> 00:53:56.090 siguiendo los pasos de ahora que entonces un par de un par de cositas mira miguel debe 00:53:56.090 --> 00:54:01.870 a está preguntando en el chat opinión entiendo que crees que es mejor ansible el de reformó 00:54:01.870 --> 00:54:08.890 jenkins a bueno Es una pregunta interesante, son todas herramientas de automatismos 00:54:08.890 --> 00:54:16.190 para cosas distintas. Ansible es este creada por automatizar tareas y ejecución 00:54:16.190 --> 00:54:22.920 paso a paso de cosas con módulos para lo que quieras, entonces es más pensado como decir 00:54:22.920 --> 00:54:28.140 bueno, quiero evitarme de hacer cosas a mano que antes ejecutaba un programas? 00:54:28.140 --> 00:54:35.160 Bueno, uso ANSI. Terraform tiene una filosofía de configuración similar en el sentido 00:54:35.160 --> 00:54:42.760 de que es un archivo en texto plano que uno puede leer, también descriptivo sobre recursos, 00:54:43.280 --> 00:54:46.440 pero se usa para crear infraestructura Terraform. 00:54:46.500 --> 00:54:50.020 Terraform no sirve para ejecutar tareas paso a paso. 00:54:50.620 --> 00:54:55.940 Sin embargo, Terraform hace cosas paso a paso, pero no nos da a nosotros la libertad 00:54:55.940 --> 00:54:59.870 de decir, bueno, Bueno, quiero hacer algo más después de que el servidor... 00:54:59.910 --> 00:55:02.132 Claro, Terraform es para crear recursos. 00:55:02.260 --> 00:55:09.620 Entonces, si yo quiero crear un servidor nuevo y eso implica 00:55:09.620 --> 00:55:11.500 crear un disco, crear la red, 00:55:12.980 --> 00:55:16.870 Lo que sea que haya que hacer, bueno, Terraform permite hacer eso. 00:55:16.950 --> 00:55:22.430 Porque de la misma forma que Ansel tiene módulos para todo, Terraform también se hizo 00:55:22.430 --> 00:55:27.470 muy popular y todos los proveedores de software crearon sus módulos que son capaces de 00:55:27.470 --> 00:55:31.830 gestionar sus recursos. Entonces, hay módulos de Terraform para poder conectarse ahora 00:55:31.870 --> 00:55:35.210 a OCI, a Amazon, a Google. 00:55:36.120 --> 00:55:42.950 Entonces, uno puede crear de forma casi con el mismo código, con algunas variantes, en 00:55:42.950 --> 00:55:49.270 todos lados cosas, ¿no? Pero los archivos que describen lo que hay que hacer solamente 00:55:49.270 --> 00:55:51.410 describen cómo crear los recursos. 00:55:52.070 --> 00:55:55.690 Termina ahí, en el curso que ha creado, y Terraform termina. 00:55:56.520 --> 00:56:02.100 No podemos decirle después de crearme, instalame ahora, aplicame un parche. 00:56:02.860 --> 00:56:10.360 No sirve para eso y Cienquis es un utilitario que sirve para automatizar ejecución, 00:56:10.360 --> 00:56:12.620 pero más orientado a tipo de eventos. 00:56:12.620 --> 00:56:20.200 Se usa mucho cuando quiero armar un ambiente donde automáticamente se me apliquen, se 00:56:20.200 --> 00:56:25.790 ejecuten o se disparen tareas anidadas, digamos. 00:56:25.950 --> 00:56:30.970 Por ejemplo, hago un cambio en la base de datos y eso me dispara, o al revés, hago un 00:56:30.970 --> 00:56:36.070 cambio en el código, eso me dispara un commit en Git y eso me dispara una compilación 00:56:36.070 --> 00:56:37.792 de una SQL en la base de datos. 00:56:37.970 --> 00:56:42.230 Eso es a Jenkins, es como más para un orquestador de cambios. 00:56:42.850 --> 00:56:49.970 Y bueno, hay formas de, hay muchas recetas, muchos ejemplos De cómo conectar cosas 00:56:49.970 --> 00:56:54.470 con otras, pero bueno, son como herramientas distintas que están todas vinculadas al 00:56:54.510 --> 00:56:56.930 tema automatismo, ¿no? Sí, sí, sí. 00:56:57.190 --> 00:57:04.290 Oye, y acá acabamos con un caso de éxito y otro caso de fracaso. 00:57:04.470 --> 00:57:09.890 Es decir, ¿tienes algún caso de estos de decir, mira, hicimos esto y fue espectacularmente 00:57:09.890 --> 00:57:12.557 bien y hicimos esto y fue espectacularmente mal? 00:57:14.480 --> 00:57:21.780 Bueno, el fracaso para mí en estos casos es cuando las estimaciones no nos dan como pensamos, 00:57:21.840 --> 00:57:27.940 ¿no? Entonces, hemos tenido proyectos donde inicialmente parecían muy simples, terminaron 00:57:27.940 --> 00:57:36.200 siendo muy complejos y costándonos muchísimo más de lo que inicialmente asignamos 00:57:36.200 --> 00:57:38.020 de gente para trabajar en eso. 00:57:40.060 --> 00:57:43.380 Eso es lo fracaso. Al final las cosas siempre funcionan. 00:57:43.420 --> 00:57:47.440 Por ejemplo, hicimos algún, hay unos compañeros, ¿no? 00:57:47.520 --> 00:57:55.680 Yo en particular no toqué mucho, pero se hizo un automatismo con Jenkins, Git 00:57:55.680 --> 00:58:01.100 y demás para aplicar cambios de bases de datos en ambientes con eBusiness Suite. 00:58:01.100 --> 00:58:07.220 que funcionó, pero tenía muchas limitaciones y requería muchas cosas manuales por parte 00:58:07.220 --> 00:58:12.380 de los usuarios. Entonces, al final, como se gastó tiempo, se hizo algo que funciona, 00:58:12.660 --> 00:58:14.860 pero no se adoptó, digamos. 00:58:15.020 --> 00:58:18.100 Como que era lindo de ver, pero no era muy práctico. 00:58:18.220 --> 00:58:23.460 Eso también puede ser... Y el caso súper éxito termina con un bombazo. 00:58:23.640 --> 00:58:26.020 Venga, terminas con el caso súper éxito. 00:58:26.140 --> 00:58:32.200 Ah, bueno. De éxito, tenemos tenemos unos módulos ahí públicos para hacer patching de 00:58:32.200 --> 00:58:36.100 instalaciones de bases Oracle con RAC que están funcionando 00:58:37.220 --> 00:58:42.480 quizás no puedo dar muchos detalles porque son cosas, algunas confidenciales pero buscan 00:58:42.480 --> 00:58:48.300 en Git, hay algunos repositorios públicos que hacen eso y que los creamos nosotros para 00:58:48.300 --> 00:58:52.800 clientes son de Pythian o son tuyos 00:58:53.890 --> 00:59:00.470 bueno, no los hice con Pythian y con otros compañeros que trabajamos para clientes están 00:59:00.470 --> 00:59:04.850 publicados en nombres de clientes o sea que si van ahí 00:59:06.490 --> 00:59:11.310 Buscan en Git y ven algunos repositorios Ansible para instalar ahora con Rack y demás, 00:59:11.310 --> 00:59:17.350 hay chance de que nosotros hayamos hecho bastante de ese código y que están ahí funcionando 00:59:17.350 --> 00:59:22.330 desde hace años y cada tanto los mantenemos y demás, pero bueno que bueno 00:59:23.470 --> 00:59:29.430 la cosa funciona, es como todo, funciona hay que dedicarle mucho este mucho tiempo pero 00:59:29.430 --> 00:59:34.910 bueno al final funcionan así y facilita mucho tiene el trabajo muy bien son las 7 nos 00:59:34.910 --> 00:59:41.910 pasamos un par de minutos Nelson sé que tienes tienes algo justo que te vas es un gustazo 00:59:41.910 --> 00:59:49.160 hablar contigo se nos queda Juan por decir ya 00:59:49.160 --> 00:59:55.000 nos hemos ido un poquito de tiempo voy Voy a crear, para terminar solo una cosita, crearé 00:59:55.000 --> 01:00:01.260 un canal de texto para que a lo mejor podamos poner ahí enlaces o podamos poner algún 01:00:01.260 --> 01:00:04.480 tipo de documentación. Y si alguien se queda con alguna preguntita, pues que lo pueda 01:00:04.520 --> 01:00:09.000 comentar también en el chat o poner algún link o algo así. 01:00:09.360 --> 01:00:15.660 Y un gustazo, es que es un gustazo tener de Nelson, eres un tanque de guerra, de verdad. 01:00:17.000 --> 01:00:18.660 Un placer. Muchas gracias. 01:00:18.800 --> 01:00:22.480 Bueno, mismo Miguel hizo unas preguntas, de repente las seguimos ahí en ese canal, viste, 01:00:22.520 --> 01:00:25.580 que están ahí de cómo automatizar OCI y AWS. 01:00:26.080 --> 01:00:28.913 Sí, qué bueno. Todo eso se puede, hay ejemplos, sí. 01:00:28.960 --> 01:00:30.640 Lo podemos seguir ahí, sí, seguro. 01:00:30.680 --> 01:00:34.740 Bueno, muchísimas gracias por la invitación y bueno, un placer, un gusto compartir esta 01:00:34.780 --> 01:00:38.113 tarde contigo y con la resta de la gente que se conectó hoy. 01:00:38.930 --> 01:00:42.170 Y de último, cuando tengas el canal creado para hablar de estas cositas que quedaron 01:00:42.210 --> 01:00:44.570 pendientes también, las que tienen preguntas. 01:00:44.610 --> 01:00:48.166 Y lo voy a hacer ahora, lo voy a hacer ahora, ¿cómo lo llamamos? 01:00:49.560 --> 01:00:55.480 Y automatizaciones automatización base de datos si lo que quieras diciendo a los que 01:00:55.480 --> 01:00:59.900 ya tenés canales tenés, pero no tenés ninguno solo automatismo, si poner la automatización 01:00:59.940 --> 01:01:07.600 en base de datos, pues mira la de chanel ha creado y le 01:01:07.600 --> 01:01:11.920 ponemos la pregunta de miguel y la seguimos después, entonces escuchó ahora tengo otras 01:01:11.960 --> 01:01:17.640 cosas para hacer, pero que esté con tiempo sé que me me habías dicho que tenías justito. 01:01:18.800 --> 01:01:20.940 Tampoco te quería alargar más. 01:01:21.000 --> 01:01:22.500 Muchísimas gracias, Nelson. 01:01:22.910 --> 01:01:25.021 Ahí dejé puesta la pregunta de Miguel. 01:01:26.300 --> 01:01:27.720 Dale, hablamos después igual. 01:01:27.760 --> 01:01:30.580 Muchas gracias. Muchísimas gracias a ti, Nelson. 01:01:30.840 --> 01:01:32.007 Un abrazo muy fuerte.