Muy buenas, me llamo Luis y en esta ocasión les traigo otro nuevo post.
Índice
Presentando CI / CD
La implementación de aplicaciones puede ser una tarea tediosa, ya que las personas históricamente tenían que escribir sus propios scripts si querían evitar largos procesos manuales. Cada proyecto y cada organización se ejecuta en una infraestructura diferente, por lo que durante mucho tiempo, nunca hubo una manera fácil de automatizar estos procesos. Para cada implementación, tendrían que repetirse los mismos procesos, por lo que llevó mucho tiempo. Afortunadamente, la adopción generalizada de la computación en la nube y la inversión en DevOps ha cambiado esto. Ahora es más fácil y económico que nunca automatizar completamente con CI (integración continua) y CD (implementación continua).
El proceso de implementación
Paso a paso
Para comenzar, debemos desglosar el proceso de implementación paso a paso. Esto deja en claro exactamente lo que debe hacer y en qué orden. A veces, las implementaciones requieren un paso, mientras que otras pueden requerir decenas de pasos. Combinados, todos los pasos formarán una tubería.
Para un sitio web estático
Al implementar un sitio web estático, en esencia, el proceso parece muy básico. Los archivos simplemente deben copiarse en la ubicación correcta en la máquina host. Hay varios protocolos disponibles para hacer esto, ya sea SFTP, FTPS, HTTPS o cualquier otro. El protocolo utilizado dependerá de su proveedor de alojamiento.
Lo más probable es que esté utilizando un generador de sitios web estático, por lo que querrá anteponer los pasos para transformar su entrada en sus archivos de salida. Las tareas necesarias para esto dependen de su pila tecnológica. En un nivel genérico, las tareas involucradas incluirán la instalación de dependencias, navegar por el sistema de archivos y ejecutar comandos específicos de la herramienta.
Azure Pipelines
Anatomía de la tubería
Canalizaciones de Azure es una plataforma nativa de la nube, extensible y de alto nivel, diseñada para automatizar completamente la integración e implementación de código. Azure Pipelines ofrece canalizaciones tanto de compilación como de lanzamiento, con canalizaciones de compilación originalmente diseñadas para la integración continua y las canalizaciones de lanzamiento para la implementación continua. Las canalizaciones de compilación han evolucionado y se han optimizado tanto para la integración como la implementación continuas, y han cambiado de nombre a canalizaciones de varias etapas, mientras que las canalizaciones de lanzamiento son ahora una característica heredada.
Al crear canalizaciones de Azure, especifica las etapas, en las que define los trabajos ejecutables, que se componen de una o más tareas. Esta es una forma de seccionar sus canalizaciones, para que pueda responder a diferentes resultados para cada etapa de su canalización. Azure Pipelines viene con cientos de tareas preconfiguradas y le permite ejecutar scripts personalizados o incluso crear sus propias extensiones de tareas.
También podría valer la pena mencionar que puede configurar diferentes entornos para sus compilaciones y ejecutarlos en diferentes máquinas. Es más fácil ejecutar compilaciones en máquinas alojadas en Azure, pero si lo desea, puede configurar agentes para ejecutarlas en sus propias máquinas.
Agentes
Los agentes de Azure Pipelines se instalan en las máquinas que ejecutan sus compilaciones y versiones. Es útil comprender cómo se configuran los agentes, para que pueda definir correctamente sus canalizaciones.
Los agentes de trabajo para canalizaciones de compilación ejecutan una compilación en un directorio numerado $ (Agent.BuildDirectory), que por defecto contiene tres subdirectorios: a
$ (Build.ArtifactStagingDirectory), b
$ (Build.BinariesDirectory) y s
$ (Build.SourcesDirectory). Los agentes tienen variables predefinidas, a la que se puede hacer referencia desde sus canales de compilación, incluidas las variables enumeradas para hacer referencia a estos directorios.
Los agentes se configuran de forma ligeramente diferente para las versiones clásicas. Contienen un directorio numerado que tiene como prefijo una r, siendo el único subdirectorio a
$ (System.ArtifactsDirectory). Del mismo modo, con las canalizaciones de compilación, las canalizaciones de versiones clásicas también tienen un conjunto de variables predefinidas.
Etapas y trabajos
Ya sea que opte por utilizar pipelines de varias etapas o versiones clásicas para la implementación, debe decidir cómo estructurar sus pipelines. Las etapas se entienden como una agrupación de trabajo de alto nivel, siendo los trabajos una unidad de trabajo que se ejecuta en una máquina. Por lo tanto, es común dividir su canalización en etapas como compilación, prueba y lanzamiento, mientras que los trabajos pueden ser transformar archivos, cargar archivos a la red o notificar a los usuarios sobre actualizaciones. Además de los trabajos estándar, Azure Pipelines tiene trabajos de implementación especiales.
Artefactos
En las canalizaciones de Azure, cada trabajo se ejecuta en una máquina diferente, por lo que a menudo los archivos deben transferirse de alguna manera entre etapas y trabajos. Esto se hace más fácilmente con artefactos, que son un conjunto de tareas para transferir archivos en sus compilaciones.
Un pipeline en la práctica
Estructurando nuestro pipeline
Para un sitio web estático, queremos tomar el código en nuestro repositorio de control de fuente y luego transformarlo en un conjunto de archivos que están listos para implementar. Después de eso, queremos implementar estos archivos en nuestro servidor web. Es lógico agrupar esto en dos etapas: compilación y lanzamiento. Es probable que la etapa de compilación solo requiera un trabajo, ya que construir su proyecto y transformar sus archivos de entrada es una unidad de trabajo. Los trabajos de implementación están destinados a ejecutarse en toda la implementación, por lo que la etapa de lanzamiento también debería requerir un trabajo, ya que lo más probable es que solo tenga un objetivo de implementación.
Configurar la canalización
Si aún no tiene uno, cree un Azure DevOps organización y proyecto. Navegue a la pestaña Pipelines en su proyecto de Azure DevOps, luego seleccione New pipeline.
Deberá conectarse a su repositorio de control de código fuente como primer paso para configurar su canalización. A continuación, seleccione una plantilla de canalización; es más fácil comenzar con la plantilla de inicio. Una vez que haya hecho eso, se le presentará el editor de canalización. Las canalizaciones de Azure están configuradas en YAML, aunque Azure DevOps contiene un asistente útil que, sinceramente, hace las cosas 10 veces más fáciles. Para cada tarea que use, eche un vistazo a la documentación si tiene dificultades para comprender la configuración requerida.
La definición de canalización contiene un desencadenante, que es la rama que se supervisa en busca de cambios, para comenzar una nueva compilación. Probablemente querrás mantener esto como maestro. También se define un grupo, que especifica las máquinas del agente en las que se ejecutará. Los grupos se pueden definir en la raíz, por etapa o por trabajo. Tenga en cuenta que si realiza la implementación en Azure, algunas tareas son solo para Windows.
Puede notar que la plantilla contiene definiciones de pasos, pero no etapas ni trabajos. Esto se debe a que si solo tiene una etapa y un trabajo, no es necesario definirlos explícitamente en la canalización. Comience eliminando todos los pasos y defina las etapas y trabajos que ha planificado. También me gusta definir los nombres de artefactos como variables, para los artefactos que crearé para transferir archivos entre cada etapa.
trigger: - masterpool: vmImage: 'windows-latest'variables: ARTIFACT_NAME: DevelopMomentumWebstages: - stage: Build displayName: Build jobs: - job: Transform displayName: Transform Input- stage: Release displayName: Release dependsOn: Build jobs: - deployment: DeployToStorage displayName: Deploy to Azure Storage
Las etapas se ejecutarán en paralelo, a menos que se definan como dependientes de otra etapa. Puede definir las condiciones para que se ejecute cada etapa. La condición predeterminada es que sus etapas dependientes se hayan completado con éxito.
La etapa de construcción
Habiendo conectado su repositorio, para trabajos estándar, el agente copiará su código en el s
directorio y configúrelo como directorio de trabajo. Por lo tanto, lo primero que debe considerar es la instalación de dependencias de compilación. Los agentes alojados en Azure ya tienen una gran cantidad de software instalado, lo que significa que es posible que no necesite definir ningún paso para esto. Puede ver el software incluido haciendo clic en los enlaces de la tabla de agentes en la Documentación de Microsoft.
En este ejemplo, construiré un sitio web estático usando .NET Core y Statiq, por lo tanto, necesito ejecutar los comandos de la CLI. dotnet restore
, dotnet build
entonces dotnet run
. Azure Pipelines viene con una tarea DotNetCoreCLI
, que usaré. Para cada tarea, necesito proporcionar la ruta del proyecto, que se puede colocar en una variable. Statiq solo genera archivos si el directorio de trabajo está configurado en el directorio que contiene la carpeta de entrada, por lo que esto debe definirse en la tarea. Algo de lo que no me di cuenta al principio, fue incluso con el directorio de trabajo definido, la ruta del proyecto en el DotNetCoreCLI@2
La tarea debe definirse en relación con el s
directorio.
- job: Transform displayName: Transform Input variables: project: 'src/Blog.csproj' steps: - task: DotNetCoreCLI@2 displayName: Restore inputs: command: 'restore' projects: $(project) - task: DotNetCoreCLI@2 displayName: Build inputs: command: 'build' projects: $(project) workingDirectory: 'src' - task: DotNetCoreCLI@2 displayName: Generate inputs: command: 'run' projects: $(project) workingDirectory: 'src'
Ahora necesitamos publicar el artefacto, que es la carpeta de salida que genera Statiq. Por lo general, los artefactos deben organizarse antes de su publicación, lo que implica copiarlos en el a
directorio. Deberías hacer esto con el CopyFiles
tarea, que toma las carpetas de origen y destino como parámetros. La publicación de artefactos se puede realizar con el PublishBuildArtifacts
o PublishPipelineArtifact
tarea, sin embargo, se recomienda utilizar artefactos de canalización, ya que están pensados como un reemplazo para construir artefactos.
- task: CopyFiles@2 displayName: Copy inputs: SourceFolder: '$(Build.SourcesDirectory)/src/output' Contents: '**' TargetFolder: '$(Build.ArtifactStagingDirectory)/output'- task: PublishPipelineArtifact@1 displayName: Share inputs: targetPath: '$(Build.ArtifactStagingDirectory)/output' artifact: '$(ARTIFACT_NAME)' publishLocation: 'pipeline'
La etapa de lanzamiento
La etapa de construcción ahora está definida, por lo que podemos ver la etapa de lanzamiento. Hemos definido un trabajo de implementación, al que actualmente le falta un entorno y una estrategia.
Múltiples entornos pueden ser útiles al crear aplicaciones receptivas a gran escala, aunque en este caso no tenemos que preocuparnos por ellos. Solo queremos un único entorno vacío, que podemos obtener proporcionando cualquier nombre de entorno.
Para finalizar, necesitamos definir la estrategia de implementación, que es un proceso que puede contener los siguientes ganchos:
preDeploy
– utilizado para la inicialización de recursosdeploy
– realiza el despliegue realrouteTraffic
– configuración para servir versión actualizadapostRouteTraffic
– destinado a la supervisión de la salud / notificaciones de usuarioon: failure
– realizar retrocesoson: success
– destinado a la limpieza
Hay tres estrategias de implementación diferentes, aunque la única que debe preocuparle es runOnce
. Esta estrategia es la más simple de las tres, ya que ejecuta cada etapa de implementación una vez por compilación.
jobs: - deployment: DeployToStorage displayName: Deploy to Azure Storage environment: developmomentum-production strategy: runOnce:
En mi caso de ejemplo, el sitio web debe implementarse en Azure Storage, lo que implica eliminar los archivos antiguos y luego copiar los nuevos en el contenedor de almacenamiento. El sitio web utiliza Azure CDN y Cloudflare como proveedor de DNS, los cuales almacenan en caché el sitio web. Estas cachés deben borrarse en cada implementación para que el tráfico se sirva correctamente.
variables: AZURE_STORAGE_ACCOUNT: developmomentumstrategy: runOnce: deploy: steps: - task: AzureCLI@2 displayName: 'Delete Existing Files' inputs: azureSubscription: 'Pay-As-You-Go (8df2aaab-fa1b-4031-9a60-43ebee006b38)' scriptType: 'pscore' scriptLocation: 'inlineScript' inlineScript: 'az storage blob delete-batch -s `$web --account-name $(AZURE_STORAGE_ACCOUNT) --auth-mode login' - task: AzureFileCopy@4 displayName: 'Copy Files to Storage' inputs: azureSubscription: 'Pay-As-You-Go (8df2aaab-fa1b-4031-9a60-43ebee006b38)' SourcePath: '$(Pipeline.Workspace)/$(ARTIFACT_NAME)/*' Destination: 'AzureBlob' storage: '$(AZURE_STORAGE_ACCOUNT)' ContainerName: '$web' routeTraffic: steps: - task: PurgeAzureCDNEndpoint@2 displayName: 'Purge Azure CDN Endpoint' inputs: ConnectedServiceNameSelector: ConnectedServiceNameARM ConnectedServiceNameARM: 'Pay-As-You-Go (8df2aaab-fa1b-4031-9a60-43ebee006b38)' ResourceGroupName: developmomentum EndpointName: developmomentum ProfileName: developmomentum continueOnError: true - task: tfx-cloudflare-purge@1 displayName: 'Purge Cloudflare Cache' inputs: username: 'adamshirt@outlook.com' apikey: '$(CLOUDFLARE_API_KEY)' zonename: developmomentum.com continueOnError: true
En mi definición, estoy usando una tarea de la CLI de Azure, que requiere un script en línea. Los scripts y las tareas basadas en scripts pueden incluir variables y las canalizaciones de Azure las convertirán automáticamente en variables de entorno, que se pasarán al script.
Estoy usando un par de tareas de extensión para la purga de caché, que se pueden encontrar en el asistente de tareas. Estas tareas deben instalarse antes de poder usarlas en sus canalizaciones. También estoy definiendo que los pasos de purga de caché no deben interrumpir la canalización, incluso si fallan.
La tarea de purga de caché de Cloudflare requiere una clave API, que debe mantenerse en secreto. Puede definir variables secretas agregando una variable en el menú Variables, seleccionando Mantener este valor en secreto.
Las variables secretas no se pueden pasar a los scripts. Por este motivo, la autenticación de la CLI de Azure no se puede realizar mediante claves. Cada suscripción de Azure que he definido es una referencia a una conexión de servicio que se ha configurado.
Autenticación
Las conexiones de servicio permiten que sus canalizaciones se autentiquen con aplicaciones externas. Configurar una conexión de servicio en Azure DevOps es fácil. En su proyecto, vaya a Configuración del proyecto y luego seleccione Conexiones de servicio. Cree una conexión de servicio seleccionando Nueva conexión de servicio y siguiendo el asistente.
Permisos externos
Con una conexión de servicio configurada, es posible que deba configurar permisos en su servicio externo. Estoy ejecutando un comando de la CLI de Azure contra Azure Storage, que requiere que la conexión del servicio tenga los permisos necesarios para eliminar archivos de Azure Storage.
Los productos de Azure administran permisos con Control de acceso (IAM), que le permite asignar roles a varias entidades en Azure. Con las asignaciones de funciones, puede otorgar a su conexión de servicio los permisos necesarios.
Comprometiendo la tubería
Con la canalización de compilación ahora definida, puede guardarla, lo que confirmará el azure-pipelines.yml
archivo a la raíz de su repositorio. Recomiendo seleccionar Crear una nueva rama para esta confirmación, ya que es posible que deba modificar su configuración inicial, que se hace mejor en una rama separada. A continuación, podrá ejecutar su canal de compilación.
Objetivos de implementación comunes
Implementación en Azure
Al ser un producto de la marca Azure, Azure Pipelines tiene una integración increíble con Azure. Hay tantos tareas nativas y la implementación en Azure es fácil. En lugar de entrar en demasiados detalles, le indicaré que lea la documentación para las tareas específicas, que es extensa.
Implementación en AWS
Azure Pipelines tiene un gran soporte para la implementación en AWS, a través del Extensión de herramientas de AWS. La instalación de la extensión para su organización hará que un montón de tareas de AWS estén disponibles para sus canalizaciones. los guía del usuario para la extensión contiene una referencia de tarea, que detalla los parámetros disponibles para cada tarea.
Gracias por leer.
Añadir comentario