반응형
Helm으로 2 tier webapp 배포 (변수)에서 이어지는 내용입니다.
목표
목표 요약
-
main chart 의 values 값을 sub chart에서 사용 가능한지 확인
-
sub chart의 values값을 sub chart에 적용
-
sub chart의 values 값 일부를 main chart의 values에 정의하여 override 가능한지 확인
main chart의 변수 사용은 어떻게 사용되는지 확인이 되었고, 이젠 sub chart에도 변수를 사용해 보려 합니다.
지금까지는 main chart의 values.yaml에 작성된 변수값들을 main chart templetes/의 yaml들에 적용을 해봤습니다.
이번에는 main chart의 values.yaml과 sub chart의 values 파일의 내용이 sub shart templetes/ yaml 파일들에 어떻게 적용 되는지 확인해보려 합니다.
결과 요약
helm chart의 values 는 상위나 하위의 values 상호 참조 불가
-
sub chart에 정의된 변수가 main chart에도 존재하면
-
sub chart에 없는 변수가 main chart에 있으면 sub chart의 yaml들은 변수 사용불가
helm install 시 사용하는 변수설정( -f other-values.yaml, --set)은 main chart의 값만 설정이 가능한 것으로 보여짐
-
main chart에만 적용 가능하며 여러 values.yaml 중 환경에 맞는 values.yaml를 사용가능
-
main chart에만 적용 가능하며 release 설치 시 --set 옵션으로 values.yaml의 값 변경
테스트
첫 번째로, sub chart의 templetes/yaml 파일들에서 main chart의 values.yaml에 정의된 변수 참조가 가능한지 확인해 보겠습니다.
main chart의 values.yaml에 아래와 같이 backend에 대한 내용을 추가 했습니다.
backInfo:
app: vote-back
service:
type: ClusterIP
port: 6379
pod:
replicaCount: 1
image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
resources:
request:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
containerPort: 6379
추가한 sub chart의 values파일에 정의된 내용을 참조하도록 sub chart templetes/ yaml 파일들을 수정합니다.
하위 차트의 서비스 yaml 파일
하위 차트의 deployment yaml 파일
values.yaml은 main chart에만 있고 sub chart에는 values.yaml이 없는 상태 입니다.
딱 이 상태에서 main chart의 문법을 검사해보겠습니다.
helm lint
음....
sub chart의 yaml 파일들은 sub chart의 values에 정의가 되어 있어야 하나 보네요
검색결과
sub chart에 사용되는 변수는 sub chart의 values에 정의를 하는 것이고,
main chart의 values에 의해 재정의 될 수 있다고 합니다.
sub char values에 정의되지 않은 값은 main chart values에 정의되어 있어도 사용이 불가 합니다.
두 번째로, main chart value에 정의 했던 vote-back 관련 변수들을 sub chart values에 옮긴 후 동작여부 확인 해보겠습니다.
위에서 sub chart의 templetes/ yaml 파일들은 변수 사용하도록 수정 했으니 그대로 놔두고,
main chart values에 작성했던 backInfo 부분을 sub chart values 로 옮겨 옵니다.
작성한 chart의 문법 검사를 진행 합니다.
helm lint
문법 오류는 없네요. 곧바로 렌더링 결과물을 확인 합니다.
helm install sample-vote . --dry-run --debug
vote-front 는 이전 테스트에서 확인 해봤으니 캡쳐하지 않고 sub chart인 vote-back만 캡쳐해봅니다.
(vote-front도 정상적으로 렌더링 결과 나왔어요)
렌더링 결과 굳입니다. 잘 출력 되었고 install 후 앱에 접속도 해 봅니다.
helm install sample-vote .
release 설치 완료 되었구요. pod, service도 이쁘게 배포 되어있습니다.
이변은 없겠지만 웹앱도 정상이겠죠?
오잉?
무엇이 잘못된 것인지 잠깐 생각해 봤는데... 금방 답을 찾을 수 있었습니다.
backend app이름을 변경 했기 때문에 front app에서 backend app을 찾을 수 없는것이 분명합니다.
main chart의 pod에서 참조할 backend app의 이름을 바꿔 줍니다.
먼저 배포 했던 release를 삭제 해 주고
helm uninstall sample-vote
main chart의 azure-vote-front-dep.yaml 에서 REDIS value 부분을 아래와 같이 변경 해 줍니다.
azure-vote-back => vote-back-svc
다시 helm으로 release를 설치합니다.
helm install sample-vote .
pod, service 잘 배포 되었고
웹앱도 정상 접속 됩니다.
반응형
음...
잘 동작하기는 하지만 한 가지 걸리는게 있네요
sub chart에서 service 이름을 변수로 바꾸었는데 여전히 main chart에서는 고정값이 사용되고 있습니다.
혹시 sub chart value값을 main chart value값에서 override 된다는 블로그 글이 있었으니
기대를 하며 곧바로 덮어쓰기를 해봐야겠어요
배포했던 release는 삭제 합니다.
helm uninstall sample-vote
세 번째로, sub value 덮어쓰기
sub chart의 value값 중 앱 이름을 정하는 변수인 backInfo.app 을 main chart value에 추가 해 봅니다.
main chart value에 추가
덮어쓰기가 제대로 되는지 확인할 겸 backInfo.app 값을 아래와 같이 추가 합니다.
추가로 중요한 부분인데요.
front-pod가 back-svc를 참조할 수 있도록 네이밍 규칙을 맞추어야 합니다.
두근두근... 긴장이 되네요...
모든 준비는 되었고, 지금까지 작성한 파일들로 문법 검사를 해봅니다.
helm lint
오호~ 오류는 없구요
곧바로 release 설치 해봐도 좋지만 손에 익힐 겸 dry-run도 한번 실행 해 봅니다.
helm install sample-vote . --dry-run --debug
다른 부분은 다 패스 하고 front-pod 에서 REDIS 참조하는 값과 back-svc 이름만 캡쳐로 확인하겠습니다.
음.... ㅠㅠ
값이 다르네요 둘 다 각자의 values.yaml 파일을 참조 해버렸습니다.
sub chart의 backInfo.app 의 값이 main chart의 backInfo.app의 값으로 덮어써질 줄 알았는데... override는 없었습니다.
아....
왜 안되지?
-set 옵션을 사용해 봅니다.
helm install sample-vote . --set backInfo.app=vote-backcc --dry-run --debug
뭔가 될 것처럼... 평소와 다르게 User Value가 보이긴 했지만...
정작 중요한 vote-back service이름은 바뀌지 않았습니다.
(helm install시 지정한 변수는 sub chart에 영향을 주지 않는 모양입니다.)
아.... 그럼 무엇을 override 한다는거지?.... 단순히 main chart의 변수만?
지금 생각해 볼 수 있는 override의 주요 기능은 아래 두 가지 경우 뿐이겠네요
-
main chart에만 적용 가능하며 여러 values.yaml 중 환경에 맞는 values.yaml를 사용가능
-
main chart에만 적용 가능하며 release 설치 시 --set 옵션으로 values.yaml의 값 변경
이번 케이스 같은 경우 {{ .Release.Name }} 값을 사용하면 해결 될 것으로 보이지만
helm 설치 시 하위 chart에는 값을 전달할 수 있는 방법이 없다는건가?.... 혼란스럽네요
차선책으로 해당 부분을 {{ .Release.Name }}로 변경 해봐야겠습니다.
Redis 서비스 이름 부분 변경
문법 검사
helm lint
문법 오류는 없고, 렌더링 결과물 확인
helm install sample-vote . --dry-run --debug
다행히 이 방법은 잘 되네요. 별 이슈 없을테니 배포 후 웹앱 호출 부분만 캡쳐 해놓겠습니다.
요건 잘 실행 되었습니다.
음..... override가 조금 아쉽지만 어떻게 돌아가는지 얼~추 파악이 되었습니다.
반응형
LIST
'IT > Kubernetes' 카테고리의 다른 글
Pod 배포 컨트롤러 종류와 차이 (0) | 2023.04.17 |
---|---|
Helm으로 2 tier webapp 배포 (변수) (0) | 2023.04.17 |
Helm으로 2 tier webapp 배포 (종속성) (1) | 2023.04.17 |
Helm으로 2 tier webapp 배포 (0) | 2023.04.17 |
Helm에 대해 알아보자 (1) | 2023.04.17 |