6일
- Config에 대한 생각
- 처음에는 Config를 실행 Argument로 전달했다.
- 매번 지정하기가 힘드니 환경 변수를 활용하기 시작했다.
- config가 복잡해 지니 argument로 path 만 전달하고, 해당 path에 file에 config 내용을 전달했다.
- 이러한 config 는 static 한 config 들이고, 실행중에 변경하기가 힘들다.
- 더욱이 Application이 더 발전하자 다른 측면에 문제도 나타났다.
- 서버 운영에 익숙한 사용자는 config 를 특정 형식의 file로 전달해도 큰 문제가 없었다.
- 문제는 서버 운영에 익숙하지 않는 사용자도 서버 운영을 할때가 있다는 것이다.
- eg) minecraft 서버를 띄워서 친구들과 같이 게임을 하고 싶은 초등학생
- 그래서 config 자체가 일종의 dynamic한 값으로 취급이 되어야 하고, 그 값도 특정 형식을 따르는 대신 좀더 친절한 방법을 채택해야 한다.
- etcd, zookeeper 등의 key-value store 가 이런 시대적 흐름을 타고 났다.
- 물론 누가 그 설정값을 쓰냐에 따라 여전히 각각의 설정 방법은 의미가 있다.
- 방식별 적절한 용도
- arguments
- 실행중에는 고정 값이지만, 실행 시 마다, 실행 위치 마다 변경될수 있는 값.
- eg) endpoint, cert path, domain name, server name, port
- 어딘가에 저장되는 것이 민감한 값
- eg) server token, server wide salt
- envirment variable
- 한번 설정하면 변경되는 일이 잘 없는 값
- eg) binary path, endpoint,
- config file(yaml, ini, …)
- 변경이 드물고, 여러값이 묶여 하나의 의미를 갖는 값
- eg) endpoint, cert path, 사용자가 선택가능한 선택지, cluster list
- key-value store
- 자주 변경이 되야 하는 값
- config 를 UI 등으로 변경 해야 할때
8일
25일