Spring Cloud Config 오픈 소스 기여(컨트리뷰션)하기
개요
이전 글에서 "Spring Cloud Config Client override"라는 글을 작성하면서 Spring Cloud Config 문서를 읽어가면서 작업을 수행하고 있었습니다. 이때 문서의 내용에 다소 혼란스러운 부분이 있다고 생각하였고 이슈를 등록하였고 최종적으로 그 부분이 반영된 것에 대한 내용을 공유하고자 합니다.
이 글을 읽으면 얻을 수 있는 것
- 나도 오픈소스에 기여할 수 있다는 자신감(이 정도는 나도?)
오픈 소스 기여(컨트리뷰션)이란?
'오픈소스에 기여한 경험이 있으면 우대'라는 문구를 채용 공고에서 종종 볼 수 있습니다.
오픈 소스는 무엇을 의미할까요?
오픈소스는 개발의 핵심 소스 코드를 공개함으로써 누구나 코드를 접근, 사용할 수 있도록 하는 소프트웨어입니다.
Backend에서 흔히 사용하는 Framework인 Spring도 하나의 오픈소스이고 Spring의 하위 프로젝트인 Spring Cloud Config도 오픈소스입니다.
기여는 무엇을 의미할까요?
오픈소스에 기여한다라고 생각했을 때 제가 처음 느낀 것은 코드를 개선하고 Pull Request를 올리는 작업이라고 생각했습니다.
하지만 실제로 기여는 크게는 버그를 수정하거나 코드를 개선하고 기능을 추가하는 것부터 작게는 오타를 수정하거나 다양한 언어로 번역하고 가이드 문서를 만드는 것까지 모두 다 오픈소스에 기여를 하는 행위입니다.
실제로 작업하는것 외에 오픈소스를 개발하는 개발자에게 도움을 주는 행위도 오픈소스에 기여하는 일입니다.
즉, 버그를 제보하고, 더 나은 기능을 제안하는 것도 기여라고 볼 수 있습니다.
Spring Cloud Config란?
오픈소스 기여에 대해 설명하기 전 사전지식을 위해 간단하게 Spring Cloud Config에 대해 설명을 하겠습니다.
Spring Cloud Config는 이름에서 알 수 있듯이 Config(설정)에 대한 역할을 수행하는 오픈소스입니다.
여러 설정 정보를 중앙에서 관리할 수 있도록 지원하고 외부 설정 저장소로 git, vault 등을 활용할 수 있습니다.
Spring Cloud Config에서는 3가지 주체가 있습니다.
- 외부 환경 저장소(external envirnoment repository) - git, vault 등
- Config Server - 외부 환경 저장소에서 설정을 가져와서 설정을 제공하는 서버
- Config Client - Config Server로부터 설정을 가져와서 설정을 사용하는 서버
정리하자면 외부 환경 저장소(git)에서 설정을 가져와 Config Server에 제공하고 Config Client는 해당 설정을 다시 가져와 사용합니다.
만약 조금 더 자세한 설명을 원하신다면 "Spring Cloud Config란?" 글을 참고해주세요.
해결하고 싶었던 문제
만약 Config Server에서 제공하는 설정의 변수의 값(A)과 Config Client에서 설정한 변수의 값(B)이 충돌되면 어떻게 될까요?
이런 경우에는 기본적으로 Config Server가 제공하는 변수의 값(A)으로 override 되어 Config Client가 실행됩니다.
이때 저는 Config Client가 우선순위를 가지도록 구현해보고 싶었습니다.
구현하고자 하는 이유는 local 등의 개발환경에서는 Config Client에서 설정을 이것저것 바꾸어보고 괜찮은 설정을 외부 환경 저장소(git, valut 등)에 반영하면 편할 것 같았기 때문입니다.
해결하면서 겪었던 문제
Config Client가 우선순위를 가지도록 하는 문제를 해결하기 위해 Spring Cloud Config Docs를 읽어보면서 해당 작업을 수행하였습니다.
문서를 읽어보았을 때 bootstrap 설정이 활성화된 경우에 client application이 config server의 설정을 override 할 수 있다고 합니다.
config server로부터 오는 애플리케이션의 설정에 2개의 프로퍼티(allowOverride=true, overrideNone=true)를 추가하면 된다고 합니다.
문서를 읽고 세운 Action Item 2가지
- bootstrap 설정 활성화하기
- config server에 해당 프로퍼티를 추가하기
Action Item을 기반으로 bootstrap 설정의 수행은 문서를 보고 성공적으로 마쳤으며, config server에 2가지 프로퍼티를 추가해 보았습니다.
하지만 Config Client를 실행하고 옵션을 출력해 보면 여전히 Config Server의 설정으로 불러와지고 있습니다.
즉, override가 적용되지 않았습니다.
원인 분석
stackover flow, github issue, 다른 docs를 살펴보면서 원인을 분석하기 시작했습니다.
Spring Cloud Config의 다른 문서를 살펴보았을 때는 2가지 문구를 해석할 수 있었습니다.
- the remote property source has to grant it permission by setting(remote에 property를 추가해서 권한을 주어야 한다)
- it doesn't work to set this locally(로컬에서 설정한 건 동작하지 않는다)
해당 프로퍼티를 어디에 줄 지 헷갈렸던 이유는 Client, Server, remote 설정인 3가지 주체에 모두 프로퍼티가 추가 가능했습니다.
즉, 또 다른 문서를 읽고 Config Client, Config Server에 해당 프로퍼티를 추가하는 게 아니라 remote 설정인 git이나 vault 등에 해당 프로퍼티를 주어 권한을 추가해야 하는구나를 알게 되었습니다.
이후에 다시 테스트를 수행해 보았을 때는 정상적으로 client에서의 설정값이 override 됩니다.
이제 해결했으니까 끝?
Spring Cloud Config에 issue 등록
어떻게 다른 문서를 찾아서 해결은 했는데 뭔가 찜찜합니다.
또한 문제 해결을 위해 여러 자료들을 찾아보았을 때 저와 비슷한 시행착오를 겪으신 분들도 발견하였습니다.
그래서 spring cloud config에 issue를 남겨보았습니다.
https://github.com/spring-cloud/spring-cloud-config/issues/2372
The wording of the client's settings override can be confusing and would be good to fix · Issue #2372 · spring-cloud/spring-cl
Hello and good day. First of all, I thought this part of the bug report and feature request was a little ambiguous because it is a document part, but I tried to categorize it as a bug report first....
github.com
해당 issue는 영어로 대화가 이루어지니 한글로 번역하면서 요약해 보겠습니다.
client의 설정을 override 하는 과정에서 공식문서의 내용이 혼란스러울 수 있으니 수정을 제안하는 issue입니다.
제가 문제를 해결했던 내용에 대하여 git repository를 링크를 제공하며 위의 공식문서 2가지를 비교하면서 혼란을 느꼈던 문서에 remote라는 용어가 드러나길 원했습니다.
문서에는 해당 내용이 추가되면 좋겠다고 제안하였습니다.
"If you want to allow your applications to override the remote properties with their own System properties or config files, the remote property source has to grant it permission by setting"
That is basically the same as what we already say in the documentation
within the applications configuration coming from the config server
"수정을 제안한 문서에서 이미 네가 제안한 내용을 이미 설명하고 있어, within the applications ~ 구절을 잘 해석해 봐"
이해하지 못한 부분에 대해 다시 답변을 달았습니다.
Does the term config server refer to an external repository like Git or Valut?
I think the yml configuration in Git or Valut etc is the remote configuration.
So I made the mistake of thinking of the Config Server term as the Spring Cloud Config Server and writing the Override property in that server's application.yml.
But in the end, I realized that I should have written the Override property in the application-local.yml of the Git repository.
This could be an error in translation as I don't speak English very well.
Thank you for your response.
within 구절에서 config server라는 용어가 git, vault과 같은 외부 설정 저장소를 의미하나요?
config server라는 용어를 보고 나는 Config Server의 Application의 yml(설정 파일)에 override 프로퍼티를 작성했습니다.
영어를 잘 못해서 번역상의 오류를 감안해 주세요.
다시 답변이 달렸습니다.
No the key is the terms "applications configuration". This is referring to the the application's configuration being served up from the config server which is stored in Git, Vault, or any other environment repository.
아니야 핵심 용어는 "applications configuration"으로 해당 용어가 외부 설정 저장소를 의미해!
다시 답변을 달았습니다.
Thank you for your prompt response.
I appreciate your assistance in clarifying the documentation. Your explanation has certainly helped me understand the context better. However, I believe that the current wording might still be a bit confusing for others as well.
I suggest making the following change in the documentation:
as-is
If you enable config first bootstrap, you can allow client applications to override configuration from the config server by placing two properties within the applications configuration coming from the config server.
to-be
"If you enable config first bootstrap, you can allow client settings to override configuration from the config server by placing two properties within the applications configuration, which may include settings from external environment repositories such as Valut and Git."
If you find this suggestion reasonable, I would be more than happy to create a Pull Request to implement the proposed change. However, if you have any reservations or prefer an alternative approach, please feel free to discuss it further or close this issue accordingly.
Once again, thank you for your help and consideration.
Thank you.
덕분에 문맥을 잘 이해할 수 있었습니다.
하지만 여전히 다른 사람들에게도 현재 내용이 혼란스러울 수 있다고 생각합니다.
따라서 as-is로 작성된 문서의 내용을 to-be로 변경할 것을 제안합니다.
제안이 합리적이라고 느껴지신다면 변경 사항을 구현하기 위해 Pull Request를 기꺼이 수행하겠습니다.
논의를 원하시면 언제든지 환영이고 동의하지 않는다면 해당 issue를 close 해주세요.
감사합니다.
새벽까지 댓글을 남기다가 자고 일어나 보니 문구만 살짝 수정하여 제안을 주셨고 해당 내용이 반영되었습니다.
마무리
저에겐 오픈 소스 기여는 해보고 싶은 일인 동시에 어렵게 느껴지는 일이었습니다.
하지만 공부하다가 생긴 의문점에 대해 한걸음 나아가 issue를 생성하고 논의를 수행해 보니 친절하고 빠르게 답변을 달아주셔서 감동이었습니다.
또한 내가 제시한 issue에 대한 내용이 오픈 소스에 반영되는 것도 재미있고 의미 있는 일이라고 생각했습니다.
Pull Request로 직접 수정하지 못한 것은 아쉽지만 다음에 또 기회가 생긴다면 그때는 직접 Pull Request까지 작성해 볼 수 있겠다는 자신감도 생겼습니다.
이제 이 정도 오픈소스 기여는 여러분들도 충분히 하실 수 있다고 느껴지나요?
그렇다면 저는 이 글을 쓴 목적을 이루었습니다.
이상으로 Spring Cloud Config 프로젝트에 Contributors가 될뻔한 이야기였습니다.
참고자료
https://github.com/spring-cloud/spring-cloud-config/issues/2372