Partager via

Ajouter l’intégration continue à vos builds de conteneur

  • Article

L’intégration continue est un processus de développement logiciel dans lequel une application est conservée dans un état de libération continue en fournissant des builds automatisées avec chaque validation dans une base de code spécifique. Vous pouvez ajouter une intégration continue à pratiquement n’importe quel système de build, mais deux d’entre elles sont particulièrement pratiques GitHub Actions et Azure Pipelines. Dans cette rubrique, vous allez voir comment utiliser GitHub Actions ou Azure Pipelines pour automatiser les étapes de génération Docker décrites dans Utiliser des conteneurs pour générer des applications Azure Sphere.

Utiliser GitHub Actions pour générer automatiquement votre conteneur

GitHub Actions vous permettent d’automatiser votre processus de génération directement à partir de vos dépôts GitHub. Par conséquent, la première étape de l’utilisation de GitHub Actions consiste à créer ou ouvrir un dépôt GitHub qui contient le code de votre application. Cette rubrique part du principe que vous avez créé un référentiel GitHub contenant l’application Blink générée dans Tutoriel : Créer une application de haut niveau et que votre projet est nommé « Blink ». Comme pour tout projet d’intégration continue, assurez-vous que votre projet est généré localement et fournit les artefacts attendus avant de tenter d’automatiser le processus. Dans cet exemple, nous supposons qu’après une génération réussie, le out répertoire contient un fichier Blink.imagepackage.

Dans le répertoire de niveau supérieur de votre dépôt GitHub, créez un répertoire nommé .devcontainer, puis créez un fichier nommé Dockerfile dans ce répertoire avec le contenu suivant :

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 ligne initiale FROM spécifie l’image Docker Azure Sphere standard comme conteneur de développement de base, et la seconde indique d’utiliser ce conteneur de base comme environnement de build. La COPY ligne copie le contenu du référentiel dans le répertoire /src/ du conteneur. spécifie WORKDIR le répertoire de build. La RUN commande fournit la commande CMake pour générer les fichiers de build. Enfin, spécifie ENTRYPOINT que ninja doit être appelé pour générer réellement l’application.

Dans le répertoire de niveau supérieur de votre dépôt, créez le répertoire .github/workflows et ajoutez un fichier nommé ci.yml avec le contenu suivant :

# 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

Ce flux de travail n’a qu’un seul travail : générer l’application ; le travail s’exécute sur un exécuteur GitHub Actions, dans ce casubuntu-latest, et comporte quatre étapes :

  1. L’étape 1, Checkout, est une action GitHub standard qui extrait simplement votre dépôt dans l’exécuteur ubuntu-latest.

  2. L’étape 2 génère l’image (docker build) et démarre le conteneur (docker run).

  3. L’étape 3 copie la sortie du conteneur vers l’exécuteur.

  4. L’étape 4, Publier le package d’images HL, publie le package d’images d’application de haut niveau en tant qu’artefact.

Validez ces modifications dans votre branche main et sélectionnez Actions. Vous devez maintenant voir une page intitulée « Tous les flux de travail », avec au moins un flux de travail en cours d’exécution ou terminé. Si le flux de travail se termine correctement, une marque de case activée verte s’affiche à côté de celui-ci. Cliquez sur un flux de travail réussi et vous devriez voir une zone intitulée « Artefacts » contenant un artefact intitulé « HL imagepackage ». Téléchargez cet artefact et décompressez le fichier imagepackage . vous pouvez ensuite créer un déploiement ou charger une version test de l’application sur votre appareil.

Utiliser Azure Pipelines pour générer automatiquement votre conteneur

Azure Pipelines vous permet d’automatiser votre processus de génération directement à partir de vos dépôts GitHub (et de nombreux autres référentiels de code). Cette rubrique suppose que vous appartenez déjà à un organization avec un projet Azure DevOps et que vous avez accès à Azure Pipelines. La première étape de l’utilisation d’Azure Pipelines consiste à créer ou à ouvrir un dépôt qui contient le code de votre application. Cette rubrique suppose que vous avez créé un dépôt GitHub contenant l’application Blink générée dans Tutoriel : Créer une application de haut niveau.

Dans le répertoire de niveau supérieur de ce référentiel, créez le répertoire .devcontainer et créez un fichier Dockerfile dans ce répertoire avec le contenu suivant :

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 ligne initiale FROM spécifie l’image Docker Azure Sphere standard comme conteneur de développement de base, et la seconde indique d’utiliser ce conteneur de base comme environnement de build. La COPY ligne copie le contenu du référentiel dans le répertoire /src/ du conteneur. spécifie WORKDIR le répertoire de build. La RUN commande fournit la commande CMake pour générer les fichiers de build. Enfin, spécifie ENTRYPOINT que ninja doit être appelé pour générer réellement l’application.

Pour créer le pipeline :

  1. Connectez-vous à votre projet Azure DevOps et ouvrez Pipelines.
  2. Sélectionnez Nouveau pipeline, puis GitHub lorsque vous êtes invité à où se trouve votre code ? Vous pouvez être redirigé vers une page d’authentification GitHub ; terminez l’authentification et passez à la page pour sélectionner votre dépôt.
  3. Sélectionnez votre dépôt Blink. Vous accédez à une page intitulée Configurer votre pipeline.
  4. Sélectionnez Pipeline de démarrage. Cela ouvre un fichier nommé azure-pipelines.yml dans le répertoire de niveau supérieur de votre dépôt avec une tâche Hello, World.
  5. Sélectionnez Enregistrer et exécuter. Acceptez le message de validation par défaut, puis sélectionnez à nouveau Enregistrer et exécuter. Le fichier azure-pipelines.yml est commité dans votre dépôt GitHub et le pipeline est créé.

Remplacez le contenu du fichier azure-pipelines.yml par le contenu suivant :

# 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'

Ce flux de travail n’a qu’un seul travail : générer l’application ; le travail s’exécute sur un agent Azure DevOps, dans ce cas ubuntu-latest, et comporte deux étapes :

  1. L’étape 1 génère l’image (docker build), démarre le conteneur (docker run) et copie la sortie du conteneur vers l’agent.

  2. L’étape 2, Publier des artefacts de build, publie le package d’images d’application de haut niveau en tant qu’artefact.

Validez ces modifications dans votre branche main. Dans Azure DevOps, ouvrez à nouveau Pipelines . Vous devriez voir une exécution de votre pipeline en cours ou juste terminée. Si l’exécution affiche une coche verte, la génération a réussi. Sélectionnez l’exécution réussie ; vous devriez voir 1 Publié dans la colonne Connexe . Téléchargez cet artefact et décompressez le fichier imagepackage ; vous pouvez ensuite créer un déploiement ou charger une version test de l’application sur votre appareil.

Ajouter l’intégration continue à des exemples d’applications Azure Sphere

GitHub Actions et Azure Pipelines sont destinés à automatiser les builds d’un seul projet, telles que celles téléchargées à partir du navigateur d’exemples Microsoft. Les exemples Azure Sphere sur GitHub sont une collection de projets avec des ressources partagées. Pour utiliser l’un de ces exemples dans l’intégration continue, vous devez incorporer toutes les ressources partagées nécessaires. En règle générale, cela signifie au moins créer un répertoire HardwareDefinitions dans le répertoire de niveau supérieur de votre projet et modifier le fichier CMakeLists.txt pour qu’il pointe vers la copie locale. Par exemple, si vous créez un projet basé sur l’exemple HelloWorld/HelloWorld_HighLevelApp, le répertoire de niveau supérieur ressemble initialement à ceci :

.vscode
.gitignore
applibs_versions.h
app_manifest.json
CMakeLists.txt
CMakeSettings.json
launch.vs.json
LICENSE.txt
main.c
README.md

Le fichier CMakeLists.txt contient la ligne suivante pointant vers le répertoire HardwareDefinitions partagé dans le référentiel Samples :

azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "../../../HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")

Pour permettre la génération de votre projet, copiez le dossier HardwareDefinitions dans votre répertoire de niveau supérieur, puis modifiez le fichier CMakeLists.txt pour utiliser l’emplacement local :

azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")

Là encore, vérifiez que votre projet est généré localement avant de tenter d’automatiser avec GitHub Actions.