Implemente con confianza
 Alcance el estado deseado de la implementación con predictibilidad. |
|---|
Cree una cadena de suministro de cargas de trabajo que le permita alcanzar de forma coherente el objetivo de previsibilidad en todos los entornos, en las plataformas de hospedaje, las aplicaciones, los datos y los recursos de configuración de la carga de trabajo. El mecanismo de implementación debe ser capaz de llevar a cabo la automatización, pruebas, supervisión y control de versiones. Debe modularizarse y estar listo para ejecutarse a petición. No debe representarse como un proceso monolítico de un extremo a otro. La cadena de suministro no sirve necesariamente para una ejecución más rápida, sino para lograr coherencia y autodocumentación en varias iteraciones.
El equipo de carga de trabajo es responsable de la cadena de suministro en relación con su propia carga de trabajo.
Escenario de ejemplo
Contoso Manufacturing ha desarrollado una aplicación basada en Java que se usa para supervisar y optimizar sus procesos de fabricación. La carga de trabajo se ha migrado recientemente a Azure y ahora se ejecuta en Azure Spring Apps, Azure Database for MySQL y Azure IoT Hub.
Implementación de la infraestructura mediante código
Use infraestructura como código (IaC) para definir los aspectos repetibles de la cadena de suministro que están listos para producción. Opte por enfoques declarativos en lugar de métodos imperativos.
Las tecnologías de IaC declarativa están diseñadas teniendo en cuenta la automatización y la reutilización. Puede descargar implementaciones de infraestructura de usuarios en herramientas y lograr una calidad coherente.
Desde una perspectiva de la infraestructura, tener menos opciones tecnológicas elimina la varianza en las herramientas y facilita la detección del desfase de configuración. El mantenimiento también será más fácil. Si alinea opciones con el conjunto de aptitudes existente del equipo, el equipo puede adoptarlas fácilmente.
Desafío de Contoso
- La versión local de la carga de trabajo usó una combinación de scripts y pasos manuales para compilar la infraestructura e implementar la aplicación en todos los entornos. Al principio del proceso de migración de Azure, el equipo realizó modificaciones en los scripts imperativos existentes para dirigirse a la nueva plataforma para que pudieran reutilizar tanto como sea posible el código base de automatización existente. Este enfoque también se adoptó debido a una falta de experiencia con tecnologías de Azure e IaC como Bicep.
- A medida que avanzó la migración y el equipo se familiarizó con la plataforma, quedaron convencidos de que el uso de un enfoque IaC con Bicep iba a ser una mejor solución a largo plazo.
Aplicación del enfoque y los resultados
- Sin conocimientos internos, el equipo contrató a contratistas experimentado para realizar el trabajo de migrar y ampliar los scripts de automatización de implementación para la carga de trabajo. Estos trabajaron junto con el equipo de desarrollo durante las fases iniciales del proyecto, al tiempo que proporcionaban la transferencia de conocimiento al resto del equipo.
- La implementación basada en Bicep resultante proporciona una manera más confiable, manejable y eficaz de aprovisionar la infraestructura en Azure. El código ahora es más legible y fácil de mantener, con una gran compatibilidad con herramientas en VSCode. También es totalmente idempotente y simplifica la administración del estado, que nunca se pudo lograr completamente con la versión anterior o imperativa.
Tratar la IaC igual que el código de la aplicación
Siga las recomendaciones de software para el desarrollo y el mantenimiento de IaC: Modularice en moderación, evite abstracciones personalizadas o de bajo valor y siga un enfoque en capas para reflejar diferentes ciclos de vida. Forme capas fundamentales en las que las capas inferiores permanecen constantes y las capas superiores cambian según sea necesario.
Los artefactos de implementación, como archivos binarios de aplicación, plantillas de IaC y parámetros, forman parte de la superficie expuesta a ataques. Aplique garantías, como la administración de secretos, el control de acceso y otros principios del pilar seguridad.
Los artefactos experimentan el mismo nivel de rigor de ingeniería que el código de aplicación. Los controles de calidad a través de revisiones y pruebas del mismo nivel le proporcionan confianza en la implementación.
Un enfoque en capas facilita el mantenimiento y crea límites que establecen líneas claras de responsabilidad.
Agregar controles de seguridad a artefactos ayuda a proteger el sistema durante el proceso de implementación.
Desafío de Contoso
- El equipo del proyecto tenía un presupuesto generoso al principio del esfuerzo de migración, por lo que reclutaron contratistas muy experimentados que entregaron un trabajo de alta calidad y en un breve período de tiempo. Los contratistas usaron un repositorio independiente para su desarrollo. Dicho repositorio no se auditó de manera periódica para la seguridad, pero el repositorio de código de aplicación principal sí.
- El equipo está preparándose para publicar un rediseño importante de la solución, y el código de implementación necesita cambios significativos. Debido a una escasez de recursos de desarrollo, dos practicantes realizan el último lote de cambios. Cuando se llama a uno de los desarrolladores sénior del equipo para ayudar a los practicantes, observa varias confirmaciones en el repositorio que no están a la par con los estándares de desarrollo del equipo, incluido tener secretos de aplicación como claves de API codificadas de forma rígida en el código base.
Aplicación del enfoque y los resultados
- El equipo decide mover el código base de compilación e implementación al mismo repositorio usado para el código de aplicación y empezar a aplicar el mismo nivel de rigor de ingeniería que otras áreas del código base. El código mejora al nivel de los estándares del equipo antes de la primera confirmación, se quitan los secretos de aplicación, y todos los demás estándares y herramientas de calidad del equipo se aplican a él.
- Como resultado, el equipo ha protegido esta sección del código base al tiempo que ha aumentado la calidad del código. Al avanzar, los cambios en esta área del código base seguirán los mismos estándares y aprovecharán las mismas herramientas que se usan para el código base de la aplicación principal, incluidas las revisiones de código del mismo nivel y el examen automatizado del código con herramientas de calidad y seguridad.
Estandarizar las implementaciones en un único manifiesto
Desarrolle un manifiesto de implementación común que se use en todos los entornos. Use ese manifiesto como mecanismo predeterminado para proyectos de tipo greenfield, actualizaciones incrementales de cargas de trabajo o recuperación ante desastres.
La aplicación de este enfoque le permitirá quitar la sobrecarga de mantener varios recursos.
Si hay un desastre, la recuperación será rápida y confiable porque puede implementar un manifiesto probado y probado en lugar de crear un entorno improvisado.
Desafío de Contoso
- Contoso Manufacturing usa una canalización totalmente automatizada para implementar la infraestructura, el código de aplicación y los cambios de configuración en el entorno de desarrollo y producción. La aplicación está configurada para que sea de alta disponibilidad en una sola región. La mayoría de los componentes de la aplicación no tienen estado, excepto la base de datos MySQL. La base de datos tiene una copia de seguridad según lo dictado por el RTO/RPO establecido, y la copia de seguridad se replica en una región secundaria.
- Si se produce un error grave o importante en la región primaria, el equipo planea crear un nuevo entorno para hospedar la aplicación en la región secundaria. Durante un simulacro planeado para probar los procedimientos de recuperación ante desastres, los scripts de implementación producen un error al intentar volver a crear el entorno en la región secundaria debido a la falta de disponibilidad de varios recursos y otras limitaciones de servicio.
Aplicación del enfoque y los resultados
- El equipo mitiga los problemas que encontraron al intentar aprovisionar en la región secundaria reemplazando el uso de algunos recursos por SKU equivalentes que están disponibles en ambas regiones y haciendo que algunas opciones se puedan configurar para que un valor diferente, pero válido, se pueda usar en la región secundaria.
- El ejercicio ha aumentado la confianza del equipo en su capacidad de recuperarse ante errores graves de infraestructura.