본 글은 야간모드에 최적화 되어있습니다. 우측 상단에서 해 혹은 달모양을 클릭시어 velog 설정을 야간모드로 해주시면 더욱 편안하게 읽으실 수 있습니다.
오늘은 회사에서 쿠버네티스 컨피그 맵을 변경해주어야하는 상황이 생겼다.
애초에 나는 클라우드 시스템이 주 분야가 아니었기때문에 다른분들이 우선 퇴사하시고, 나 역시도 퇴사까지 한달 남짓 남겨놓고 유지보수를 진행하고있어서 어쩌다보니 클라우드쪽도 건드릴 수 밖에 없게 되었다.
AWS는 당연히 서비스로 굴리고있으니 어느정도 찍먹수준으로만 알고있었지만, 쿠버네티스의 경우에는 완전 문외한이었기때문에 기존에 담당하시던 분들이 알려주고 가신 내용을 토대로 작업한 것을 작성해보고자 한다.
인프라 구조는 회사마다 워낙에 다르기도 하고, 완전 초짜의 시선에서 작성한 내용이라는점은 인지해주셨으면 좋겠다.
본론으로 돌아가 어떠한 상황인고 하니, 이전에 사용하던 이메일 발송계정이 변경되어 전역변수로 설정해놓은 부분에서 변경이 필요했다.
전역변수로해서 서버쪽에 담아놓고 사용하고 있다보니 개발환경과 운영환경에서 사용해주어야하는 환경변수를 변경해주고 배포를 했는데 이메일이 사라진 이전 계정으로 자꾸 시도를 해서 SES에서 실패로그를 보내왔다.
왜일까 하다가 생각해보니 서버내의 EKS에 들어있는 전역변수 쉘 파일에서 변경을 해주고 컨피그맵을 새롭게 배포해서 변경을 해주는걸 깜빡했다.
쿠버네티스 컨피그맵(ConfigMap)?
일단 컨피그맵이 무엇인지 개념이라도 어느정도 알고가야 작업을 할 수 있을 것 같기도 했고, 클라우드쪽에서 쿠버네티스는 완전 문외한이다 보니 궁금하기도 해서 냅다 쿠버네티스 공식문서에 가서 해당 내용에 대해 정독부터 진행했다.
컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 파드는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.
컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.
- 출처 : 쿠버네티스 공식문서(https://kubernetes.io/ko/docs/concepts/configuration/configmap/)
쭉 읽어보니 각각의 파드에게 적용될 환경변수를 미리 구성해두고 운영환경에 맞게 읽어오도록 할 수 있게 처리해주는 역할로 이해를 했다.
아마 로컬에서 작업할 때나 가상환경에서 환경변수를 쉘 파일을 통해 적용하고 시작할때 source 명령어로 적용시키듯 쿠버네티스에서는 컨피그맵이 그런역할을 하는 것 같다.
1. 서버내의 EKS 환경변수 확인
1-1. 적용할 서버의 환경변수 yaml 파일 확인
우선 전달받은대로 우리 서버의 EKS 설정파일들을 가지고 있는 깃 레포지토리에 들어갔다.
각각의 환경에 맞는 브랜치에서 수정을 해주어야하기때문에 처음시도해보는것이기도 하니 개발환경부터 건드려보기로 했다.
(아마 회사마다 이 부분은 제각각일 듯 하니 참고용으로만 읽어주시면 될 것 같다.)
우리 회사의 경우에는 아래와 같은 경로에 설정파일이 위치하고 있어 해당 경로로 접속해주었다.
{eks_project}/objects/{service_name}/{source_position}/{server_name}env/main-svr.yaml
간단하게 풀어서 예를 들면 아래와 같은 모양새로 보면 된다.
set_eks/objects/test_service/backend/main/env/main-svr.yaml
들어가보니 이게 뭔... 익숙하면서도 굉장히 적응이 안되는 형태가 눈에 들어왔다. 아무래도 야말파일이라 그런듯 한데 익숙한 이유는 환경변수를 설정해놓는 부분이라 그랬던 것 같다.
해당 파일을 쭉 내리다보면 이런 모양을 한 코드들이 쭉 나열되어있었는데 환경변수 내용들인 것을 알 수 있었다.
- name: DEPLOY_SERVER_TYPE
valueFrom:
configMapKeyRef:
name: main
key: DEPLOY_SERVER_TYPE
...(중략)
찾아보니 해당 야말파일이 EKS안에서 각각의 환경에 맞게 환경변수를 읽을수있도록 지정해주는 역할이라고 한다.
여기서 나는 추가가 아니라, 기존 것을 변경해주어야했기때문에 해당파일은 따로 변경해주거나 하지는 않고 확인만 진행하고 넘어갔다.
만약 추가가 필요한 경우에는 아래 예시처럼 동일한 형식으로 환경변수 명을 추가해서 커밋을 시켜주면 된다.
// 예시
- name: {your_env_var_name}
valueFrom:
configMapKeyRef:
name: {deploy_server_name}
key: {your_env_var_name}
// 예시를 토대로 작성한 환경변수
- name: SERVER_LOG_FILE_NAME
valueFrom:
configMapKeyRef:
name: main
key: SERVER_LOG_FILE_NAME
1-2. env파일에 환경변수에 적용할 변수값 추가
yaml 파일을 확인했다면 이제는 해당 환경변수에 적용시켜줄 변수값을 추가해주기 위해 env 파일에도 동일하게 적용시켜주어야한다.
깃 레포지토리에서 한 단계 이전으로 올라가면 존재하는 env 폴더로 접속한다
set_eks/objects/test_service/backend/env
접속하게되면 각각의 운영환경에 맞는 환경변수 파일이 존재한다. 우리같은 경우에는 개발서버, 운영서버가 있기때문에 아래와같이 각각 2개의 env 파일들이 존재한다.
여기서 나는 메인서버의 환경변수를 설정할 것이었기때문에 dev.main.env로 접속해서 환경변수를 설정해 주었다.
들어가게 되면 우리가 익숙하게 다뤘던 아래와 같은 모양으로 환경변수들이 쭉 존재한다.
DEBUG=True
DEPLOY_SERVER_TYPE=dev
EMAIL_SEND_MAIL='abc@gmail.com'
EMAIL_REPLY_MAIL='defg@gmail.com'
... (중략)여기서 내가 변경시켜줄 이메일에 해당하는 부분에 이메일 계정을 새롭게 바꿔서 커밋을 해주었다.
CI/CD의 경우에는 gitlab과 연동시켜두었기때문에 커밋하면 자동으로 올라가진다.
일단 git에서 변경해주는 EKS 환경변수 설정은 여기까지 진행하고 다음은 쿠버네티스 설정을 새롭게 해줄 차례였다.
2. 쿠버네티스 환경설정 파일 변경 적용 및 배포
2-1. 서버 EC2 접속 및 경로 이동
이제 내가 커밋했던 내용을 서버내에 존재하는 환경설정파일에도 동일하게 적용을 시켜주어야하기때문에, ec2에 접속했다. ec2 접속은 당연하겠지만 putty를 쓰시는 분들은 ppk 파일로, 맥에서 작업하시거나 ssh로 접속하시는 분들은 pem키를 사용해서 접속하면된다.
나는 맥북에서 터미널을 통해 ssh 접속으로 시도했기때문에 pem 키가 있는 경로로 이동하여 아래와 같은 접속 명령어를 사용해서 접속했다. 혹여나 모르시는 분들이 계실까 해서 예시로 작성해두었다. (물론 그러시는 분들은 없겠지만...)
ssh -i "{my_pem_key_name}" {server_account_name}@ec2-12-345-67-890.ap-northeast2.compute.amazonaws.com서버에 접속하고나서는 git과 동일하게 경로로 이동해주면 된다. EKS 설정파일이 있는 경로로 이동하여 준다.
해당경로로 이동하고나서 아까 커밋을 진행했던 파일들을 내려받아 최신화 해주기 위해서 pull을 한번 진행한다.
잘못해서 다른 코드를 받게되면 환경변수가 덮어씌워지거나 뒤틀릴 수 있는것을 미연에 방지하기 위해서 그전에 git branch 명령어를 통해 현재 서버의 git branch가 배포할 운영환경 브랜치인지 반드시 확인하고 진행하자.
2-2. 환경변수 파일 및 kubernetes 설정 파일 최신화 & 배포
해당 경로에 도착해서 ls를 입력해서 파일 리스트를 보면 아래와 같은 파일이 있을텐데 그 파일을 지워주도록하자.
> ls
> xxx bbb dddd ccc ... kustomization.yaml ... yyy zzzz
> rm kustomization.yaml kustomization.yaml 파일이 가지고 있는 정보는 우리 쿠버네티스에 가지고있는 모든 리소스 혹은 오브젝트에 label을 붙여 관리하는 파일이라고 보면된다 라는데 자세한 내용은 쿠버네티스를 조금 더 공부해봐야 알 것 같다.
여기서 이 파일을 지워주고 우리는 새로운 kustomization.yaml 파일을 우리가 지정했던 환경변수를 포함해서 다시 생성할 것이다.
아래 명령어를 입력하여 kustomization.yaml 파일을 재생성했다.
envsubst < kustomization.template.yaml > kustomization.yaml
위 명령어의 뜻은 풀어보면 다음과 같다고 한다.
- kustomization.template.yaml 이라는 우리 쿠버네티스 설정파일을 기준으로 해서 kustomization.yaml을 만든다
재생성이 완료되었는지 ls 명령어를 통해 다시 확인하고 나서 kustomization.yaml이 재생성된 것을 확인 후에 cat kustomization.yaml을 통해 해당 파일의 속성값들이 전부 잘 적용되어 생성되었는지 마지막으로 확인!
> ls
> xxx bbb dddd ccc ... kustomization.yaml ... yyy zzzz
> cat kustomization.yaml여기서 kustomization.yaml을 확인해보면 우리 쿠버네티스 환경의 파드나 네임스페이스, 우리가 추가했던 환경변수 내용들이 포함되어있는데, 이 내용들을 포함하여 현재 적용시킬 서비스 환경상태가 맞는지까지 최종적으로 확인을 거치면된다.
확인이 끝났다면 쿠버네티스 환경을 적용시켜 배포해주는 아래 명령어를 통해 변경된 kustomization.yaml과 컨피그맵을 배포해준다.
kubectl apply -k .
3. 정상 배포 확인 및 동작 확인
정상적으로 잘 배포가 되었는지 확인하기 위해 쿠버네티스 대시보드에 접속했다.
대시보드도 처음에는 원래 제공해주는건가 싶어서 클라우드 팀 개발자분들이 계실때 한번 여쭤보았었는데, 원래 존재하는것은 아니고 구성을 해야 볼 수 있는 것이라고 들었다.
당시에 시간이 없던터라 더 질문을 드리지는 못하고 넘어갔었는데 이제와서 쿠버네티스를 조금씩 써보다 보니 대시보드를 어떻게 구성하는지도 궁금해서 나중에 찾아볼 예정이다.
정상적으로 배포가 되었다면 기존 파드를 유지한 상태에서 새롭게 변경된 컨피그맵을 가진 파드로 자동으로 교체하여 배포가 이루어진다.
배포가 이뤄지는 동안 내가 확인해야할 것은 대시보드의 컨피그맵 항목에서 내가 방금전 명령어를 입력하여 적용시켰던 쿠버네티스 컨피그맵이 잘 배포되어 변경 혹은 추가한 내용이 포함되어있는지 확인해보면 끝이다.
후기
사실 클라우드는 백엔드 코드보다도 더 보이지 않는 측면의 내용이 강해서 접근하기도 좀 꺼렸고, 문제가 발생하면 해결하는 시간도 길기 때문에 막상 다뤄보면 두려움이 앞섰었다.
하지만 이제 다른 개발자분들도 퇴사를 하시고, 나도 1달남짓 남은 시점에서 유지보수를 하기위해 결국 손을 대야하는 상황이다보니, 다른 큰 곳에서도 쓰는 기술이기도 하고 해서 알아두면 나쁠거 없다는 생각이 들었다.
인수인계 이후부터 조금씩 찾아보고있는데, 나름 흥미는 생긴다. 그래도 워낙에 인프라쪽으로 내가 약하다보니 알아야할 것도 산더미다 ㅋㅋ.. 이제 그래도 배포나, 파드로그, 컨피그맵까지는 명령어로 조작을 할 수 있게되었다.
다음에는 쿠버네티스 명령어를 좀 정리해볼까 싶기도 하다.
아, 환경변수 배포는 성공적으로 마쳐서 잘 동작한다 ㅎㅎ
이상 끝!
