SCG 홈페이지 k8s에 날려보내기
안녕하세요, SCG 31기 이찬형입니다.
2026년에 새롭게 합류하여 처음으로 맡은 프로젝트(?)인 SCG 홈페이지 k8s 이관에 대한 이야기를 하고자 합니다. 그리 어려운 작업은 아니지만 처음이라 좀 많이 헤맨 것 같긴 하네요.
k8s란 무엇인가?
일반적으로 어떠한 프로그램을 개발하게 되면, 해당 프로그램은 컴퓨터 상에서 실행되기 위해 수많은 변수들을 필요로 합니다. 흔히 "환경 변수" 라고 부르는 것들이 그러한 것들이죠.
개발하는 사람의 pc의 환경 변수에서 돌아가는 프로그램은 해당 환경을 매개 삼아 작동합니다. 하지만 이러한 프로그램을 다른 사람의 pc에서 실행시키면 어떻게 될까요?
환경 변수는 말 그대로 해당 pc에서의 설정을 바탕으로 하기 때문에 완벽히 동일한 세팅을 직접 깔아 설정해 주지 않는 이상, 프로그램을 작동시키며 버그가 발생할 수밖에 없습니다.
이러한 문제를 해결하기 위한 방법으로 등장한 것이 바로 컨테이너와 Docker입니다.
Docker는 각각의 소프트웨어가 돌아갈 수 있는 환경 자체를 격리시켜 만들어 둔 '컨테이너' 라는 기술을 활용해 소프트웨어를 작동시킬 수 있는 플랫폼입니다. 개발자가 배포를 '이미지'라고 불리우는 컨테이너를 배포하게 되면, Dockerhub에서 해당 이미지를 활성화하거나, 비활성화하면서 컨테이너를 관리할 수 있게 됩니다.
Docker는 개별 컨테이너(이미지)를 관리하는 데에 정말 효율적인 툴이 될 수 있습니다. 하지만 한 번에 많은 이미지를 관리하는 경우엔 어떨까요?
하나의 서버를 구동하는 데에 여러 개의 컨테이너가 필요하거나, 컨테이너를 교체해야 하는 경우가 빈번히 일어나는 경우에도 효과적일까요?
이를 조금 더 효율적으로 만들어 관리할 수 있게 한 것이 바로 Kubernetes, 통칭 k8s라고 불리는 툴입니다.
(k ubernete s에서 ubernete 가 8글자라 k8s라고 하네요)
k8s의 장점?
k8s는 컨테이너를 배포하며 벌어지는 스케일링, 네트워킹 및 프로덕션 상에서 발생하는 관리, 리커버리 등을 한 번에 확인할 수 있도록 하는 기술입니다. 흔히 "컨테이너 오케스트레이션(Orchestration)"이라 불리는, 관리자가 지정한 상태에 맞춰 자동으로 관리하는 역할을 맡습니다.
k8s는 컨테이너 기반 애플리케이션을 여러 노드 단위에서 효율적으로 스케줄링하고, 분산 시스템을 운영하여 오류가 발생한 프로덕션을 복구하거나, 다른 곳에 이관하는 데에 장점을 띄고 있습니다.
k8s에 여러 서비스를 올려두면 하나의 UI 혹은 CLI에서 관리가 가능하기 때문에 SCG에서는 장기적으로 모든 프로젝트를 k8s에 이관하는 것을 목표로 하고 있는데요~!
이번엔 SCG의 대문, 메인 홈페이지 역할을 하고 있는 scg.skku.ac.kr을 k8s로 이관하는 작업을 진행하고자 했습니다.
현재는 어떻게 운영되고 있었는가?
SCG에서 k8s에 올라가지 않은 이미지들과 프로덕션들은 모두 portainer라는 dockerhub 관리 툴을 통해 관리되고 있습니다. 일반적으로 portainer는 배포와 이후 일련의 과정이 수동으로 이루어져, 운영의 입장에서 약간의 불편함이 있는 편이었습니다.
물론 올해 이전의 운영 방식을 제대로 알진 못하는 신입이기 때문에 잘 모르긴 하지만, 그래도 k8s를 활용한 DevOps의 효과까지 바라보고 있는 SCG의 현황을 통해 어느 정도 불편함이 있었다는 점은 추측해 볼 수 있었습니다.
본격 이관 전 사전 작업
SCG에선 gitOps를 채택하고 있고, 이를 위한 도구로 github Actions + ArgoCD를 활용해 CI/CD 파이프라인을 구축해 두었습니다. 따라서, 해당 구조에 맞게 기존 이미지로 패키징되던 빌드 구조를 바꿀 필요가 있었습니다.
github Actions는 github repo에 코드가 commit되면, .github/workflows 파일 하위에 있는 yml 파일을 따라서 개발자가 지정한 행동을 자동으로 실행해 주는 기능입니다. 무려 repo 상단에 항상 존재했었는데 지금까지 github를 쓰면서 한 번도 써 본적이 없어서 처음엔 조금 신기했었네요.
ArgoCD는 k8s 오케스트레이션을 위한 GUI 툴인데, k8s의 각각의 node들에서 돌아가는 하위 항목(secret, deployment, ingress 등)들을 모두 한 눈에 확인할 수 있어서 DevOps에 대한 효과적인 관리가 가능합니다.
추가적인 gitOps와 관련된 글은 이전에 작성된 장재원 회장님의 글을 참고해 주시면 좋을 것 같습니다.
아무튼, 이번 scg 홈페이지를 이관하면서 기존 코드에서의 수정 사항은 크게 3가지 정도였습니다.
- Dockerfile의 빌드 수정 : 기존 gitLab 기반으로 개발되던 것이 github로 이관되어 왔기에, 이에 대한 레거시 코드를 찾아 변경해 주어야 했습니다. (혹시 몰라서 환경 변수를 남겨둔 것을 추후 31기 동료분께서 완전 삭제하시면서 없어졌습니다.)
- github Action workflow 작성 : github Action workflow 파일 작성이 필요했습니다.
- config repo 및 yaml 파일 작성 : CI를 통해 완성된 이미지를 ArgoCD가 감지하여 프로덕션에 병합할 수 있게끔 하는 yaml 파일을 제작할 필요가 있었습니다.
요 3개를 작성하고, ArgoCD에서 sync를 눌렀을 때 아래와 같이 기분 좋은 초록색 체크 표시가 뜨면 성공한 것입니다.
workflow, yaml 파일은 기존에 작성된 다른 프로덕션 repo에 있는 것들을 참고해서 금방 작성했습니다.
docker에서 build되는 것을 확인하고, frontend/backend repo와 config repo를 연결한 후에 argoCD에 config repo를 연결했더니 말짱히 잘 sync되는 것을 확인했습니다.
하지만 바로 배포를 하는 것은 위험부담이 있기에, fe.scg.skku.ac.kr이라는 다른 도메인을 따로 파서 제대로 돌아가는 지 확인 후에 실제 배포를 진행하고자 했고, bind9를 통해 DNS 레코드를 수정 후에 확인해봤더니 잘 돌아가는 것을 확인, 성공했습니다. 이제 실제 배포로 넘어갈 단계입니다.
배포를 진행하며
배포를 하는 과정에서, 최대한 다운타임을 줄이기 위해 argoCD 배포 후에 도메인을 중복으로 겹쳐 두고, TTL이 만료되면 자동으로 k8s로 넘어가게끔 한 후에 기존에 배포되고 있던 Docker 이미지를 내리는 방식을 채택해봤습니다.
두 서비스가 잘 교체되었는지 구분하는 방법은 백엔드 서버 요청이 오는 도메인이 be.scg.skku.ac.kr이면 성공한 것으로 판단하면 되는 것이었습니다. 기존에 api.scg.skku.ac.kr로 오던 요청을 다른 걸로 돌려놨기에 바뀌면 성공이었습니다.
argoCD에 올린 후에 DNS sync를 누르는 순간..! 접속 실패라는 메시지를 받고 어디가 문제인지 계속 뒤져보고 있었습니다. 같이 모니터링 해주시던 SCG 선배님들이 TTL 만료를 기다려보자고 해서 당장 docker 이미지를 내릴 준비를 하고 기다리고 있었습니다.
그리고, TTL 만료되는 것을 확인하니 제대로 잘 돌아가는 것을 확인했습니다.
Docker 이미지를 내리고도 멀쩡하게 잘 돌아가는 것을 확인한 후에, 이관이 완료되었습니다!
해당 프로세스를 겪으며
프로그램을 개발하는 과정은 많이 알고 있었지만, 이를 직접 프로덕션에 올리는 과정을 경험해 본 것은 많지 않았기에 이번 기회 자체가 많은 도움이 되었던 것 같습니다. 처음 SCG에 들어오면서, 인프라 관련 업무를 맡고 싶기도 했어서 Ops와 관련된 것들이 쌓이고 쌓이면서 SCG의 인프라가 어떻게 구성되어 있는지 청사진을 확인할 방법을 찾아가는 것 같아 뿌듯했습니다.
이후 비슷한 gitOps 과정들을 거치면서 홈페이지 이관했을 때 작성한 yml, yaml 파일들이 어떤 문제를 갖고 있는지, 어떤 수정을 거쳐야하는지에 대해 조금씩 보이는 것 같은데, 이것도 추후 수정해 보고자 합니다.
감사합니다.