클라우드 기반 지속적 통합 환경에서 가상 테스트 및 시뮬레이션 수행

자동차 기업들이 계속해서 소프트웨어를 사용하여 고객에게 더 많은 가치를 제공함에 따라 엔지니어링 팀에서 CI(지속적 통합) 파이프라인을 워크플로에 통합하는 경우가 증가하고 있습니다. 이와 동시에, 팀이 모델 기반 설계를 사용하여 더 높은 품질의 제품을 더 촉박한 일정에 따라 제공함에 따라 가상 테스트 및 시뮬레이션의 필요성 역시 증가하고 있습니다. 이러한 두 가지 경향이 결합되어 많은 팀이 필요에 따라 자동으로 확장이 가능한 클라우드 기반 CI 솔루션을 찾게 되었습니다.

클라우드 기반 솔루션은 비용, 확장성, 유연성 측면에서 상당한 이점을 제공합니다. 온프레미스에서 구매, 설정, 유지하기 위한 시간과 투자가 필요한 하드웨어와 달리, 클라우드 플랫폼은 CI 팀이 필요한 연산 능력에 대해서만 비용을 지불할 수 있는 다양한 서비스를 제공합니다. 클라우드 플랫폼은 다양한 인프라 구성요소와 여러 버전의 서버를 지원하며, 변화하는 CI 기술 스택, 구성, 환경 요구사항에 따라 적응할 수 있는 유연성을 제공합니다.

클라우드 기반 CI의 이점은 명확하지만 구현에 이르기 위한 경로는 그만큼 명확하지 않습니다. 팀은 사용할 클라우드 제공 업체, 배포할 CI 기술, 컨테이너 또는 VM(가상 머신)을 사용할지 여부를 포함한 여러 가지 주요 의사 결정에 직면합니다. 답은 각 팀의 구체적인 시나리오에 따라 달라지므로 AGSOTEC 팀은 사용 가능한 옵션을 고려하면서 장단점을 파악하기 위해 다양한 활용 사례에 대한 클라우드 기반 CI 개념 증명 구현을 구축했습니다.

이 기술 칼럼에서는 필요에 따라 클라우드에서 실행되는 VM과 컨테이너 인스턴스, 그리고 GitHub^®, GitLab^®, Jenkins^® 등 다양한 기술을 사용하여 클라우드 기반 CI로 AEB(자동 긴급 제동) 시스템을 위한 Simulink^® 모델을 테스트하는 사례 연구를 살펴봅니다. (그림 1) 이를 살펴본 후에는 엔지니어가 팀의 구체적인 클라우드 기반 CI 요구사항에 맞는 기술을 선택하는 데 도움이 되는 핵심 요점을 설명합니다.

클라우드 기반 CI에 적합한 툴의 요소

기술적인 세부 정보를 살펴보기 전에, 모든 소프트웨어가 CI 또는 클라우드 환경에서 사용하기에 적합한 것은 아니라는 점을 알아두는 것이 중요합니다.

MATLAB 및 Simulink 제품은 플랫폼 독립적이며, Windows^®, Linux 및 macOS 운영 체제를 지원한다는 특징이 있습니다. 클라우드 솔루션으로의 통합을 계획할 때는 이 같은 다용성이 핵심입니다. 가장 적합한 인프라를 선택할 수 있는 유연성을 제공하기 때문입니다. Linux는 다른 대안에 비해 더 비용 효율적인 경우가 많으므로 이는 다시 비용 절감으로 이어질 수 있습니다.

또한 MPM(MATLAB Package Manager)을 사용하여 Docker^® 컨테이너 등 Linux 가상 머신 및 컨테이너에서 MATLAB 및 Simulink 제품의 설치를 간소화할 수도 있습니다.

마지막으로, MathWorks는 엔지니어링 팀을 위한 추상화 계층을 제공하고, 전문가가 아닌 사용자도 선택한 CI 플랫폼의 CI를 간편하게 사용할 수 있게 해주는 광범위하게 사용되는 CI 소프트웨어 및 서비스를 위한 플러그인 및 기타 통합을 제공합니다. MathWorks는 MATLAB 및 Simulink에서 직접 파이프라인을 구축하기 위한 Process Advisor 앱도 제공합니다. 이러한 파이프라인은 MATLAB 프로젝트 내에서 아티팩트의 디지털 스레드를 통한 점진적 빌드를 지원합니다. 또한 이 앱은 제출 전 확인을 위해 MATLAB과 대화형 방식으로 사용하고 CI 플랫폼에서 자동화된 방식으로 사용할 수 있습니다. 일부 플랫폼에서는 MATLAB 파이프라인 설명에서 다단 CI 파이프라인을 자동으로 생성할 수도 있습니다. Process Advisor는 CI/CD Automation for Simulink Check™의 일부입니다.

VM 및 컨테이너를 사용한 가상 테스트 파이프라인

클라우드 기반 CI 파이프라인의 핵심 구성요소는 가상 테스트가 실행되는 환경입니다. 한 가지 옵션은 가상 머신 이미지를 생성한 다음 이 VM의 인스턴스를 자동으로 시작하여 대기 중인 작업을 실행하도록 파이프라인을 구성하는 것입니다. 다른 방법은 VM 대신 컨테이너를 사용하고 서버리스 컨테이너 실행 서비스를 통합하는 방법입니다. 이를 통해 사전 구성된 컨테이너를 레지스트리에서 CI 파이프라인으로 가져올 수 있습니다.

가상 테스트 파이프라인을 위한 VM 이미지 만들기

AWS는 AMI(Amazon Machine Image)라고 하는 지원되는 여러 가상 머신 이미지를 제공하며 이를 수정하여 사용자 지정 AMI를 만들 수 있습니다.

CI 파이프라인에서 사용하기 위한 사용자 지정 AMI를 만들려면 다음 단계를 따릅니다.

1. 기존 AMI의 인스턴스를 원하는 구성으로 시작합니다.
2. 인스턴스에 연결하고 필요한 모든 소프트웨어를 설치합니다.

MPM을 사용하여 MATLAB, Simulink 및 필요한 모든 툴박스를 Linux 환경에 설치할 수 있습니다. 특정 MATLAB 릴리스에 대한 모든 종속성은 MathWorks MATLAB Dependencies GitHub 리포지토리에 있는 관련 종속성 파일에서 찾을 수 있습니다.

예를 들어, 다음 명령은 MATLAB r2022b 및 이 릴리스의 종속성을 설치합니다.

apt-get update 

# 종속성 다운로드 

apt-get install --no-install-recommends -y ca-certificates unzip libasound2 libc6 libcairo2 libcairo-gobject2 libcap2 libcrypt1 libcrypt-dev libcups2 libdrm2 libdw1 libgbm1 libgdk-pixbuf2.0-0 libgl1 libglib2.0-0 libgomp1 libgstreamer1.0-0 libgstreamer-plugins-base1.0-0 libgtk-3-0 libice6 libnspr4 libnss3 libodbc1 libpam0g libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libsndfile1 libsystemd0 libuuid1 libwayland-client0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxft2 libxinerama1 libxrandr2 libxt6 libxtst6 libxxf86vm1 linux-libc-dev locales locales-all make net-tools odbcinst1debian2 procps sudo unzip wget zlib1g 

export DEBIAN_FRONTEND=noninteractive 

wget -q GIT HUB.com/mathworks/build-glibc-bz-19329-patch/releases/download/ubuntu-focal/all-packages.tar.gz 

tar -x -f all-packages.tar.gz --exclude glibc-*.deb --exclude libc6-dbg*.deb 

apt-get install --yes --no-install-recommends ./*.deb 

# MATLAB Package Manager 다운로드 

wget -q https://www.mathworks.com/mpm/glnxa64/mpm chmod +x mpm

# MPM을 사용하여 MATLAB, Simulink 및 모델링에 필요한 툴박스 다운로드 

./mpm install --release=r2022b --destination=/opt/matlab --products MATLAB Simulink Simulink_Test Image_Processing_Toolbox Computer_Vision_Toolbox Automated_Driving_Toolbox Control_System_Toolbox Model_Predictive_Control_Toolbox 

3. 인스턴스를 중지하고 AWS Management Console을 사용하여 이 인스턴스에서 AMI를 만듭니다.
4. 나중에 CI 시스템을 구성할 때 사용할 AMI ID를 저장합니다.

사용자 지정 이미지가 생성되면 다음 워크플로를 구현하는 VM 기반 파이프라인에 이 이미지를 배포할 수 있습니다. (그림 2)

1. 개발자가 소스 코드 리포지토리에 변경 사항을 커밋하면 테스트 파이프라인이 트리거됩니다.
2. 사용자 지정 AMI 기반의 새로운 VM이 시작됩니다(저장된 AMI ID 사용).
3. GitLab, GitHub와 같은 클라우드 파일 호스트 서비스에서 프로젝트 파일이 복제됩니다.
4. MATLAB이 -batch 인수로 실행되어 Simulink Test™로 테스트 시나리오를 로드하고 실행을 시작합니다.
5. 테스트 결과가 포함된 보고서가 생성되어 아티팩트로 저장되고 VM이 종료됩니다.

가상 테스트 파이프라인을 위한 컨테이너 만들기

AWS로 컨테이너 기반의 CI 파이프라인 구현을 준비하는 과정은 2단계 과정으로 구성됩니다. 먼저 로컬에서 컨테이너 이미지를 만든 다음 Amazon ECR(Amazon Elastic Container Registry) 같은 웹 기반 레지스트리에 이 이미지를 업로드합니다.

이 과정의 첫 부분은 MATLAB Container Image GitHub 리포지토리 만들기에 설명된 지침을 따르면 대폭 간소화할 수 있습니다.

두 번째 부분, 즉 이미지를 Amazon ECR에 업로드하기 위해서는 다음 단계를 따릅니다.

1. AWS Management Console을 사용하여 ECR 이미지 리포지토리를 만듭니다.
2. 새로 생성된 클라우드 리포지토리를 위한 로컬 컨테이너에 태그를 지정합니다.

다음 명령은 ID가 e5be3y248h47인 로컬 컨테이너 이미지에 aws_account_id.dkr.ecr.us-west-2.amazonaws.com/my-repository:tag 태그를 지정합니다.

docker tag e5be3y248h47 aws_account_id.dkr.ecr.eu-central-1.amazonaws.com/my-repository:tag

3. 새로 태그를 지정한 컨테이너 이미지를 리포지토리로 푸시합니다.

docker push aws_account_id.dkr.ecr.us-west-2.amazonaws.com/my-repository:tag

컨테이너 이미지가 생성되어 Amazon ECR 리포지토리로 푸시된 이후에는 다음 워크플로를 구현하는 컨테이너 기반 파이프라인에 이 이미지를 배포할 수 있습니다. (그림 3)

1. 개발자가 소스 코드 리포지토리에 변경 사항을 커밋하면 테스트 파이프라인이 트리거됩니다.
2. AWS 서버리스 계산 엔진인 Fargate에 알림이 전달되고, ECR(컨테이너 이미지 레지스트리)의 컨테이너가 시작됩니다.
3. GitLab, GitHub와 같은 클라우드 파일 호스트 서비스에서 프로젝트 파일이 복제됩니다.
4. MATLAB이 -batch 인수로 실행되어 Simulink Test로 테스트 시나리오를 로드하고 실행을 시작합니다.
5. 테스트 결과가 포함된 보고서가 생성되어 아티팩트로 저장되고 서버리스 컨테이너가 종료됩니다.

가상 테스트 파이프라인을 사용하도록 CI 시스템 구성

팀이 컨테이너 기반 파이프라인 또는 VM 기반 파이프라인을 통해 클라우드에서 가상 테스트를 실행할 용량을 갖추면 이 용량을 사용하여 CI 공정을 자동 확장할 수 있습니다. VM 또는 컨테이너와 함께 GitHub, GitLab 및 Jenkins를 사용할 수 있지만, 다음 세 가지 옵션이 대체로 구성하고 다루기가 더 쉽습니다.

옵션 A: VM을 사용하여 자동으로 확장하도록 GitHub 구성

GitHub Marketplace에서 제공되는 다양한 GitHub Action은 GitHub와 클라우드 서비스의 용이한 통합을 위해 설계되었습니다.

팀은 GitHub를 AWS 가상 테스트 파이프라인과 통합하기 위한 작업(예: CI 공정 중에 AWS EC2 러너 인스턴스를 동적으로 시작, 중지, 관리)을 간소화하는 GitHub Action을 사용했습니다.

이 GitHub Action을 구성하기 위해 GitHub 리포지토리의 .github/workflows/directory에 workflow.yml이라는 새 워크플로 파일을 만들었습니다. 이 파일 내에서 우리는 수행할 동작과 이러한 동작의 순서, 실행해야 하는 조건을 포함한 CI 워크플로를 정의했습니다. (그림 4)

아래 예제 코드는 자격 증명과 민감한 파라미터를 암호화하기 위해 GitHub 비밀과 결합된 일반적인 GitHub Action 구성을 보여줍니다. 이 코드는 필요한 AWS 자격 증명을 지정하고, 동작 모드를 정의하고(EC2 러너 시작), GitHub 개인 액세스 토큰과 이미지 ID(AMI ID), 인스턴스 유형 등 필요한 입력값을 공정에 제공합니다.

 name: Create and start an EC2 runner 
      runs-on: Linux 
      outputs: 
        label: ${{ steps.start-ec2-runner.outputs.label }} 
        ec2-instance-id: ${{ steps.start-ec2-runner.outputs.ec2-instance-id }} 
      steps: 
       - name: Configure AWS credentials 
         # 필수 액세스 키, 비밀 키 및 토큰을 비밀로 사용하여 AWS 자격 증명 구성 
         uses: aws-actions/configure-aws-credentials@v1-node16 
         with: 
           aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} 
           aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} 
           aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }} 
           aws-region: ${{ secrets.AWS_REGION }} 
       - name: Start EC2 runner 
         id: start-ec2-runner 
         # image-id 및 security-group-id 같은 자동 생성 인스턴스 설정 구성 
         uses: machulav/ec2-github-runner@v2 
         with: 
           mode: start 
           github-token: ${{ secrets.GH_PERSONAL_ACCESS_TOKEN }} 
           ec2-image-id: ${{ secrets.IMAGE_ID }} 
           ec2-instance-type: m5.large 
           subnet-id: ${{ secrets.SUBNET_ID }} 
           security-group-id: ${{ secrets.SECURTITY_GROUP_ID }} 
           iam-role-name: ${{ secrets.ROLE_NAME }} # 선택 사항, Role 프로파일을 사용하면 인스턴스가 지정된 프로파일 역할로 AWS의 다른 리소스 사용 가능 
           aws-resource-tags: > # 선택 사항, 명확성을 위해 추가 정보로 인스턴스에 태그 지정 
             [ 
               {"Key": "Name", "Value": "ec2-github-runner"}, 
               {"Key": "GitHubRepository", "Value": "${{ github.repository }}"} 

그 다음 테스트 공정을 시작하는 MATLAB 스크립트를 실행하기 위해 아래와 같은 GitHub Action 코드를 추가했습니다.

testing: 
  name: Start MATLAB 
  needs: start-runner # 러너가 준비되면 메인 작업을 시작하는 데 필요 
  runs-on: ${{ needs.start-runner.outputs.label }} # 새로 생성된 러너에서 작업 실행 
  steps: 
    - name: Execute MATLAB tests 
      run: | 
        export MLM_LICENSE_FILE=27000@ec2-35-156-32-190.eu-central-1.compute.amazonaws.com 
        matlab -batch "addpath(genpath(cd)); \ 
        testFile = sltest.testmanager.load('AutonomousEmergencyBrakingTests.mldatx'); \ 
        testSuite = getTestSuiteByName(testFile,'Test Scenarios'); \ 
        testCase = getTestCaseByName(testSuite,'scenario_25_AEB_PedestrianTurning_Nearside_10kph'); \ 
        resultObj = run(testCase); \ 
        sltest.testmanager.report(resultObj,'Report.pdf', Title='Autonomous Emergency Braking', IncludeMATLABFigures=true, IncludeErrorMessages=true, IncludeTestResults=0, LaunchReport=false);" 

위의 동작이 포함된 GitHub CI 작업을 실행하면 이전에 생성된 AMI를 기반으로 클라우드에 새 가상 머신이 시작되고, 이를 노드로 사용하여 MATLAB 테스트 스크립트를 실행합니다. (그림 4)

옵션 B: 컨테이너를 사용하여 자동 확장하도록 GitLab 구성

GitLab을 서버리스 컨테이너와 함께 사용하기 위해 AWS Fargate 계산 엔진과 함께 작동하도록 GitLab Runner를 구성했습니다. 이 작업은 다음의 3단계로 실행되었습니다.

1. 러너 config.toml 파일을 다음과 같이 편집했습니다.

[[runners]] 
  name = “fargate-test” 
  url = “https://gitlab.com/” 
  token = “__REDACTED__” 
  executor = “custom” 
  builds_dir = “/opt/gitlab-runner/builds” 
  cache_dir = “/opt/gitlab-runner/cache” 
  [runners.custom] 
    volumes = [“/cache”, “/path/to-ca-cert-dir/ca.crt:/etc/gitlab-runner/certs/ca.crt:ro”] 
    config_exec = “/opt/gitlab-runner/fargate” 
    config_args = [“—config”, “/etc/gitlab-runner/fargate.toml”, “custom”, “config”] 
    prepare_exec = “/opt/gitlab-runner/fargate” 
    prepare_args = [“—config”, “/etc/gitlab-runner/fargate.toml”, “custom”, “prepare”] 
    run_exec = “/opt/gitlab-runner/fargate” 
    run_args = [“—config”, “/etc/gitlab-runner/fargate.toml”, “custom”, “run”] 
    cleanup_exec = “/opt/gitlab-runner/fargate” 
    cleanup_args = [“—config”, “/etc/gitlab-runner/fargate.toml”, “custom”, “cleanup”] 

2. 다음과 같이 AWS Fargate 사용자 지정 실행기 드라이버를 설치했습니다.

 sudo curl -Lo /opt/gitlab-runner/fargate “https://gitlab-runner-custom-fargate-downloads.s3.amazonaws.com/latest/fargate-linux-amd64” 
 sudo chmod +x /opt/gitlab-runner/fargate 

3. 필요한 AWS 파라미터로 드라이버의 fargate.toml 파일을 구성했습니다.

 [Fargate] 
    Cluster = “test-cluster” # 클러스터 이름 
    Region = “us-east-2” # 배포할 AWS 리전 
    Subnet = “subnet-xxxxxx” # VPC 서브넷 
    SecurityGroup = “sg-xxxxxxxxxxxxx” # 컨테이너 네트워킹 
    TaskDefinition = “test-task:1” # AWS Fargate에서 실행될 작업 이름 
    EnablePublicIP = true # 컨테이너에 퍼블릭 IP 주소를 할당하여 외부 연결 허용 

[TaskMetadata] 
   Directory = “/opt/gitlab-runner/metadata” 

[SSH] 
  Username = “root” # 컨테이너에서 사용할 사용자 
  Port = 22 # SSH to port 22 

Fargate 실행기를 구성하고 러너를 프로젝트 리포지토리에 연결하면 이후 모든 GitLab CI 작업은 자동으로 클라우드에서 컨테이너를 시작하고 이를 사용하여 작업을 실행합니다. (그림 5)

다음 CI 단계 스크립트를 사용하여 MATLAB 테스트 스크립트를 실행했습니다.

 Run MATLAB: 
   script: 
     - export MLM_LICENSE_FILE=27000@ec2-35-156-32-190.eu-central-1.compute.amazonaws.com 
     - > 
       matlab -batch "addpath(genpath(cd)); 
       testFile = sltest.testmanager.load('AutonomousEmergencyBrakingTests.mldatx'); 
       testSuite = getTestSuiteByName(testFile,'Test Scenarios'); 
       testCase = getTestCaseByName(testSuite,'scenario_25_AEB_PedestrianTurning_Nearside_10kph'); 
       resultObj = run(testCase); 
       sltest.testmanager.report(resultObj,'Report.pdf', Title='Autonomous Emergency Braking', IncludeMATLABFigures=true, IncludeErrorMessages=true, IncludeTestResults=0, LaunchReport=false);" 

옵션 C: VM을 사용하여 자동 확장하도록 Jenkins 구성

Amazon EC2 Jenkins 플러그인을 사용하면 Jenkins CI 파이프라인에 AWS EC2 인스턴스를 통합할 수 있으며, 자동화된 인스턴스 생성, 관리, 종료가 지원됩니다. 다음과 같은 단계에 따라 EC2 플러그인을 구성했습니다.

1. Jenkins 플러그인 관리자를 통해 EC2 플러그인을 설치합니다.
2. Manage Jenkins > Configure System > Cloud > Add a new cloud > Amazon EC2로 이동합니다.
3. AWS 자격 증명을 입력하고 리전을 선택하고 인스턴스에 사용할 AMI ID를 지정합니다. (그림 6)
4. 인스턴스 유형, 보안 그룹 및 기타 설정을 필요에 따라 구성합니다.
5. 사용량, 유휴 종료 시간 같은 자동 확장 옵션을 구성합니다.
6. 구성을 저장합니다.

이 설정을 사용하여 새로 생성된 클라우드 노드를 사용하도록 파이프라인을 할당하고 대기 중인 작업을 실행하기 위한 EC2 인스턴스를 자동으로 생성했습니다. (그림 7)

Jenkins 파이프라인을 정의하는 Jenkinsfile을 위해 다음과 같이 작업 환경을 지정했습니다.

environment { 
     MLM_LICENSE_FILE= '27000@ec2-35-156-32-190.eu-central-1.compute.amazonaws.com' 
} 

또한 다음과 같은 단계 코드를 사용하여 MATLAB 테스트 스크립트를 시작했습니다.

stage('Build and Test') { 
    steps { 
        sh ''' 
matlab -batch "addpath(genpath(cd));\ 
testFile = sltest.testmanager.load('AutonomousEmergencyBrakingTests.mldatx');\ 
testSuite = getTestSuiteByName(testFile,'Test Scenarios');\ 
testCase = getTestCaseByName(testSuite,'scenario_25_AEB_PedestrianTurning_Nearside_10kph');\ 
resultObj = run(testCase);\ 
sltest.testmanager.report(resultObj,'Report.pdf', Title='Autonomous Emergency Braking', IncludeMATLABFigures=true, IncludeErrorMessages=true, IncludeTestResults=0, LaunchReport=false);"' 
        ''' 
    } 
} 

대안 비교: 핵심 요점

클라우드 기반 CI를 위해 VM 또는 컨테이너 중에서 선택할 때는 다음과 같은 여러 측면을 고려하는 것이 좋습니다.

• 설정. AMI(Amazon Machine Image)를 생성하는 작업에는 일반적으로 인스턴스를 시작하고 이 인스턴스에 연결하고 필요한 소프트웨어를 설치하고 이를 AMI로 저장하는 과정이 포함되며, 컨테이너의 경우 이미지를 작성하는 데 필요한 모든 명령이 포함된 Dockerfile 스크립트를 통해 생성됩니다. Python^® 또는 Terraform 스크립트로도 AMI를 생성할 수 있으므로 두 대안 모두 버전이 지정된 인프라 또는 코드형 인프라를 지원합니다. 소규모 프로젝트에서 하나의 이미지가 필요한 경우 설치 과정을 작성하거나 시스템을 구성하는 것에 대한 방대한 지식이 필요하지 않은 AMI를 사용하는 방법이 더 편리할 수 있습니다. 또한 MathWorks에서 제공하지 않은, 컨테이너를 지원하지 않고 수동으로 설치해야 하는 특정 툴을 사용하는 상황에서는 AMI가 유일한 옵션입니다.
• 유지관리. 컨테이너 이미지와 AMI 모두를 생성 스크립트를 수정하는 방법으로 업데이트하고 관리할 수 있습니다. 또한 AMI 또는 컨테이너 이미지에 연결하여 수정한 다음 새 이미지로 저장할 수 있습니다.
• 비용. 컨테이너 이미지는 일반적으로 더 가벼우므로 비용 측면에서 유리합니다.
• 이식성. AMI를 포함한 가상 머신 이미지는 Azure 또는 Google 같은 다른 클라우드 제공 업체로 이전할 수 없습니다. 반면 컨테이너 이미지는 플랫폼 독립적이며 여러 플랫폼에 걸쳐 공유가 가능합니다.
• 운영 체제 지원. 가상 머신 이미지와 컨테이너 이미지 모두 Linux 및 Windows Server^® 등 다양한 운영 체제를 지원합니다. 단, Windows 컨테이너는 GUI를 지원하지 않으므로 여기서 실행되는 애플리케이션은 GUI 없이 실행이 가능해야 합니다.

우리는 이러한 요소를 감안하여 비용 효율성, 이식성, 유연성이 뛰어난 컨테이너 이미지를 대체로 선호합니다. 그러나 테스트를 실행하기 위한 컨테이너 이미지를 다운로드하고 실행할 목적으로 VM 인스턴스를 배포하는 경우, 특히 Windows 데스크탑 지원이 필요하다면 AMI와 같은 가상 머신 이미지가 더 적합한 솔루션일 수 있습니다.

GitHub, GitLab, Jenkins 중의 선택에는 명확한 정답이 없습니다. 각 CI 플랫폼마다 장단점이 있기 때문입니다.

• GitHub는 수많은 워크플로 동작이 있는 마켓플레이스를 제공하지만 차별화되는 사항은 모든 인스턴스 구성과 테스트 단계를 단일 YAML 파일 내에 통합할 수 있다는 것입니다. GitHub는 이 중앙 집중식 접근법 덕분에 개별 테스트 케이스의 종합적인 제어와 관리에 좋은 솔루션입니다. 그러나 유휴 인스턴스 및 유휴 시간 관리와 같은 확장성 제어 옵션은 부족합니다.
• GitLab도 광범위한 클라우드 서비스와의 통합을 용이하게 해주는, 동작 및 플러그인과 비교할 수 있는 다양한 실행기를 제공합니다. 유휴 시간, 하루 중 특정 시간에 사용 가능한 인스턴스 수와 같은 확장성 제어 기능을 제공합니다. 그러나 설정 및 구성 과정이 복잡하고, 특정 하드코딩된 구성을 수정하기 위해서는 러너 관리자 인스턴스에 액세스해야 합니다.
• 우리에게 있어 Jenkins는 설정하고 관리하기가 확실히 쉬웠습니다. GitLab, GitHub에 호스팅되는 리포지토리 또는 기타 웹 기반 Git™ 리포지토리에 웹훅을 사용하여 연결할 수 있으며, 코드가 푸시되면 자동으로 파이프라인을 트리거합니다. Jenkins는 폭넓은 플러그인과 알림 및 플러그인 관리자 시스템을 제공합니다.

결론적으로, 가능한 경우 컨테이너를 사용하고, 어느 CI 플랫폼을 사용할지에 대한 결정은 프로젝트의 구체적인 요구사항 또는 팀의 기존 지식이나 특정 플랫폼 사용과 같은 요소를 기반으로 내리는 것이 좋습니다.