많은 서버가있는 시스템을 상상해보십시오. 각각에는 여러 가지 설정이 있습니다.
- 서버에 특정한 것
- 지역에 따라 일부
- 그들 모두에게 공통적 인 것
- 이 서버 그룹은 읽기 전용이므로 일부 사용자 지정 그룹을 가질 수 있습니다.
- 기타
내가 생각하는 현재 관행은 재정의 능력을 가진 간단한 속성 구조입니다.
예제 목적으로 Google 서버를 사용할 수 있습니다. 각각에는로드 할 설정 목록이 있습니다.
예를 들어 런던 서버에는 다음이있을 수 있습니다.
rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.properties, 등
각 파일에 일련의 속성이 포함되어 있고 로딩 순서를 통해 속성을 재정의 할 수있는 경우 더 멀리 갈 수 있습니다.
예를 들어 rootsettings.properties있을 수 있습니다 accessible=false기본으로하지만,에 오버라이드 searchengine.properties와accessible=true
내가이 구조로 가지고있는 문제는 통제하기가 매우 쉽다는 것입니다. 전혀 구조화되지 않았으므로 어떤 수준에서든 속성을 정의 할 수 있으며 많은 항목이 더 이상 사용되지 않을 수 있습니다.
또한 이제는 많은 서버에 영향을 미치므로 네트워크가 성장함에 따라 중간 레벨을 변경할 수 없습니다.
마지막으로, 각 개별 인스턴스에는 1 개의 특수 속성이 필요할 수 있습니다. 즉, 트리는 각 서버에 대한 구성으로 끝나므로 최적의 솔루션이 아닙니다.
더 나은 구성 관리 아키텍처의 제안 / 아이디어가 있다면 대단히 감사하겠습니다.
답변
먼저 몇 가지 질문을하고 요점을 명확히해야 문제를 해결할 방법을 더 잘 결정할 수 있습니다.
첫째 : 누가 서버를 제어해야합니까?
-
수백 대의 서버를 제어 할 단일 관리자입니까? 그런 다음 구성을 최대한 중앙 집중화해야합니다.
-
또는 각 서버가 개별 관리자를 제어 할 수 있습니까? 누가 중앙 집중식 구성으로 인해 자신의 설정을 무시하거나 제어하지 않겠습니까? 그런 다음 분산 구성에 중점을 두어야합니다. 각 관리자가 관리 할 서버가 최대 인 경우 여전히 수동으로 관리 할 수 있습니다.
둘째, 정말 많은 구성 옵션이 필요합니까, 아니면 그 수를 몇 개로 줄일 수 있습니까? 모든 경우를 “경우에 따라”구성 할 수 있도록하는 대신, 시스템이 실제로 필요로하는 옵션으로 스스로를 더 잘 제한하십시오. 예를 들어 다음과 같이 수행 할 수 있습니다.
-
소프트웨어를 조금 더 똑똑하게 만드는 것 (예를 들어, 환경을 요청하여 프로그램이 자동으로 결정할 수있는 것)?
-
예를 들어, 특정 명명 규칙을 설정하거나 다른 옵션에서 일부 옵션을 기본값으로 파생하여 “구성에 대한 컨벤션”을 엄격히 준수
셋째 : 소프트웨어에 하드 코딩 된 계층 적 구성 수준을 정말로 원하십니까? 트리와 같은 계층 구조가 서버에 가장 적합한 구조인지 또는 트리에 필요한 수준이 몇 개인 지 미리 알 수 없다고 상상해보십시오. 내가 생각할 수있는 가장 간단한 해결책은 중앙 집중식 구성을 전혀 제공하지 않고 서버 당 하나의 구성 파일 만 제공 하고 책임있는 서버 관리자 가 여러 서버의 구성 관리 문제를 어떻게 해결 할지 스스로 결정하게 하는 것입니다.
예를 들어, 관리자는 중앙 구성 파일을 다른 서버 그룹에 분배하고 각 사본을 약간 수정하는 생성기 스크립트를 작성할 수 있습니다. 이렇게하면 사전에 “서버 배포 토폴로지”에 대해 어떤 가정도 할 필요가 없으며 언제든지 실제 요구 사항에 맞게 토폴로지를 조정할 수 있습니다. 단점은 Perl, Python, Bash 또는 Powershell과 같은 언어로 스크립트를 작성하는 방법에 대한 지식이있는 관리자가 필요하다는 것입니다.
답변
나는 개인적으로 구성 파일 상속을 좋아하지 않았습니다. 로딩 순서가 있다고 언급하지만 그것이 어떻게 정의 또는 파생되는지 확실하지 않습니다. 파일을 넣거나 파일 이름에 포함하는 디렉토리 구조로 시퀀스를 미러링하여 시퀀스를 명확하게 만드는 데 도움이 될 수 있습니다.
rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties
이것은 지역에 맞지 않는 구성 값의 집합이있는 지점까지 다소 작동합니다. 따라서 선택한 조직 축을 고려해야합니다.
내가 더 좋아하는 것은 구성 값의 집합을 자체 파일로 분리하고 (리프) 구성 파일이 하나를 가리 키도록하는 것입니다.
예를 들면 :
bigcity.searchsettings.properties
regional.searchsettings.properties
내부에는 londonsettings.properties다음과 같은 값이있을 수 있습니다.
searchsettings:bigcity.searchsettings.properties
이것은 더 많은 자유도 또는 추가 자유도를 허용합니다.
답변
나는 같은 문제가 있었고 내 솔루션을 오픈 소스로 제공했습니다. https://github.com/Bikeman868/Urchin 에서 소스 코드를 찾을 수 있습니다.
많은 서버, 각 서버에 여러 응용 프로그램 및 여러 환경이있는 대규모 시스템에 사용합니다. 구성 관리를 위해 Dart로 작성된 UI가 포함되어 있습니다.
지상에서 내리는 데 도움이 필요하면 저에게 직접 연락하십시오.
내가 구현 한 솔루션은 규칙 기반입니다. 일반적으로 모든 구성에 적용되는 하나의 규칙으로 시작한 다음 “이 환경의 모든 시스템이이 UNC 경로에 로그 파일을 작성합니다”와 같은 규칙을 추가 할 수 있습니다. 규칙은 환경, 응용 프로그램, 컴퓨터 또는 응용 프로그램 인스턴스에 따라 달라질 수 있습니다. 이 특정 서버에서 실행되는이 응용 프로그램의이 특정 인스턴스에서만 규칙이 더 구체적 일 수 있습니다.
규칙은 가장 구체적인 순서부터 가장 적은 순서로 적용되며 이후 규칙은 이전 규칙에 지정된 값을 무시할 수 있습니다. 예를 들어 특정 응용 프로그램에 적용되는 규칙을 만든 다음 특정 컴퓨터 또는 응용 프로그램의 특정 인스턴스 등에 대해 다른 값으로 규칙을 재정의 할 수 있습니다.
서버에는 REST + JSON 인터페이스가 있으므로 대부분의 개발 시스템에서 작동하며 .Net 애플리케이션을위한 편리한 클라이언트 라이브러리도 있습니다.
답변
이러한 종류의 설정은 관리하기에 악몽입니다. 소프트웨어 구성 요소가 모든 경우를 처리하도록하여 최대한 많이 시도하고 줄이는 것이 가장 좋습니다.
즉, 지역에 대해 api 서버를 설정하는 대신 api 호출로 지역을 전달하고 단일 서버 설정이 모든 지역을 처리하도록합니다.
그러나 현재 상태에있는 경우 구성 설정 생성을위한 시스템 설정을 권장하지 않습니다. 이미 복잡한 문제에만 복잡성을 추가합니다.
대신 서버 유형별로 설정을 배포 도구에 저장하십시오. (문어 배포 설정, 팀 시티 파일 다시 쓰기 등)이를 통해 소프트웨어를 업그레이드 할 때 마지막으로 구성한 것과 동일한 구성 설정을 배포하고 변경 사항을 세밀하게 제어 할 수 있습니다.
메타 구성 파일을 변경 한 후 다양한 지역 / 서버 / 사용자 정의 그룹에서 생성되는 구성 파일을 테스트해야하는 상황에 처하고 싶지 않습니다.
답변
연구가 없습니다. 모든 개인적인 의견, 30 가지 이상의 IT 경험. 복잡한 데이터 구조처럼 들리며 많은 사용자가 빠르게 변경 / 수정할 수 있습니다.
각 사용자에 대해 개별 구성 파일을 생성하는 사용자 지정 추출 프로세스를 사용하여 데이터를 구조화 할 데이터베이스 저장소 (예 : SQL)를 고려하십시오. 데이터베이스 쿼리를 사용하여 변경이 구현되기 전에 변경의 영향을 확인할 수 있습니다. 중복 발생 등을 찾습니다. 개별 플랫 파일이 문제의 일부입니다. 또한 변경 로그 및 복구 / 재 구축 지원을받을 수 있습니다. 데이터베이스 제어를 사용하면 구성 상속 문제를 제거 할 수 있습니다. 이러한 유형의 솔루션에는 추가 데이터베이스 구조가 필요합니다. 올바른 복합 키 구조가 매우 중요합니다.
그게 내 제안입니다.
이러한 유형의 서비스를 구현하는 매우 비싼 공급 업체 시스템 보안 및 제어 시스템을 살펴볼 수 있습니다. 그들을 고려하십시오. 일반적으로 환경에 따라 다릅니다.