오늘은 회사에 새로운 (대단한) DevOps가 조인하고 생긴 여러가지 변화 중 하나를 소개한다. 나는 2003년 처음 시스템 엔지니어(솔라리스)로 업무를 할 때는 까만 콘솔에 명령어를 치면서 작업했다. 여러 Unix 명령어를 외우는게 중요했다. 사실 명령어도 쳤지만 네트워크 케이블 찝고 바닥 뜯고 8U(SUN 880, 무게가 무려 88Kg, 둘이서 마운트하면 허리 나간다.) 서버 마운트하고 랙 뒷면 케이블 이쁘게 정리하는게 주요한 업무였다.
당연히 코드를 짤일이 없었다. 시스템 운영자는 개발자와 업무가 달랐다. 난 경력 초반 3년 엔지니어 생활을 하고 이후 여러가지 이유로 제안서를 만들고 고객 미팅을 주로하는 시스템 아키텍트, 세일즈 엔지니어 등의 업무를 15년 넘게 하였다.
굳이 정리하자면 기존의 시스템 엔지니어(SE)는
- 콘솔 명령어 기반 작업 : 여러 명령어를 외우고 있어야 한다.
- 사전에 전체 작업을 준비하고 리뷰하는게 한계가 있어서 작업 시 발생하는 돌발 상황에 대처할 수 있는 순발력이 중요하다. 이건 경험이 필수다. 짬밥이 대우받을 수 밖에 없다.
- 한정된 작업 시간에 빠르게 작업해야 하기에 명령어치면서 피드백 받는 것, 그런 것 없다. 피드백, 회고가 없기에 대부분 그냥 하던대로 했다.
- 하드웨어 기반이라 하드웨어가 없으면 경험도 실력도 못 쌓는다. 기회가 주어진 일부 엔지니어만 잘할수 있는 구조였다. 테스트 시스템이 필수인데, 구축하기가 참 어려웠다.
비교를 하기 위해서 나쁜 점 위주이지만 위와 같은 경우가 많았다.
그러다 약 4년 전부터 쿠버네티스를 하게 되면서 시스템 작업에 YAML를 사용하였다. YAML도 코드라 부르기는 조금 민망하지만 어쨌든 코드이기에 깃(Git)정도는 알아야 했다. 쿠버네티스와 함께 DevOps도 이미 대중화된 개념이라 시스템 엔지니어도 더욱 개발자를 잘 알고 커뮤니케이션을 잘해야 하는게 당연한 소양이기도 했다.
난 약 1년 전에 DevOps로 이직했었고 작년 11월 개발자 출신의 DevOps가 Join하고 나서 본격적으로 GitOps 기반으로 업무를 하게 되었다. 변명이 길었는데 위와 같은 백그라운드의 나는 새로운 개발자 문화에 적응해야 했다. 가장 큰 변화가 소스 기반으로 작업하고 내가 짠 소스는 Git에 올려서 동료에게 리뷰를 받고 Approve하면 해당 소스 기반으로 시스템에 적용한다는 것이다.
예를 들어 EKS 업그레이들 작업을 들면
- 작업은 소스 코드 기반, 테라폼으로 작업을 한다. 콘솔 명령어에서 옵션으로 들어가는 모든 작업이 이제는 YAML 코드에 들어간다.
- 업그레이드 용 테라폼 파일을 만든다. 간단하기는 하다. YAML 파일에서 version을 1.22에서 1.23으로 변경한다. 물론, 대부분의 다른 작업의 YAML 파일의 이처럼 간단하지 않다.
- 새로운 브랜치를 만들고 내가 만든 소스를 commit 한다. 최대한 동료가 쉽게 알아볼 수 있게 commit 메시지를 작성한다. commit 메시지는 매우 중요하다. 예를든 1.23 to 1.23의 경우 간단하지만 다른 작업은 보통 복잡하여 맥락을 잘 설명해야 한다.
- 이때 중요한 게 'diff'가 보여야 한다는 것이다. 해당 작업을 실제 운영 시스템에 적용하면 작업을 하기 '전'과 하기 '후'가 어떻게 달라지는지 'diff'로 검증할 수 있어야 한다. argocd를 사용하면 아래의 그림처럼 sync 버튼을 누르기 전에 diff 명령어가 익숙할 것이다. 동일하다. 깃 커밋 메시지에도 위와 같은 'diff' 메시지를 추가하여 리뷰하는 동료가 어떤 작업을 할 것인지 알 수 있어야 한다. 개발자가 CI 단계애서 단위 테스트를 하듯이 운영자도 CI 단계에서 어떤 영향이 있을지 미리 확인하는 검증단계가 필요하다.
- 참고로 헬름을 사용하면 helm diff 라는 도구를 사용할 수 있다. 명령어 helm diff upgrade로 검증하면 아래의 그림과 유사하다.
- 깃헙액션을 CI로 사용해서 테라폼 작업인 경우 terraform plan 파일이 자동으로 생성되어 시스템 변경 내역을 미리 검증할 수 있다. 위 'diff' 내용이 자동으로 CI로 포함된다.
- 동료는 깃을 보고 리뷰를 한다. 빠뜨린 건 없는지, 오타는 없는지, 포맷 등 diff 뿐만 아니라 여러 가지를 검증한다.
- 리뷰가 완료되면 main으로 merge하고 작업한다. 물론 리뷰전에 merge하고 작업을 하는 경우도 많지만 급한 작업이 아니라면 꼭 지킨다. 급하다고 막하는건 안된다. 정확성이 가장 우선이고 다음이 속도, 그리고 고도화다.
다시 새로운 업무 방식을 정리하면
- 모든 작업은 코드 기반이다. 그때그때 명령어를 입력하는 게 아니라 사전에 충분히 검토해서 코드를 작성한다. 물론 이전 명령어 기반 작업도 사전에 충분히 연습, 검증을 하고 작업하지만 코드 기반의 작업보다 준비하는 범위가 제한적이었다.
- GitOps 기반으로 PR, Review 한다. 작업 전 동료의 피드백을 받으므로 실수를 훨씬 줄이고 품질을 높일 수 있다. 피드백을 받을 수 있어 끊임없이 내 작업의 품질을 높일 수 있다. 당연하게도 피드백은 성장에 필수다.
- 회고와 재작업에 매우 유리하다. history 명령어로 검색하는 것과 비하면 아마도 하늘과 땅차이다. 그리고 재작업시 아마도 10개의 시스템만 있어도 일일이 명령어를 치는게 얼마나 어려운지 잘 알것이다. 더욱이 요즘처럼 쿠버네티스에 100개, 1000개 파드를 우습게 넘기는 시대라면 코드 기반으로 작업하는게 필수다.
지금도 서툴기는 하지만 처음에는 git을 몰라서 많이 힘들었다. merge하면 conflict 나고 git pull 에러로 에라 모르겠다 하는 경우도 많았다. 명령어 그냥 하나 치면 되는데 왜 이 고생을 사서하는지.... 힘들었다.
물론 모든 업무가 GitOps로 다 돌아가는 건 아니다. 시스템 업무는 개발 업무와 달라 실제 적용을 해야만 알 수 있는 경우도 많다. terraform plan에는 이상없지만 terraform apply하면 에러가 나는 경우도 많다. 하지만 예외가 있다고 적용을 안하는 건 참 미련하다. 조금씩 하다보면 적응을 하고 결국에는 여러가지를 알게되어 예외를 많이 없앨 수 있다. 결국 사람이 하는 일이라 사람이 발전하면 저절로 발전해서 에러도 많이 없어진다. 사람이 문제인 경우가 태반이다.
사실 이글은 나에게 하는 일기같은 글이라 조금 보편성이 떨어진다. 커밋 메시지 대충 쓰고, 코드 리뷰도 대충하는 나에 대한 훈계다. 게을러서 자꾸 예전처럼 일하려 한다. 깃옵스는 장점이 많은 업무 방식이므로 높은 수준으로 꼭 지켜야겠다.
'쿠버네티스 일반' 카테고리의 다른 글
| 쿠버네티스 베스트 프랙티스 레이블 및 헬름 레이블 적용 (0) | 2024.06.17 |
|---|---|
| 쿠버스택 창업? (4) | 2023.03.20 |
| EKS 무중단 업그레이드 경험 공유 (1) | 2023.03.10 |
| 파이썬으로 여러 쿠버네티스의 클러스터 정보 가져오기 (0) | 2022.11.05 |
| EKS CSI Driver 설치 (2) | 2022.06.15 |