Menú

Gestión de la configuración en prácticas de DevOps

  • Principal
  • Otro
  • Gestión de la configuración en prácticas de DevOps

configuration management devops practices

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Qué es la gestión de la configuración en las prácticas de DevOps?

Concepto de Pruebas continuas en DevOps se explicó en detalle en nuestro tutorial anterior.

Lo más destacado de la gestión de la configuración en DevOps es ofrecer,

  1. Infraestructura como código
  2. Configuración como código

Debe leer completamente => Serie exclusiva de tutoriales de DevOps

punteros de lista enlazada c ++

Gestión de la configuración en prácticas de DevOps

Existen numerosos beneficios de 'Infraestructura como código' y 'Configuración como código' en la práctica de DevOps.

    • Las configuraciones están controladas por versiones
    • Automatizado y estandarizado
    • Elimina la dependencia
    • Configuraciones de infraestructura sin errores
    • Aumenta la colaboración entre el equipo de operaciones y desarrollo
    • Corregir la desviación de la configuración
    • Tratar la infraestructura como un recurso flexible
    • Escalado automatizado de infraestructura
    • Mantener la coherencia en las configuraciones

VIDEO Parte 4 Bloque 1: Gestión de la configuración- 23 minutos 7 segundos

Transcripción:

En esta parte, aprenderemos sobre Gestión de la configuración, gestión de versiones y supervisión del rendimiento de las aplicaciones en DevOps.

Aquí, en el bloque 1, nos centraremos en la gestión de la configuración y entenderemos qué es la gestión de la configuración y en qué se diferencia en DevOps y los métodos tradicionales.

Para empezar, sepamos ¿Qué es la gestión de la configuración?

La gestión de la configuración, como su propio nombre lo explica, no es más que gestionar todas las configuraciones de los entornos en los que se aloja la aplicación de software.

Como sabemos, tenemos diferentes entornos en todo el SDLC en DevOps, comenzando con pruebas unitarias, pruebas de integración, pruebas de sistemas, pruebas de aceptación y pruebas de usuario final.

Y también he explicado en mis tutoriales anteriores que el entorno configurado para estas pruebas se volvería progresivamente más complejo a medida que avanza hacia el entorno de preproducción y producción.

Entonces, básicamente, la gestión de la configuración es el proceso automatizado para gestionar todas las configuraciones de cada uno de estos entornos.

Entonces, ¿cuál es la diferencia entre la gestión de configuración tradicional y la gestión de configuración de DevOps?

En nuestros métodos tradicionales de gestión de la configuración, el equipo solía administrar estas configuraciones de varios entornos a través de documentación formal en la que cada una de las configuraciones solía registrarse en los documentos y el equipo de configuración o administrador solía manejar el control de versiones de estos documentos.

Y a medida que vaya sufriendo cambios, también asumirá la responsabilidad de configurar el entorno y gestionar las configuraciones manualmente.

Ahora, en DevOps, por lo general, todos estos procesos de gestión de la configuración están bastante bien automatizados y las configuraciones se encapsulan en forma de código o scripts y se controlan a través de la herramienta de control de versiones.

En este contexto, podemos llamar a que el equipo de Operaciones se integra con Desarrollo en la gestión de los entornos a través de la herramienta de control de versión única.

Por lo tanto, lo más destacado de la gestión de la configuración en DevOps es ofrecer,

      1. Infraestructura como código
      2. Configuración como código

¿Qué significa realmente 'Infraestructura como, como código'? Está definiendo toda la definición del entorno como un código o una secuencia de comandos en lugar de grabar en un documento formal.

Entonces, ¿qué incluye la definición de entorno? La definición del entorno generalmente incluye la instalación de servidores, la configuración de redes y la instalación de otros recursos informáticos, que forman parte de la configuración de la infraestructura de TI. Por lo tanto, todos estos detalles se escribirían como un archivo o en forma de código y se registrarían en la herramienta de control de versiones.

Este script o código, que se registra en el control de versiones, se convertiría en la única fuente para definir el entorno o incluso actualizar esos entornos.

Solo para dar un simple Ejemplo , si tenemos que agregar un servidor al entorno específico, todo lo que haríamos es actualizar esta información en los scripts del entorno y ejecutar la canalización de entrega, en lugar de ir manualmente y generar un nuevo entorno con el servidor agregado o buscar la ayuda de la gente de administración del sistema para hacer esto.

Entonces, lo bueno aquí es que el desarrollador o evaluador no necesita ser un experto en administración de sistemas para configurar sus servidores para la actividad de desarrollo o prueba.

Entonces, la infraestructura configurada en DevOps será completamente automatizada y básicamente sigue el script que se registra en el control de versiones a partir de la instalación de los servidores, la configuración, la instalación del SO, hasta que los canales de comunicación de estas instancias se establecen con el implementado. software.

¿Cuál es la configuración como código?

La configuración como código no es más que definir todas las configuraciones de los servidores o cualquier otro recurso como un código o script y verificarlos en el control de versiones.

Estos scripts de configuración que se registran en el control de versiones se ejecutan como parte del proceso de implementación para configurar la infraestructura y sus configuraciones de forma automatizada.

Bueno, definir configuraciones incluye parámetros que definen las configuraciones recomendadas para que el software se ejecute correctamente. O un conjunto de comandos que se ejecutarán inicialmente para configurar la aplicación de software. O incluso podrían ser configuraciones de cada uno de los componentes del software que se van a configurar, o roles de usuario específicos, privilegios de usuario, etc.

Simple Ejemplo sería configurar los conmutadores de funciones, donde los valores predeterminados se configuran como parte del parámetro de configuración.

Agregar otro puerto a un firewall sería otra Ejemplo , que se puede actualizar en la secuencia de comandos y, posteriormente, estas secuencias de comandos se ejecutan como parte del proceso de entrega.

Se encuentran disponibles varias herramientas para realizar la automatización de la infraestructura en el mercado. Pocos son Chef, Puppet, Terraform, etc., Chef y Puppet son herramientas de gestión de configuración basadas en ruby, mientras que Terraform es una herramienta de aprovisionamiento.

Además, en estos días, como casi todas las aplicaciones se alojarán en la nube, AWS, ellas mismas proporcionan RESTAPI, que se pueden aprovechar para este propósito.

Tengo una enorme lista de beneficios de la gestión de la configuración en DevOps, en lugar de definir la infraestructura y las configuraciones como un código.

Repasemos uno por uno.

Todas las configuraciones y los detalles de la infraestructura están controlados por versiones, lo que es un gran beneficio en la implementación de DevOps.

#1) Esto ayuda al equipo a gestionar los cambios en los servidores y la configuración de forma automatizada y ayuda a depurar rápidamente si algo falla, en un corto período de tiempo y también permite retroceder rápidamente a la versión anterior, sin causar ninguna interrupción a los clientes.

#2) Dado que estos scripts están ubicados en el servidor central y todos los miembros del equipo saben qué hay en cada uno de estos scripts y cuáles son los cambios realizados en cada una de estas versiones. Esto también permite al equipo, volver a la versión anterior, si hay algún problema en las últimas versiones.

Imagínese, si hay un fallo del servidor, cuánto tiempo habría tardado en restaurarlo manualmente. Y ahora, al definir la infraestructura como un script y el control de versiones, podemos restaurar inmediatamente yendo a la versión anterior.

#3) La gestión de las configuraciones como un código también evita que alguien realice cambios en el sistema accidentalmente y evita cualquier daño que se produzca más adelante en la producción.

Dado que la gestión de la configuración está totalmente automatizada, la intervención manual para configurar o actualizar se elimina por completo.

Imagine el impacto en el costo, la calidad y el tiempo cuando antes la gente solía depender de los recursos humanos para realizar estas configuraciones manualmente y cuando ciertas configuraciones se pierden o no se configuran como se requiere.

Por lo tanto, la automatización de la gestión de la configuración no solo se ha beneficiado en el ahorro de tiempo, sino también en la eliminación de tales errores humanos y la mejora de la calidad. Además, el estándar de codificación ha ayudado al equipo a seguir el estándar especificado en la codificación y la automatización en lugar de seguir la fantasía de cada una de las personas que escriben la guía de configuración.

Como se discutió anteriormente, las configuraciones que se entregan como un código han eliminado la dependencia de una sola persona o un equipo llamado administrador de configuración o equipo de configuración. El equipo de desarrollo no necesita esperar a que el equipo de configuración venga y solucione cualquier problema de configuración o de infraestructura.

O incluso para configurar la infraestructura y las configuraciones, que son completamente automatizadas y controladas por versiones. Por lo tanto, cualquier persona del equipo, ya sea un desarrollador o un evaluador, puede hacer girar un servidor y realizar las configuraciones para su desarrollo y pruebas. Por lo tanto, la instalación del servidor y las configuraciones se ha vuelto independiente de la persona.

Esto también garantiza que los equipos de desarrollo y de control de calidad no utilicen los mismos servidores para sus actividades, como solía ser el caso antes.

La infraestructura y las configuraciones definidas como un código común junto con la automatización y el control de versiones estandarizan todos los entornos y configuraciones. Por lo tanto, esto no solo facilita la tarea de depuración para los desarrolladores, sino que también elimina los errores humanos que resultan en configuraciones de infraestructura sin errores, de lo contrario, causarían un gran daño si no se detectan temprano.

Aquí, podemos ver claramente la clara colaboración entre Dev y Ops, donde ambos dependen de una sola fuente para llevar a cabo la configuración de infraestructura y ambos equipos participan activamente en la automatización y configuración de toda la gestión de la configuración.

Este trabajo conjunto para lograr un objetivo común impulsa la colaboración entre los equipos, el desarrollo y las operaciones.

Corrección de la desviación de la configuración

¿Qué es la deriva de configuración?

Las pequeñas diferencias e inconsistencias entre los servidores, que a veces ocurren debido a la actualización manual, que se acumula durante un período de tiempo, se denominan Deriva de configuración.

Esta no es una buena situación, porque esta inconsistencia en los servidores hace que ciertos archivos de programa como el manifiesto, el libro de jugadas no se ejecuten de manera confiable en todos los servidores y, por lo tanto, conduce a fallas de automatización. Por lo tanto, esto debe evitarse para que el equipo use la automatización de configuraciones de manera efectiva.

La gestión de infra y config como un código y la versión que los controla ha ayudado al equipo a evitar o corregir cualquier tipo de desviación de configuración entre varios entornos o entre configuraciones de desarrollo y producción manteniendo consistentemente las configuraciones en todos los servidores.

Por lo tanto, un equipo puede estar mejor seguro de tener configuraciones de configuración similares en la configuración de desarrollo que en producción. Esto también les ayuda a simular los problemas de producción en el entorno de desarrollo.

Por lo tanto, esto ayuda a evitar cualquier tipo de cambios inesperados que cualquiera de los miembros del equipo podría intentar hacer en la infraestructura, lo que podría romper la configuración y también obligar al equipo a no realizar cambios en la configuración a menos que estén conectados como un código al repositorio.

La entrega de infraestructura y su configuración como código ha permitido al equipo administrarla como un recurso flexible para satisfacer las necesidades comerciales dinámicas del cliente.

Es una especie de plug and play ahora. Un equipo puede ingresar específicamente al servidor o red en particular y realizar los cambios en ellos. Podría ser simplemente actualizar el servidor de aprovisionamiento o agregar o modificar el almacenamiento en una red en particular, o incluso actualizar el sistema operativo, y todo se puede actualizar de forma independiente como un recurso flexible.

Anteriormente, cambiar un parámetro de configuración solía llevar mucho tiempo, especialmente cuando se requería actualizar en todos los servidores, pero ahora es solo una vez. Actualice el script y cárguelo en la herramienta de control de versiones y todo estará listo.

Existe la flexibilidad de eliminar por completo la infraestructura existente y crear otra totalmente. Por lo tanto, administrar la infraestructura y las configuraciones se ha vuelto bastante fácil ahora. Bueno, las soluciones basadas en la nube han permitido que la infraestructura se amplíe automáticamente agregando los recursos informáticos o de almacenamiento adicionales según sea necesario y reduciendo cuando no son necesarios.

Esto ha permitido la optimización del uso de recursos en función de la demanda. Si queremos escalar la infraestructura aumentando el tamaño de la máquina, podemos hacerlo de inmediato. De manera similar, si queremos escalar horizontalmente o quizás agregar otra configuración, o agregar más interfaces, podemos hacerlo en segundos simplemente actualizándolo en el código y ejecutando la canalización automatizada.

Por último, pero no menos importante, la infraestructura, la entrega como código en un entorno controlado, ayuda a mantener la coherencia de los entornos en varias configuraciones. Esto también ayuda a depurar el problema. Este punto también lo he cubierto anteriormente hasta cierto punto al hablar sobre la desviación de la configuración.

Eso es todo y esto completa nuestra charla sobre la gestión de la configuración en DevOps, en cuanto a qué es la infraestructura y las configuraciones como código y cuáles son sus beneficios.

En nuestro próximo tutorial, discutiremos los aspectos de Release Management en DevOps.

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^