Autor: Xu Lei
La dirección original del artículo: https://smartide.cn/zh/blog/2022-1010-iac/
Como práctica básica de la ingeniería de software moderna, la infraestructura como código (IaC) es la lógica subyacente detrás de los contenedores, los microservicios y DevOps nativos de la nube. Cabe decir que todas las tecnologías o prácticas anteriores son una colección de uno o más métodos basados en la infraestructura como código. La infraestructura como código no es una tecnología específica, sino una forma de resolver problemas. Este artículo le ayudará a comprender por qué los sistemas DevOps que no utilizan IaC son fraudulentos desde tres aspectos: el significado, los principios y los métodos de implementación de la infraestructura como código.
¿Qué es el CI?
El objetivo de la infraestructura como código es resolver un antiguo problema : cómo completar el proceso de entrega de software de forma segura, estable, rápida y eficiente. Tenga en cuenta que la entrega aquí no se refiere solo a implementar software implementable en el entorno operativo final, sino a un concepto más amplio de entrega, es decir, transformar el software de una idea o creatividad invisible e intangible a uno que los usuarios puedan operar. usar. Este proceso implica todo el proceso de captura, diseño, planificación, desarrollo, prueba, implementación y lanzamiento de ideas de software, así como la iteración de recopilar comentarios de los usuarios e iniciar el proceso anterior después del lanzamiento del software. Esta iteración se repetirá durante todo el ciclo de vida del software hasta que el software ya no se utilice y llegue al final de su vida útil.
Este proceso iterativo continuo en el ciclo de vida del software constituye el concepto del ciclo de retroalimentación de DevOps . Los extremos izquierdo y derecho de este ciclo de retroalimentación son Dev y Ops, y el código y la infraestructura son los artefactos más importantes de Dev y Ops. Dev mantiene el código, y Ops mantiene la infraestructura. Tradicionalmente, existe una clara distinción entre código e infraestructura. En términos generales, el código se refiere específicamente al código de la aplicación, mientras que la infraestructura se refiere a todos los componentes "básicos" excepto la aplicación (o los siguientes).
Antes de la aparición de la tecnología de computación en la nube, el hardware se consideraba generalmente inmutable una vez creado. Era como comprar una computadora y si querías reemplazar la CPU, los componentes internos, los discos y las tarjetas de red, tenías que volver a comprar los componentes correspondientes y reinstalarlos. .Montar. La computación en la nube desacopla los recursos informáticos (computadoras) en tres tipos de recursos que se pueden combinar a voluntad: informática, almacenamiento y red , lo que permite a los usuarios combinarlos según sea necesario. Su mecanismo de implementación subyacente es convertir el hardware en software . Por ejemplo, la tecnología de almacenamiento de objetos y las redes definidas por software (SDN) son las tecnologías básicas de la computación en la nube. El resultado de que el hardware esté basado en software es que podemos cambiar la capacidad del hardware mediante la configuración. En realidad, este es el significado más básico de infraestructura como código.
Pero a los usuarios, en realidad no les importa en qué hardware o nube se ejecuta el software que utilizan. Por ejemplo: para las necesidades sociales de los usuarios, WeChat es la infraestructura para las necesidades sociales; para los usuarios que necesitan escribir documentos, WORD es su infraestructura. En comparación con el hardware, este es en realidad otro significado extremo de infraestructura, es decir: cualquier capacidad de soporte que ayude a los usuarios a completar una determinada operación puede convertirse en la infraestructura para este tipo de operación del usuario.
En este sentido extremo, cualquier capa de la pila del entorno anterior puede convertirse en la infraestructura anterior. Para proporcionar a la capa superior capacidades de autoservicio similares a las de la computación en la nube, es necesario proporcionar capacidad de configuración. Para satisfacer esta necesidad de configurabilidad, han surgido en la industria de TI implementaciones de infraestructura como código, como la tecnología de contenedorización, Kubernetes, Terraform y Azure Resource Manager. De hecho, todas estas tecnologías resuelven un problema: la capacidad de configuración del sistema.
Principios de implementación de la IaC
Hay muchas formas de lograr la configurabilidad: el método tradicional de operación y mantenimiento es en realidad muy simple, que consiste en automatizar el proceso de configuración a través de scripts, automatizando el proceso de configuración originalmente engorroso.
Aunque el método de script automatizado puede resolver el problema de configurabilidad hasta cierto punto, cuando la frecuencia de los cambios del sistema alcanza un cierto nivel, la carga de trabajo de mantener el script automatizado compensará la mejora de eficiencia aportada por el script automatizado . y mantenimiento Los equipos pueden descubrir que el procesamiento manual es incluso más eficiente que escribir y mantener scripts automatizados. Por lo tanto, en el contexto actual de iteraciones de software cada vez más rápidas, los scripts automatizados gradualmente no pueden satisfacer las necesidades del equipo para responder al mercado que cambia rápidamente. Necesitamos una forma de mantener el entorno que permita al equipo adaptarse fácilmente a los cambios rápidos. En este contexto nació Infraestructura como Código (IaC). De hecho, no es exacto decir que nació IaC, IaC es en realidad el resultado de la mejora continua por parte de los ingenieros después de encontrar problemas.
Cuando la forma de mantener scripts automatizados no puede adaptarse a las necesidades del mercado que cambian rápidamente, cómo desacoplar los equipos de desarrollo y operación y mantenimiento se convierte en el núcleo de la solución de este problema. En el modelo de trabajo en el lado izquierdo de la figura anterior, el núcleo del problema es el modelo de trabajo de "solicitud-respuesta" entre los equipos de desarrollo y operación y mantenimiento. Este modelo de trabajo hace que los equipos de desarrollo y operación y mantenimiento dependan de cada uno otros e incapaces de seguir independientemente su propio trabajo rítmico. Para resolver este problema, IaC toma prestado el principio de capas en el diseño de arquitectura de software a gran escala para convertir las capacidades que deben compartirse en componentes comunes y compartir estos componentes entre desarrollo, operación y mantenimiento, de modo que las dos partes que están Originalmente interdependiente puede Un equipo se vuelve dependiente de otro componente de terceros. Como se muestra abajo:
Para poder trabajar junto con componentes de terceros, el enfoque IaC debe seguir varios principios clave
-
Declarativo: para que todas las capacidades de orquestación sean independientes de los equipos de desarrollo y operación y mantenimiento, ningún equipo debe mantener las operaciones específicas de las capacidades dentro de su propio equipo. La configuración declarativa puede garantizar esto, porque en la configuración Siempre que la declaración no tenga Lógica específica, significa que ambas partes de la dependencia original deben contribuir con capacidades públicas; de lo contrario, C en la figura anterior no tendrá efecto.
-
Idempotencia: Además, la configuración declarativa debe poder garantizar los resultados de la orquestación del entorno en cualquier momento, lo que también significa que las operaciones en el entorno en el componente general C deben poder ejecutarse en cualquier estado y obtener un resultado final consistente. En otras palabras, no importa si el entorno de destino está en el estado inicial, intermedio, final o de error, cuando se carga la configuración declarativa, se convertirá en el estado deseado (estado deseado) que necesitamos.
Cómo implementar IaC
En esencia, IaC es una forma de hacer las cosas. Siempre que los métodos y herramientas para implementar IaC sigan los principios anteriores, pueden ayudar a los equipos a implementar este método. En el proceso de trabajo real, necesitamos algunas condiciones básicas para lograr IaC:
apoyo cultural
La implementación de IaC cambiará el modelo de trabajo y los métodos de colaboración de los equipos (especialmente los equipos de desarrollo y operación y mantenimiento), y los límites de trabajo y las responsabilidades de ambas partes cambiarán. En el modelo tradicional, los equipos de desarrollo y operación y mantenimiento colaboran a través de procesos. Cuando ambas partes necesitan la cooperación de la otra parte, inician un proceso (emiten una solicitud), esperan a que la otra parte complete la operación según sea necesario (dar una respuesta), y luego continuar el proceso hasta lograr el objetivo. IaC requiere que ambas partes colaboren a través de capacidades compartidas. Ambas partes deben continuar descubriendo problemas que impiden a la otra parte trabajar de forma independiente durante la colaboración y contribuir conjuntamente con la capacidad de resolver estos problemas a otro componente compartido por ambas partes (generalmente una herramienta). ) En el trabajo diario, ya no dependen de procesos para impulsarse entre sí, sino que utilizan este componente compartido (herramienta) para completar el trabajo. El modelo de trabajo de IaC requiere que ambos equipos acepten una forma de pensar incierta y, cuando surgen problemas, deben resolverlos conjuntamente en lugar de definir y asignar responsabilidades. Si la cultura en el equipo no permite la existencia de esta forma de pensar incierta, IaC no se implementará.
Compartir herramientas
Los equipos con el apoyo cultural anterior deben construir conjuntamente una herramienta que sea reconocida por ambas partes y encapsular todas las capacidades de orquestación ambiental que ambas partes necesitan en esta herramienta. Los objetivos principales de esta herramienta son dos:
Desacoplamiento: Permitir que ambas partes ya no dependan la una de la otra en el trabajo diario y puedan utilizarlo libremente según su propio ritmo y modo de trabajo. Al mismo tiempo, garantiza que los estándares, reglas y estrategias que interesan a ambas partes puedan ser implementarse normalmente y puede ser supervisado.
Personalizable y evolutiva: El propósito de esta herramienta es adaptarse a las necesidades cambiantes del mercado. Una herramienta estática no puede hacer esto. Sólo las herramientas que son altamente personalizables y escalables pueden hacerlo. Capacidad. Por lo tanto, es crucial controlar la granularidad funcional en el proceso de diseño e implementación de esta herramienta. Si todas las funciones se diseñan de acuerdo con los procesos comerciales diarios sin considerar la versatilidad, el resultado final será que cualquier cambio en el flujo de trabajo provocará cambios en la herramienta. , dichas herramientas perderán su valor de existencia como componentes generales.
IaC está en todas partes
De hecho, los nativos de la nube, los microservicios, la contenedorización y DevOps practican IaC en diferentes niveles. La nube nativa enfatiza el uso de las características básicas de la nube para empoderar a los equipos, de hecho, utiliza la tecnología subyacente de la computación en la nube para proporcionar a los equipos las condiciones básicas para implementar IaC. Los microservicios utilizan el pensamiento en componentes para permitir que varios equipos trabajen de forma independiente sin verse afectados por otros equipos, maximizando así la eficiencia del trabajo en equipo. Los contenedores se basan en la tecnología de computación en la nube y proporcionan capacidades de IaC para el sistema operativo y su pila de entorno superior. Las principales herramientas de contenedores, incluidas Docker y Kubernetes, están diseñadas en función de la configuración declarativa y los principios de idempotencia.
¿Qué es DevOps aquí? DevOps es la síntesis de todos los conceptos, métodos y prácticas anteriores, de hecho, el alcance de DevOps es más amplio que esto. En la imagen al principio debería poder ver que, en términos de amplitud, el bucle infinito formado alrededor de Dev y Ops en realidad cubre todos los aspectos del proceso de entrega de software. En términos de profundidad, DevOps puede cubrir conceptos culturales y métodos de gestión. , innovación empresarial, ágil y eficiente, gestión de proyectos, gestión de equipos, gestión técnica y todos los niveles de implementación de herramientas. Como resultado, cada vez más personas están poniendo cada vez más contenido bajo el sombrero de DevOps y han surgido muchos conceptos extendidos como AIOps, GitOps, TestOps, DevSecOps, BizDevOps, etc.
De hecho, no tenemos que preocuparnos por el concepto en sí, porque DevOps, que proviene del resumen espontáneo de la comunidad, no tiene un propietario de propiedad intelectual centralizado y nadie puede darle una interpretación clara. Esto en sí mismo es realmente algo bueno, porque al igual que el análisis y la explicación anteriores de IaC, la existencia de DevOps también nos ayuda a seguir mejorando. Si se convierte en un conjunto de métodos o herramientas estáticos, ¿cómo puede adaptarse a la situación actual? ¿Qué pasa con el cambiante entorno empresarial y las necesidades del mercado? Desde esta perspectiva, todas las denominadas certificaciones, sistemas y programas que pretenden estandarizar DevOps son en realidad engañosas.
En el proceso de introducción de tecnología de contenedores, microservicios, nube nativa y DevOps, muchas empresas aún continúan con la estructura de departamentos y el flujo de trabajo originales, e intentan integrar estas nuevas tecnologías y métodos en los procesos existentes en lugar de explorar nuevas tecnologías. . Me he encontrado con demasiadas organizaciones similares en los últimos diez años ayudando a las empresas a implementar DevOps. El síntoma más obvio es que encontrará que los departamentos que promueven la implementación de DevOps están constantemente definiendo responsabilidades y echando culpas. Deben ser deshonestos con DevOps. Las ideas de trabajo de IaC que describí anteriormente nunca han sido importantes para estas personas. No les importa el análisis de la causa raíz y las medidas de mejora después de que ocurre el problema. Por el contrario, si los resultados del análisis de la causa raíz se culpan a ellos mismos, entonces preferirían no analizar, si el resultado de las medidas de mejora es que necesitas aportar parte de tus funciones, lo cual es aún más imposible. El resultado final es esa "herramienta compartida" con varios parches, procesos codificados y deuda técnica enterrada en ella. Es concebible cómo una herramienta de este tipo puede generar incertidumbre y cómo puede ayudar a otros departamentos a mejorar la eficiencia, y mucho menos a mejorar la organización. su eficacia global. Por cierto, esta herramienta que esconde muchas bombas de tiempo es la "plataforma integrada de I + D / plataforma DevOps" que le apasiona.