하드웨어 인 더 루프 테스팅을 위한 빌드 및 런타임 환경 컨테이너화

Ari Mahpour
|  작성 날짜: April 16, 2024

최근에 지속적 통합 시스템을 사용할 때 자동화된 테스트를 위한 컨테이너 환경에 대한 질문을 많이 받고 있습니다. 만약 그 문장의 대부분을 이해하지 못했다면 걱정하지 마세요. 왜냐하면 우리는 컨테이너, Docker, 그리고 내장 환경 및 하드웨어 인 더 루프 테스팅에서 이를 활용하는 방법에 대해 자세히 알아볼 것이기 때문입니다.

컨테이너란 무엇인가?

컨테이너에 대한 훌륭한 글이 많이 있습니다. 여기에는 Docker에서 제공하는 이 글이 있습니다(가장 인기 있는 컨테이너 런타임 엔진 중 하나입니다). 빌드 환경(예: 내장 시스템) 및 테스트 환경(예: 하드웨어 인 더 루프 테스팅)에서 컨테이너는 새로운 기계를 구동할 때마다 모든 복잡한 설정을 추상화할 수 있는 능력을 제공합니다. 이것은 새로운 테스트 기계에만 관련된 것이 아니라 내장 펌웨어를 빌드하기 위해 클라우드에서 우리의 작업을 확장하는 것과도 관련이 있습니다.

요즘 어떤 규모의 작업을 하든 많은 회사들이 베어 메탈 서버를 유지하는 것을 외부에 맡기기 위해 클라우드를 활용합니다. DevOps 원칙에서 우리는 언제든지 어디서든지 작성한 소프트웨어를 빌드하고 실행할 수 있도록 항상 보장하고자 합니다. 클라우드에서 새로운 기계를 지속적으로 구동하고 컴파일 소프트웨어, 라이브러리 및 기타 소프트웨어 패키지를 설치하는 것은 잘 확장되지 않습니다. 이것이 바로 컨테이너화가 그렇게 인기 있는 이유입니다. 우리는 빌드(또는 런타임 환경)를 매우 가벼운 가상 머신으로 패키징하여 클라우드나 우리 자신의 개인 컴퓨터에서 실행할 수 있는 기계에 전달할 수 있습니다.

컨테이너 생성 및 사용

프로젝트에서 이러한 컨테이너를 실제로 생성하고 사용하는 방법을 살펴봅시다. 컨테이너 이미지를 처음 생성하기 시작할 때 “베이스 이미지”라는 기존 이미지에서 시작해야 합니다. 대부분의 경우, Debian, Ubuntu, 또는 Alpine과 같은 리눅스 운영 체제의 변형이 적합합니다. Dockerfile을 생성하면 다음과 같이 이미지를 참조합니다:

FROM ubuntu:latest

이는 베이스 운영 체제가 최신 Ubuntu Docker 이미지를 실행할 것임을 나타냅니다. 그 후에는 빌드 또는 테스트 환경에 필요한 라이브러리를 설치해야 합니다. 예제 저장소에서, 저는 Debian 패키지 관리자(Apt)를 사용하여 Arduino IDE를 설치한 다음 Arduino Sam 보드 드라이버를 설치하여 더 많은 레이어를 추가했습니다. 이 컨테이너를 특권 모드에서 실행하거나(또는 장치에 볼륨 마운트 지점을 전달하면) Docker만 포함된 새로운 기계에서 명령 줄을 통해 Arduino 스케치를 컴파일하고 업로드할 수 있습니다.

우리가 테스트 중인 장치에 연결된 기계들과도 같은 일을 할 수 있습니다. 제가 만든 이 Docker 컨테이너에서는 Analog Discovery 2 장치를 실행하는 데 필요한 모든 의존성과 소프트웨어를 설치합니다. 이론적으로 Docker만 있는 새로운 기계에서 Docker 컨테이너를 실행하고 별다른 어려움 없이 Analog Discovery 2와 통신을 시작할 수 있습니다. Analog Discovery 2를 사용하여 ADC, DAC를 검증하는 테스트를 작성하거나 보드의 다른 칩에 I2C/SPI 명령을 보내는 등 다양한 기능을 수행할 수 있습니다.

지속적 통합으로 확장하기

이제 컨테이너가 지속적 통합(CI) 시스템과 결합될 때 효율성과 확장성을 어떻게 향상시킬 수 있는지 논의해 보겠습니다. 진정한 마법은 컨테이너를 지속적 통합(CI) 시스템과 함께 사용하기 시작할 때 발생합니다. 우리는 수십 대, 아니 수백 대의 물리적 테스트 기계를 가지고 있거나 테스트 및 빌드 서버를 위해 수천 대의 클라우드 기계에 접근할 수 있습니다. 위에서 언급한 것처럼 실질적으로 확장하려면, 온라인 상태가 되는 각각의 기계를 개별적으로 구성할 수는 없습니다. CI 실행마다 컨테이너를 제공함으로써 빌드와 테스트를 실행하는 시스템적이고 반복 가능한 방법을 제공할 뿐만 아니라 (클라우드에서는 거의 모든 CI 실행마다 발생하는) 기계를 매번 재구성할 필요가 없어집니다. 임베디드 빌드와 물리적 하드웨어 테스트에 컨테이너를 활용함으로써 우리와 우리 회사는 이전 세대가 꿈꿀 수만 있었던 일정 수준의 확장성을 제공합니다.

결론

이 글에서는 다양한 유형의 인프라에서 일관된 빌드 및 테스트 환경을 위해 임베디드 시스템 개발에서 컨테이너의 중요한 역할을 강조했습니다. 그들의 지속적 통합 시스템과의 통합은 개발을 간소화할 뿐만 아니라 제품의 확장성과 신뢰성을 향상시킵니다. 컨테이너 기술이 발전함에 따라, 그 채택은 개발자들에게 점점 더 중요해질 것입니다. 다양한 설정을 실험하고 더 깊이 탐구하려면 https://gitlab.com/docker-embedded에서 몇 가지 예제 저장소를 방문하세요.

작성자 정보

작성자 정보

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

관련 자료

관련 기술 문서

홈으로 돌아가기
Thank you, you are now subscribed to updates.