automatización

  • Artículo

En la infraestructura en la nube definida por software, los equipos usan diversas herramientas y técnicas para aprovisionar, configurar y administrar la infraestructura. A medida que los equipos evolucionan y crecen, pueden pasar de usar portales y trabajos manuales a usar código y automatización para aprovisionar, configurar y administrar la infraestructura y los servicios.

Consideraciones relativas a la automatización de la plataforma

  • La implementación de la metodología Todo como código (EaC) permite a los equipos descubrir ventajas clave, crear una cultura de desarrollo sólida y permitir a todos los usuarios de cada equipo inspeccionar qué recursos se implementan y cómo se hace. La metodología EaC también ayuda a los equipos de plataforma a adoptar procedimientos de desarrollo clave que mejoran su agilidad y eficacia. Los equipos pueden hacer un seguimiento de los cambios y controlar los que pasan a producción mediante el almacenamiento de código en repositorios y el uso de sistemas de control de versiones para administrarlos.
  • Los equipos pueden seguir el principio de cuatro ojos y usar la programación en pareja o la revisión por homólogos a fin de garantizar que los cambios de código nunca se hagan solos. La programación en pareja y la revisión por homólogos mejoran la calidad del código, permiten que los equipos compartan la responsabilidad de los cambios y aumentan el conocimiento que los equipos tienen sobre lo que se ha acordado e implementado. La revisión de código es una forma fantástica de que los miembros de los equipos aprendan técnicas y métodos nuevos de codificación y automatización.
  • Los equipos deben usar sistemas de control de versiones como Git, junto con repositorios de Git, para aplicar la revisión por homólogos. Los repositorios de Git permiten a los equipos definir las ramas importantes y protegerlas con directivas de rama. Puede usar la directiva para requerir cambios de código en estas ramas a fin de cumplir criterios determinados, como un número mínimo de aprobaciones de miembros de los equipos, antes de que puedan combinarse en una rama protegida.
  • Los equipos deben conectar la metodología de EaC y el proceso de revisión de cambios junto con un proceso de integración continua y entrega continua (CI/CD). Cada cambio de código debería desencadenar automáticamente un proceso de CI que ejecute implementaciones de prueba, validación y análisis de código estático. La integración continua garantiza que los desarrolladores comprueben su código al principio (lo que suele conocerse como fracasar y responder rápido a los errores o prueba de desplazamiento a la izquierda) para ver si hay errores que puedan provocar problemas a futuro. En función de la estrategia de ramificación que utilice el equipo, los cambios en cualquier rama importante deberían desencadenar la implementación en entornos diferentes. Una vez que se aprueban los cambios y se combinan en main, el proceso de implementación continua los implementa en el entorno de producción. Este sistema de administración de código proporciona a su equipo una única fuente de verdad para lo que se ejecuta en cada entorno.
  • Para asegurarse de que la plataforma sea totalmente independiente y proporcione autoservicio para los equipos de carga de trabajo, el equipo de la plataforma debe trabajar a fin de automatizarlo todo (lo que suele conocerse como Automatización extrema) desde el aprovisionamiento, la configuración y la administración de plataformas hasta el aprovisionamiento de suscripciones de zona de aterrizaje para los equipos de carga de trabajo. La automatización extrema permite a su equipo de plataforma centrarse en proporcionar valor en lugar de implementar, configurar y administrar la plataforma. La automatización extrema también crea un ciclo de mejora automática que proporciona al equipo más tiempo para crear más automatización.
  • A medida que los equipos de plataforma automatizan las actividades operativas y reducen la intervención humana, deben cambiar su enfoque a tareas importantes que permitan y aceleren la innovación de los equipos de carga de trabajo en Azure. Para lograr esto, el equipo de plataforma debe iterar varios ciclos de compilación y desarrollo a medida que ponen en marcha las herramientas, los scripts y las mejoras de funcionalidad de la plataforma.
  • Hay varias opciones disponibles para ayudar al equipo a empezar a trabajar con la implementación de la zona de aterrizaje de Azure. Estas opciones dependen de las funcionalidades actuales del equipo y pueden aumentar a medida que evoluciona el equipo. Más concretamente, para la implementación de plataformas, puede elegir entre experiencias basadas en Portal, Bicep o Terraform, en función de la preferencia de herramientas y competencia de IaC de Teams correspondiente.
    • Los equipos de plataforma nuevos y emergentes que acaban de conocer la metodología Infraestructura como código (IaC) y están más familiarizados con el uso de un portal para implementar y administrar recursos pueden usar el acelerador de zonas de aterrizaje de Azure (con AzOps) para empezar, lo que brinda soporte a los equipos que todavía utilizan un enfoque ClickOps. ClickOps es el proceso de aprovisionamiento, configuración y administración de recursos mediante clics en portales, consolas de administración y asistentes. Este acelerador permite al equipo usar el portal como herramienta de implementación inicial y progresivamente, a medida que crece la madurez de la ingeniería de plataformas, para usar aún más la CLI de Azure, PowerShell o IaC.
    • La solución AzOps permite que los equipos hagan evolucionar sus procedimientos de automatización y administración de plataformas de controlados por ClickOps a compatibles con DevOps. El equipo puede pasar del uso de su acceso de cuenta personal al uso de los principios y procedimientos de DevOps que se basan solo en CI/CD con AzOps e IaC. AzOps permite que el equipo traiga su propia arquitectura, use la arquitectura implementada por el acelerador de Azure Landing Zone Portal (después de la implementación inicial basada en el portal, ya que la integración de AzOps no forma parte de la experiencia del portal de ALZ), se integra con una implementación de brownfield o usa plantillas personalizadas (Bicep o ARM) para compilar y operacionalizar la plataforma.
    • Los equipos de plataforma con aptitudes y funcionalidades establecidas pueden adoptar un enfoque codificado que sigue los principios y procedimientos de DevOps. El equipo se debe basar en gran medida en los procedimientos de desarrollo moderno e IaC, a fin de apartarse del acceso de Azure en sus cuentas personales y acercarse a la ejecución de todas las operaciones a través de la canalización de CI/CD. Su equipo debería usar aceleradores basados en IaC, como ALZ-Bicep o el módulo Terraform de zonas de aterrizaje de Azure para acelerar esta transición.
  • Los aceleradores basados en IaC tienen un ámbito de administración limitado. Las versiones nuevas proporcionan más funcionalidades y mayor capacidad de administración de recursos. Si usa un acelerador, el equipo debe considerar el uso de un enfoque por capas que comience con un acelerador y, a continuación, agregue una capa de automatización. La capa de automatización proporciona funcionalidades que el equipo necesita para dar soporte completo a los equipos de carga de trabajo con características de plataforma como la implementación del controlador de dominio para aplicaciones heredadas.
  • A medida que el equipo de plataforma realiza la transición a un enfoque de DevOps, debe establecer un proceso para controlar las correcciones de emergencia. El equipo puede usar permisos aptos de Privileged Identity Management (PIM) para solicitar acceso y hacer correcciones y, posteriormente, revertirlas al código para limitar el desfase de configuración, o bien puede usar código para implementar una corrección rápida. El equipo siempre debe registrar correcciones rápidas en su trabajo pendiente para volver a trabajar cada corrección en un momento posterior y limitar su deuda técnica. Demasiada deuda técnica lleva a una desaceleración futura, ya que cierto código de plataforma no se revisa completamente y no cumple con los principios y directrices de codificación del equipo.
  • Puede usar directivas de Azure para agregar algo de automatización a la plataforma. Considere la posibilidad de usar IaC para implementar y administrar las directivas de Azure, las que se suelen conocer como Directivas como código (PaC). Estas directivas permiten automatizar actividades como la recopilación de registros. Muchos marcos de PaC también implementan un proceso de exención, por lo que se recomienda planear que los equipos de carga de trabajo soliciten exenciones de directivas.
  • Use "Gobernanza controlada por directivas" para indicar a los equipos de carga de trabajo cuando intenten implementar recursos que no cumplan con un control de seguridad. Para esas situaciones, considere la posibilidad de implementar directivas con el efecto deny, que permite que los equipos de carga de trabajo usen también la metodología Todo es código y eviten el desfase de configuración cuando el código declara una cosa y la directiva ha cambiado una configuración en el momento de la implementación. Evite el uso de efectos modify, como si un equipo de carga de trabajo implementa una cuenta de almacenamiento con supportOnlyHttpsTraffic = false definido en el código donde una directiva modify lo cambia a true en el momento de la implementación para que siga siendo compatible. Esto lleva al desfase de código de lo que se implementa.

Recomendación relativa al diseño de la automatización de la plataforma

  • Siga un enfoque del tipo Todo es código para lograr una transparencia y un control de configuración total de la plataforma de Azure, la documentación, la implementación y el proceso de prueba.
  • Utilice el control de versiones para administrar todos los repositorios de código, entre los que se incluyen:
    • Infraestructura como código
    • Directiva como código
    • Configuración como código
    • Implementación como código
    • Documentación como código
  • Implemente el principio de cuatro ojos y un proceso para la programación en pareja o la revisión por homólogos a fin de garantizar que el equipo revise todos los cambios de código antes de implementarlos en el entorno de producción.
  • Adopte una estrategia de ramificación para el equipo y establezca directivas de rama para las ramas que desea proteger. Con las directivas de rama, los equipos deben utilizar solicitudes de incorporación de cambios para combinar los cambios.
  • Use la integración continua y entrega continua (CI/CD) para automatizar las pruebas de código y su implementación en distintos entornos.
  • Trabaje para automatizarlo todo, como el aprovisionamiento, la configuración y la administración de la plataforma, así como el aprovisionamiento de suscripciones de zona de aterrizaje para los equipos de carga de trabajo.
  • Use uno de los aceleradores disponibles que coincidan con las funcionalidades de su equipo para empezar a implementar las zonas de aterrizaje de Azure.
  • Planee usar un enfoque de implementación por capas para agregar funcionalidades que no están cubiertas por un acelerador, pero que son necesarias para brindar soporte completo a los equipos de carga de trabajo.
  • Establezca un proceso para usar código para implementar correcciones rápidas. Registre siempre las correcciones rápidas en el trabajo pendiente de su equipo para que cada corrección se pueda volver a trabajar más adelante y pueda limitar la deuda técnica.
  • Use Infraestructura como código para implementar y administrar directivas de Azure (que se suelen conocer como Directivas como código).
  • Implemente un proceso de exención para las directivas. Planee que los equipos de carga de trabajo soliciten exenciones de las directivas y prepárese para desbloquear los equipos cuando sea necesario.
  • Use "Gobernanza controlada por directivas" para bloquear a los equipos de carga de trabajo cuando intenten implementar recursos que no cumplan con un control de seguridad. Esto ayuda a reducir el desfase de configuración, donde el código declara un estado diferente al que se termina implementando.

Más información