새로운 마이크로 서비스 간의 일관성을 어떻게 보장 할 수 있습니까?

우리 조직은 폭발적인 마이크로 서비스를 경험하고 있습니다. 현재 새 프로젝트를 공식화 할 방법이 없습니다. 팀이 배포 또는 빌드 프로세스에서 버그를 발견하게되었고 이미 다른 프로젝트에서 이미 해결했음을 깨닫기 위해 시간을 투자 할 것입니다. 표준화하고 싶은 프로젝트간에 많은 불일치가 있습니다.

변경 사항에는 종종 단일 파일 (예 : serverless.yml 또는 Makefile)이 포함되므로 공유 라이브러리와 같은 솔루션 (git submodules)은 실용적이지 않습니다. 각 프로젝트에는 Dockerfile 또는 serverless.yml과 같이 유지 관리해야하는 자체 구성 세트가 있으므로 VM의 중앙 집중식 구성 관리 솔루션을 실제로 적용 할 수 없습니다.

새로운 마이크로 서비스가 조직 표준을 준수하고 새로운 프로젝트를 시작하려는 개발자에게 쉽고 직관적 인 방식으로 기존 프로젝트의 버그 수정 / 기능을 포함하도록하려면 어떻게해야합니까? 이러한 문제를 해결하기위한 모범 사례는 무엇입니까?

현재 워크 플로는 옆에있는 사람에게 "템플릿으로 사용하려면 어떤 프로젝트를 복제해야합니까?" 그런 다음 해당 프로젝트에 필요하지 않은 모든 항목을 삭제하십시오.

지금까지 내 솔루션이 무엇인지에 대한 답변을 추가 할 것입니다. 그러나 여전히 다른 조직이이 문제를 해결하는 방법과 모범 사례를 듣는 데 관심이 있습니다.

프로젝트를 만들 수있는 일관된 기반이없는 문제를 해결하기 위해 상용구 / 템플릿의 리포지토리 (리포지토리?)를 만들고 쿠키 커터 를 사용 하여 새로운 마이크로 서비스를 발판하는 도구로 사용하는 것이 좋습니다 . 이러한 방식으로 각 프로젝트는 표준 기반에서 만들어지며 조직으로 통합 된 모든 교훈을 얻을 수 있습니다. 변경 사항은 상용구 저장소에 업스트림으로 통합 될 수 있습니다. Nodejs Docker 이미지, 서버리스 SPA, Python 람다 등을위한 템플릿이 있다고 생각합니다.

템플릿에 대한 변경 사항이 모든 프로젝트에 다운 스트림으로 전파되는 문제를 해결하기 위해, 나의 솔루션은 마이크로 서비스 소유자가 템플릿에 대한 변경 사항을 인식하고 해당 변경 사항을 마이크로 서비스에 전파하는 프로세스를 구현하는 것입니다.

구성 관리 / 자동 배포 시스템을 사용하십시오. 이것이 이것들을 위해 설계된 것입니다. Kubernetes, Puppet, Chef, Ansible 및 Salt Stack과 같은 것은 이러한 용도로만 설계되었으며 Golden Master 템플릿, 킥 스타트 스크립트, Amazon AMI 또는 Docker 컨테이너와 함께 사용할 수 있습니다. 이를 통해 기본 기본 템플릿을 사용하고 추가 역할을 수행 할 수 있습니다. 이를 통해 빌드가 코드로 완벽하게 문서화되고 프로덕션에 빠르고 쉽게 배포 할 수 있으며 확장 성 또는 중복성이 필요하거나 문제가 발생했을 때 추가 인스턴스를 디자인하거나 배포 한 것과 정확히 동일하게 배포됩니다. 이 방법으로 변경 / 업데이트를 통합 할 수도 있습니다. 소프트웨어 업데이트를 릴리스하는 것처럼 구성에 대한 업데이트를 릴리스 할 수 있으며 소프트웨어 코드가 관리되는 것처럼 동일한 리포지토리 및 동일한 워크 플로로 구성 코드를 관리 할 수 ​​있습니다. 그리고 업그레이드 시간이 오면 물건이 어떻게 만들어 지는지 미스터리가 없으며 단지 스크립트를보십시오.

구성 관리 시스템이이를 수행하는 한 가지 방법은 구성 파일에 템플릿을 많이 사용하는 것입니다. 예를 들어, 일반적으로 환경에 동일하거나 유사한 여러 줄이 있습니다. SaltStack은 jinja 템플릿을 사용하고 꼭두각시는 Embedded Ruby 템플릿을 사용 합니다. 예를 들어 AWS를 사용하면 모든 인스턴스에서 모두 동일한 api 키, IAM 역할, 리전 (또는 리전 목록에서 리전을 임의로 선택), VPC 등을 설정해야합니다. 그러나 기능과 출력이 고유해야합니다. 또는 "계약"을 정의하는 퍼펫 모듈 또는 솔트 공식을 작성하고 입력 및 출력 모두에 해당 계약 (api 정의)을 사용하여 마이크로 서비스를 2-3 곳에서 구성 할 필요가 없습니다.

예를 들어 SaltStack은 최근이 특정 시나리오 를 논의하기위한 모임을 가졌습니다 . 또한 SaltStack은 도커 컨테이너를 기본적으로 관리 및 배포 할 수 있습니다. (Puppet 에는 Docker 용 모듈도 있습니다. ) Ansible 에는 서버리스 배포 및 Docker 컨테이너 작업을위한 플레이 북 및 문서가 있습니다 .

또한이 테마를 계속하려면 서버리스 테마 / 패러다임, Puppet , Ansible 및 saltstack을 모두 마스터리스하거나 마스터리스 모드를 지원하려는 경우.

이 질문은 광범위하므로 내 대답이 약간 오프베이스 인 경우 컨텍스트와 특정 예제를 추가하여 더 잘 이해할 수 있도록하십시오.

AWS의 AMI와 같은 머신 이미지를 사용하면 기본 또는 골든 이미지를 생성 할 수 있으며,이를 통해 지속적으로 제공 및 배포 또는 구현할 수 있습니다. 이 아키텍처를 사용하면 모든 마이크로 서비스가 동일한 구성으로 일관된 하드웨어에 배포되므로 직면 한 문제는 마이크로 서비스 / 애플리케이션 구성과 관련이 있습니다.

Ansible 및 Packer와 같은 구성 도구를 추가하여 이러한 불변성을 더욱 높일 수 있습니다. 구성 관리를 사용하면 원하는대로 (애플리케이션 포함) 머신 이미지를 프로비저닝 할 수 있습니다. 그런 다음 Packer를 사용하면 해당 머신 이미지의 스냅 샷을 작성할 수 있으며 각 배치는 동일합니다.

이 예제를 사용하면 Ansible 및 Packer의 도움으로 설치된 올바른 패키지, 업데이트 및 구성으로 기본 AMI를 '베이킹'할 수 있습니다. 또한 'Ansible-Pull'을 살펴보면 애플리케이션 코드를 가져와 변경하고 해당 기본 이미지 위에 마이크로 서비스를 배포하여 배포를 완료 할 수 있습니다.

그러나 내가 줄 수있는 가장 중요한 조언은 전체 조직이 지원하고 유지할 수있는 솔루션을 제시하는 것입니다. 특정 문제를 해결하고 리더십의 문화와 태도에 부합하며 현대 건축 관행을 수용하는 SDLC를 구축하는 것이 좋습니다.

저는 3 개의 조직에서 근무했으며 3 가지 매우 다른 접근법을 취했습니다.

행운을 빕니다!