응용 프로그램 구성을 저장하는 기본 방법은 무엇입니까?

대부분의 경우 개발 응용 프로그램 구성을 프로젝트의 루트 디렉토리에 다음과 같이 저장합니다.

app
|-- config.json

그러나이 구성은 버전 제어 시스템에 저장되어 사용자 이름, 암호 및 기타 민감한 정보가 유출 될 수 있으므로 최선의 방법은 아닙니다.

12 Factor App 안내서는 구성 파일을 모두 삭제하고 구성 설정에 환경 변수를 사용하도록 권장합니다.

... 환경 변수에 구성을 저장합니다. 환경 변수는 코드를 변경하지 않고 배포간에 쉽게 변경할 수 있습니다. 구성 파일과 달리 실수로 코드를 저장소에 체크인 할 가능성은 거의 없습니다. 사용자 정의 구성 파일 또는 Java 시스템 특성과 같은 기타 구성 메커니즘과 달리 언어 및 OS에 구애받지 않는 표준입니다.

그것은 나에게 정말 좋게 들리지만, 한 곳에서 환경 변수를 소스 제어로 확인하지 않고 어디에 저장 했습니까? 그리고 이러한 변수를 앱에 전달하기 위해 어떤 도구를 사용할 수 있습니까? 수십 가지 구성 옵션이있을 수 있으며 앱을 시작할 때마다 수동으로 입력하는 것이 좋지 않으므로 어딘가에 파일 형식으로 저장해야합니다. 따라서 해당 파일은 소스 제어로 끝나고 시작한 곳으로 돌아갑니다.

소스 제어에 로컬 구성을 저장할 위험이없는 구성 옵션을 처리하는 보편적으로 허용되는 방법이 있습니까?

아마도 이것에 대한 좋은 대답은 없습니다. 이 데이터는 재난 복구 목적으로 필요하기 때문에 언젠가 안전한 곳에 저장해야합니다. 이는 환경 변수를 설정하는 특성 파일 및 스크립트에 동일하게 적용됩니다.

• SVN / GIT 등의 소스 코드를 사용하면이 데이터베이스에 프로덕션 데이터베이스 비밀번호 등이 포함되므로 실제로 나쁜 생각입니다.
• 회사 야간 백업은 충분하지만 쉽게 액세스 할 수있는 변경 기록을 유지하지는 않습니다.
• 데이터는 소비 소프트웨어와 별도로 버전 화해야합니다. 현재 시스템에서 구성을 변경하면 새로운 응용 프로그램 빌드가 생성되며 이는 잘못된 것입니다.

현재이 문제에 대한 해결책을 찾고 있으며 액세스가 제한된 코드 저장소를 향해 기울고 있습니다. 이 저장소에는 구성 데이터 만 포함됩니다. 다른 사람들이 공유 할 경험이 있습니까?

문제와 가능한 해결책을 조사 할 때 Jeff Atwood가 대중화 한 방법을 사용하는 데 도움이됩니다 . 신이 민감한 구성 정보를 저장하는 방법을 만들려면 어떻게해야합니까?

글쎄, 그는 구성 정보가 필요한 사람을 알고 그 사람들에게만 정보를 제공 할 것이며, 다른 사람이 정보에 액세스 할 수 없게됩니다.

첫 번째 부분은 이미 관리해야합니다. 소스 제어 시스템은 사용자를 인증해야합니다. 또한이 접근 방식은 Troy Hunt의 10 가지 소스 제어 명령 에서 # 10에 따라 "종속성이 소스 제어에 있어야합니다"에 따라 유효 합니다.

그러나 누출 된 경우 안전하게 유지하는 방법은 무엇입니까? 글쎄, 일반 텍스트로 저장할 필요는 없습니다! 암호화를 사용하십시오. .NET 에는 구성 파일에서 연결 문자열 데이터를 암호화하기 위해 수행 할 수있는 단계가 있습니다 . 선택한 특정 기술을 사용하여 동등한 방법을 찾아야합니다.

많은 사람들이 구성 파일을 소스 코드와 함께 일반 파일로 저장하는 것을 비판하지만 내 경험상 이것은 실제로 매우 좋은 해결책입니다.

• 모든 언어로 간단하게 구현할 수 있습니다. 대부분의 경우 복잡한 구성 파일을 즉시 지원합니다. 예를 들어 Spring Boot를 사용하는 Java의 경우 트리와 같은 구조를 표현할 수있는 YAML 지원이 제공되며 환경 별 파일을 상속 할 수있는 기본 구성뿐만 아니라 다른 환경에 대한 별도의 구성 파일을 쉽게 가질 수 있습니다.
• 소프트웨어를 실행하려면 구성이 필요하며 코드를 변경하려면 구성 설정을 추가 / 수정해야하는 경우가 있으므로 구성과 코드를 함께 유지하는 것이 당연합니다.
• 소스와 함께 구성을 저장하면 누가 정기적으로 코드를 검토 할 때 구성을 확인할 수있는 설정과시기 또는시기를 알 수있는 것처럼 소스 제어의 모든 이점을 얻을 수 있습니다.
• CIA에서 일하지 않는 한, 보안 논쟁은 나에게 과장된 것 같습니다. 따라서 데이터베이스 비밀번호는 앱이 실행되는 머신의 파일에 저장됩니다. 글쎄, 누군가가 앱으로 컴퓨터에 액세스 할 수 있다면 이미 많은 문제가있을 것입니다. 예를 들어 앱을 중단하고 같은 포트에서 자신의 앱을 시작할 수 있습니다. 이러한 시나리오에서 DB 암호에 액세스하는 것은 그리 큰 문제가 아닐 수 있습니다. 모든 연결이 완전히 암호화되어 있지 않으면 컴퓨터에 액세스 할 수 없다면 어쨌든 네트워크 인터페이스에서 많은 흥미로운 데이터를 스니핑 할 수 있습니다.
• Hiera 와 같은 도구를 사용하여 텍스트 구성 파일을 만들 수 있지만 암호 나 기타 중요한 데이터는 저장할 수 없습니다.

따라서 대부분의 경우 소스 제어에 코드와 함께 저장된 텍스트 구성이 좋은 시작입니다.

분산 시스템에 있거나 응용 프로그램을 다시 배포하지 않고 구성을 핫 스왑하려면 구성 서버를 기반으로하는 솔루션을 더 잘 찾을 수 있습니다. Spring Cloud는 이러한 메커니즘 을 지원 하며 백엔드 서빙 구성은 git 저장소 또는 Eureka 일 수 있습니다 . 예를 들어 Zookeeper를 사용하여 자신의 롤을 만들 수도 있습니다 . 이러한 접근 방식을 사용하면 소프트웨어를 다시 빌드하고 재배치하지 않고도 구성을 업데이트하기 위해 많은 서버에서 일관된 구성을보다 쉽게 ​​관리 할 수 ​​있습니다. 물론 구성 서버를 배우고 응용 프로그램과 배포 및 유지 관리를 위해 다른 시스템에서 구성 서버를 사용하는 방법을 배우는 비용이 발생합니다.

우리는 내가 일하는 것과 같은 문제를 진압하고 있습니다. 현재 모든 구성은 파일 기반이며이를 사용하는 개별 응용 프로그램으로 소스 제어됩니다. 이로 인해 개발자는 개발이 아닌 프로덕션 / qa 비밀번호에 액세스 할 수 있습니다.

그것은 우리가 앞으로 좋은 해결책을 제시했다고 생각합니다. 우리는 설정 파일을 별도의 git repo (config repo라고 표시)로 옮깁니다. 그런 다음 전달 된 프로파일을 기반으로 구성 저장소에서 파일을 제공하는 spring-cloud-config (java) 서버를 설정했습니다. 클라이언트를 사용하고 시작시 다운로드 할 수있는 Java 응용 프로그램에 유용합니다. PHP / 비 자바 애플리케이션의 경우 파일을 직접 풀다운합니다. (이상적이지 않음). 앞으로 우리는 PHP 응용 프로그램이 자체 구성을 다운로드하여 어딘가에 캐시 할 수있는 것을 작성할 수 있지만 첫 번째 실행에는 우선 순위가 높지 않습니다. 이 솔루션을 12 가지 요인 앱 권장 사항을 명시 적으로 위반하지 않는 config-as-a-service라고 생각합니다.

나는 zookeeper가 같은 것에 사용될 수 있다고 생각합니다 (kubernetes + zookeeper로 설정을 보았습니다). 왜 그 대답이 -1을 얻었는지 잘 모르겠습니다.

모래밭:

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

전체 구성을 하나의 파일로 저장하는 대신 여러 파일로 저장하십시오.

• 구성 디렉토리가 있어야합니다 . 이 파일을 제외한 모든 파일은 구성 파일로 해석됩니다 README*.
• 모든 파일 이름은 알파벳순으로 정렬되며 파일은 순서대로로드됩니다. 그렇기 때문에 이러한 경우 파일은 종종 숫자로 시작합니다 : 01-logging.json. 02-database.json등
• 모든 파일의 데이터 는 애플리케이션에서 사용 가능한 동일한 구성 구조 로로드됩니다 . 이것은 여러 파일이 서로의 설정을 보완하고 예측 가능한 방식으로 재정의하는 방법입니다.
• 보기 쉬운 값 또는 기본값을 가진 구성 파일 만 VCS에 저장하십시오. 배포 중에 비밀이 포함 된 구성 파일을 추가하거나 인증 된 비밀 스토리지 서비스를 사용하는 것이 좋습니다.

가장 가까운 Linux 상자에서 /etc/sudoers.d또는을 살펴보십시오 /etc/nginx/conf.d. 같은 패턴을 보여줍니다.

비밀 관리는 다른 짐승입니다. 소규모 인 경우 수동 단계로 관리 할 수 ​​있습니다. Zookeeper와 같은 것을 사용할 수 있습니다. 당신은 할 수 있습니다 VCS는에 비밀을 확인 암호화 된 형태 , 및 배포 단계로 암호를 해독. 다른 많은 옵션이 존재합니다.

(또한 의견 : JSON은 주석을 허용하지 않기 때문에 좋은 구성 파일 형식이 아닙니다. 주석이 중요합니다. TOML, YAML 및 INI 형식도 실용적으로 더 좋습니다.)

귀하의 옵션은 배포하려는 OS에 따라 다소 정의되어 있다고 생각합니다.

예, 값을 소스 제어에 넣으십시오. 그러나 'dev'버전 만. 소스 코드가 컴파일되고 작동하기를 원합니다! 여분의 비밀 단계를 포함하지 마십시오

그러면 빌드 및 배치 프로세스는 배치 중에 환경별로 이러한 값을 교환해야합니다. (문어에는 이런 종류의 모델이 있습니다)

Apache zookeeper는 분산 시스템의 애플리케이션 구성을 저장하는 훌륭한 옵션을 제공합니다. Zookeeper에서 작성된 변경 사항은 응용 프로그램 끝에 큐레이터 또는 Zookeeper 리스너를 갖도록하여 캡처하고 처리 할 수 ​​있습니다.