웹 개발 파이프라인 구축(4)

이미지 레지스트리 구성

인수 테스트 (UAT; User Acceptance Test)

요구사항 (requirement)대로 기능이 구현되엇는지를 확인하는 과정

• 전체 시스템을 사용자 관점에서 시험하는 블랙박스 테스트를 포함

이것을 자동화하는 것은 쉽지 않은 일이지만 CI/CD의 구축을 위해 반드시 필요

• 전통적으로는 QA 담당자나 사용자의 수작업에 의존해 왔음

사용자 인수 테스트를 자동화하는 것이 어려운 요인들

• 사용자 참여: 기술적 측면과 비기술적 측면에 대한 요구사항의 최종 확인은 실사용자여야 함
• 의존성 통합: 테스트할 애플리케이션은 모든 의존성을 포함하여 실행되어야 함
• 스테이징 환경: 프로덕션 환경과 동일한 스테이징(테스트) 환경에서 이루어져야 함
• 애플리케이션 동일성: 한 번만 빌드하여 프로덕션에서와 동일한 바이너리를 이용해야 함
• 틸리스 준비: 인수 테스트를 통과한 애플리케이션은 즉시 릴리스 준비가 되어야 함

아티팩트 리포지토리 (Artifact Repository)

🔸버전관리, 접근 제어 등의 기능을 가지는 소프트웨어 개발 산출물(예: 패키지)을 발행(푸시)하거나

인출(풀) 할 수 있는 저장소 및 관리 기법이 필요

🔸파이프라인의 모든 단계에서 동일한 바이너리가 사용되는 것을 보장함으로써

지속적 인도 프로세스에서 매우 중요한 역할을 함

도커 레지스트리 (Docker Registry)

컨테이너화된 소프트웨어의 산출물인 도커 이미지를 관리할 수 있는 리포지토리

클라우드 방식 레지스트리

• Docker Hub (및 이와 유사한 기능을 제공하는 레지스트리 서비스들)

자체 호스팅 방식 레지스트리

• 사내 네트워크가 아닌 외부에 소프트웨어를 보관하는 것을 금지하는 정책을 갖고 있는 경우에는 유일한 해결 방법
• 직접 관리해야 하는 부담이 있고 접근 제어 및 인증서 설정 등의 번거로운 작업이 수반됨

데이터 볼륨과 SSL 인증서

호스트의 디렉토리를 레지스트리에 볼륨으로 공유

• 레지스트리에 저장된 데이터는 컨테이너 및 포드 등이 사멸하는 경우에도 유지할 수 있도록
• 실제 개발 환경에서는 어딘가 저장 장소를 마련해 두고 주기적으로 백업하는 방법을 택할 것이겠으나.
  • 우리 실습에서는 호스트의 파일시스템 내 특정 위치에 데이터가 저장되도록 설정
• PV를 정의하고 PVC를 설정하여 레지스트리 서버 컨테이너에서 이용하도록 볼륨 마운트

자가 서명된 (self-signed) 인증서 발급하여 레지스트리에 서버에 설치

• 실제 운용 환경에서는 CA (certificate authority)로부터 발급받은 인증서를 설치하고
  • 주기적으로 갱신하여 공인할 수 있는 인증을 이용할 것
• 우리 실습에서는 간이로 자가 서명 인증서를 발급하고 이것을 레지스트리 서버에 설치
  • 다음 실습에서는 이 레지 스트리를 이용하려는 쪽의 컨테이너에도 인증 설정

자가 서명 인증서 발급

OpenSSl을 이용한 인증서 발급 및 설치

• 우선 openssl이 설치되어 있음을 확인 (그렇지 않다면 적당한 방법을 찾아서 설치)

openssl req\
-newkey rsa:4096 -nodes -sha256 -keyout certs/registry.key \
-addext "subjectAltName = DNS:registry-service.registry.svc.cluster.local" \
-x509 -days 3650 -out certs/registry.crt

• k8s의 secret으로 등록

kubectl create secret tls registry-cert \
--cert=certs/registry.crt \
--key=certs/registry.key \
-n registry

접근제어

보통은 login id와 password의 쌍으로 사용자 인증

• 로그인하는 사용자에 따라 서로 다른 권한을 적용

간단한 인수 테스트

Jenkins 파이프라인에서의 인수 테스트

1. 개발자가 변경한 코드를 GitHub에 푸시

2. Jenkins가 변경을 감지하고 코드를 인출해 빌드를 시작,

코드를 점검 (단위테스트 수행)

3. Jenkins가 빌드를 완료하여 도커 이미지를 생성

4. Jenkins가 생성한 이미지를 레지스트리로 푸시

5. Jenkins가 스테이징 환경을 구성하고 도커 컨테이너 실행

6. 스테이징 환경의 도커 호스트가 이미지를 가져다가(풀) 컨테이너를 실행

7. Jenkins가 스테이징 환경에서 실행 중인 애플리케이션을 대상으로 인수 테스트를 실행

인수 테스트 파이프라인 스테이지들

애플리케이션 빌드 스테이지: stage("Package")

도커 이미지 빌드 스테이지 : stage("Docker Build")

🔸Docker daemon 실행에는 'dind' 컨테이너를 추가로 설정/실행하여 이용

도커 푸시 스테이지 : stage("Docker Push")

🔸 Docker daemon이 레지스트리를 인즐할 수 있도록 'docker:latest'에 인증서를 추가하여

'dind'의 스펙 구성

인수 테스트 스테이지 : stage("Acceptance Test")

빌드에 사용할 컨테이너 설정 (1)

컨테이너 'jnlp'

• JNPL 실행 및 docker와 kubectl 클라이언트 기능 담당

참고: Dockerfile-jnlp (kubectl 클라이언트를 jnlp-agent-docker 위에 설치)

빌드에 사용할 컨테이너 설정 (2)

컨테이너 'dind'

• Docker daemon의 기능을 담당

Dockerfile-dind (docker:latest 위에 자가 서명 인증서를 설치)

테스트 자동화를 위한 리포지토리 설정

GitHub 소스 리포지토리에 다음 두 개의 파일을 추가

• Dockerfile
  • 로컬 도커 환경에서 docker build 및 docker run을 이용해서
    • 이미지가 잘 빌드될 것 같다는 생각을 확인한 바 있으므로 파일 커밋
• acceptance_test.sh
  • 자동화된 인수 테스트를 수행하기 위해서 테스트 스크립트도 코드 리포지토리에 등록

작업용 임시 파이프라인 만들기

기존에 설정한 파이프라인에서 "Poll SCM" 옵션을 잠시 꺼 두고

• GitHub 리포지토리에 푸시가 일어날 때마다 파이프라인이 트리거되는 것을 막아 두기 위함

시험을 위한 새로운 Jenkins  아이템을 생성

• 리포지토리의 Jenkinsfile 내용을 가져다가 Pipeline Script로 입력
• 단, "Checkout" 스테이지의 "chekout scm"은 이전에 이용했던 방식을 적용하여
  • GitHub 리포지토리 주소와 credentials 정보를 적용한 내용을 변경

지금까지 구성한 단계가 성공적으로 동작함을 확인 (Build Now)

• Checkout > Compile > Unit Test > code Coverage > Static Analysis

인수 테스트 프레임워크 적용

사용자 대면 테스트

REST API의 경우에는 curl에 의한 테스트로도 (기술적으로는) 어느 정도 블랙박스 테스트가 가능

그러나, 일반적으로는 이런 테스트에 의존할 수 없음

• 읽고 이해하기가 어려움 (특히 비기술 영역 사용자에게)
• 유지보수 불리함

사용자와 함게 작성할 수 잇고 사용자가 이해할 수 있는 테스트 작성 방법이 필요

• 특정한 목적(사업적 가치)를 반영하는 인수 테스트

BDD (Behavior-Driven Development)

사용자(또는 프로덕트 오너)가 인수 기준을 제시

위 인수 기준으로부터 개발자는 픽스터(fixture) 또는 스텝 정의(step definitions)라고 부르는 사용자 친화적인 DSL(domain-specific language)와 프로그래밍 언어를 통합해서 테스트를 작성

 

도구들

• Cucumber
• Selenium

Cucumber를 이용한 인수 테스트 생성

인수 기준 생성

• 특정 파일에 비즈니스 사양을 명세

스텝 정의 작성

• 기능 사양을 실행할 수 있는 Java 바인딩을 생성

자동 인수 테스트 실행

• Gradle 설정에 라이브러리 의존성 명세 추가
• Gradle 태스크와 Junit 테스트 러너를 추가

(중요) 여기에서는 cucumber를 이용한 테스트가 아니라 인수 테스트 자동화에 관심과 중점

TDD (Test-Driven Development)

(중요) 인수 테스트는 기술보다 사람이 중심

• 지속적 인도 프로세스의 다른 단계들도 마찬가지

소프트웨어 개발 수명 주기 중 어느 시점에 테스트 작성?

• 코딩 전 || 코딩 후 ?
• TDD는 특히 인수 테스트에 적합

인수 기준 사양을 먼저 작성

• 인수 테스트 통과를 기능 구현 완료로 간주
• 이슈 추적 도구의 요청 티켓에 기능 사양을 첨부하는 방법도