Vagrant ansible pesadilla en la consultoria
•Descargar como PPT, PDF•
1 recomendación•314 vistas
Slides de mi presentación que realice en mi empresa en el 101 Panel Tech Days https://www.youtube.com/watch?v=ocPN6Ocvihk&t=14s
Recomendados
Más contenido relacionado
Destacado
Similar a Vagrant ansible pesadilla en la consultoria
Similar a Vagrant ansible pesadilla en la consultoria (20)
Vagrant ansible pesadilla en la consultoria
- 2. ¿Quien es este tío que viene a darnos la charla? Alejandro de la Hoz Martin es.linkedin.com/in/alejandrodelahozmartin sliphup@gmail.com @sliphup Desarrollador de aplicaciones informáticas 8 años de experiencia en el sector informático en clientes como ISBAN (Siconet), JAZZTEL(Wairbut), kuehne nagel (TAHBIT), GEAR,TELCO,HPE (Polar Consultores) Me encanta investigar y salir de mi zona de confort, pero sobre todo programador JAVA Actualmente “Ingeniero de Consultoría y Desarrollo” aunque en cristiano diría analista programador. ¿Y ahora DEVOPS?
- 3. ¿Volviendo a la pregunta recurrente de hoy en día? ¿Big Data con mongoDB? NO esta vez, pero quien sabe en un futuro ¿Contenedores ya sean de docker o html? NO, pero con lo del docker nos vamos acercando ¿DEVOPS? SI
- 4. Según nuestra amada WIKIPEDIA
- 5. Situación actual en la mayoría de proyectos y empresas
- 6. Lo que se supone que seria un devops y las funciones que asumiría de cada una de sus partes
- 7. Lo que se quiere conseguir
- 8. Ejemplos de herramientas para realizar estas funciones
- 12. Según nuestra amada WIKIPEDIA
- 13. Vagrant esta soportado en
- 14. Ejemplo visual de uso de vagrant
- 15. Ejemplos reales
- 16. Ejemplos escritos de amazon EC2
- 18. Según nuestra amada WIKIPEDIA
- 19. Ansible esta soportado en
- 20. Ejemplo visual de uso de ansible
- 21. Otro ejemplo visual mas concreto de uso de ansible
- 22. Un repositorio y generación de roles
- 23. Ejemplo de estructura de un role
- 24. Ejemplos reales
- 26. Ejemplo visual de uso de vagrant y ansible
- 27. Ejemplos reales
- 31. ¿Organización de los entornos de un proyecto cualquiera? EQUIPO DESARROLLO SERVIDOR DESARROLLO SERVIDOR TEST IT SERVIDOR TEST QA SERVIDORES PRODUCCIÓN
- 32. En ese momento aparece chicote
- 36. Posible solución
- 37. Mientras chicote revisa el entorno de integración
- 38. Se encuentra con Paco Lobatón propietario de Paquito Soware
- 39. Después de esto Paquito sorprende con
- 40. Chicote explota
- 43. Alejandro de la Hoz Martin es.linkedin.com/in/alejandrodelahozmartin sliphup@gmail.com @sliphup PREGUNTAS
Notas del editor
- Presentación
- Ir siguiendo el hilo de los textos
- La aceptación de la filosofía DevOps significa la adopción de una ideología que fomenta una cultura altamente productiva de colaboración entre sus equipos de desarrollo (Dev) y operaciones (Ops). El objetivo compartido de DevOps consiste en eliminar la fricción, el riesgo y otras restricciones para facilitar el éxito de los despliegues de producción de las aplicaciones, todo ello para encontrar el camino más rápido para obtener resultados de la máxima calidad.
- La frontera entre el desarrollo y la parte operacional siempre es muy difusa y suele hacer mas complejos los desarrollos y el mantenimiento de las aplicaciones. Esto se produce al tener separados estos dos mundos. Con devops lo que se pretende es crear comunicación o grupos multidisciplinares para este cometido
- DEV rendimiento de las aplicaciones desarrolladores modernos utilizan herramientas de APM para disminuir la latencia y tener mejor visibilidad en los código, bases de datos, memorias caché, las colas y de terceros. Análisis del Usuario Final Un gran desarrollador entiende a los usuarios finales, tienen la mejor reglamentación y análisis y juegan una parte enorme de la comprensión de los usuarios. Los desarrolladores están monitoreando constantemente la latencia del usuario final y comprueban el funcionamiento de los dispositivos y navegadores. Código de Calidad Los desarrolladores lo necesitan para asegurar sus despliegues y las nuevas versiones no implosionan ni degradan el rendimiento general. Errores de código de nivel Cuando se tiene una gran aplicación distribuida, es vital, tenerlos para disminuir tiempo medio de reparación mediante la búsqueda de la causa de los errores y excepciones. OPS Solicitud de disponibilidad Las aplicaciones tienen que estar en funcionamiento y es de los ops la responsabilidad de garantizar el tiempo de actividad y que los SLA están en orden. rendimiento de las aplicaciones Las Operaciones clásicas generalmente se basan en las métricas de infraestructura - CPU, memoria, red y Dick E / S, etc. Las Operaciones modernas se correlacionan todas esas métricas con métricas de software que solucionan los problemas 10 veces más rápido. Las quejas de los usuarios finales el objetivo es conocer y solucionar los problemas antes de recibir quejas de los usuarios finales, reducir el número de tickets de soporte, y eliminar las falsas alertas. rendimiento Analytics Información automática de las métricas de Operaciones ayudan a comprender lo que ha cambiado y dónde enfocar los esfuerzos para dar solución a problemas. Alertas en base a la desviación de las líneas base observadas ayudan a mejorar la calidad y reducir el ruido de las alertas.
- Al crear estos equipos y estas comunicaciones mas ágiles tendremos proyectos con la filosofía devops que ayudaran a agilizar, mejorar su rendimiento y hacerlos que sean menos susceptibles de errores. Con ello serán proyectos de mayor calidad.
- Para crear proyectos que cumplan las exigencias de un equipo con filosofía devops existen muchos productos que ayudaran en dicho cometido. Según vayan apareciendo nuevas necesidades aparecerán mas productos. Algunas necesidades se cubren con estas cuatro categorías aunque se podrían añadir mas. Automatización Manejadores de configuración Visualización de equipos Visualización de datos También tendremos herramientas de motorización y validación de proyectos pero la mayoría se integraran con las anteriores
- Ahora solo falta entrar en esta vertiente de la gestión de proyectos y formar a los equipos para poder poco a poco cumplir estos hitos. Con ello haremos que los proyectos cumplan lo comentado anteriormente ademas de conseguir que nuestros equipos sean mas conscientes de como funciona su proyecto y no crear personas indispensables para el proyecto. También tendremos perfiles mas ricos y capaces de poder adaptarse a otros proyectos ya que tendrán una visión y predisposición a a tener varias funcionalidades dentro de su equipo.
- Si pero para saber porque se han desarrollado estos productos tenemos que saber que necesidades han venido a cubrir. Tranquilos que ya empezamos.
- Vagrant es una herramienta para la creación y configuración de entornos de desarrollo virtualizados. Vagrant es capaz de trabajar con múltiples proveedores, como virtualbox, VMware, Amazon EC2 Vagrant se ha desarrollado en Ruby se puede usar en multitud de proyectos escritos en otros lenguajes, tales como PHP, Python, Java, C# y JavaScript.
- Vagrant esta disponible para plataformas linux, mac y windows. Vagrant creara maquinas virtuales de plataformas diversas según el proveedor seleccionado. Ademas de poder montar nuestras propias imágenes, vagrant nos permite recuperar imágenes de su repositorio con unas preconfiguraciones especificas
- Vagrant nos permitirá a partir de unos comandas y unos ficheros de configuración crear y gestionar dichas maquinas virtuales en el proveedor seleccionado. En la imagen tenemos un ejemplo de como vagrant + virtualbox + imagen ubuntu podremos crear n maquinas virtuales
- Ahora pasaremos a ver unos ejemplos de configuración y ejecución de unos comandos para que veáis como funciona. El fichero por excelencia que veremos sera el Vagrantfile
- Para poder usar vagrant con amazon WS requeriremos del plugin vagrant-aws No hemos podido crear ningún ejemplo de amazon porque tenemos todas las maquinas ocupadas
- Ansible es una plataforma de software libre para configurar y administrar computadoras. Combina instalación multi-nodo, ejecuciones de tareas ad hoc y administración de configuraciones. Adicionalmente, Ansible es categorizado como una herramienta de orquestación. Maneja nodos a través de SSH Dispone de módulos que trabajan sobre JSON y la salida estándar puede ser escrita en cualquier lenguaje. Nativamente utiliza YAML para describir configuraciones reutilizables de los sistemas El diseño de Ansible8 incluye: Mínimo por naturaleza. Los sistemas de administración no deben imponer dependencias adicionales. Consistente. Seguro. Ansible no instala agentes vulnerables en los nodos. Solamente se requiere OpenSSH que es considerado crítico y altamente testeado. Alta confiabilidad. El modelo de idempotencia es aplicado para las instalaciones y configuraciones, para prevenir efectos secundarios en la ejecución repetitiva de scripts. Suave curva de aprendizaje. Los playbooks usan un lenguaje descriptivo simple, basado en YAML
- Ansible esta soportado en plataformas linux y mac Para plataformas windows se puede soportar pero requiere de otros softwares para su funcionamiento y no es muy recomendable Y la gestión de nodos o maquinas serán linux aunque ya se han implementado componentes que según la versión vienen incluidos tanto para windows como contenedores docker
- Como se muestra en la imagen con ansible seremos capaces de gestionar varias maquinas desde un mismo playbook que es la estructura mínima de un proyecto de ansible.
- En esta imagen podemos ver como desde el host en el que esta ansible tenemos: playbook (ordenes, preconfiguraciones) inventories (hosts a los que nos conectaremos y configuraciones concretas de cada host) El propio ansible Los módulos propios de ansible y los creados por nosotros mismo (los módulos son funciones concretas que realizara ansible) Los plugins que son un conjunto de módulos y mejoras de ansible y entre ellos se encuentran los encargados de las conexiones con los hosts que queremos configurar
- Ansible tiene una funcionalidad que es ansible galaxy en la que podremos generar proyectos con una estructura concreta para posterior mente publicarlas en un repositorio GitHub publico o privado para su posterior reutilización. También generar ficheros tar.gz para facilitar su almacenamiento. En esta funcionalidad nos creara una estructura de fichero en la que ademas de las variables, funcionalidad y requisitos también nos dará ficheros para la documentación de dichos roles
- Cada carpeta tiene su función: -Defaults: Son las variables por defecto necesarias para este role. Estas variables se podrán modificar sus variables desde la llamada a los roles o desde los groups vars - Files: Ficheros que se usaran dentro de los roles, ya sean para copiarse o descomprimirse en las maquinas a las que nos conectamos. -Handlers Mediante los “handlers” podemos utilizar la etiqueta “notify” y estas acciones se disparan al final de cada bloque de tareas en los playbooks. Solo se activan una vez, incluso si un mismo “notify” está definido en varias tareas diferentes. -Meta Estos archivos describen el entorno (SO, versión, etc), autor, licencia, y también establece las dependencias del role. -Tasks Conjunto de acciones que se realizan sobre los hosts si cumplen las exigencias marcadas. Este directorio puede contener mas de un yml pero solo serán ejecutados si son referenciados desde main.yml -Templates Los templates son parecidos a los files, pero éstos admiten modificaciones (cambiar valores según las variables,...) -Test Como su nombre indica contiene una ejecución para probar el funcionamiento del role contra un host concreto indicado en el inventory. -Vars Tiene la misma función que defaults y se usa para almacenar variables. Además, las variables definidas en vars tienen mas prioridad que las variables definidas bajo defaults -.travis.yml Este fichero solo es usado en el caso de usar ansible-galaxy para publicar el role. -README.md Como me imagino que suponéis es para documentar el role pero es usado para ansible-galaxy como documentación para la wiki del github
- Ahora pasaremos a ver unos ejemplos de configuración y ejecución de unos comandos para que veáis como funciona. El ansible puede ir desde un único fichero yml en el que tendremos todo o un playbook con sus inventories donde irán configurados los hosts
- Ahora ya si que entramos en ver a la parejita feliz aunque también podríamos darle una vuelta mas en el siguiente curso y meter otro componente y hacer un trió pero eso ya sera para la siguiente charla. Por ahora nos quedamos con la pareja feliz.
- Para que quede mas claro vemos este flujo visual de como tendríamos nuestra arquitectura y las etapas por las que pasaremos para realizar la funcionalidad completa. Primero tendremos Ansible y vagrant que duda cabe y ademas tendremos que tener un proveedor de maquinas virtuales para vagrant. Haremos un vagrant up desde el directorio del vagrantfile a usar. Dicho vagrant file arrancara la imagen seleccionada y preconfigurara la maquina con lo indicado. Posteriormente lanzaremos el playbook ya sea desde vagrant o manualmente con el host de la maquina virtual y este configurara la maquina y orquestara las acciones indicadas. Posteriormente conectaremos a dicha maquina ya sea usando el vagrant ssh o a través del cliente de la propia maquina para comprobar que la maquina esta correctamente configurada.
- Ahora pasaremos a ver unos ejemplos de las dos herramientas.
- Ahora tampoco os penséis que crearemos maquinas como churros con un pájaro dándole a la letra S o Y,ni que dbas y los administradores de sistemas desaparecerán. Si que crearemos maquinas de manera mas sencilla, rápida, reutilizable, mantenible y mas fáciles de almacenar pero el conocimiento seguirá recayendo en los perfiles anteriormente indicados y para poder automatizar primero hay que haberlo instalado manualmente. Lo mas importante es que conseguimos replicar configuraciones iguales o similares a entornos de producción en todos los escalafones del desarrollo e integrar las maquinas en los flujos de construcción.
- Y tampoco os penséis que con esto dejaremos de trabajar ya que esto nos obliga a estar pendientes constantemente de la gestión de estos ficheros y estas maquinas para que estén incluidas en el flujo del proyecto, saber las vanguardias de las herramientas para mejorar y optimizar estos procesos. Ademas de estar conectados entre los proyectos de la empresa para poder reutilizar el trabajo ya realizado.
- Tenemos un proyecto tipo con nuestro equipo de desarrollo,nuestro servidor de desarrollo,test,qa, n y llegamos hasta producción. Todo parece muy bonito en este esquema en el que todo el equipo es feliz y vive en armonía hasta que empiezan a aparecer ciertas circunstancias que empiezan a alterar la visión del proyecto y la imagen perfecta del esquema empieza a verse que en su interior esconde una visión muy diferente.
- Chicote a venido para enseñarnos la realidad de este proyecto tan bonito en el esquema pero tan turbio por dentro en la realidad
- Programadores salvajes aparecen. Están discutiendo sobre la ultima entrega que a realizado uno ellos ya que no le funciona al otro. Con esto llegamos a la situación tan típica
- En mi maquina funciona como que no funciona en la tuya.
- De quien es el problema?? De uno, de ninguno, de los dos.Generalmente esta situación se da por una cagada del programador. Vale somos humanos. Pero también hay situaciones que el programador a programado bien, en su entorno local funciona pero a un compañero no. O me funciona en mi equipo pero en el resto no. Esto ocurre porque las plataformas en las que se a probado el código son distintas. Las posibles situaciones son: Cada equipo esta configurado de su padre y de su madre en desarrollo. Resto de entornos se van parcheando cada cual a su ritmo y a mano. Pudiendo darse casos de olvidar migrar esos cambios a las maquinas en su ciclo de vida.
- Si integramos en el flujo del desarrollo vagrant y ansible siempre tendremos entornos configurados de la misma manera indicando en cada entrega de software la versión correspondiente de scripts de ansible y vagrant. Generalmente el script de vagrant solo se usara la primera vez y se irán ejecutando en cada entrega los tasks de los scripts de ansible correspondientes. También nos da la posibilidad de que el equipo de desarrollo pueda crear una maquina virtual completa igual a las de los entornos posteriores.
- Encuentra una maquina en la cual están instaladas muchas aplicaciones, funcionalidades obsoletas que ademas no aportan valor al proyecto y muchos ficheros de configuración que no se sabe a que aplicaciones afectan. Pero claro hacer una revisión de todo ademas de costoso es un poco insufrible. Entonces chicote pregunta sobre los scripts de configuración de la maquina y la persona que administro la maquina durante la vida del proyecto
- Este proyecto ademas de no haber contado con una historificación o repositorio de scripts de instalación han pasado muchos administradores y por ello es imposible saber quien hizo que, ni porque. Si hubieran usado ansible y vagrant hubieran podido historificar los scripts con la vida del proyecto y así saber porque y para que se instalaron ciertas aplicaciones y como están configuradas, Esto hubiera ayudado a la buena administración y mantenimiento de estas maquinas. Los nuevos administradores hubieran sabido con facilidad la situación de la maquina y no tendrían tanta dependencia de las personas que la gestionaban
- Paquito sorprende a chicote comunicándole que ese proyecto con tan bonito esquema pero con un mantenimiento mas que dudoso y un desarrollo con bastantes traspiés, tiene que salir a producción en modo producto esa misma semana y que tendrá que ser instalable de manera fácil y sencilla por sus clientes.
- Teniendo en cuenta que no ha habido un repositorio en el que se hayan ido historificando los scripts de cambio de las maquinas y los responsables de mantenimiento del equipo ni el equipo de desarrollo saben realmente lo que es esencial para poder correr su software y ningún entorno tiene las versiones homogeneizas de aplicaciones instaladas. Chicote decide huir del lugar sabiendo que tendría un largo trabajo de investigación para poder saber los requisitos mínimos que el software requiere realmente y eso no entraría en los tiempos que paquito quería cumplir
- -Si el proyecto hubiera tenido entornos homogéneos. -Si se hubiera historificado los scripts de mantenimiento de las maquinas y de versiones mínimas para el software -Si no se hubiera dejado el conocimiento de las maquinas en manos de unos pocos El proyecto hubiera salido adelante con mayor facilidad Vagrant y ansible hubieran ayudado en ello Cierto que siempre tendremos una curva de aprendizaje, tendremos que integrar o facilitar la comunicación entre departamentos y distribuir el conocimiento por todos los perfiles del equipo. Pero con esto conseguiremos perfiles mas ricos y poder reutilizar muchos de estros esfuerzos en otros proyectos. Ademas conseguiremos proyectos mas ágiles y con mayor calidad.