컨테이너 빌드에 연속 통합 추가

아티클
08/09/2023

연속 통합은 특정 코드 베이스에 대한 각 커밋과 함께 자동화된 빌드를 제공하여 애플리케이션이 지속적으로 릴리스 가능한 상태로 유지되는 소프트웨어 개발 프로세스입니다. 거의 모든 빌드 시스템에 연속 통합을 추가할 수 있지만 특히 편리한 두 가지는 GitHub Actions 및 Azure Pipelines입니다. 이 항목에서는 GitHub Actions 또는 Azure Pipelines를 사용하여 컨테이너를 사용하여 Azure Sphere 앱 빌드에 설명된 Docker 빌드 단계를 자동화하는 방법을 알아봅니다.

GitHub Actions 사용하여 컨테이너 자동 빌드

GitHub Actions GitHub 리포지토리에서 직접 빌드 프로세스를 자동화할 수 있습니다. 따라서 GitHub Actions 사용하는 첫 번째 단계는 애플리케이션 코드가 포함된 GitHub 리포지토리를 만들거나 여는 것입니다. 이 항목에서는 자습서: 상위 수준 애플리케이션 빌드 에서 생성된 Blink 애플리케이션이 포함된 GitHub 리포지토리를 만들었으며 프로젝트 이름이 "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 줄은 표준 Azure Sphere Docker 이미지를 기본 개발 컨테이너로 지정하고, 두 번째 줄은 기본 컨테이너를 빌드 환경으로 사용한다고 말합니다. 줄은 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)에서 실행되며 4단계가 있습니다.

1단계, Checkout는 단순히 리포지토리를 ubuntu-latest 실행기로 체크 아웃하는 표준 GitHub 작업입니다.
2단계는 이미지(docker build)를 빌드하고 컨테이너(docker run)를 시작합니다.
3단계는 컨테이너의 출력을 실행기로 복사합니다.
4단계, HL imagepackage 게시는 상위 수준 애플리케이션 imagepackage를 아티팩트로 게시합니다.

이러한 변경 내용을 기본 분기에 커밋하고 작업을 선택합니다. 이제 하나 이상의 워크플로가 실행되거나 완료된 "모든 워크플로"라는 레이블이 지정된 페이지가 표시됩니다. 워크플로가 성공적으로 완료되면 녹색 검사 표시가 옆에 나타납니다. 성공적인 워크플로를 클릭하면 "HL imagepackage"라는 레이블이 지정된 아티팩트 하나가 포함된 "아티팩트"라는 레이블이 지정된 상자가 표시됩니다. 이 아티팩트 다운로드 및 imagepackage 파일 압축 풀기; 그런 다음 , 배포를 만들 거나 애플리케이션을 디바이스에 테스트용으로 로드할 수 있습니다.

Azure Pipelines를 사용하여 컨테이너 자동으로 빌드

Azure Pipelines를 사용하면 GitHub 리포지토리(및 다른 많은 코드 리포지토리)에서 직접 빌드 프로세스를 자동화할 수 있습니다. 이 항목에서는 사용자가 이미 Azure DevOps 프로젝트의 organization 속하고 Azure Pipelines에 액세스할 수 있다고 가정합니다. Azure Pipelines를 사용하는 첫 번째 단계는 애플리케이션 코드가 포함된 리포지토리를 만들거나 여는 것입니다. 이 항목에서는 자습서: 상위 수준 애플리케이션 빌드에서 생성된 Blink 애플리케이션이 포함된 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" ]

파이프라인을 만들려면 다음을 수행합니다.

Azure DevOps 프로젝트에 로그인하고 파이프라인을 엽니다.
새 파이프라인을 선택한 다음, 코드가 어디에 있는지 묻는 메시지가 표시되면 GitHub를 선택합니다. GitHub 인증 페이지로 이동될 수 있습니다. 인증을 완료하고 페이지로 계속 이동하여 리포지토리를 선택합니다.
Blink 리포지토리를 선택합니다. 파이프라인 구성이라는 페이지로 이동합니다.
시작 파이프라인을 선택합니다. 그러면 Hello, World 작업을 사용하여 리포지토리의 최상위 디렉터리에 azure-pipelines.yml이라는 파일이 열립니다.
저장 및 실행을 선택합니다. 기본 커밋 메시지 적용하고 저장 및 실행을 다시 선택합니다. 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단계는 이미지를 빌드하고(docker build) 컨테이너를 시작하고(docker run) 컨테이너의 출력을 에이전트에 복사합니다.
2단계, 빌드 아티팩트 게시, 고급 애플리케이션 이미지패키지를 아티팩트로 게시합니다.

이러한 변경 내용을 기본 분기에 커밋합니다. Azure DevOps에서 Pipelines를 다시 엽니다. 파이프라인 실행이 진행 중이거나 완료된 것으로 표시됩니다. 실행에 녹색 확인 표시가 표시되면 빌드에 성공했습니다. 성공적인 실행을 선택합니다. 관련 열에 게시된 1이 표시됩니다. 이 아티팩트 다운로드 및 imagepackage 파일 압축 해제; 그런 다음 , 배포를 만들 거나 애플리케이션을 디바이스에 테스트용으로 로드할 수 있습니다.

Azure Sphere 샘플 애플리케이션에 연속 통합 추가

GitHub Actions 및 Azure Pipelines는 Microsoft 샘플 브라우저에서 다운로드한 프로젝트와 같은 단일 프로젝트에 대한 빌드를 자동화하기 위한 것입니다. GitHub의 Azure Sphere 샘플 은 일부 공유 리소스가 있는 프로젝트의 컬렉션입니다. 연속 통합에서 이러한 샘플 중 하나를 사용하려면 필요한 공유 리소스를 통합해야 합니다. 일반적으로 이는 적어도 프로젝트의 최상위 디렉터리에 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 사용하여 자동화하기 전에 프로젝트가 로컬로 빌드되는지 확인합니다.

다음을 통해 공유

컨테이너 빌드에 연속 통합 추가

GitHub Actions 사용하여 컨테이너 자동 빌드

Azure Pipelines를 사용하여 컨테이너 자동으로 빌드

Azure Sphere 샘플 애플리케이션에 연속 통합 추가

피드백

추가 리소스