Kubernetes 모범 사례, 제 2판

6장. 버전 관리, 릴리스 및 롤아웃

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

기존 모놀리식 애플리케이션의 주요 불만 중 하나는 시간이 지나면서 너무 커져서 비즈니스에 필요한 속도로 제대로 업그레이드, 버전 변경 또는 수정하기 어렵다는 것입니다. 많은 사람들은 이 점이 바로 Agile 개발 관행과 마이크로서비스 아키텍처의 등장으로 이어진 중요한 요인 중 하나라고 주장합니다. 새로운 코드를 신속하게 반복하고, 새로운 문제를 해결하거나, 숨겨진 문제가 주요 문제가 되기 전에 수정하는 것, 그리고 다운타임 없는 업그레이드에 대한 약속은 개발팀이 추구하는 목표입니다. 실제로 이러한 문제는 시스템 유형에 관계없이 적절한 프로세스와 절차를 마련하면 해결할 수 있지만 일반적으로 유지 관리에 기술 및 인적 자본의 비용이 훨씬 더 많이 듭니다.

시스템을 설계할 때 격리 및 구성 가능성은 중요한 변수입니다. 애플리케이션 코드의 런타임으로 컨테이너를 채택하면 이를 가능하게 하지만 대규모 시스템을 신뢰할 수 있는 수준으로 유지하려면 여전히 높은 수준의 인적 자동화 또는 시스템 관리가 필요합니다. 시간이 지나면서 시스템이 성장하고 더 많은 취약성이 도입되면서 시스템 엔지니어는 복잡한 릴리즈, 업그레이드 및 장애 감지 메커니즘을 제공하기 위해 복잡한 자동화 프로세스를 구축하기 시작했습니다. Apache Mesos와 같은 서비스 오케스트레이터, HashiCorp Nomad와 같은 서비스 오케스트레이터, 심지어 Kubernetes와 Docker Swarm과 같은 특수 컨테이너 기반 오케스트레이터까지 이러한 프로세스를 런타임에 직접 적용하는 보다 원시적인 구성 요소로 발전시켰습니다. 이제 시스템 엔지니어는 애플리케이션의 버전 관리, 릴리즈, 시스템으로의 배포를 포함하도록 테이블 스테이크가 높아짐에 따라 더 복잡한 시스템 문제를 해결할 수 있게 되었습니다.

버전 관리

이 섹션은 소프트웨어 버전 관리와 그 뒤에 숨겨진 역사에 대한 입문서가 아니며, 이 주제에 관한 수많은 기사와 컴퓨터 과학 강좌 책이 있습니다. 중요한 것은 패턴을 선택하고 그것을 고수하는 것입니다. 대부분의 소프트웨어 회사와 개발자들은 특히 특정 마이크로서비스를 작성하는 팀이 시스템을 구성하는 다른 마이크로서비스의 API 호환성에 의존하는 마이크로서비스 아키텍처에서 어떤 형태의 시맨틱 버전 관리가 가장 유용하다는 데 동의했습니다.

시맨틱 버전 관리를 처음 접하는 분들을 위해 기본적으로는 주 버전, 부 버전, 패치의 세 부분으로 이루어진 버전 번호를 따르며, 보통 1(주).2(부).3(패치)와 같은 점 표기법으로 표시됩니다. 패치는 버그 수정 또는 API 변경 사항이 없는 아주 사소한 변경 사항이 포함된 증분 릴리스를 의미합니다. 마이너 버전은 새로운 API 변경 사항이 있을 수 있지만 이전 버전과 하위 호환되는 업데이트를 의미합니다. 이는 자신이 개발에 관여하지 않은 다른 마이크로서비스를 사용하는 개발자에게 ...