Compartir a través de


Administración del análisis a escala de la nube

En la actualidad, DevOps ha cambiado la cultura de cómo las personas piensan y trabajan, acelerando la velocidad a la que las empresas se dan cuenta de valor al ayudar a las personas y organizaciones a desarrollar y mantener prácticas de trabajo sostenibles. DevOps combina el desarrollo y las operaciones, y a menudo está asociado a 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 de compilación y entrega automáticas (como Azure Pipelines o Acciones de GitHub).

DevOps combinado con observabilidad es clave para proporcionar una plataforma ágil y escalable. DevOps ofrece a los equipos la capacidad de implementar el control de código fuente, las canalizaciones de CI/CD, la infraestructura como código, flujos de trabajo y automatización. Aunque la observabilidad permite a los propietarios de negocios, ingenieros de DevOps, arquitectos de datos, ingenieros de datos e ingenieros de confiabilidad de sitios detectar, predecir, evitar y resolver problemas de forma automatizada, ayudando a prevenir el tiempo de inactividad que podría interrumpir el análisis de 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 conserven y que se realice un seguimiento de los cambios y versiones. La mayoría de los sistemas de control de código fuente también tienen procesos integrados para revisar y trabajar en diferentes ramas de un repositorio de código. Actualmente, el tipo de control de código fuente más popular actualmente es Git, que es un sistema de controles de versión distribuido que permite a los usuarios trabajar sin conexión y sincronizar con repositorios centrales. Normalmente, los proveedores de Git también utilizan ramas y siguen las directrices de pull request para respaldar el flujo de cambio y revisión.

Las ramas aíslan los cambios o los desarrollos de características sin afectar a otros trabajos que se producen 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 de una rama en la rama predeterminada y admiten un proceso de revisión controlado. Con fines de seguridad, la rama principal debe usar solicitudes de incorporación de cambios para garantizar las revisiones de código.

Importante

Siga estas instrucciones para repositorios de análisis a escala en la nube:

  • Proteja la rama principal del repositorio estableciendo políticas de ramas y solicitudes de incorporación de cambios para garantizar procesos de revisión controlados.
  • Los repositorios de Azure DevOps o GitHub deben usarse para el control de código fuente para realizar un seguimiento de los cambios en el código fuente y permitir que varios miembros del equipo desarrolle código al mismo tiempo.
  • El código de aplicación y las configuraciones de infraestructura deben registrarse en un repositorio.

Canalizaciones de CI/CD

CI permite a los equipos probar y compilar código fuente automáticamente y permite iteraciones rápidas y bucles de comentarios para garantizar una alta calidad de código en CD. Las pipelines son maneras de configurar la CI de cambios (tanto del software como de la infraestructura) y CD de los cambios empaquetados/compilados. Esto también se conoce como compilación y versión. CD describe la implementación automática de aplicaciones en uno o varios entornos. El CD suele seguir un proceso de CI y usa pruebas de integración para validar toda la aplicación.

Las canalizaciones pueden contener varias fases con varias tareas y pueden tener flujos de aprobación sencillos a 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 a escala empresarial e inteligencia artificial, los pasos de producción siempre deben tener la aprobación previa humana y esto está integrado en el modelo de operación. Las canalizaciones de CI/CD deben construirse utilizando GitHub Actions o Azure Pipelines, y deben contar con desencadenadores automáticos.

Infraestructura como código

El término código en IaC suele plantear preocupaciones para el personal de TI sin experiencia en desarrollo, pero IaC no hace referencia a escribir código como lo hacen los desarrolladores de software. Sin embargo, adopta muchas de las mismas herramientas y principios de los procesos de desarrollo de software para ofrecer infraestructura en un formato predecible.

IaC ayuda a la infraestructura a aprovisionar, configurar y administrar como parte de una canalización de DevOps con controles de cambio completos, historial de auditoría, pruebas, validaciones y procesos de aprobación, lo que garantiza que las tareas se puedan delegar a los roles adecuados para el proyecto sin poner en peligro la seguridad y el cumplimiento.

Los dos enfoques de IaC son declarativos e imperativos:

  • Declarativo se refiere a especificar el estado deseado de la infraestructura y a permitir que un motor de orquestación ejecute las acciones necesarias para alcanzarlo. En Azure, esto se realiza con 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 la línea de comandos o PowerShell, pero los kits de desarrolladores de software de lenguaje de programación nativo, por ejemplo, .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 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, almacenados en un repositorio e implementados a través de canalizaciones de CI/CD. Esto permite a los equipos realizar un seguimiento de los cambios en la infraestructura y la configuración del ámbito de Azure, a la vez que admiten diferentes niveles de arquitectura para automatizarse 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 no tenga errores y esté listo para su despliegue en producción. Algunos procedimientos recomendados son tener un entorno de desarrollo, un entorno de prueba y un entorno de producción. Estas fases también deben reflejarse en Azure mediante servicios independientes para cada entorno.

El equipo de plataforma es responsable de proporcionar y mantener plantillas de implementación para escalar rápidamente dentro de una organización y simplificar las implementaciones para los equipos que no están familiarizados con IaC. Estas plantillas sirven como línea base para los nuevos artefactos dentro del escenario y deben mantenerse con el tiempo para representar procedimientos recomendados y estándares comunes dentro de la empresa.

Las implementaciones para probar y producir solo deben administrarse 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 deben ejecutarse 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.

Pasos siguientes

Automatización de la plataforma