Agregar integración continua a las compilaciones de contenedor
La integración continua es un proceso de desarrollo de software en el que una aplicación se mantiene en un estado continuamente releable al proporcionar compilaciones automatizadas con cada confirmación de una base de código específica. Puede agregar integración continua a prácticamente cualquier sistema de compilación, pero dos de las más convenientes son Acciones de GitHub y Azure Pipelines. En este tema, verá cómo usar Acciones de GitHub o Azure Pipelines para automatizar los pasos de la compilación de Docker que se describen en Usar contenedores para crear aplicaciones de Azure Sphere.
Usar Acciones de GitHub para crear automáticamente el contenedor
Acciones de GitHub te permiten automatizar el proceso de compilación directamente desde tus repositorios de GitHub. Por lo tanto, el primer paso en el uso de Acciones de GitHub es crear o abrir un repositorio de GitHub que contenga el código de aplicación. En este tema se supone que ha creado un repositorio de GitHub que contiene la aplicación Blink generada en Tutorial: Crear una aplicación de alto nivel y que el proyecto se denomina "Blink". Al igual que con cualquier proyecto de integración continua, asegúrese de que el proyecto se compila localmente y proporciona los artefactos esperados antes de intentar automatizar el proceso. En este ejemplo, suponemos que, después de una compilación correcta, el out
directorio contiene un archivo Blink.imagepackage.
En el directorio de nivel superior del repositorio de GitHub, cree un directorio denominado .devcontainer y cree un archivo denominado Dockerfile en ese directorio con el contenido siguiente:
FROM mcr.microsoft.com/azurespheresdk:latest AS dev
FROM dev AS build
COPY ./ /src/
WORKDIR /out
RUN cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/opt/azurespheresdk/CMakeFiles/AzureSphereToolchain.cmake" \
-DAZURE_SPHERE_TARGET_API_SET="latest-lts" -DCMAKE_BUILD_TYPE="Release" "/src"
ENTRYPOINT [ "ninja" ]
La línea inicial FROM
especifica la imagen estándar de Azure Sphere Docker como contenedor de desarrollo base y la segunda indica que debe usar ese contenedor base como el entorno de compilación. La COPY
línea copia el contenido del repositorio en el directorio /src/ del contenedor. Especifica WORKDIR
el directorio de compilación. El RUN
comando proporciona el comando CMake para generar los archivos de compilación. Por último, el ENTRYPOINT
especifica que ninja debe invocarse para crear realmente la aplicación.
En el directorio de nivel superior del repositorio, cree el directorio .github/workflows y agregue un archivo denominado ci.yml con el contenido siguiente:
# This is a basic workflow to help you get started with Actions
name: ContinuousIntegration
# Controls when the action will run. Triggers the workflow on push or pull request
# events, but including workflow_dispatch also allows manual execution
on:
push:
pull_request:
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
name: Build Azure Sphere Apps
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Build image for az sphere builds and Start container from build image
run: |
docker build --target build -t hlbuildimage -f .devcontainer/Dockerfile .
docker run --name hlbuildcontainer hlbuildimage
- name: Copy container build output
run:
docker cp hlbuildcontainer:/out HLOutput
- name: Publish HL imagepackage
uses: actions/upload-artifact@v2
with:
name: HL imagepackage
path: ${{ github.workspace }}/HLOutput/Blink.imagepackage
Este flujo de trabajo solo tiene un trabajo: crear la aplicación; el trabajo se ejecuta en un Acciones de GitHub ejecutor, en este caso ubuntu-latest
, y tiene cuatro pasos:
Paso 1,
Checkout
, es una acción de GitHub estándar que simplemente comprueba el repositorio para el ubuntu-latest runner.El paso 2 crea la imagen (
docker build
) y inicia el contenedor (docker run
).El paso 3 copia el resultado del contenedor al ejecutor.
Paso 4, Publicar paquete de imágenes de HL, publica el imagepackage de aplicación de alto nivel como un artefacto.
Confirma estos cambios en la rama principal y selecciona Acciones. Ahora debería ver una página con la etiqueta "Todos los flujos de trabajo", con al menos un flujo de trabajo ejecutándose o completado. Si el flujo de trabajo se completa correctamente, aparecerá una marca de verificación verde junto a él. Haga clic en un flujo de trabajo correcto y verá un cuadro con la etiqueta "Artefactos" que contiene un artefacto con la etiqueta "HL imagepackage". Descargar este artefacto y desempaquetar el archivo imagepackage; puedes crear una implementación o realizar instalaciones de prueba de la aplicación en el dispositivo.
Usar Azure Pipelines para crear automáticamente el contenedor
Azure Pipelines le permite automatizar el proceso de compilación directamente desde sus repositorios de GitHub (y muchos otros repositorios de código). En este artículo se asume que ya pertenece a una organización con un proyecto de Azure DevOps y tiene acceso a Azure Pipelines. El primer paso para usar Azure Pipelines es crear o abrir un repositorio que contenga el código de aplicación. En este tema se asume que ha creado un repositorio de GitHub que contiene la aplicación Blink generada en Tutorial: Crear una aplicación de alto nivel.
En el directorio de nivel superior de este repositorio, cree el directorio .devcontainer y cree un archivo Dockerfile en ese directorio con el contenido siguiente:
FROM mcr.microsoft.com/azurespheresdk:latest AS dev
FROM dev AS build
COPY ./ /src/
WORKDIR /out
RUN cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/opt/azurespheresdk/CMakeFiles/AzureSphereToolchain.cmake" \
-DAZURE_SPHERE_TARGET_API_SET="latest-lts" -DCMAKE_BUILD_TYPE="Release" "/src"
ENTRYPOINT [ "ninja" ]
La línea inicial FROM
especifica la imagen estándar de Azure Sphere Docker como contenedor de desarrollo base y la segunda indica que debe usar ese contenedor base como el entorno de compilación. La COPY
línea copia el contenido del repositorio en el directorio /src/ del contenedor. Especifica WORKDIR
el directorio de compilación. El RUN
comando proporciona el comando CMake para generar los archivos de compilación. Por último, el ENTRYPOINT
especifica que ninja debe invocarse para crear realmente la aplicación.
Para crear la canalización:
- Inicie sesión en su proyecto de Azure DevOps y abra Canalizaciones.
- Selecciona Nueva canalización y, a continuación, selecciona GitHub cuando se te pregunte ¿Dónde está el código? Es posible que se te lleve a una página de autenticación de GitHub; complete la autenticación y continúe con la página para seleccionar el repositorio.
- Seleccione el repositorio de Blink. Se le lleva a una página titulada Configurar la canalización.
- Seleccione Canalización inicial. Se abrirá un archivo denominado azure-pipelines.yml en el directorio de nivel superior de su repositorio con una tarea Hello, World.
- Seleccione Guardar y ejecutar. Acepte el mensaje de confirmación predeterminado y, de nuevo, seleccione Guardar y ejecutar. El archivo azure-pipelines.yml está comprometido con el repositorio de GitHub y se crea la canalización.
Reemplace el contenido del archivo azure-pipelines.yml por el contenido siguiente:
# Docker
# Build a Docker image
# /azure/devops/pipelines/languages/docker
trigger:
- main
resources:
- repo: self
variables:
tag: '$(Build.BuildId)'
stages:
- stage: Build
displayName: Build image
jobs:
- job: Build
displayName: Build
pool:
vmImage: 'ubuntu-latest'
steps:
- bash: docker build --target build -t hlbuildimage -f .devcontainer/Dockerfile . && docker run --name hlbuildcontainer hlbuildimage && docker cp hlbuildcontainer:/out $(Build.ArtifactStagingDirectory)/HLOutput
displayName: Build high-level Azure Sphere application in a container and copy the output
- task: PublishBuildArtifacts@1
displayName: Publish build artifacts
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/HLOutput/Blink.imagepackage'
ArtifactName: 'BlinkSample.imagepackage'
publishLocation: 'Container'
Este flujo de trabajo solo tiene un trabajo: crear la aplicación; el trabajo se ejecuta en un agente de Azure DevOps, en este caso ubuntu-latest
, y tiene dos pasos:
El paso 1 genera la imagen (
docker build
), inicia el contenedor (docker run
) y copia el resultado del contenedor al agente.Paso 2, Publicar artefactos de compilación, publica el paquete de imágenes de aplicación de alto nivel como un artefacto.
Confirma estos cambios en la rama principal. En Azure DevOps, vuelva a abrir Canalizaciones . Debería ver una ejecución de la canalización en curso o recién completada. Si la ejecución muestra una marca de verificación verde, la compilación se realizó correctamente. Seleccione la ejecución correcta; debería ver 1 Publicado en la columna Relacionados . Descargar este artefacto y descomprimir el archivo imagepackage; puedes crear una implementación o realizar instalaciones de prueba de la aplicación en el dispositivo.
Agregar integración continua a aplicaciones de ejemplo de Azure Sphere
Acciones de GitHub y Azure Pipelines están diseñadas para automatizar compilaciones para un único proyecto, como las descargadas desde el explorador de ejemplos de Microsoft. Azure Sphere Samples en GitHub son una colección de proyectos con algunos recursos compartidos. Para usar uno de estos ejemplos en la integración continua, debe incorporar los recursos compartidos necesarios. Normalmente, esto significa al menos crear un directorio HardwareDefinitions en el directorio de nivel superior del proyecto y editar el archivo CMakeLists.txt para que apunte a la copia local. Por ejemplo, si crea un proyecto basado en el ejemplo de HelloWorld/HelloWorld_HighLevelApp, el directorio de nivel superior tendrá inicialmente este aspecto:
.vscode
.gitignore
applibs_versions.h
app_manifest.json
CMakeLists.txt
CMakeSettings.json
launch.vs.json
LICENSE.txt
main.c
README.md
El archivo CMakeLists.txt contiene la línea siguiente que apunta al directorio compartido HardwareDefinitions del repositorio de ejemplos:
azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "../../../HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")
Para habilitar la compilación del proyecto, copia la carpeta HardwareDefinitions en el directorio de nivel superior y, a continuación, edita el archivo CMakeLists.txt para usar la ubicación local:
azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")
Una vez más, compruebe que el proyecto se compila localmente antes de intentar automatizar con Acciones de GitHub.