버전이 지정된 패키지를 통한 구성 관리

우리가 관리하는 호스트의 경우 상사는 버전이 지정된 패키지(특별한 경우 fpm 기반 데비안 패키지)를 통한 구성 관리에 대한 비전을 가지고 있습니다. 이는 다음을 위한 것입니다:

• 호스트 배포가 더 쉬워졌습니다.
• 로컬 변경 사항을 더 쉽게 추적할 수 있습니다.
• 대부분의 경우 기능 버그든 구성 버그든 소프트웨어 버전을 버그로 표시할 수 있으므로 버그 추적이 더 쉬워집니다.

또 다른 옵션은 현재 사용 중인 매뉴얼에 표시된 권장 레이아웃을 사용하여 Ansible을 통한 구성 관리입니다. 버전이 지정된 패키지(거의 모든 웹 서비스)를 설치합니다. 이 패키지는 자체 패키지별 구성을 처리하고 Ansible을 시스템 전체 구성에 맡깁니다. 호스트 소프트웨어를 업데이트하면 버전 번호가 늘어나고 스크립트가 다시 실행됩니다. 우리는 중요한 정보를 구성과 별도로 유지하기 위해 Ansible의 "var_prompts" 기능에 크게 의존합니다.

"버전이 지정된 패키지를 통한 구성 관리"의 경우:

배포를 위해 최소한의 서버(에이전트 등)를 시작하고 패키지 관리자(우리의 경우 apt)를 사용하여 모든 종속 패키지를 설치하는 단일 우산 패키지를 설치합니다. 종속 패키지를 변경하면 최상위 패키지 버전만 적용되므로 기존 배포를 더 쉽게 업데이트할 수 있습니다.

구성의 경우 모든 패키지에는 구성 변경만 허용하는 "config" 패키지가 함께 제공됩니다. 각 패키지에는 호스트의 로컬 변경 사항을 확인할 때 패키지 간의 충돌을 방지하기 위한 독립적인 구성 파일이 있습니다. 구성을 생성하는 명령을 실행하는 대신 생성된 파일이 패키지의 일부로 포함되는지 확인하지만 여전히 사전 설치/설치 후 스크립트를 통해 명령을 실행할 수 있습니다. AFAIK, 대부분의 경우 패키지는 모두 동일한 구성 파일에 의존하지만, 이 경우(시스템 구성의 경우) 한 쌍의 종속성을 갖는 다른 패키지를 갖게 됩니다. 이 특정 상황이 통제 불능에 빠지는 것을 볼 수 있지만 항상 독립적인 구성 파일을 보장함으로써 제어할 수 있습니다. 마지막으로 각 호스트에는 고유한 구성 패키지가 있습니다. 분명히 이러한 모든 파일은 소스 제어하에 있으며 자체 간단한 템플릿 시스템을 가동하여 Ansible 역할의 유연성도 확보할 수 있습니다.

이와 같은 호스트를 구성하고 배포하는 워크플로에 대한 정보/분석을 찾을 수 없는 이유가 무엇인지 궁금합니다. 기존 구성 관리 도구와 비교하여 이 접근 방식에는 근본적인 결함이 없습니까?