[CI/CD] Blue/Green 무중단 배포 - CodeBuild

DevOps Architecture

본 실습은 위 아키텍처를 기반으로 구현되었다. 아키텍처에 따라 간단하게 흐름 정리를 하면 아래와 같이 설명할 수 있다.

 

1. 개발자는 새로운 기능이나 수정된 코드를 작성하고 이를 Git 저장소(Git Repo)에 커밋한다.
2. 개발자가 커밋한 코드는 Git Repository에 저장된다. 해당 단계에서는 코드가 버전 관리 시스템을 통해 중앙 저장소에 올라가며, 이후 단계에서 빌드 및 배포에 사용된다.
3. AWS CodeBuild는 Git 저장소에서 코드를 가져와 빌드 과정을 수행한다. 코드를 컴파일하고, 필요한 테스트를 수행하며, 최종 배포 가능한 아티팩트를 생성한다.
4. 빌드가 완료된 아티팩트는 S3 버킷에 저장된다.
5. AWS CodeDeploy는 S3에 저장된 애플리케이션 아티팩트를 가져와 Auto Scaling Group에 배포한다. 해당 단계에서는 블루/그린 배포 전략이 적용되어, 새로운 버전(그린)을 배포하면서 기존 버전(블루)을 유지한다.
6. Auto Scaling Group은 서버 인스턴스들을 관리하는 역할을 한다. 블루/그린 배포를 통해 새로운 애플리케이션 버전이 기존 서버에 적용되고, Auto Scaling Group 내에서 인스턴스가 동적으로 스케일링된다.
7. ALB (Application Load Balancer)는 사용자의 요청을 블루 또는 그린 인스턴스 중 하나로 라우팅한다. 즉, ALB는 현재 가동 중인 애플리케이션 인스턴스들 중에서 사용자가 접속할 수 있도록 요청을 적절히 분배하는 역할을 한다.

---

Step 1. Buildspec.yml

CodeBuild를 수행하기 위해서는 Buildspec.yml 파일이 필요하다. 본격적으로 해당 파일을 쓰기에 앞서, buildspec이 무엇이며 어떻게 작성할 수 있는지 알아보고 WebGoat 리포지토리를 활용하여 CodeBuild를 수행하기 위해 buildspec.yml 파일은 어떻게 쓸 수 있을지 알아보자. 

Buildspec.yml 이란?

📂 Buildspec.yml
AWS CodeBuild에서 사용하는 파일로, 빌드 프로세스를 정의한다
→ 즉, 빌드를 실행하는 데 사용되는 빌드 명령 및 관련 설정 (YAML 형식)의 모음

 

buildspec 파일의 특징

• 해당 파일은 소스 디렉터리의 루트에 배치해야 한다
• buildspec 파일의 이름과 상관없이, 한 빌드 프로젝트에 대해 하나의 buildpsec만 지정할 수 있다
• YAML에서 지원하지 않는 문자나 문자열이 명령에 포함된 경우 명령을 따옴표("")로 YAML 묶어야 한다

 

buildspec 파일 구문

version: 0.2

run-as: Linux-user-name

env:
  shell: shell-tag
  variables:
    key: "value"
  parameter-store:
    key: "value"
  exported-variables:
    - variable
  secrets-manager:
    key: secret-id:json-key:version-stage:version-id
  git-credential-helper: no | yes

proxy:
  upload-artifacts: no | yes
  logs: no | yes

batch:
  fast-fail: false | true
  # build-list:
  # build-matrix:
  # build-graph:
        
phases:
  install:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE
    runtime-versions:
      runtime: version
    commands:
      - command
    finally:
      - command
    
  pre_build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE
    commands:
      - command
    finally:
      - command
    
  build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE
    commands:
      - command
    finally:
      - command
    
  post_build:
    run-as: Linux-user-name
    on-failure: ABORT | CONTINUE
    commands:
      - command
    finally:
      - command
    
reports:
  report-group-name-or-arn:
    files:
      - location
    base-directory: location
    discard-paths: no | yes
    file-format: report-format
artifacts:
  files:
    - location
  name: artifact-name
  discard-paths: no | yes
  base-directory: location
  exclude-paths: excluded paths
  enable-symlinks: no | yes
  s3-prefix: prefix
  secondary-artifacts:
    artifactIdentifier:
      files:
        - location
      name: secondary-artifact-name
      discard-paths: no | yes
      base-directory: location
    artifactIdentifier:
      files:
        - location
      discard-paths: no | yes
      base-directory: location
cache:
  paths:
    - path

 

 

|  version

• buildspec 버전을 나타내는 부분으로, 0.2 버전 사용이 권장된다.

 

|  run-as

• 선택적 시퀀스로, Linux 사용자만 사용할 수 있다.
• buildspec 파일의 명령을 실행하는 Linux 사용자를 지정한다.
• 지정한 사용자에게 읽기 및 실행 권한을 부여한다.
• 모든 buildspec 파일 명령에 대한 사용자를 지정하지 않으려는 경우 phases 블록 중 하나에 run-as를 사용하여 단계에 명령에 대한 사용자를 지정할 수 있다.
• run-as를 지정하지 않으면 모든 명령이 루트 사용자로 실행

 

|  env: 선택적 시퀀스로, 하나 이상의 사용자 지정 환경 변수에 대한 정보

• /shell: Linux 또는 Windows 운영 체제에서 지원되는 쉘 지정
  → Linux 운영 체제 쉘 태그 : bash, /bin/sh
  → Windows 운영 체제 쉘 태그 : powershell.exe, cmd.exe
• /variables: env가 지정된 경우 및 사용자 지정 환경 변수를 일반 텍스트로 정의할 때 필요
• /parameter-store: env가 지정되어 있고 Amazon EC2 Systems Manager 파라미터 스토어에 저장된 사용자 정의 환경 변수를 검색하려는 경우 필수
• 이 외에도 secrets-manager, exported-variables, git-credential-helper 등이 있다.

 

|  proxy: 선택적 시퀀스로, 명시적 프록시 서버에서 빌드 실행 시 설정을 나타내는데 사용됨

• upload-artifacts와 logs로 구분될 수 있다.

 

|  phases: 필수 시퀀스로, 빌드의 각 단계에서 CodeBuild 실행되는 명령을 나타냄

• phases/install: 선택적 시퀀스로, 설치 중에 CodeBuild가 실행되는 명령을 나타냄 → 빌드 환경에서 패키지를 설치하는 경우에만 install을 사용하는 것이 좋음
• phases/install/runtime-versions: 하나 이상의 런타임 지정 가능
• phases/pre_build: 빌드 전에 CodeBuild에서 실행되는 명령어가 있는 경우 이를 나타냄
  → phases/pre_build/commands: pre_build를 지정한 경우 필수 시퀀스로, 빌드 전에 CodeBuild 실행되는 단일 명령을 나타냄
• phases/build: 빌드 중에 CodeBuild에서 실행되는 명령어가 있는 경우 이를 나타냄
  → phases/build/commands: build를 지정한 경우 필수 시퀀스로, 빌드 중에 CodeBuild 실행되는 단일 명령을 나타냄
• phases/post_build: 빌드 후에 CodeBuild에서 실행되는 명령어가 있는 경우 이를 나타냄
  Ex) Maven을 사용하여 빌드 아티팩트를 JAR or WAR 파일로 패키징하거나 Docker 이미지를 Amazon으로 푸시할 수 있음
  → phases/post_build/commands: post_build를 지정한 경우 필수 시퀀스로, 빌드 중에 CodeBuild 실행되는 단일 명령을 나타냄

 

|  artifacts: 빌드 출력을 찾을 수 있는 CodeBuild 위치와 S3 버킷에 업로드하기 위해 빌드 출력을 CodeBuild 준비하는 방법에 대한 정보를 나타냄

• artifacts/files: 필수 시퀀스로, 빌드 환경의 빌드 출력 결과물을 포함하는 위치를 나타냄
• artifacts/name: 빌드 아티팩트의 이름 지정 가능
• artifacts/discard-paths: 빌드 아티팩트 디렉터리가 출력에서 평면화되는지 여부 지정
  • 이 값이 지정되지 않거나 no를 포함하는 경우 빌드 아티팩트는 디렉터리 구조가 손상되지 않은 상태로 출력
  • yes가 포함된 경우 모든 빌드 아티팩트가 동일한 출력 디렉터리에 배치
• artifacts/base-directory: 원본 빌드 위치를 기준으로 빌드 출력 아티팩트에 포함할 파일 및 하위 디렉터리를 결정하는 데 CodeBuild 사용하는 하나 이상의 최상위 디렉터리를 나타냄

 

|  cache: 선택적 시퀀스로, 캐시를 S3 캐시 버킷에 업로드하기 위해 파일을 CodeBuild 준비할 수 있는 위치에 대한 정보를 나타냄

• cache/paths: 필수 시퀀스로, 캐시의 위치를 나타냄

 

Buildspec.yml 작성하기

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto17  
  pre_build:
    commands:
      - echo Nothing to do in the pre_build phase...

  build:
    commands:
      - echo Building started on 'date'...
      - pwd && ls && whoami
      - ./mvnw clean install -D skipTests  

  post_build:
    commands:
      - echo Build completed on `date`

artifacts:
  files:
    - target/webgoat-2023.9-SNAPSHOT.jar
    - appspec.yml
    - start.sh

 

[ buildspec.yml 파일 해석 ]

• buildspec.yml 파일의 버전을 0.2로 설정
• phases 섹션에서는 빌드 과정에서 실행할 명령어를 설치, pre-build, post-build로 구분
  • install 단계에서 빌드 환경의 런타임 버전을 JDK 17 버전으로 사용할 수 있도록 설정
  • pre_build 단계에서 echo 명령어 정의
  • build 단계에서 echo 명령어를 정의하고 mvnw를 사용하여 Java 프로젝트를 빌드한다. 이때, clean install 옵션으로 프로젝트 빌드 전 기존의 빌드된 파일을 삭제 후 새롭게 빌드하며, -D skipTests 옵션으로 테스트를 건너띄고 빌드
  • post_build 단계에서 빌드 후 실행되는 명령어들에 대해 정의하여 빌드가 완료된 시간을 출력해줌
• artifacts 섹션은 빌드 후 생성된 아티팩트를 지정하는 부분으로, Maven 빌드 후 생성된 jar 파일을 저장하고 배포를 위한 설정 파일 appspec.yml과 애플리케이션 실행을 위한 start.sh 스크립트 코드도 함께 저장해준다.

 

📂 webgoat-2023.9-SNAPSHOT.jar
📌 jar란?
여러 개의 자바 클래스 파일과 클래스들이 이용하는 관련 리소스 등 메타데이터를 하나의 파일로 모아서 자바 플랫폼에 응용 소프트웨어나 라이브러리를 배포하기 위한 소프트웨어 패키지 파일 포맷

📌 SNAPSHOT.jar란?
SpringBoot에서 SNAPSHOT.jar 파일은 실행 가능한 아카이브임을 의미하고, SNAPSHOT-plain.jar는 실행이 불가능한 아카이브를 의미한다.

📢 WebGoat는 Java 기반으로 작성되었으며, Spring Boot 프레임워크를 사용하여 웹 애플리케이션 구조를 구성하고 있기 때문에 최종 아티팩트로 들어가는 파일의 형태는 ~SNAPSHOT.jar 파일이 되는 것이다.

참고자료
- [Spring] jar 파일 만들어서 빌드하고 실행하기
- https://hyuckang.tistory.com/61

---

Step 2. Appspec.yml

CodeDeploy를 위해서는 appspec.yml 파일을 사용하여 애플리케이션의 배포 단계를 정의해주어야 한다. 이때, 배포 단계를 정의하는 과정에서 애플리케이션을 어디에, 어떻게 배포할지 정의해주는 것 뿐만 아니라 소스 코드 파일의 복사도 명시할 수 있기 때문에 buildspec.yml 파일을 작성한 디렉토리와 같은 디렉토리에 작성해줄 수 있다. 그럼 WebGoat 리포지토리의 CodeDeploy를 위해 appspec.yml 파일이 무엇이고 어떻게 작성할 수 있을지 본격적으로 알아보자.

Appspec.yml 이란?

📂 Appspec.yml
AWS CodeDeploy에서 사용하는 파일로, 애플리케이션의 배포 단계를 정의한다.
→ YAML 형식 또는 CodeDeploy JSON 형식의 파일로, 파일에 정의된 일련의 수명 주기 이벤트 후크로 각 배포를 관리하는 데 사용됨

 

appspec 파일의 특징

✅ AppSpec Amazon ECS 컴퓨팅 플랫폼의 파일

• 배포 중에 Application Load Balancer 또는 Network Load Balancer가 트래픽을 다시 라우팅하는 대체 작업 세트의 컨테이너 및 포트
• Amazon ECS 서비스에 대한 선택적 정보
• Amazon ECS 배포 중에 수명 주기 이벤트에 해당하는 후크 중에 실행할 Lambda 함수

 

✅ AppSpec AWS Lambda 컴퓨팅 플랫폼의 파일

• 배포할 Lambda 함수 버전
• 확인 테스트로 사용할 Lambda 함수

 

✅ AppSpec EC2/온프레미스 컴퓨팅 플랫폼의 파일

• Amazon S3의 애플리케이션 수정 버전에서 인스턴스에 설치해야 하는 내용 또는 GitHub
• 배포 수명 주기 이벤트에 대한 응답으로 실행될 수명 주기 이벤트 후크

 

📌 우리는 이 중 AppSpec을 EC2 컴퓨팅 플랫폼의 목적으로 배포 수명 주기 이벤트 즉, 배포 관리 파일에 대해 배포 방식 및 배포 후 수행 작업을 정의하기 위해 appspec.yml 파일을 작성하고자 한다.

 

appspec.yml 파일 구조

※ 본격적으로 appspec.yml 파일의 구조에 대해 설명하기에 앞서, 본 설명은 WebGoat 리포지토리를 최종적으로 EC2 서버에 배포할 것이기 때문에 EC2 배포에만 해당하는 Files, Permissions, Hooks 세션들에 대해서만 다룰 예정이다. 참고로 본 글에서 다루지 않은 Resources 세션에 대한 내용은 본 글 하단 참고자료 중 AWS 공식 문서에 보면 자세한 설명이 언급되어 있다.

 

|  AppSpec Files Section

: 배포의 Install 이벤트 중에 인스턴스에 설치해야 하는 CodeDeploy 애플리케이션 수정 버전의 파일에 대한 정보를 제공

• source: 인스턴스에 복사할 수정된 파일 또는 디렉토리 식별
  • source가 파일을 나타내는 경우 지정한 파일만 인스턴스에 복사됨
  • source가 디렉터리를 나타내는 경우 디렉터리 내의 모든 파일이 인스턴스에 복사됨
  • source가 슬래시 하나인 경우 수정 버전의 모든 파일이 인스턴스에 복사됨
• destination: 인스턴스에서 파일이 복사되어야 하는 위치를 식별
  • 정규화된 경로이어야 함

 

|  AppSpec Permissions Section

: files 섹션의 파일 및 디렉터리가 인스턴스에 복사된 후 해당 파일 및 디렉터리에 권한이 어떻게 적용되어야 하는지를 지정

• object: 필수 입력 사항으로, 파일 시스템 객체가 인스턴스로 복사된 후 지정한 권한이 적용되는 파일 시스템 객체 세트
• pattern: 권한을 적용할 패턴 지정
  • 따옴표("")가 있는 문자열을 사용하여 지정
  • 지정하지 않거나 특수 문자 "**"를 사용하여 지정하면 권한이 type에 따라 일치하는 모든 파일 또는 디렉터리에 적용됨
• except: 패턴에 대한 예외인 파일 또는 디렉터리 지정
• owner: object의 소유자 이름
• group: object의 그룹 이름
• mode: object에 권한을 지정하는 숫자 값으로 Linux chmod 명령 구문을 따름

 

|  AppSec Hooks Section

: 배포 수명 주기 이벤트 후크를 하나 이상의 스크립트에 연결하는 매핑이 포함되어 있음

• ApplicationStop: 새 애플리케이션을 배포하기 전에 기존 애플리케이션을 중지
• DownloadBundle: AWS S3 버킷 또는 기타 소스에서 새 애플리케이션 버전을 다운로드
• BeforeInstall: 새 애플리케이션이 설치되기 전에 실행되는 단계
• Install: 실제로 새 애플리케이션을 설치하는 단계
• AfterInstall: 애플리케이션 설치 후 실행되는 단계
• ApplicationStart: 새 애플리케이션을 시작하는 단계
• ValidateService: 새 애플리케이션이 올바르게 실행되고 있는지 확인하는 단계
• BeforeAllowTraffic: 새 애플리케이션에 트래픽을 전환하기 전에 실행되는 단계
• AllowTraffic: 실제로 새 애플리케이션으로 트래픽을 전환하는 단계
• AfterAllowTraffic: 트래픽 전환 후 추가 작업을 수행하는 단계

▶ 본 실습에서 진행할 배포 유형은 블루/그린 형태의 배포이므로 아래 이미지의 이벤트 후크 순서대로 실행된다

 

Appspec.yml 작성하기

version: 0.0  # CodeDeploy 버전
os: linux
files:
  - source: / # buildspec.yml에서 생성된 아티팩트 경로에 맞춰 수정
    destination: /home/ubuntu/build/  # 파일을 복사할 대상 경로
    # overwrite: yes

permissions:  # 파일 권한 설정
  - object: /  # 복사된 파일에 대한 권한 설정
    pattern: "**"
    owner: ubuntu
    group: ubuntu
    # mode: 755
    
hooks:
  AfterInstall:  # 배포를 완료한 후 실행되는 스크립트
    - location: start.sh
      timeout: 60
      runas: ubuntu

 

[ appspec.yml 파일 해석 ]

• version: 0.0
  • appspec.yml 파일의 버전을 0.0으로 설정
• os: linux
  • 애플리케이션이 배포될 대상 운영 체제를 리눅스로 지정
• files
  • 아티팩트가 저장된 위치 즉, source를 '/'인 루트 디렉토리로 설정하여 buildspec.yml에서 생서된 아티팩트 경로와 일치해야 함
  • 아티팩트가 복사될 대상 서버의 경로인 destination을 '/home/ubuntu/build'로 설정하여 모든 파일 및 디렉토리를 '/home/ubuntu/build' 디렉토리로 복사
• permissions
  • 복사된 파일들에 대해 권한을 설정할 대상을 루트 디렉토리로 지정
  • 모든 파일과 디렉토리에 대해 권한을 적용하기 위해 **로 모든 파일을 의미하는 패턴 설정
  • 복사된 파일들의 소유자를 ubuntu 사용자로 설정하고 ubuntu 그룹에 속하도록 설정함
• hooks
  • 파일 복사 및 배포가 완료된 후에 실행될 스크립트에 대해 AfterInstall 단계로 정의
  • start.sh 파일 실행
  • 스크립트 실행 제한 시간을 60초 설정
  • ubuntu 사용자 권한으로 실행될 수 있도록 runas 설정

---

Step 3. Start.sh

📢 Start.sh가 필요한 이유

• WebGoat 애플리케이션이 CodeDeploy를 통해 배포된 후 자동으로 애플리케이션을 실행하고, 환경 설정 및 서버 준비 작업 등을 처리하기 위해 필요하다.
• 해당 파일을 통해 애플리케이션이 자동으로 시작되고, 서버에서 안정적으로 실행될 수 있다.
• 스프링부트 애플리케이션인 WebGoat를 'java -jar' 명령어로 실행해줄 수 있다.
• 애플리케이션 시작 과정에서 발생할 수 있는 에러 및 로그를 남기는 역할도 할 수 있다.

 

Start.sh 작성하기

#!/bin/bash

JARFILE=$(ls /home/ubuntu/build/target/*.jar)
echo "filename : $JARFILE" >> startsh.log

CURRENT_PID=$(pgrep -f $JARFILE)
echo "currentpid : $CURRENT_PID" >> startsh.log
kill -9 $CURRENT_PID 2>/dev/null
sleep 5

nohup java -jar $JARFILE > /dev/null 2> /dev/null < /dev/null &

 

[ start.sh 파일 해석 ]

• '/home/ubuntu/build/target/' 디렉토리에서 .jar 파일을 찾아 경로를 JARFILE 변수에 저장하고 해당 파일 경로를 startsh.log 파일에 기록
• pgrep 명령어로 현재 실행 중인 애플리케이션의 PID를 찾아 CURRENT_PID 변수에 저장하고, 이를 startsh.log에 기록
• 현재 실행 중인 애플리케이션이 있을 경우 'kill -9' 명령어로 강제 종료
• '2>/dev/null' 오류 메시지를 무시하고 출력하지 않도록 설정
• 강제로 애플리케이션을 종료한 후 5초간 대기하여 애플리케이션이 완전히 종료되도록 여유를 줌
• nohup을 사용하여 JAR 파일을 백그라운드에서 실행
  • 표준 출력, 오류 출력, 표준 입력을 모두 /dev/null로 리디렉션하여 아무런 출력도 발생하지 않게 설정
  • &를 사용하여 애플리케이션을 백그라운드에서 실행

---

Step 4. CodeBuild 설정

위 이미지와 같이 WebGoat 깃허브 레포지토리를 fork해서 내 레포지토리로 복제한 후 앞선 단계에서 설명했던 buildspec.yml, appspec.yml, start.sh 파일을 깃허브 레포지토리 내에 추가해주었다.

 

CodeBuild로 이동 후 '프로젝트 빌드' 탭에서 '프로젝트 생성' 버튼을 누른다

 

생성할 빌드 프로젝트의 이름을 설정한다

 

소스 설정 부분에서 우리는 Git Repository 내에 있는 WebGoat 레포지토리를 가져올 것이기 때문에 소스 공급자로 'Github'를 선택한다. 자격 증명 및 유형의 경우 '사용자 지정 소스 자격 증명'과 'OAuth' 앱을 사용하여 보안 암호까지 연결할 수 있다. 리포지토리는 '내 GitHub 계정의 리포지토리'를 선택하고 우리가 WebGoat를 자신의 계정으로 fork를 수행한 해당 링크를 리포지토리의 경로를 넣는 부분에 넣어준다.

 

환경의 경우 기본 설정 그대로 진행하고

 

서비스 역할은 WebGoat 빌드를 위해 생성해둔 역할을 선택하고 (만약 사전에 생성해둔 역할이 따로 없다면 '새 서비스 역할'을 클릭하여 새로운 역할을 생성해줄 수 있다.) 깃허브 레포지토리 내에 있는 buildspec.yml 파일을 사용하고자 'buildspec 파일 사용'과 'buildspec.yml'의 이름을 입력해줄 수 있다.

 

아티팩트의 경우 S3 버킷에 저장할 것이기 때문에 유형에는 'Amazon S3'를 선택하고 버킷 이름과 아티팩트를 저장할 압축 파일의 이름을 설정해주고 zip 형식으로 압축될 수 있도록 아티팩트 패키징을 'Zip'으로 선택한다.

 

'빌드 프로젝트 생성'을 클릭하여 빌드 프로젝트를 생성해준다

 

생성된 빌드 프로젝트에서 우측 상단의 '빌드 시작' 버튼을 눌러 빌드를 진행해준다.

 

빌드 진행 후, 빌드가 오류없이 모두 성공적으로 진행되었다면 위 이미지와 같이 모든 빌드가 성공적으로 마무리 된 것을 볼 수 있다.

 

빌드 아티팩트가 잘 들어가졌는지 확인해보고자 S3로 이동해서 확인해본 결과, CodeBuild 생성 과정에서 설정한 이름으로 zip 파일이 생성된 것을 볼 수 있었고

 

압축 파일을 다운로드 받아서 확인해보니 해당 buildspec.yml 파일에서 아티팩트로 저장하기 위해 설정했었던 target/webgoat-2023.9-SNAPSHOT.jar, appspec.yml, start.sh 파일이 모두 들어있는 것을 확인할 수 있다.

---

주의사항

WebGoat 레포지토리를 이용해서 CodeBuild를 구현하는 과정에서 몇가지 주의할 부분을 아래와 같이 정리해보았다.

1. 올바른 파일 경로 설정

복제 작업을 수행한 WebGoat 레포지토리에 추가로 작성한 buildspec.yml, appspec.yml, start.sh 와 관련하여 각 파일들을 저장한 경로에 따라 빌드의 성공 여부가 달라질 수 있으므로 주의해야 한다.

 

buildspec.yml 파일의 경우 AWS CodeBuild에서 빌드 프로세스를 정의하는 중요한 파일로, CodeBuild는 루트 디렉터리에서 해당 파일을 찾기 때문에 루트 즉, 최상위 디렉터리에 위치할 수 있도록 해주어야 한다. 만약, 해당 파일이 최상위 디렉터리에 없다면 CodeBuild가 이를 인식하지 못하고 빌드 과정이 중단될 수 있다.

 

appspec.yml 파일은 AWS CodeDeploy에서 애플리케이션의 배포 단계를 정의하여 해당 위치가 정확하지 않으면 배포 프로세스가 실패할 수 있다. 해당 파일은 배포 시 아티팩트로 복사되며, 빌드된 결과물과 함께 전달된다. 따라서 buildspec.yml에서 아티팩트에 포함되었는지 확인하고, 배포 후에 정확한 경로에 위치해야 한다.

 

start.sh 파일은 애플리케이션을 배포한 후 자동으로 실행하는 스크립트로 애플리케이션의 시작을 관리해주기 때문에 해당 파일이 배포된 인스턴스에서 정확한 경로에 있어야 appspec.yml에서 이를 참조하여 올바른 실행이 가능하다.

 

2. Java 버전 및 환경 설정

WebGoat는 Spring Boot 기반의 애플리케이션으로 빌드와 실행을 위해 Java를 필요로 한다. 이때, buildspec.yml 파일 내에 install 섹션에 올바른 Java 버전을 명시해주어야 한다. 일반적으로 Amazon Corretto나 OpenJDK 17을 사용하지만, 복제한  WebGoat의 버전에 따라 17이 아닌 다른 버전을 사용하고 있을 수 있기 때문에 한번 더 확인 과정을 거친 후 작성해주어야 한다.

 

 

📂 출처 & 참고자료
- https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/reference-appspec-file-structure-files.html
- https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/build-spec-ref.html
- https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/concepts.html#concepts-how-it-works