La informática sin servidor consiste en eliminar los servidores, la infraestructura y los sistemas operativos, lo que permite a los desarrolladores centrarse en el desarrollo de aplicaciones. Una sólida CI/CD (Integración continua/Entrega continua) de estas aplicaciones permite a las empresas distribuir versiones de software completamente probadas e integradas en cuestión de minutos de desarrollo. Proporciona una red troncal del entorno DevOps moderno.
¿Qué significa realmente CI/CD?
- La integración continua (CI) permite a los equipos de desarrollo integrar los cambios de código en un repositorio compartido de forma casi instantánea. Esta capacidad, junto con las pruebas y compilaciones automatizadas antes de que se integren los cambios, garantiza que solo el código de aplicación totalmente funcional está disponible para la implementación.
- La entrega continua (CD) permite que los cambios en el código fuente, la configuración, el contenido y otros artefactos se entreguen a producción y estén listos para implementarse en los usuarios finales, de la manera más rápida y segura posible. El proceso mantiene el código en un estado implementable en todo momento. Un caso especial de esto es la implementación continua, que incluye la implementación real para los usuarios finales.
En este artículo se describe una canalización de CI/CD para el front-end web de una implementación de referencia sin servidor. Esta canalización se desarrolla mediante los servicios de Azure. El front-end web muestra una aplicación web moderna, con JavaScript del lado cliente, varias API del lado servidor reutilizables y marcado precompilado, que también se denomina Jamstack. Puede encontrar el código en este repositorio de GitHub. El archivo Léame describe los pasos para descargar, compilar e implementar la aplicación.
En el siguiente diagrama se describe la canalización de CI/CD que se usa en este front-end de ejemplo:
En este artículo no se explica qué es la implementación de back-end.
Requisitos previos
Para trabajar con esta aplicación de ejemplo, asegúrese de que dispone de lo siguiente:
- Una cuenta de GitHub.
- Una cuenta de Azure. En caso de no tener ninguna, puede probar con una cuenta gratuita de Azure.
- Una organización de Azure DevOps. Si no tiene una, puede probar con un plan básico, que incluye servicios de DevOps como Azure Pipelines.
Usar un sistema de control de versiones en línea
Los sistemas de control de versiones realizan un seguimiento de los cambios en el código fuente y los controlan. Mantener el código fuente en un sistema de control de versiones en línea permite que varios equipos de desarrollo puedan colaborar. También es más fácil de mantener que un control de versiones tradicional local. Estos sistemas en línea se pueden integrar fácilmente con los principales servicios de CI/CD. Puede crear y mantener el código fuente en varios directorios, junto con archivos de compilación y configuración, en lo que se denomina un repositorio.
Los archivos de proyecto de esta aplicación de ejemplo se guardan en GitHub. Si no tiene una cuenta de GitHub, lea esta documentación para empezar a trabajar con los repositorios de GitHub.
Automatización de la compilación y la implementación
El uso de un servicio de CI/CD, como Azure Pipelines puede servir para automatizar los procesos de compilación e implementación. Puede crear varias fases en la canalización, donde cada una de ellas se ejecuta según el resultado de la anterior. Las fases se pueden ejecutar en un contenedor de Windows o Linux. El script debe asegurarse de que las herramientas y los entornos están configurados correctamente en el contenedor. Azure Pipelines puede ejecutar diversas herramientas de compilación y puede trabajar con bastantes sistemas de control de versiones en línea.
Integrar herramientas de compilación
Las herramientas de compilación modernas pueden simplificar el proceso de compilación y proporcionar funciones como la configuración previa, la minificación de los archivos JavaScript y la generación de sitios estática. Los generadores de sitios estáticos pueden compilar archivos de marcado antes de implementarlos en los servidores de hospedaje, lo que da lugar a una experiencia de usuario rápida. Puede seleccionar entre una variedad de estas herramientas, según el tipo de lenguaje de programación y plataforma de la aplicación, así como las funciones adicionales necesarias. En este artículo se proporciona una lista de las herramientas de compilación populares para una aplicación moderna.
El ejemplo es una aplicación React, creada mediante Gatsby.js, que es un generador de sitios estáticos y un marco de desarrollo de front-end. Estas herramientas se pueden ejecutar localmente durante las fases de desarrollo y pruebas y, después, integrarse con Azure Pipelines para la implementación final.
En el ejemplo se usa el archivo gatsby-ssr.js para la representación y gatsby-config.js para la configuración del sitio. Gatsby convierte todos los archivos JavaScript en el subdirectorio pages
de la carpeta src
en archivos HTML. Los componentes adicionales van en el subdirectorio components
. En el ejemplo también se usa el complemento gatsby-plugin-typescript que permite usar TypeScript para la seguridad de tipos, en lugar de JavaScript.
Para más información sobre cómo configurar un proyecto de Gatsby, vea la documentación oficial de Gatsby.
Automatizar compilaciones
La automatización del proceso de compilación reduce los errores humanos que se pueden introducir en los procesos manuales. El archivo azure-pipelines.yml incluye el script para una automatización en dos fases. El archivo Léame de este proyecto describe los pasos necesarios para configurar la canalización de la automatización mediante Azure Pipelines. En las subsecciones siguientes se muestra cómo se configuran las fases de canalización.
Fase de compilación
Puesto que Azure Pipelines se integra con el repositorio de GitHub, cualquier cambio en el directorio del que se realiza el seguimiento de la rama principal desencadena la primera fase de la canalización, la de compilación:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- src/ClientApp
En el fragmento de código siguiente se muestra el inicio de la fase de compilación, que inicia un contenedor de Ubuntu para ejecutar esta fase.
stages:
- stage: Build
jobs:
- job: WebsiteBuild
displayName: Build Fabrikam Drone Status app
pool:
vmImage: 'Ubuntu-16.04'
continueOnError: false
steps:
Esto va seguido de tareas y scripts necesarios para compilar correctamente el proyecto. Entre ellas, figuran:
Instalar Node.js y configurar variables de entorno;
Instalar y ejecutar Gatsby.js que crea el sitio web estático:
- script: | cd src/ClientApp npm install npx gatsby build displayName: 'gatsby build'
Instalar y ejecutar una herramienta de compresión denominada brotli para comprimir los archivos compilados antes de la implementación:
- script: | cd src/ClientApp/public sudo apt-get install brotli --install-suggests --no-install-recommends -q --assume-yes for f in $(find . -type f \( -iname '*.html' -o -iname '*.map' -o -iname '*.js' -o -iname '*.json' \)); do brotli $f -Z -j -f -v && mv ${f}.br $f; done displayName: 'enable compression at origin level'
Calcular la versión de la compilación actual para la administración de memoria caché;
Publicar los archivos compilados para usarlos en la fase de implementación:
- task: PublishPipelineArtifact@1 inputs: targetPath: 'src/ClientApp/public' artifactName: 'drop'
Al completar correctamente la fase de compilación, se anula el entorno de Ubuntu y se desencadena la fase de implementación en la canalización.
Fase de implementación
La fase de implementación se ejecuta en un nuevo contenedor de Ubuntu:
- stage: Deploy
jobs:
- deployment: WebsiteDeploy
displayName: Deploy Fabrikam Drone Status app
pool:
vmImage: 'Ubuntu-16.04'
environment: 'fabrikamdronestatus-prod'
strategy:
runOnce:
deploy:
steps:
Esta fase incluye varias tareas y scripts de implementación para:
- Descargar los artefactos de compilación en el contenedor (lo que sucede automáticamente como consecuencia de usar
PublishPipelineArtifact
en la fase de compilación); - Grabar la versión de lanzamiento de la compilación y actualizar en el repositorio de GitHub;
- Cargar los archivos del sitio web en Blob Storage, en una nueva carpeta correspondiente a la nueva versión;
- Cambiar la red CDN para que apunte a esta nueva carpeta.
Los dos últimos pasos juntos replican una eliminación de caché, ya que los servidores perimetrales de la red CDN ya no pueden tener acceso a las carpetas más antiguas. En este fragmento de código se muestra cómo se consigue esto:
- script: |
az login --service-principal -u $(azureArmClientId) -p $(azureArmClientSecret) --tenant $(azureArmTenantId)
# upload content to container versioned folder
az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.html" --content-type "text/html"
az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js" --content-type "application/javascript"
az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js.map" --content-type "application/octet-stream"
az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.json" --content-type "application/json"
az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --pattern "*.txt" --content-type "text/plain"
# target new version
az cdn endpoint update --resource-group $(azureResourceGroup) --profile-name $(azureCdnName) --name $(azureCdnName) --origin-path '/$(releaseSemVer)'
AZURE_CDN_ENDPOINT_HOSTNAME=$(az cdn endpoint show --resource-group $(azureResourceGroup) --name $(azureCdnName) --profile-name $(azureCdnName) --query hostName -o tsv)
echo "Azure CDN endpoint host ${AZURE_CDN_ENDPOINT_HOSTNAME}"
echo '##vso[task.setvariable variable=azureCndEndpointHost]'$AZURE_CDN_ENDPOINT_HOSTNAME
displayName: 'upload to Azure Storage static website hosting and purge Azure CDN endpoint'
Implementaciones atómicas
La implementación atómica garantiza que los usuarios de su sitio web o aplicación siempre obtienen el contenido correspondiente a la misma versión.
En la canalización de CI/CD de ejemplo, el contenido del sitio web se implementa en el almacenamiento de blobs, que actúa como el servidor de origen para Azure CDN. Si los archivos se actualizan en la misma carpeta raíz en el BLOB, el sitio web se atenderá de manera incoherente. Este problema se resuelve al cargar en una nueva carpeta con versión, como se muestra en la sección anterior. Los usuarios obtienen todo o nada de la nueva compilación correcta, ya que la red CDN apunta a la nueva carpeta como origen, solo después de que todos los archivos se actualicen correctamente.
Las ventajas de este enfoque son las siguientes:
- Como el nuevo contenido no está disponible para los usuarios hasta que CDN apunta a la nueva carpeta de origen, se produce una implementación atómica.
- Puede revertir fácilmente a una versión anterior del sitio web si es necesario.
- Dado que el origen puede hospedar varias versiones del sitio web en paralelo, puede ajustar la implementación mediante técnicas como permitir la vista previa de determinados usuarios antes de obtener una disponibilidad más amplia.
Hospedar y distribuir a través de la nube
Una red de entrega de contenido (CDN) es un conjunto de servidores distribuidos que agilizan la entrega de contenido a los usuarios a través de una gran zona geográfica. Cada usuario obtiene el contenido del servidor más cercano. La red CDN accede a este contenido desde un servidor de origen y lo almacena en la memoria caché para servidores perimetrales en ubicaciones estratégicas. En el ejemplo de CI/CD de este artículo se usa Azure CDN, que apunta al contenido del sitio web hospedado en Azure Blob Storage como el servidor de origen. El almacenamiento de blobs está configurado para el hospedaje de sitios web estáticos. Para obtener una guía rápida sobre cómo usar Azure CDN con Azure Blob Storage, lea Inicio rápido: Integración de una cuenta de Azure Storage en Azure CDN.
Estas son algunas estrategias que pueden mejorar el rendimiento de la red CDN.
Comprimir el contenido
Comprimir los archivos antes de entregarlos mejora la velocidad de transferencia de archivos y aumenta el rendimiento de carga de página para los usuarios finales.
Existen dos formas de hacerlo:
Sobre la marcha en los servidores perimetrales de la red CDN. Esto mejora el consumo de ancho de banda en un porcentaje considerable, lo que hace que el sitio web sea mucho más rápido que sin compresión. Es relativamente fácil habilitar este tipo de compresión en Azure CDN. Puesto que está controlado por la red CDN, no puede elegir ni configurar la herramienta de compresión. Use esta compresión si el rendimiento del sitio web no es algo crítico.
Comprimir previamente antes de llegar a la red CDN, ya sea en el servidor de origen o antes de llegar al origen. La compresión previa mejora aún más el rendimiento en tiempo de ejecución del sitio web, ya que se realiza antes de que lo capture la red CDN. La canalización de CI/CD de ejemplo comprime los archivos compilados en la fase de implementación, mediante brotli, como se muestra en la sección sobre compilación anterior. Estas son las ventajas de usar la compresión previa:
- Puede usar cualquier herramienta de compresión con la que esté familiarizado y ajustar aún más la compresión. Las redes CDN pueden tener limitaciones en las herramientas que usan.
- Algunas redes CDN limitan los tamaños de archivo que se pueden comprimir sobre la marcha, lo que produce un impacto en el rendimiento de los archivos más grandes. La compresión previa no establece ningún límite en el tamaño del archivo.
- Al comprimir previamente en la canalización de implementación, se necesita menos almacenamiento en el origen.
- Esto es más rápido y eficaz que la compresión de la red CDN.
Para más información, consulte Mejora del rendimiento comprimiendo archivos en Azure CDN.
Aceleración de sitios dinámicos
El uso de la red CDN es ideal para el contenido estático, que se puede almacenar en caché de forma segura en los servidores perimetrales. Pero los sitios web dinámicos necesitan que el servidor genere contenido en función de la respuesta del usuario. Este tipo de contenido no se puede almacenar en caché en el perímetro, para lo que se necesita una solución integral más compleja que pueda acelerar la entrega de contenido. La aceleración de sitios dinámicos por Azure CDN es una solución de este tipo que mejora el rendimiento de las páginas web dinámicas.
Este ejemplo habilita la aceleración de sitios dinámicos como se muestra en esta sección del archivo Léame.
Administrar caché de sitios web
Las redes CDN usan el almacenamiento en caché para mejorar su rendimiento. La configuración y la administración de esta caché se convierte en una parte integral de la canalización de implementación. En la documentación de Azure CDN se muestran varias maneras de hacerlo. Puede establecer reglas de almacenamiento en caché en la red CDN, así como configurar el período de vida para el contenido en el servidor de origen. El contenido web estático puede almacenarse en caché durante mucho tiempo, ya que es posible que no cambie demasiado con el tiempo. Esto reduce la sobrecarga de tener acceso al servidor de origen único para cada solicitud de usuario. Para más información, consulte Cómo funciona el almacenamiento en caché.
Purga de la memoria caché
La red CDN almacena en caché los archivos del sitio web en los servidores perimetrales hasta que expire el período de vida. Estos se actualizan para una nueva solicitud de cliente, solo después de que expire el período de vida. Es necesario eliminar la memoria caché de la red CDN para garantizar que todos los usuarios obtengan los archivos más recientes del sitio web activo, especialmente si la implementación se produce en la misma carpeta de origen de la red CDN. Azure CDN permite eliminar la memoria caché de Azure Portal.
Un mejor enfoque consiste en invalidar esta caché mediante el uso del control de versiones durante la implementación. Una depuración o expiración de caché explícita normalmente hace que la red CDN recupere las versiones más recientes del contenido web. Aunque, dado que la red CDN siempre señala a la versión más reciente de la implementación, esto mejora el almacenamiento en caché de la siguiente manera:
- La red CDN valida index.html con el origen para cada nueva instancia de sitio web.
- Excepto en el caso de index.html y 404.html, todos los demás archivos del sitio web se firman y se almacenan en caché durante un año. Esto se basa en la suposición de que los recursos, como las imágenes y los vídeos, no necesitan cambios frecuentes. Si estos archivos se actualizan y se vuelven a generar, los nombres se actualizan con un nuevo GUID de huella digital. Como resultado, se actualiza el archivo index.html con una referencia actualizada al archivo de recursos modificado. Después, la red CDN recupera el archivo index.html actualizado y, dado que no encuentra el archivo de recursos de referencia en su memoria caché, también recupera los archivos de recursos modificados.
Esto garantiza que la red CDN siempre obtiene nuevos archivos actualizados y elimina la necesidad de eliminar la memoria caché para una nueva compilación.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Dhanashri Kshirsagar | Gestor de contenido sénior
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Ahora que comprende los aspectos básicos, siga este archivo Léame para configurar y ejecutar la canalización de CI/CD.
Conozca los Procedimientos recomendados para el uso de redes de entrega de contenido (CDN)