저대역폭 연결을 위한 효율적인 Docker 이미지 배포

이 아티클에서는 간헐적이거나 낮은 대역폭의 인터넷 연결을 통해 컨테이너화된 IoT(사물 인터넷) 에지 모듈을 배포하는 솔루션을 설명합니다.

에지 처리는 모바일 시나리오와 같이 대기 시간이 짧은 연결을 제공하고 대역폭을 절약하기 위한 주요 IoT(사물 인터넷) 패턴입니다. IoT 시스템은 일반적으로 소프트웨어 컨테이너 이미지를 배포하여 에지 디바이스를 프로비전합니다. 간헐적인 저대역폭 인터넷 연결로 인해 컨테이너 배포가 중단되면 모바일 시나리오에서 오류가 발생할 수 있습니다. 대역폭이 제한적이거나 간헐적이거나 낮은 IoT 시나리오에는 안정적이고 복원력 있는 배포 기능이 필요합니다.

이 예제에서는 한 대형 물류 회사가 전 세계 제품 배송 추적을 개선하고자 했습니다. 이 회사는 간헐적인 저대역폭 인터넷 연결을 사용하는 지역을 포함한 많은 로캘에 다양한 지상, 항공 및 해상 운송 방법으로 상품을 배송했습니다. 제품 유형에 따라 제품 배송에는 다양한 기능을 갖춘 다양한 IoT 보험, 안전 또는 추적 디바이스가 설치되어 있습니다. 디바이스에는 GPS 추적기, 온도 센서 및 데이터 캡처 도구가 포함되어 있습니다.

회사는 최근에 개발된 Azure IoT 에지 플랫폼을 통해 디바이스를 업데이트하는 데 문제가 있었습니다. 주요 문제점은 다음과 같았습니다.

• 업데이트된 소프트웨어를 디바이스에 배포할 때 대역폭 사용량이 높습니다.
• 디바이스 간에 표준화된 자동 배포가 없습니다.
• 기술 선택에 대한 유연성이 제한적입니다.

이러한 문제를 해결하기 위해 개발 팀은 다음과 같은 솔루션을 만들었습니다.

• 각 디바이스에 대한 배포 크기를 최소화하여 대역폭을 줄입니다.
• IoT Edge 플랫폼에서 다른 유형의 원격 IoT 디바이스로의 표준화된 Docker 컨테이너 배포를 구현합니다.
• 신뢰할 수 있는 배포 모니터링을 가능하게 합니다.
• 다양한 Azure DevOps 및 클라우드 서비스를 활용하고 고객이 선호하는 레거시 도구를 사용합니다.

이 솔루션은 연결이 제한적인 환경에서 디바이스 프로비저닝 프로세스의 안정성과 복원력을 크게 향상했습니다. 이 아티클에서는 솔루션 세부 정보 및 솔루션 옵션 평가 프로세스에 대해 설명합니다.

고객 요구 사항

고객의 요구 사항은 다음과 같았습니다.

• 솔루션은 간헐적인 저대역폭 클라우드 연결을 지원해야 합니다.
• 배포된 애플리케이션은 로컬에서 계속 실행되어야 합니다.
• 로컬 직원은 오프라인 상태에서 또는 클라우드 왕복 지연 없이 기능을 사용해야 합니다.
• 연결된 상태에서는 솔루션이 클라우드 연결을 효율적으로 사용해야 합니다.
• 솔루션은 전체 제품에 걸쳐 일관되게 정의된 비즈니스 규칙에 따라 데이터 전송의 우선 순위를 지정해야 합니다.

다음과 같은 세부 요구 사항도 있었습니다.

• 이미지 파일은 대역폭이 낮고(1Mbit/s) 간헐적인 연결인 위성 연결을 통해 전송되어야 합니다.
• 전송되는 데이터의 양을 최소화해야 합니다.
• 디바이스로 파일을 전송할 때는 고객이 선호하는 타사 애플리케이션을 사용합니다.
• 디바이스 워크로드는 IoT Edge의 Docker 이미지를 사용합니다.
• 이미지 크기는 수십 MB에서 수 GB까지 다양합니다.
• IoT Edge 모듈은 .NET Core 2.2로 작성됩니다.

잠재적인 사용 사례

이 솔루션은 소프트웨어 컨테이너가 대역폭이 낮고 간헐적인 연결을 통해 솔루션을 제공하는 IoT 시나리오에 적합합니다. 다음은 이러한 템플릿의 예입니다.

• 석유, 가스 및 채광 원격 모니터링
• 무선 자동차 업데이트
• 강력한 연결이 보장되지 않는 모든 곳

아키텍처

고대역폭 시나리오에서 Azure IoT Edge는 인터넷 액세스 가능한 Docker 레지스트리(Docker 허브 또는 Azure Container Registry와 같은 프라이빗 레지스트리)에서 직접 이미지를 풀합니다. 이 기능은 docker pull <image_name> 명령을 실행하는 것과 동일합니다.

그러나 위성 인터넷 연결과 같이 간헐적일 수 있는 네트워크 액세스로 작업해야 하는 경우 Docker 풀 방법은 안정적이지 않습니다. Docker가 이미지를 풀하는 동안 인터넷 연결이 끊어지면 진행률이 캐시되지 않습니다. 따라서 인터넷에 다시 연결되면 Docker가 다시 처음부터 이미지를 풀하기 시작해야 합니다.

이 솔루션은 대체 배포 메커니즘인 Docker 이미지 파일의 이진 패치를 사용하여 대역폭을 줄이고 간헐적인 연결을 보정합니다.

데이터 흐름

1. 개발자는 소스 코드 리포지토리에서 에지 모듈 소스 코드와 상호 작용합니다.
2. Container Registry는 각 모듈의 Docker 이미지를 저장합니다.
3. 매니페스트 리포지토리는 모든 작업 흐름의 배포 매니페스트를 포함합니다.
4. 각 모듈에는 일반 Docker 빌드를 사용하여 자동으로 모듈을 만들고 등록하는 Azure Pipelines 빌드 파이프라인이 있습니다.
5. 이미지-디바이스 파이프라인은 매니페스트 파일에 의해 정의된 대로 대상 디바이스에 Docker 이미지를 배포합니다.
6. 매니페스트-디바이스 파이프라인은 업데이트되는 디바이스에 대한 적절한 Azure IoT Hub에 배포 매니페스트를 푸시합니다.
7. 타사의 고속 파일 전송 솔루션이 Azure Storage 계정에서 디바이스로 파일을 전송합니다.
8. 이미지 재구성 IoT Edge 모듈은 디바이스에 수신된 패치를 적용하는 작업을 담당합니다.
9. IoT Hub는 이미지 재구성 모듈로부터 상태 메시지를 수신하고 디바이스에 대한 배포 매니페스트를 설정합니다. 나머지 파이프라인 흐름은 이 배포 매니페스트를 사용합니다.
10. Azure Functions는 IoT Hub 메시지 스트림을 모니터링하고, SQL 데이터베이스를 업데이트하고, 사용자에게 성공 또는 실패 알림을 제공합니다.
11. Azure SQL Database는 배포 중 및 배포 후에 대상 디바이스 및 Azure 기반 서비스에서 발생을 추적합니다.

구성 요소

• Azure IoT Edge는 디바이스에서 컨테이너화된 워크로드를 실행하여 대기 시간이 짧은 연결을 제공하고 대역폭을 절약합니다.
• Azure IoT Hub는 IoT 애플리케이션과 이를 통해 컨트롤되는 디바이스 사이의 통신을 위한 중앙 메시지 허브 역할을 하는 관리되고 클라우드 호스팅되는 서비스입니다.
• Azure Container Registry는 프라이빗 Docker 컨테이너 이미지 및 관련 아티팩트의 저장 및 관리를 위한 클라우드 기반 프라이빗 레지스트리 서비스입니다.
• Azure Pipelines는 CI(연속 통합) 및 CD(지속적인 업데이트)를 통합하여 자동으로 코드를 테스트 및 빌드하고 어떤 대상에든 제공합니다.
• Azure Functions는 인프라를 프로비저닝하거나 관리할 필요 없이 이벤트 트리거 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다.
• Azure Storage는 모든 유형의 비즈니스 데이터, 개체 및 파일에 대해 확장성이 뛰어나고 안전하며 성능이 뛰어나고 비용 효율적인 스토리지를 제공합니다.
• Azure SQL Database는 클라우드용으로 빌드된 완전 관리형 다중 모델 관계형 데이터베이스 서비스입니다.
• Docker는 컨테이너화된 애플리케이션을 개발, 배송 및 실행하기 위한 개방형 플랫폼입니다.

대안

개발 팀은 전체 Docker 이미지 델타 전송 솔루션을 결정하기 전에 몇 가지 옵션을 평가했습니다. 다음 섹션에서는 평가 대안 및 결과에 대해 설명합니다.

팀은 각 옵션에 대해 다음과 같은 평가 기준을 고려했습니다.

• 솔루션이 요구 사항을 충족하는지.
• 디바이스에서 구현해야 하는 논리의 수가 적은지, 보통인지, 많은지.
• Azure에서 구현해야 하는 논리의 수가 적은지, 보통인지, 많은지.
• 컨테이너 이미지를 전송하기 위해 전송된 데이터의 대역폭 효율성 또는 이미지의 총 크기에 대한 비율.

대역폭 효율성에는 다음과 같은 시나리오가 포함되었습니다.

• 디바이스에 이미지가 없습니다.
• 베이스가 같은 이미지가 디바이스에 있습니다.
• 이전 애플리케이션 버전의 이미지가 디바이스에 있습니다.
• 이전 베이스 이미지에 기반해 빌드된 애플리케이션의 이미지가 디바이스에 있습니다.

팀은 다음 시나리오를 사용하여 대역폭 효율성을 평가했습니다.

Docker 레이어 전송 옵션

Docker 컨테이너 이미지는 읽기 전용 파일 시스템 차이의 UnionFS 탑재이며, 컨테이너가 실행되는 동안 변경된 다른 쓰기 가능한 레이어가 포함되어 있습니다. 파일 시스템은 레이어라고 부르며 이는 기본적으로 폴더 및 파일입니다. 레이어는 컨테이너의 루트 파일 시스템의 베이스를 형성하기 위해 누적됩니다. 레이어는 읽기 전용이므로 다양한 이미지는 공통으로 가지는 레이어를 공유할 수 있습니다.

Docker 레이어 전송 옵션은 이미지 간의 레이어를 재사용하고 새 레이어만 디바이스로 전송합니다. 이 옵션은 동일한 베이스 레이어(일반적으로 OS)를 공유하는 이미지에 대해 가장 유용합니다. 또는 기존 이미지의 버전을 업데이트할 때도 마찬가지 입니다.

이 메서드의 결점은 다음과 같습니다.

• 오케스트레이터는 어떤 디바이스에 어떤 레이어가 존재하는지에 관한 정보를 유지 관리해야 합니다.
• 기본 계층 변경으로 인해 모든 후속 계층의 해시가 변경됩니다.
• 비교에는 일관된 레이어 해시가 필요합니다.
• Docker 저장 및 Docker 로드에 대한 종속성이 존재할 수 있습니다.

Docker 클라이언트 옵션 수정

이 옵션은 중단 후 레이어 다운로드를 다시 시작할 수 있도록 Docker 클라이언트를 수정하거나 래핑하는 데 중점을 둡니다. 기본적으로 인터넷 연결이 중단된 후 30분 이내에 복원되면 Docker 풀이 다운로드를 다시 시작합니다. 그렇지 않으면 클라이언트가 종료되고 모든 다운로드 진행률이 소실됩니다.

이 메서드는 실행 가능하지만 다음과 같은 문제가 있습니다.

• 대역폭 효율성을 최대화하기 위해 이미지를 풀하는 Docker 디먼에 디바이스의 모든 이미지를 등록해야 합니다.
• 이 기능을 지원하도록 오픈 소스 Docker 프로젝트를 수정해야 하며, 오픈 소스 유지 관리자가 거부하면 위험이 초래됩니다.
• 고객이 선호하는 고속 파일 전송 솔루션 대신 HTTP를 통해 파일을 전송하려면 사용자 지정 재시도 논리를 개발해야 합니다.
• 베이스 이미지가 변경되면 모든 레이어를 다시 전송해야 합니다.

에지 디바이스에서의 빌드 옵션

이 접근 방식은 이미지 빌드 환경을 각 디바이스로 이동합니다. 다음 데이터가 디바이스로 전송됩니다.

• 빌드 중인 애플리케이션의 소스 코드
• 코드가 종속성을 가지는 모든 NuGet 패키지의 복사본
• .NET Core 빌드 환경 및 런타임의 Docker 기본 이미지
• 엔드 이미지에 대한 메타데이터

그런 다음, 디바이스의 빌드 에이전트가 이미지를 빌드하여 디바이스 Docker 관리자에 등록합니다.

이 솔루션은 다음과 같은 이유로 거부되었습니다.

• 여전히 큰 Docker 이미지를 디바이스로 이동하는 방법이 필요합니다. .NET 애플리케이션을 빌드하기 위한 이미지는 앱 이미지 자체보다 큽니다.
• 이 메서드는 팀이 소스 코드를 보유한 애플리케이션에서만 작동하므로 타사 이미지를 사용할 수 없습니다.
• 이 옵션을 사용하려면 NuGet 패키지를 만들고 디바이스로의 이동을 추적해야 합니다.
• 디바이스에서 이미지를 빌드하지 못하는 경우 팀은 빌드 환경과 만들어진 이미지를 원격으로 디버그해야 합니다. 원격 디버깅을 사용하려면 제한적일 수 있는 인터넷 연결을 많이 사용해야 합니다.

전체 이미지 델타 전송 옵션

선택된 접근 방식에서는 Docker 이미지를 단일 이진 파일로 처리합니다. Docker save 명령은 이미지를 .tar 파일로 내보냅니다. 솔루션은 기존 및 새 Docker 이미지를 내보내고, 적용할 때 기존 이미지를 새 이미지로 변환하는 이진 델타를 계산합니다.

솔루션은 디바이스의 기존 Docker 이미지를 추적하고 이진 델타 패치를 빌드하여 기존 이미지를 새 이미지로 변환합니다. 시스템은 저대역폭 인터넷 연결을 통해 델타 패치만 전송합니다. 이 솔루션은 이진 패치를 빌드하기 위한 몇 가지 사용자 지정 논리가 필요했지만, 디바이스로 최소한의 데이터를 전송합니다.

평가 결과

다음 표는 평가 기준에 따라 측정된 위의 각 솔루션을 보여 줍니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상하는 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

성능 효율성

이 솔루션은 IoT 디바이스 업데이트에 사용되는 대역폭을 크게 줄였습니다. 다음 표는 전송 효율성의 차이점에 대한 분석을 보여 줍니다.

이미지 재구성자를 원본으로 간주

이전 버전을 원본으로 간주

운영 우수성

다음 섹션에서는 솔루션에 대한 자세한 설명을 제공합니다.

소스 코드 리포지토리

개발자는 소스 코드 리포지토리에서 에지 모듈 소스 코드와 상호 작용합니다. 리포지토리는 다음과 같이 각 모듈의 코드를 포함하는 폴더로 구성됩니다.

\- repository root
    - modulea
    - modulea.csproj
    - module.json
    - Program.cs
    - Dockerfile

\- moduleb
    - moduleb.csproj
    - module.json
    - Program.cs
    - Dockerfile

권장되는 소스 코드 리포지토리 수는 다음과 같습니다.

• 모든 작업 흐름에 걸친 모든 모듈을 위한 리포지토리 1개
• 각 작업 흐름의 소스 코드 리포지토리 1개

Container Registry 인스턴스

Container Registry는 각 모듈의 Docker 이미지를 저장합니다. Container Registry에 가능한 두 가지 구성은 다음과 같습니다.

• 모든 이미지를 저장하는 단일 Container Registry 인스턴스입니다.
• 하나는 개발, 테스트 및 디버깅 이미지를 저장하고 다른 하나는 프로덕션 준비로 표시된 이미지만 포함하는 두 개의 Container Registry 인스턴스입니다.

매니페스트 리포지토리

매니페스트 리포지토리는 모든 작업 흐름의 배포 매니페스트를 포함합니다. 템플릿은 해당 작업 흐름에 기반한 폴더에 있습니다. 이 예제에서 두 작업 흐름은 공유 인프라 및 컨테이너화된 애플리케이션입니다.

\- repository root
     - Workstream1
         - deployment.template.json
     - Workstream2
         - deployment.template.json

Docker 이미지 빌드 파이프라인

각 모듈에는 Azure Pipelines 빌드 파이프라인이 있습니다. 파이프라인은 제네릭 Docker 빌드를 사용하여 모듈을 만들고 등록합니다. 파이프라인은 다음을 담당합니다.

• 소스 코드의 보안 검사
• Docker 이미지를 빌드하기 위한 기본 이미지의 보안 검사
• 모듈의 단위 테스트 실행
• 소스를 Docker 이미지로 빌드. 이미지 태그는 BUILD_BUILDID를 포함하므로 이미지를 만든 소스 코드에 항상 다시 연결될 수 있습니다.
• Container Registry 인스턴스에 이미지 푸시.
• 델타 파일 만들기
• 이미지의 서명 파일을 만들어 Azure 스토리지 계정에 저장.

모든 파이프라인 인스턴스는 단일 YAML 파이프라인 정의에 기반합니다. 파이프라인은 환경 변수를 사용하여 모듈에서 작동할 수 있습니다. 필터는 특정 폴더에서 변경 내용이 커밋된 경우에만 각 파이프라인을 트리거합니다. 이 필터는 모듈 하나만 업데이트되는 경우 모든 모듈을 빌드할 필요가 없도록 해줍니다.

이미지-디바이스 파이프라인

이미지-디바이스 파이프라인은 매니페스트 파일에 의해 정의된 대로 대상 디바이스에 Docker 이미지를 배포합니다. 파이프라인을 트리거하면 배포가 수동으로 시작됩니다.

파이프라인 정의는 컨테이너 내에서의 이러한 배포의 실행을 지정합니다. 파이프라인은 기반 컨테이너에 이미지에 대한 변수를 입력하도록 지원합니다. 단일 변수는 모든 파이프라인에 대한 배포를 제어할 수 있습니다.

이 이미지는 빌드할 패치를 결정하고, 해당 패치를 빌드하고, 파일 전송 도구의 Azure 쪽에 해당 패치를 배포하는 코드를 포함합니다.

이미지 배포 도구에 다음과 같은 정보가 필요합니다.

• 배포 대상 이미지이며 이 정보는 리포지토리의 매니페스트가 제공합니다.
• 배포 대상 디바이스이며 이 정보는 파이프라인을 트리거하는 사용자가 제공합니다.
• 이미 대상 디바이스에 있는 이미지이며 이 정보는 Azure SQL 데이터베이스가 제공합니다.

파이프라인의 출력은 다음과 같습니다.

• 디바이스에 배포할 파일 전송 도구의 Azure 쪽으로 전송되는 패치 번들.
• 각 디바이스로 전송하기 시작한 이미지를 표시하는 SQL 데이터베이스 항목.
• 새 배포 집합에 대한 SQL 데이터베이스 항목. 이러한 항목에는 배포를 지시한 사용자의 이름과 이메일 주소가 포함됩니다.

이 파이프라인은 다음 단계를 수행합니다.

1. 배포 매니페스트에 따라 필요한 이미지를 결정합니다.
2. SQL을 쿼리하여 디바이스에 이미 있는 이미지를 확인합니다. 모든 이미지가 이미 있는 경우 파이프라인이 성공적으로 종료됩니다.
3. 만들 패치 번들을 결정합니다. 시작 이미지를 결정하는 알고리즘은 가장 작은 패치 번들을 생성합니다.
   • 입력: 배포할 새 이미지를 포함하는 .tar 파일 및 디바이스에 있는 기존 이미지의 서명 파일.
   • 출력: 만들 가장 작은 패치를 결정하는 기존 이미지 순위.
4. 각 디바이스에 필요한 패치 번들을 만듭니다. 유사한 패치를 한 번 빌드하고 이를 필요로 하는 모든 디바이스에 복사합니다.
5. 배포를 위해 파일 전송 도구 스토리지 계정에 패치를 배포합니다.
6. 각 대상 디바이스에 대해 새 이미지를 in transit으로 표시하도록 SQL을 업데이트합니다.
7. 이미지를 배포하는 사람의 이름 및 연락처 메일을 포함한 배포 세트 정보를 SQL에 추가합니다.

매니페스트-디바이스 파이프라인

매니페스트-디바이스 파이프라인은 업데이트되는 디바이스를 위한 적절한 IoT Hub 연결에 배포 매니페스트를 푸시합니다. 사용자는 파이프라인을 수동으로 트리거하고 대상으로 지정할 IoT Hub 인스턴스에 대한 환경 변수를 지정합니다.

이 파이프라인은 다음과 같습니다.

• 배포에 필요한 이미지를 결정합니다.
• SQL을 쿼리하여 필요한 이미지가 모두 대상 디바이스에 있는지 확인합니다. 대상 디바이스에 없는 경우 파이프라인은 failed 상태로 종료됩니다.
• 새 배포 매니페스트를 적절한 IoT 허브에 푸시합니다.

빠른 파일 전송 솔루션

고객은 Azure와 해당 IoT 디바이스 간의 연결을 제공하기 위해 FileCatalyst라는 타사 고속 파일 전송 솔루션을 계속 사용하고자 했습니다. 이 솔루션은 궁극적으로는 일관된 파일 전송 도구입니다. 즉, 전송에 시간이 오래 걸릴 수 있지만 결국에는 파일 정보를 잃지 않고 완료됩니다.

이 솔루션은 연결의 Azure 쪽에서 Azure Storage 계정을 사용하고, 이미지를 수신하는 각 디바이스에 대해 고객의 기존 파일 전송 호스트 VM을 사용했습니다. 패치 번들은 IoT Hub를 실행하는 Linux VM으로 전송됩니다.

이미지 재구성 모듈

이미지 재구성 IoT Edge 모듈은 디바이스에 수신된 패치를 적용하는 작업을 담당합니다. 모든 디바이스는 Docker 오픈 소스 레지스트리를 사용하여 자체 로컬 컨테이너 레지스트리를 호스트합니다. 이미지 재구성 프로세스는 파일 전송 VM과 같은 호스트 VM에서 실행됩니다.

이 모듈은 다음을 수행합니다.

1. 컨테이너에 탑재된 폴더에서 패치 번들을 수신합니다.
2. 패치 콘텐츠의 압축을 풀고 구성 파일을 읽습니다.
3. 해시를 사용하여 로컬 컨테이너 레지스트리에서 베이스 이미지를 풀합니다.
4. 베이스 이미지를 .tar 파일로 저장합니다.
5. 베이스 이미지에 패치를 적용합니다.
6. 새 이미지가 포함된 새 .tar 파일을 Docker에 로드합니다.
7. 식별 이름 및 태그를 포함한 구성 파일을 사용하여 새 이미지를 로컬 컨테이너 레지스트리에 푸시합니다.
8. IoT Hub에 성공 메시지를 보냅니다.

프로세스가 어느 시점에서든 실패하는 경우 모듈은 배포를 트리거한 사람이 알 수 있도록 IoT Hub에 실패 메시지를 보내는 작업을 담당합니다.

IoT Hub

배포 프로세스 중 일부는 IoT Hub를 사용합니다. IoT Hub는 이미지 재구성 모듈이 보내는 상태 메시지를 수신하는 것 외에도 디바이스를 위해 배포 매니페스트를 설정합니다. 나머지 파이프라인 흐름은 이 매니페스트를 사용합니다.

Azure 기능

Azure Functions는 IoT Hub에서 오는 메시지 스트림을 모니터링하고 클라우드에서 작업을 수행합니다.

성공 메시지의 경우

• 이 기능은 디바이스 상의 이미지에 대한 SQL 항목의 상태를 in transit에서 succeeded으로 업데이트합니다.
• 이 이미지가 배포 집합에 마지막으로 도착하는 경우:
  • 이 기능은 사용자에게 배포 성공에 대해 알려줍니다.
  • 이 기능은 새 이미지를 사용하기 시작하도록 매니페스트-디바이스 파이프라인을 트리거합니다.

오류 메시지의 경우

• 이 기능은 디바이스 상의 이미지에 대한 SQL 항목의 상태를 in transit에서 failed로 업데이트합니다.
• 이 기능은 사용자에게 이미지 전송 실패를 알려줍니다.

SQL Database

SQL 데이터베이스는 배포 중 및 배포 후에 대상 디바이스 및 Azure 기반 배포 서비스에서 발생하는 항목을 추적합니다. Azure Functions 및 Azure Pipelines는 모두 데이터베이스와 상호 작용하기 위해 만든 프라이빗 NuGet 패키지를 사용합니다.

SQL Database는 다음 데이터를 저장합니다.

• 각 디바이스에 있는 이미지.
• 각 디바이스로 전송 중인 이미지.
• 세트에 속한 배포 중인 이미지.
• 배포를 지시한 사용자.

이 예제의 목표는 시스템이 향후 데이터 대시보드에 필요한 데이터를 생성하도록 하는 것이었습니다. IoT Hub 쿼리를 하면 매니페스트-디바이스 파이프라인에 관한 다음 데이터를 제공할 수 있습니다.

• 배포 상태
• 지정된 디바이스의 이미지
• 이미지가 있는 디바이스
• 성공한 전송 및 실패한 전송에 대한 시계열 데이터
• 사용자를 기반으로 한 배포 쿼리

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Kanio Dimitrov | 수석 소프트웨어 엔지니어링 리드

다음 단계

• 가상 Linux 디바이스에 첫 번째 IoT Edge 모듈 배포
• Linux 컨테이너로 IoT Edge 모듈 개발

관련 참고 자료

• Azure IoT 참조 아키텍처
• Azure DevOps를 사용하여 CI/CD 파이프라인 설계
• 업계를 위한 짧은 대기 시간 네트워크 연결