테스트와 관련하여 두 가지 옵션을 생각할 수 있습니다.

1. 하나의 이미지에 테스트와 응용 프로그램을 모두 넣습니다.
2. 이미지에는 응용 프로그램 코드 만 포함하십시오. 기본 이미지 다음에 빌드하고 일부 레이어 (테스트 코드, 종속성 등)를 추가하는 테스트 특정 컨테이너를 작성하십시오.

첫 번째 옵션으로 컨테이너를 테스트하고 테스트 한 그대로 배송 할 수 있습니다. 명백한 단점은 이미지에 불필요한 코드 (및 잠재적으로 테스트 데이터)가 포함된다는 것입니다.

두 번째 옵션을 사용하면 배송 된 이미지가 테스트 된 이미지와 동일하지 않습니다.

둘 다 나쁜 전략처럼 보입니다. 더 나은 세 번째 전략이 있습니까?

빌드 타임 테스트를 실행하는 경우 선호되는 방법은 다단계 빌드 를 사용하는 것 입니다. 다단계 Dockerfile을 사용하면 빌드 및 테스트에 대한 모든 종속성이있는 더 큰 무대를 확보 한 다음 테스트 한 정확한 아티팩트를 다른 스테이지로 복사하여 더 작은 런타임 이미지를 만들 수 있습니다.

또한 컨테이너 내에서 실행하는 대신 외부 인터페이스를 사용하여 여러 컨테이너의 시스템 수준 테스트를 원합니다. 이러한 테스트에는 서비스 간의 조정이 포함되며 오케스트레이션 액세스와 같은 다른 종속성이 필요하고 빌드 타임 테스트만큼 철저하지 않으며 어쨌든 완전히 다른 언어로 작성되기 때문에 별도의 Docker에서 실행하는 것이 그리 중요하지 않습니다. 시스템 테스트 전용 컨테이너.

당신이 말한 것처럼 세 번째 방법이 있습니다. 개발, 테스트 및 배포를 혼합하고 있다고 생각합니다. SDLC 전체를 전체적으로 살펴보고, 무엇을 달성 하려는지 이해하기를 제안합니다. 이것은 큰 주제이지만 요약하기 위해 최선을 다할 것입니다.

TL; DR;

간단히 말해서 다음을 분리해야합니다.

• 귀하의 코드
• 응용 프로그램 구성
• 시스템 환경 구성.

각각은 서로 독립적이고 적절해야합니다.

• 버전 제어
• 테스트
• 배치 가능

더 긴 버전

먼저 코드와 (별도의 세트) 구성으로 구성된 응용 프로그램이 있습니다. 빌드 및 의도 기능 모두에 대해 테스트해야합니다.이를 CI (Continuous Integration)라고합니다. 온라인 및 로컬로이 서비스를 제공하는 많은 제공자가 있습니다 (예 : 저장소에 링크하고 커밋 할 때마다 빌드 및 테스트하는 클라우드 제공자의 경우 CircleCI) . 저장소가 온 프레미스이고 Jenkins 와 같은 클라우드 공급자를 사용할 수없는 경우동등한 것입니다. 응용 프로그램이 상당히 표준적인 경우 CI 서비스가 사용할 수있는 기존 Docker 이미지가있을 수 있습니다. 그렇지 않은 경우 응용 프로그램 코드 및 구성을 배포 할 수 있도록 클러스터를 만들거나 클러스터를 만들어야합니다. 올바르게 구성하면 응용 프로그램 코드의 품질에 대한 다양한 통계가 제공됩니다.

다음으로, 응용 프로그램의 기능과 정확성에 만족하면 특정 릴리스에 맞게 코드베이스에 태그를 지정해야합니다. 그런 다음이 빌드를 테스트 환경에 배포해야합니다. 코드는 CI에서 테스트 한 것과 동일하지만 (올바르게 수행 한 경우) 구성이 다를 수 있습니다. 또한 일부 CI 제공 업체는이 단계를 제공하여 패키지 된 응용 프로그램의 배포 및 개별 구성을 테스트 할 수 있습니다. 이 단계에는 일반적으로 사용자 기능 테스트 (새로운 기능의 경우)와 자동 테스트 (알려진 기능의 경우)가 포함됩니다. 릴리스가이 단계를 통과하면 통합 테스트를위한 릴리스 후보가 있습니다. 다른 Docker 컨테이너에서 자동화 테스트를 실행할 수 있습니다.테스트 노력을 나타내는 몇 가지 메트릭은 코딩 노력과 1 : 1입니다 (자신이 확실하지는 않지만).

마지막으로, 다음 단계는 마치 프로덕션 환경 인 것처럼 (시스템) 환경을 구축하는 것입니다. 프로덕션에서 Docker를 사용하는 경우 보안 강화, 네트워크 및 서버 최적화 등을 생각할 수 있습니다. Docker 이미지는 개발에서 사용한 이미지를 기반으로 할 수 있지만 (이상적으로는) 확장 및 보안에 대한 변경 사항이있을 수 있습니다 , 내가 말했듯이. 이제 응용 프로그램의 기능 테스트가 완료되었으므로 보안 및 성능에 더 관심이 있습니다. 기능 테스트에 따라 다른 Docker 이미지에서 테스트를 개발, 배포 및 실행할 수 있습니다. 이 단계는 끔찍하게 비싸고 거의 수행되지 않았으므로 생산을 재현 할 수있는 전용 하드웨어가 필요했습니다. 오늘날에는 거의 모든 규모의 온 디맨드 환경에서 일어 서서 분해 할 수 있기 때문에이 기능은 완전히 실현 가능합니다.

마지막으로, 통합 테스트의 구성 델타 (IP 주소, 데이터베이스 URI, 비밀번호 등)의 구성 델타 세트만으로 프로덕션 준비가 된 릴리스가 있습니다. 코드베이스는이 시점에서 적어도 세 가지 다른 환경에서 테스트되었습니다. 포인트 및 대부분의 시스템 구성을 한 번 이상

나는 당신이 다른 종류의 테스트를 섞고 있다고 생각합니다. 기본적으로 당신은 스스로에게 물어볼 필요가 있습니다 : 여기서 테스트 할 유닛은 무엇입니까?

개발자로 작업 할 때 가장 일반적인 시나리오는 작업중인 일부 코드에 대한 단위 / 통합 테스트를 작성하는 것입니다. 여기서 해당 코드는 테스트 대상 단위입니다. 이러한 테스트는 로컬 및 / 또는 CI에서 실행합니다.

새로운 도커 이미지를 만들면 테스트 할 수있는 새로운 단위가됩니다. 이 이미지에 대해 어떤 종류의 테스트를 원하십니까? 제공하는 API는 무엇입니까? 그것을 어떻게 테스트합니까?

웹 응용 프로그램 인 경우 이미지를 기반으로 컨테이너를 시작하고 일부 HTTP 요청을 수행하고 응답이 예상 한 것인지 확인할 수 있습니다. 내가 경험하고있는 문제는 응용 프로그램 코드에 연결된 테스트 프레임 워크에 매우 익숙하다는 것입니다. 개발 중에는 괜찮지 만 이제 도커 이미지를 테스트하려고하므로 응용 프로그램 코드와 관련이없는 새로운 종류의 테스트 프레임 워크가 필요합니다.

그래서 당신이 찾고있는 세 번째 옵션은 다음과 같습니다.

• 도커 이미지를 만들기 전에 단위 / 통합 테스트를 실행하십시오.
• 배포하려는 응용 프로그램 만 포함 된 도커 이미지를 작성하십시오.
• 해당 응용 프로그램 이미지 위에 추가 레이어를 추가하는 대신 특정 매개 변수를 사용하여 레이어를 실행하고 예상 출력을 지정하여 그대로 테스트합니다.

따라서 CI / CD 단계는 다음과 같습니다.

개발 환경 설정-> 코드에서 테스트 실행-> 최종 이미지 빌드-> 이미지에서 테스트 실행-> 이미지 배치.