Administración del análisis a escala de la nube
A día de hoy DevOps ha cambiado la cultura de la forma de pensar y trabajar de las personas. También ha acelerado la velocidad con la que las empresas generan valor al ayudar a individuos y organizaciones a desarrollar y mantener prácticas de trabajo sostenibles. DevOps combina desarrollo y operaciones, y a menudo se asocia con herramientas de ingeniería de software que admiten prácticas de integración continua (CI) y entrega continua (CD). Estas herramientas y prácticas incluyen administradores de código fuente (como Git, Apache Subversion o Control de versiones de Team Foundation) y administradores automáticos de compilación y entrega (como Azure Pipelines o Acciones de GitHub).
Combinar DevOps con la observabilidad es clave para ofrecer una plataforma ágil y escalable. DevOps ofrece a los equipos la capacidad de implementar el control de origen, canalizaciones de CI/CD, infraestructura como código, cargas de trabajo y automatización. La observabilidad permite a los empresarios, ingenieros de DevOps, arquitectos de datos, ingenieros de datos e ingenieros de confiabilidad de sitios detectar, prevenir y resolver problemas de forma automatizada y evitar tiempo de inactividad que, de lo contrario, interrumpirían la producción y la inteligencia artificial.
Control de código fuente
El control de código fuente garantiza que el código y las configuraciones se mantienen y que se realizan el seguimiento y el control de versiones de los cambios. La mayoría de los sistemas de control de código fuente también tienen procesos integrados para la revisión y el trabajo en distintas ramas de un repositorio de código. Actualmente, el tipo de control de código fuente más popular es Git, que es un sistema de controles de versiones distribuido que permite a los usuarios trabajar sin conexión y realizar la sincronización con repositorios centrales. Normalmente, los proveedores de Git también usan ramas y siguen las instrucciones de solicitud de incorporación de cambios para admitir el flujo de cambio y revisión.
Las ramas aíslan los cambios o desarrollos de características sin influir en otro trabajo que se produce al mismo tiempo. El uso de ramas debe promoverse para desarrollar características, corregir errores y experimentar de forma segura con nuevas ideas. Las solicitudes de incorporación de cambios combinan los cambios realizados desde una rama en la rama predeterminada y admiten un proceso de revisión controlado. Por motivos de seguridad, la rama principal debe usar solicitudes de incorporación de cambios para garantizar las revisiones de código.
Importante
Siga estas directrices para los repositorios de análisis a escala de la nube:
- Proteja la rama principal del repositorio mediante la aplicación de ramas y solicitudes de incorporación de cambios para garantizar un proceso de revisión controlado.
- Los repositorios de Azure DevOps o GitHub deben usarse para el control de código fuente con la finalidad de realizar un seguimiento de los cambios en el código fuente y permitir que varios miembros del equipo desarrollen código al mismo tiempo.
- El código de la aplicación y las configuraciones de la infraestructura se deben insertar en un repositorio.
Canalizaciones de CI/CD
La integración continua permite a los equipos probar y compilar automáticamente el código fuente y permite iteraciones rápidas y bucles de comentarios para garantizar una alta calidad del código en la implementación continua. Las canalizaciones son formas de configurar la integración continua de los cambios (código de software o código de infraestructura) y la implementación continua de los cambios empaquetados o compilados. Esto también se conoce como compilación y lanzamiento. La implementación continua describe la implementación automática de aplicaciones en uno o varios entornos. La implementación continua sigue a un proceso de integración continua y usa pruebas de integración para validar toda la aplicación.
Las canalizaciones pueden contener varias fases con diversas tareas y puede tener flujos de aprobación simples y complejos para garantizar el cumplimiento y la validación. En función de las preferencias, las canalizaciones también se pueden configurar con varios desencadenadores automáticos. En el caso de la implementación de inteligencia artificial y escala empresarial, los pasos de producción siempre deben tener aprobación humana previa, que se basa en el modelo de operación. Las canalizaciones de CI/CD se deben basar en Acciones de GitHub o Azure Pipelines, y deben ser desencadenadores automatizados.
Infraestructura como código
El término código de IaC suele generar preocupaciones para el personal de TI sin la experiencia en desarrollo, pero la opción IaC no hace referencia a la escritura de código de la manera en que lo hacen los desarrolladores de software típicos. Sin embargo, adopta muchas de las herramientas y los principios de los procesos de desarrollo de software para proporcionar la infraestructura en un formato predecible.
La opción IaC ayuda a aprovisionar, configurar y administrar la infraestructura como parte de una canalización de DevOps con controles de cambios completos, historial de auditoría, pruebas, validaciones y procesos de aprobación, lo que garantiza que las tareas se puedan delegar en los roles adecuados para el proyecto sin poner en peligro la seguridad y el cumplimiento.
Los dos enfoques de IaC son el declarativo y el imperativo:
El declarativo hace referencia a especificar el estado deseado de la infraestructura y hacer que un motor de orquestación ejecute las acciones necesarias para lograr el estado deseado. En Azure, esto se hace con las plantillas de Azure Resource Manager. Las capas de abstracción de terceros, como Terraform, también están disponibles para este enfoque.
El enfoque imperativo hace referencia a la ejecución de comandos específicos en un orden definido. Para Azure, esto se puede lograr con la interfaz de línea de comandos o PowerShell, pero los kits para desarrolladores de software del lenguaje de programación nativo, como .NET, Python y Java, también están disponibles si se requieren soluciones integradas.
En las plantillas de Azure Resource Manager, el aprovisionamiento principal se encuentra en la sección de recursos, y la configuración de los recursos individuales se define en una sección de propiedades. Para una instancia de Azure Data Lake Storage Gen2, la configuración es similar a la siguiente:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Importante
Todas las capas de análisis a escala de la nube, como la zona de aterrizaje de administración de datos, las zonas de aterrizaje de datos o las aplicaciones de datos, que crean productos de datos, deben definirse con un lenguaje declarativo como Azure Resource Manager o Terraform, insertarse en un repositorio e implementarse a través de canalizaciones de CI/CD. Esto permite que los equipos realicen un seguimiento y creen una versión de los cambios en la infraestructura y la configuración del ámbito de Azure, al mismo tiempo que admiten la automatización de distintos niveles de arquitectura de forma ágil. Esta guía lleva a los equipos a usar repositorios de Git para tener siempre visibilidad sobre el estado de ámbitos específicos de Azure.
Flujos de trabajo y automatización
Los equipos deben usar canalizaciones de CI/CD en varias fases para asegurarse de que el código desarrollado está libre errores y listo para producción. Algunos procedimientos recomendados son tener un entorno de desarrollo, un entorno de pruebas y un entorno de producción. Estas fases también deben reflejarse en Azure usando servicios independientes para cada entorno.
El equipo de la plataforma es responsable de proporcionar y mantener plantillas de implementación para escalar rápidamente en una organización y simplificar las implementaciones para los equipos que no están familiarizados con la opción IaC. Estas plantillas sirven de base de referencia para nuevos artefactos en el escenario y deben mantenerse con el tiempo para representar los procedimientos recomendados y los estándares comunes en la empresa.
Las implementaciones de prueba y producción solo se deben administrar a través de una canalización de CI/CD y una conexión de servicio con permisos elevados para aplicar procedimientos recomendados comunes (por ejemplo, plantillas de Azure Resource Manager).
Precaución
Los equipos de aplicaciones de datos solo deben tener acceso de lectura a entornos de prueba y producción, y las implementaciones en estos entornos solo se deben ejecutar a través de canalizaciones de CI/CD y conexiones de servicio con permisos elevados. Para acelerar la ruta de acceso a producción, los equipos de aplicaciones de datos deben tener acceso de escritura al entorno de desarrollo.