고객사 솔루션 설치 지원 업무

고객사에 쿠버네티스 기반의 솔루션을 설치하면서 경험한 이슈들을 회고합니다.

 

우리 솔루션은 "kubectl 만 주어지면 설치할 수 있다!" 라는 대명사와 함께 다양한 클라우드 환경에 대응할 수 있도록 설계되었고, 실제 설치에는 AWS의 EKS와 Azure의 AKS 같은 Kubernetes 서비스를 사용했습니다.

 

고객사의 환경은 크게 두가지로 나뉘었습니다.

 

1. 외부망을 사용할 수 있는 환경

이 경우 자사 Harbor 에 있는 Helm Chart, Docker Image 들을 사용했기 때문에

개발서버를 구축하는 것과 크게 다름이 없어서 수월했습니다.

 

2. 외부망을 사용할 수 없는 환경(폐쇄망)

이 경우 필요한 모든 이미지와 바이너리 파일들을 미리 패키징하여 반입 절차를 거친 후 설치했습니다.

 

사전 준비

 

설치 전, 사전 요구사항들을 문서화하여 고객사에 전달했고,

사내 개발서버를 폐쇄망으로 구축한 후 여러번 테스트하여 최대한 변수를 줄이도록 했습니다.

 

설치중 겪은 이슈

 

그럼에도 불구하고 현장에서는 예상치 못한  여러 이슈가 생겼었습니다.

 

1. 필수 패키지가 설치되어있지 않은 Bastion 서버

 

설치 작업을 수행할 Bastion 서버에 Docker가 설치되어 있지 않은 상황이 있었습니다.

 

kubectl, helm 바이너리만 준비했기 때문에 Docker 를 위한 추가 반입 절차가 필요했었습니다.

 

이후부터는 모든 설치 환경에 필요한 바이너리, 패키지를 함께 반입하도록 정책을 변경했습니다.

 

 

2. 권한 문제

 

폐쇄망, 혹은 고객사에 필요한 권한을 미리 제공해달라고 해야하는 경우 권한 문제가 빈번하게 발생합니다.

 

가끔 필요한 권한 요청을 즉시 대응해주는 고객사도 있었지만 원칙적으로는 그것이 불가능하단 것을 염두에 두어야 했기 때문에

 

클라우드별로 필요한 IAM 권한을 미리 작성해놓고 사전 요구사항에 미리 권한을 확보하도록 개선했습니다.

 

 

3. Hiware 등 보안 프로그램 

 

단순 접속 감시용인줄 알았던 Hiware가 psql, mariadb 같은 DB 접속 명령어를 차단하는 기능이 있었습니다.

 

이로 인해 "특정 버전에 누락한 DB스키마가 있다" 라는 솔루션 개발자의 요구를 적용하지 못하는 경우가 있었습니다.

( 물론, Flyway 외의 마이그레이션을 위한 이미지에서 파이썬 스크립트로 SQL을 우회해서 사용할 수 있긴 했습니다. )

 

이후 사내 개발 정책문서에 Flyway 의 중요성을 좀더 강조하여 최대한 수동으로 DB를 제어하는 일이 없도록 하였습니다.

 

 

 

고객사 설치는 단순히 한번 설치하고 끝이 아니라 그 환경에서 발생한 문제점들을 파악하고 사내 설치 문서에 트러블슈팅으로 업데이트, 표준으로 가져가야 할 이슈라면 패키징 스크립트에 반영을 하는 것까지 하나의 프로세스라고 생각하게 되었습니다.

 

폐쇄망 환경에서는 작은 변수 하나가 전체 일정에 큰 영향을 미칠 수 있기 때문에 

설치 문서를 최대한 정확하게 작성하고 사전 요구를 명확하게 해야하는 것이 중요하다고 느꼈습니다.