지속적인 통합을 위해 Docker에서 마이크로서비스 자동 테스트

마이크로서비스 아키텍처 개발과 관련된 프로젝트에서 CI/CD는 즐거운 기회의 범주에서 긴급한 필요성의 범주로 이동합니다. 자동화된 테스트는 팀에게 가족 및 친구들과 함께 즐거운 저녁 시간을 보낼 수 있는 유능한 접근 방식인 지속적인 통합의 필수적인 부분입니다. 그렇지 않으면 프로젝트가 완료되지 않을 위험이 있습니다.

모의 객체를 사용한 단위 테스트로 전체 마이크로서비스 코드를 포괄하는 것이 가능하지만 이는 문제를 부분적으로만 해결하고 특히 데이터 작업을 테스트할 때 많은 질문과 어려움을 남깁니다. 항상 그렇듯이 가장 시급한 작업은 관계형 데이터베이스의 데이터 일관성 테스트, 클라우드 서비스 작업 테스트, 모의 개체 작성 시 잘못된 가정을 하는 것입니다.

Docker 컨테이너에서 전체 마이크로서비스를 테스트하면 이 모든 문제와 그 이상의 문제를 해결할 수 있습니다. 테스트의 유효성을 보장하는 데 있어 의심할 여지 없는 이점은 프로덕션에 사용되는 동일한 Docker 이미지가 테스트된다는 것입니다.

이 접근 방식을 자동화하면 여러 가지 문제가 발생하며 이에 대한 해결책은 아래에 설명되어 있습니다.

• 동일한 도커 호스트에서 병렬 작업의 충돌;
• 테스트 반복 중 데이터베이스의 식별자 충돌;
• 마이크로서비스가 준비되기를 기다리는 중입니다.
• 로그를 외부 시스템에 병합하고 출력합니다.
• 나가는 HTTP 요청 테스트
• 웹 소켓 테스트(SignalR 사용)
• OAuth 인증 및 승인 테스트.

이 기사는 다음을 기반으로 합니다. 나의 연설 SECR 2019에서. 그래서 책 읽기가 너무 귀찮은 분들을 위해, 여기 연설 녹음이 있습니다.

이 기사에서는 스크립트를 사용하여 Docker에서 테스트 중인 서비스, 데이터베이스 및 Amazon AWS 서비스를 실행한 다음 Postman에서 테스트하고 완료되면 생성된 컨테이너를 중지하고 삭제하는 방법을 설명합니다. 코드가 변경될 때마다 테스트가 실행됩니다. 이런 방식으로 우리는 각 버전이 AWS 데이터베이스 및 서비스에서 올바르게 작동하는지 확인합니다.

Windows 데스크톱의 개발자와 Linux의 Gitlab CI 서버 모두 동일한 스크립트를 실행합니다.

정당화하려면 새로운 테스트를 도입할 때 개발자의 컴퓨터나 커밋에서 테스트가 실행되는 서버에 추가 도구를 설치할 필요가 없어야 합니다. Docker는 이 문제를 해결합니다.

테스트는 다음과 같은 이유로 로컬 서버에서 실행되어야 합니다.

• 네트워크는 결코 완전히 신뢰할 수 없습니다. 수천 개의 요청 중 하나가 실패할 수 있습니다.
  이 경우 자동 테스트가 작동하지 않고 작업이 중지되며 로그에서 이유를 찾아야 합니다.
• 일부 타사 서비스에서는 너무 빈번한 요청을 허용하지 않습니다.

또한 다음과 같은 이유로 스탠드를 사용하는 것은 바람직하지 않습니다.

• 스탠드는 잘못된 코드가 실행될 때뿐만 아니라 올바른 코드가 처리할 수 없는 데이터로 인해 손상될 수도 있습니다.
• 테스트 중에 테스트로 인해 발생한 모든 변경 사항을 되돌리려고 아무리 노력해도 문제가 발생할 수 있습니다(그렇지 않으면 테스트할 이유가 무엇입니까?).

프로젝트 및 프로세스 조직 정보

우리 회사는 Amazon AWS 클라우드의 Docker에서 실행되는 마이크로서비스 웹 애플리케이션을 개발했습니다. 프로젝트에는 단위 테스트가 이미 사용되었지만 단위 테스트에서 감지하지 못하는 오류가 자주 발생했습니다. 데이터베이스 및 Amazon 서비스와 함께 전체 마이크로서비스를 테스트해야 했습니다.

이 프로젝트는 모든 커밋에서 마이크로서비스 테스트를 포함하는 표준 연속 통합 프로세스를 사용합니다. 작업을 할당한 후 개발자는 마이크로서비스를 변경하고 수동으로 테스트하며 사용 가능한 모든 자동화 테스트를 실행합니다. 필요한 경우 개발자는 테스트를 변경합니다. 문제가 발견되지 않으면 이 문제의 분기에 커밋이 이루어집니다. 커밋할 때마다 테스트가 서버에서 자동으로 실행됩니다. 성공적인 검토 후에 공통 분기에 병합하고 자동 테스트를 시작합니다. 공유 브랜치의 테스트를 통과하면 Amazon Elastic Container Service(벤치)의 테스트 환경에서 서비스가 자동으로 업데이트됩니다. 스탠드는 모든 개발자와 테스터에게 꼭 필요한 제품이므로 부수는 것은 바람직하지 않습니다. 이 환경의 테스터는 수동 테스트를 수행하여 수정 사항이나 새로운 기능을 확인합니다.

프로젝트 아키텍처

이 애플리케이션은 XNUMX개 이상의 서비스로 구성됩니다. 그 중 일부는 .NET Core로 작성되고 일부는 NodeJ로 작성되었습니다. 각 서비스는 Amazon Elastic Container Service의 Docker 컨테이너에서 실행됩니다. 각각에는 자체 Postgres 데이터베이스가 있고 일부에는 Redis도 있습니다. 공통 데이터베이스가 없습니다. 여러 서비스에 동일한 데이터가 필요한 경우 이 데이터가 변경되면 SNS(Simple Notification Service) 및 SQS(Amazon Simple Queue Service)를 통해 각 서비스로 전송되고 서비스는 이를 별도의 데이터베이스에 저장합니다.

SQS와 SNS

SQS를 사용하면 메시지를 대기열에 넣고 HTTPS 프로토콜을 사용하여 대기열에서 메시지를 읽을 수 있습니다.

여러 서비스가 하나의 대기열을 읽는 경우 각 메시지는 그 중 하나에만 도착합니다. 이는 동일한 서비스의 여러 인스턴스를 실행하여 인스턴스 간에 로드를 분산시킬 때 유용합니다.

각 메시지를 여러 서비스에 전달하려면 각 수신자에게 자체 대기열이 있어야 하며 메시지를 여러 대기열에 복제하려면 SNS가 필요합니다.

SNS에서는 주제(예: SQS 대기열)를 생성하고 구독합니다. 주제에 메시지를 보낼 수 있습니다. 이 경우 메시지는 이 주제를 구독하는 각 대기열로 전송됩니다. SNS에는 메시지를 읽는 방법이 없습니다. 디버깅 또는 테스트 중에 SNS로 전송된 내용을 찾아야 하는 경우 SQS 대기열을 생성하고 원하는 주제를 구독한 후 대기열을 읽을 수 있습니다.

API 게이트웨이

대부분의 서비스는 인터넷에서 직접 액세스할 수 없습니다. 접근은 접근권한을 확인하는 API Gateway를 통해 이루어집니다. 이것은 또한 우리의 서비스이며 이에 대한 테스트도 있습니다.

실시간 알림

응용 프로그램이 사용하는 시그널R사용자에게 실시간 알림을 표시합니다. 이는 알림 서비스에서 구현됩니다. OAuth와 알림 서비스를 통합하는 것에 비해 웹 소켓에 대한 지원을 게이트웨이에 구축하는 것이 비현실적인 것으로 밝혀졌기 때문에 인터넷에서 직접 액세스할 수 있고 자체적으로 OAuth와 함께 작동합니다.

잘 알려진 테스트 접근 방식

단위 테스트는 데이터베이스와 같은 것을 모의 개체로 대체합니다. 예를 들어 마이크로서비스가 외래 키를 사용하여 테이블에 레코드를 생성하려고 하는데 해당 키에서 참조하는 레코드가 존재하지 않으면 요청을 실행할 수 없습니다. 단위 테스트에서는 이를 감지할 수 없습니다.

В 마이크로소프트의 기사 메모리 내 데이터베이스를 사용하고 모의 객체를 구현하는 것이 제안됩니다.

인메모리 데이터베이스는 Entity Framework에서 지원하는 DBMS 중 하나입니다. 테스트용으로 특별히 제작되었습니다. 이러한 데이터베이스의 데이터는 해당 데이터베이스를 사용하는 프로세스가 종료될 때까지만 저장됩니다. 테이블을 생성할 필요가 없으며 데이터 무결성을 확인하지 않습니다.

모의 객체는 테스트 개발자가 작동 방식을 이해하는 정도까지만 대체하는 클래스를 모델링합니다.

테스트를 실행할 때 Postgres가 자동으로 시작되고 마이그레이션을 수행하도록 하는 방법은 Microsoft 문서에 지정되어 있지 않습니다. 내 솔루션은 이를 수행하며, 또한 마이크로서비스 자체에 대한 테스트용으로 특별히 코드를 추가하지 않습니다.

솔루션으로 넘어 갑시다

개발 과정에서 단위 테스트만으로는 모든 문제를 적시에 찾아내기에 충분하지 않다는 것이 분명해졌기 때문에 이 문제에 대해 다른 각도에서 접근하기로 결정했습니다.

테스트 환경 설정

첫 번째 작업은 테스트 환경을 배포하는 것입니다. 마이크로서비스를 실행하는 데 필요한 단계:

• 로컬 환경에 대해 테스트 중인 서비스를 구성하고, 환경 변수에서 데이터베이스 및 AWS에 연결하기 위한 세부 정보를 지정합니다.
• Postgres를 시작하고 Liquibase를 실행하여 마이그레이션을 수행합니다.
  관계형 DBMS에서는 데이터베이스에 데이터를 쓰기 전에 데이터 스키마, 즉 테이블을 생성해야 합니다. 애플리케이션을 업데이트할 때 테이블은 새 버전에서 사용되는 형식으로 가져와야 하며, 가급적 데이터 손실 없이 가져와야 합니다. 이것을 마이그레이션이라고 합니다. 처음에 비어 있던 데이터베이스에 테이블을 만드는 것은 마이그레이션의 특별한 경우입니다. 마이그레이션은 애플리케이션 자체에 내장될 수 있습니다. .NET과 NodeJS에는 모두 마이그레이션 프레임워크가 있습니다. 우리의 경우 보안상의 이유로 마이크로서비스에는 데이터 스키마를 변경할 수 있는 권한이 박탈되었으며 마이그레이션은 Liquibase를 사용하여 수행됩니다.
• Amazon LocalStack을 시작합니다. 이는 집에서 실행할 수 있는 AWS 서비스의 구현입니다. Docker Hub에는 LocalStack용으로 미리 만들어진 이미지가 있습니다.
• 스크립트를 실행하여 LocalStack에 필요한 엔터티를 생성합니다. 셸 스크립트는 AWS CLI를 사용합니다.

프로젝트 테스트에 사용됨 우편 집배원. 이전에도 존재했지만 수동으로 실행되었으며 이미 스탠드에 배포된 애플리케이션을 테스트했습니다. 이 도구를 사용하면 임의의 HTTP(S) 요청을 수행하고 응답이 예상한 대로인지 확인할 수 있습니다. 쿼리는 컬렉션으로 결합되며 전체 컬렉션을 실행할 수 있습니다.

자동 테스트는 어떻게 작동하나요?

테스트 중에는 테스트 중인 서비스, Postgres, 마이그레이션 도구, Postman 또는 해당 콘솔 버전인 Newman 등 모든 것이 Docker에서 작동합니다.

Docker는 다음과 같은 여러 문제를 해결합니다.

• 호스트 구성과의 독립성
• 종속성 설치: Docker는 Docker Hub에서 이미지를 다운로드합니다.
• 시스템을 원래 상태로 되돌리기: 간단히 컨테이너를 제거하면 됩니다.

Docker 작성 컨테이너를 인터넷에서 격리된 가상 네트워크로 통합합니다. 여기서 컨테이너는 도메인 이름으로 서로를 찾습니다.

테스트는 쉘 스크립트에 의해 제어됩니다. Windows에서 테스트를 실행하려면 git-bash를 사용합니다. 따라서 Windows와 Linux 모두에 하나의 스크립트로 충분합니다. Git 및 Docker는 프로젝트의 모든 개발자가 설치합니다. Windows에 Git을 설치하면 git-bash가 설치되므로 모두가 이를 가지고 있습니다.

스크립트는 다음 단계를 수행합니다.

• 도커 이미지 빌드

  docker-compose build

• 데이터베이스 및 LocalStack 실행

  docker-compose up -d <контейнер>

• 데이터베이스 마이그레이션 및 LocalStack 준비

  docker-compose run <контейнер>

• 테스트 중인 서비스 출시

  docker-compose up -d <сервис>

• 테스트 실행(Newman)
• 모든 컨테이너 중지

  docker-compose down

• Slack에 결과 게시
  녹색 확인 표시나 빨간색 십자가가 있는 메시지와 로그 링크가 있는 채팅이 있습니다.

이러한 단계에는 다음 Docker 이미지가 포함됩니다.

• 테스트 중인 서비스는 프로덕션과 동일한 이미지입니다. 테스트 구성은 환경 변수를 통해 이루어집니다.
• Postgres, Redis 및 LocalStack의 경우 Docker Hub에서 미리 만들어진 이미지가 사용됩니다. Liquibase 및 Newman용 기성 이미지도 있습니다. 우리는 그들의 뼈대 위에 우리의 것을 만들고 거기에 파일을 추가합니다.
• LocalStack을 준비하려면 미리 만들어진 AWS CLI 이미지를 사용하고 이를 기반으로 하는 스크립트가 포함된 이미지를 생성합니다.

사용 볼륨, 컨테이너에 파일을 추가하기 위해 Docker 이미지를 빌드할 필요가 없습니다. 그러나 Gitlab CI 작업 자체가 컨테이너에서 실행되기 때문에 볼륨은 우리 환경에 적합하지 않습니다. 이러한 컨테이너에서 Docker를 제어할 수 있지만 볼륨은 다른 컨테이너가 아닌 호스트 시스템의 폴더만 탑재합니다.

발생할 수 있는 문제

준비를 기다리는 중

서비스가 포함된 컨테이너가 실행 중이라고 해서 연결을 수락할 준비가 되었다는 의미는 아닙니다. 연결이 계속될 때까지 기다려야 합니다.

이 문제는 때때로 스크립트를 사용하여 해결됩니다. 기다려라.sh, TCP 연결을 설정할 기회를 기다립니다. 그러나 LocalStack에서 502 Bad Gateway 오류가 발생할 수 있습니다. 또한 많은 서비스로 구성되어 있으며 그중 하나가 준비되어 있으면 다른 서비스에 대해서는 아무 말도하지 않습니다.

결정: SQS와 SNS 모두에서 200 응답을 기다리는 LocalStack 프로비저닝 스크립트입니다.

병렬 작업 충돌

동일한 Docker 호스트에서 여러 테스트를 동시에 실행할 수 있으므로 컨테이너 및 네트워크 이름은 고유해야 합니다. 또한 동일한 서비스의 여러 분기의 테스트도 동시에 실행될 수 있으므로 각 작성 파일에 이름을 쓰는 것만으로는 충분하지 않습니다.

결정: 스크립트는 COMPOSE_PROJECT_NAME 변수를 고유한 값으로 설정합니다.

윈도우 기능

Windows에서 Docker를 사용할 때 지적하고 싶은 사항이 많이 있습니다. 이러한 경험은 오류가 발생하는 이유를 이해하는 데 중요하기 때문입니다.

1. 컨테이너의 셸 스크립트에는 Linux 줄 끝이 있어야 합니다.
   쉘 CR 기호는 구문 오류입니다. 오류 메시지에서는 이것이 사실인지 알기가 어렵습니다. Windows에서 이러한 스크립트를 편집하려면 적절한 텍스트 편집기가 필요합니다. 또한 버전 관리 시스템도 적절하게 구성되어야 합니다.

Git이 구성되는 방식은 다음과 같습니다.

git config core.autocrlf input

1. Git-bash는 표준 Linux 폴더를 에뮬레이트하고 exe 파일(docker.exe 포함)을 호출할 때 절대 Linux 경로를 Windows 경로로 바꿉니다. 그러나 이는 로컬 시스템에 없는 경로(또는 컨테이너의 경로)에는 적합하지 않습니다. 이 동작은 비활성화할 수 없습니다.

결정: 경로 시작 부분에 추가 슬래시를 추가합니다(/bin 대신 //bin). Linux는 이러한 경로를 이해하므로 여러 개의 슬래시가 하나와 동일합니다. 그러나 git-bash는 그러한 경로를 인식하지 못하고 변환을 시도하지 않습니다.

로그 출력

테스트를 실행할 때 Newman과 테스트 중인 서비스의 로그를 모두 보고 싶습니다. 이러한 로그의 이벤트는 서로 연결되어 있으므로 하나의 콘솔에 결합하는 것이 두 개의 별도 파일보다 훨씬 편리합니다. Newman은 다음을 통해 출시됩니다. 도커 작성 실행, 그리고 출력은 콘솔에서 끝납니다. 남은 것은 서비스의 출력도 해당 위치로 이동하는지 확인하는 것입니다.

원래 해결책은 다음과 같습니다. 도커 - 작성 깃발 없음 -d, 그러나 셸 기능을 사용하여 이 프로세스를 백그라운드로 보냅니다.

docker-compose up <service> &

이는 Docker에서 타사 서비스로 로그를 전송해야 할 때까지 작동했습니다. 도커 - 작성 콘솔에 로그 출력을 중지했습니다. 그러나 팀은 일했습니다. 도커 부착.

결정:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

테스트 반복 중 식별자 충돌

테스트는 여러 번 반복하여 실행됩니다. 데이터베이스가 지워지지 않습니다. 데이터베이스의 레코드에는 고유 ID가 있습니다. 요청에 특정 ID를 기록하면 두 번째 반복에서 충돌이 발생합니다.

이를 방지하려면 ID가 고유해야 하거나 테스트에서 생성된 모든 개체를 삭제해야 합니다. 요구 사항으로 인해 일부 개체를 삭제할 수 없습니다.

결정: Postman 스크립트를 사용하여 GUID를 생성합니다.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

그런 다음 쿼리에서 기호를 사용하십시오. {{myUUID}}, 이는 변수의 값으로 대체됩니다.

LocalStack을 통한 협업

테스트 중인 서비스가 SQS 대기열을 읽거나 쓰는 경우 이를 확인하려면 테스트 자체도 이 대기열과 함께 작동해야 합니다.

결정: Postman에서 LocalStack으로의 요청입니다.

AWS 서비스 API가 문서화되어 SDK 없이도 쿼리를 수행할 수 있습니다.

서비스가 대기열에 쓰면 이를 읽고 메시지 내용을 확인합니다.

서비스가 SNS에 메시지를 보내는 경우 준비 단계에서 LocalStack도 대기열을 생성하고 이 SNS 주제를 구독합니다. 그러면 모든 것이 위에서 설명한 내용으로 귀결됩니다.

서비스가 대기열에서 메시지를 읽어야 하는 경우 이전 테스트 단계에서 이 메시지를 대기열에 기록했습니다.

테스트 중인 마이크로서비스에서 발생하는 HTTP 요청 테스트

일부 서비스는 AWS가 아닌 다른 서비스를 사용하여 HTTP를 통해 작동하며 일부 AWS 기능은 LocalStack에서 구현되지 않습니다.

결정: 이런 경우에는 도움이 될 수 있습니다 모의서버, 기성 이미지가 있는 도커 허브. 예상되는 요청과 이에 대한 응답은 HTTP 요청으로 구성됩니다. API는 문서화되어 있으므로 Postman에 요청합니다.

OAuth 인증 및 승인 테스트

우리는 OAuth를 사용하고 JSON 웹 토큰(JWT). 테스트에는 로컬로 실행할 수 있는 OAuth 공급자가 필요합니다.

서비스와 OAuth 공급자 간의 모든 상호 작용은 두 가지 요청으로 귀결됩니다. 먼저 구성이 요청됩니다. /.잘 알려진/openid-구성, 구성의 주소에서 공개 키(JWKS)가 요청됩니다. 이 모든 것은 정적 콘텐츠입니다.

결정: 우리의 테스트 OAuth 공급자는 정적 콘텐츠 서버와 여기에 두 개의 파일이 있습니다. 토큰은 한 번 생성되어 Git에 커밋됩니다.

SignalR 테스트의 특징

Postman은 웹소켓에서 작동하지 않습니다. SignalR을 테스트하기 위해 특별한 도구가 만들어졌습니다.

SignalR 클라이언트는 단순한 브라우저 이상의 역할을 할 수 있습니다. .NET Core에는 이에 대한 클라이언트 라이브러리가 있습니다. .NET Core로 작성된 클라이언트는 연결을 설정하고 인증을 받은 후 특정 메시지 시퀀스를 기다립니다. 예기치 않은 메시지가 수신되거나 연결이 끊어지면 클라이언트는 코드 1로 종료됩니다. 마지막으로 예상된 메시지가 수신되면 클라이언트는 코드 0으로 종료됩니다.

Newman은 클라이언트와 동시에 작업합니다. 메시지가 필요한 모든 사람에게 메시지가 전달되었는지 확인하기 위해 여러 클라이언트가 시작됩니다.

여러 클라이언트를 실행하려면 옵션을 사용하십시오. --규모 docker-compose 명령줄에서.

실행하기 전에 Postman 스크립트는 모든 클라이언트가 연결을 설정할 때까지 기다립니다.
우리는 이미 연결을 기다리는 문제에 직면했습니다. 하지만 서버가 있었고 여기에 클라이언트가 있습니다. 다른 접근 방식이 필요합니다.

결정: 컨테이너의 클라이언트가 메커니즘을 사용합니다. 건강 체크호스트의 스크립트에 상태를 알립니다. 클라이언트는 연결이 설정되자마자 /healthcheck라는 특정 경로에 파일을 생성합니다. Docker 파일의 HealthCheck 스크립트는 다음과 같습니다.

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

팀 도커 검사 컨테이너의 정상 상태, 상태 및 종료 코드를 표시합니다.

Newman이 완료되면 스크립트는 클라이언트가 있는 모든 컨테이너가 코드 0으로 종료되었는지 확인합니다.

해피네스가 존재한다

위에서 설명한 어려움을 극복한 후 일련의 안정적인 실행 테스트를 거쳤습니다. 테스트에서 각 서비스는 단일 단위로 작동하여 데이터베이스 및 Amazon LocalStack과 상호 작용합니다.

이러한 테스트는 자주 배포되는 30개 이상의 마이크로서비스의 복잡한 상호 작용을 통해 10명 이상의 개발자로 구성된 팀을 애플리케이션의 오류로부터 보호합니다.

출처 : habr.com