Поделиться через

Добавление непрерывной интеграции в сборки контейнеров

  • Статья

Непрерывная интеграция — это процесс разработки программного обеспечения, в котором приложение постоянно освобождается, предоставляя автоматические сборки с каждой фиксацией для определенной базы кода. Вы можете добавить непрерывную интеграцию практически в любую систему сборки, но два из них особенно удобны: GitHub Actions и Azure Pipelines. В этом разделе вы узнаете, как использовать GitHub Actions или Azure Pipelines для автоматизации действий по сборке Docker, описанных в разделе Использование контейнеров для создания приложений Azure Sphere.

Использование GitHub Actions для автоматической сборки контейнера

GitHub Actions позволяют автоматизировать процесс сборки непосредственно из репозиториев GitHub. Таким образом, первым шагом в использовании GitHub Actions является создание или открытие репозитория GitHub, содержащего код приложения. В этом разделе предполагается, что вы создали репозиторий GitHub, содержащий приложение Blink, созданное в руководстве по созданию высокоуровневого приложения , и что проект называется Blink. Как и в случае с любым проектом непрерывной интеграции, убедитесь, что проект выполняет сборку локально и предоставляет ожидаемые артефакты, прежде чем пытаться автоматизировать процесс. В этом примере предполагается, что после успешной сборки out каталог содержит файл Blink.imagepackage.

В каталоге верхнего уровня репозитория GitHub создайте каталог с именем .devcontainer и создайте в этом каталоге файл с именем Dockerfile со следующим содержимым:

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" ]

В начальной FROM строке указывается стандартный образ Docker Azure Sphere в качестве базового контейнера разработки, а во второй строке указано, что в качестве среды сборки используется этот базовый контейнер. Строка COPY копирует содержимое репозитория в каталог /src/ контейнера. Указывает WORKDIR каталог сборки. Команда RUN предоставляет команду CMake для создания файлов сборки. Наконец, указывает, ENTRYPOINT что для фактической сборки приложения необходимо вызвать ninja.

В каталоге верхнего уровня репозитория создайте каталог .github/workflows и добавьте файл с именем ci.yml со следующим содержимым:

# 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

Этот рабочий процесс имеет только одно задание — для создания приложения; Задание выполняется в средстве выполнения GitHub Actions, в данном случае ubuntu-latestи состоит из четырех шагов:

  1. Шаг 1, Checkout, — это стандартное действие GitHub, которое просто извлекает репозиторий в средство выполнения ubuntu-latest.

  2. Шаг 2 создает образ (docker build) и запускает контейнер (docker run).

  3. Шаг 3 копирует выходные данные из контейнера в средство выполнения.

  4. Шаг 4. Публикация пакета изображений HL публикует высокоуровневый пакет изображений приложения в качестве артефакта.

Зафиксируйте эти изменения в ветви main и выберите Действия. Теперь вы увидите страницу с меткой "Все рабочие процессы" с по крайней мере одним рабочим процессом, запущенным или завершенным. Если рабочий процесс завершается успешно, рядом с ним появится зеленая проверка метка. Щелкните успешный рабочий процесс, и вы увидите поле с надписью "Артефакты", содержащее один артефакт с меткой "HL imagepackage". Скачайте этот артефакт и распакуйте файл imagepackage; Затем можно создать развертывание или загрузить неопубликованное приложение на устройство.

Использование Azure Pipelines для автоматической сборки контейнера

Azure Pipelines позволяет автоматизировать процесс сборки непосредственно из репозиториев GitHub (и многих других репозиториев кода). В этом разделе предполагается, что вы уже принадлежите к организации с проектом Azure DevOps и имеете доступ к Azure Pipelines. Первым шагом в использовании Azure Pipelines является создание или открытие репозитория, содержащего код приложения. В этом разделе предполагается, что вы создали репозиторий GitHub, содержащий приложение Blink, созданное в руководстве по созданию высокоуровневого приложения.

В каталоге верхнего уровня этого репозитория создайте каталог .devcontainer и создайте в этом каталоге файл Dockerfile со следующим содержимым:

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" ]

В начальной FROM строке указывается стандартный образ Docker Azure Sphere в качестве базового контейнера разработки, а во второй строке указано, что в качестве среды сборки используется этот базовый контейнер. Строка COPY копирует содержимое репозитория в каталог /src/ контейнера. Указывает WORKDIR каталог сборки. Команда RUN предоставляет команду CMake для создания файлов сборки. Наконец, указывает, ENTRYPOINT что для фактической сборки приложения необходимо вызвать ninja.

Чтобы создать конвейер, выполните следующие действия:

  1. Войдите в проект Azure DevOps и откройте Pipelines.
  2. Выберите Создать конвейер, а затем выберите GitHub при появлении запроса Где находится код? Возможно, вы перейдете на страницу проверки подлинности GitHub. завершите проверку подлинности и перейдите на страницу, чтобы выбрать репозиторий.
  3. Выберите репозиторий Blink. Вы перейдете на страницу Настройка конвейера.
  4. Выберите Начальный конвейер. Откроется файл с именем azure-pipelines.yml в каталоге верхнего уровня репозитория с задачей Hello, World.
  5. Выберите Сохранить и запустить. Примите сообщение о фиксации по умолчанию и снова выберите Сохранить и запустить. Файл azure-pipelines.yml фиксируется в репозитории GitHub и создается конвейер.

Замените содержимое файла azure-pipelines.yml следующим содержимым:

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

Этот рабочий процесс имеет только одно задание — для создания приложения; Задание выполняется в агенте Azure DevOps, в данном случае ubuntu-latest, и состоит из двух этапов:

  1. Шаг 1 создает образ (docker build), запускает контейнер (docker run) и копирует выходные данные из контейнера в агент.

  2. Шаг 2. Публикация артефактов сборки публикует высокоуровневый пакет изображений приложения в качестве артефакта.

Зафиксируйте эти изменения в main ветви. В Azure DevOps снова откройте Pipelines . Вы должны увидеть выполнение конвейера в процессе выполнения или только что завершено. Если при выполнении отображается зеленая галочка, сборка прошла успешно. Выберите успешное выполнение; В столбце Связанные должно отобразиться значение 1 Опубликовано. Скачайте этот артефакт и распакуйте файл imagepackage; Затем можно создать развертывание или загрузить неопубликованное приложение на устройство.

Добавление непрерывной интеграции в примеры приложений Azure Sphere

GitHub Actions и Azure Pipelines предназначены для автоматизации сборок для одного проекта, например для тех, которые скачиваются из браузера примеров Майкрософт. Примеры Azure Sphere на GitHub — это коллекция проектов с некоторыми общими ресурсами. Чтобы использовать один из этих примеров в непрерывной интеграции, необходимо включить все необходимые общие ресурсы. Как правило, это означает, по крайней мере, создание каталога HardwareDefinitions в каталоге верхнего уровня проекта и изменение файла CMakeLists.txt, указывающего на локальную копию. Например, если создать проект на основе примера HelloWorld/HelloWorld_HighLevelApp, каталог верхнего уровня изначально выглядит следующим образом:

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

Файл CMakeLists.txt содержит следующую строку, указывающую на общий каталог HardwareDefinitions в репозитории Примеры:

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

Чтобы включить сборку проекта, скопируйте папку HardwareDefinitions в каталог верхнего уровня, а затем измените файл CMakeLists.txt, чтобы использовать локальное расположение:

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

Еще раз убедитесь, что проект выполняет локальную сборку, прежде чем пытаться автоматизировать с помощью GitHub Actions.