최근 몇 년 새 IT 업계에서 급속도로 떠오른 키워드가 하나 있습니다. 바로 ‘노코드, 로코드(no code, low code)’인데요. 이는 코딩을 최소화하고, 간소화한 것이죠. 노코드, 로코드 도구를 활용하면 코딩할 줄 모르는 비개발자도 소프트웨어를 간단히 개발할 수 있습니다. DevOps 업계에서도 ‘노코드, 로코드를 DevOps에 적용하는 방안’을 모색하고 있는데요. 그 결과물은 노코드, 로코드 기반의 DevOps 플랫폼, CI/CD 파이프라인 에디터 등 서비스로 나오기도 합니다. DevOps 업계는 노코드, 로코드의 어떤 점에 주목해 이를 DevOps에 접목하려는 걸까요? 노코드, 로코드는 DevOps가 발전하는 데 도움이 될 수 있을까요? 이 글에서는 DevOps 업계가 노코드, 로코드를 주목하는 배경과 노코드, 로코드가 DevOps에 미치는 영향, 그리고 둘을 결합할 때 일어날 수 있는 문제를 함께 살펴보려고 합니다.

개발을 공부하는 사람들은 ‘코드 리뷰가 개발자 개인과 팀 전체의 성장에 중요한 역할을 한다’고 생각합니다. 그래서 취준생을 대상으로 하는 유료 코드 리뷰 서비스가 있기도 하고, 좋은 개발 문화를 가진 기업은 저마다의 코드 리뷰 방식이 있습니다. 그렇다면 개발자가 코드 리뷰를 받고 성장하려면 어떤 자세를 가지고 있어야 할까요? 코드 리뷰를 잘하는 방법을 소개하는 글은 많지만, 코드 리뷰를 받는 사람이 알아야 하거나 지녀야 할 자세와 관련된 자료는 부족한데요.

이번 포스팅에서는 코드 리뷰로 성장하기 위해 리뷰이가 지녀야 할 자세를 저의 경험과 더불어 정리했습니다. 아울러 인포그랩 프로덕트 팀의 코드 리뷰 문화도 함께 다뤘습니다.

6월 26일, GitLab 코리아에서 16번째 밋업을 진행하였습니다. 이날은 평소보다 많은 분이 밋업에 참가해 주었는데요. 아마도 밋업 주제가 상당한 흥미를 불러온 것으로 생각합니다. 이날의 밋업 주제는 ‘GitLab + AI로 생산성 **높이기, 코드 리뷰 자동화’**였습니다.

밋업은 세션 1, 2로 나눠 진행됐습니다. **세션 1에서는 유인철 GitLab 코리아 이사가 ‘GitLab AI Assisted 주요 기능 알아보기’**를 주제로 발표했고요. 주요 내용으로 Code Suggestions, Suggested Reviewers 등 업무에 강력한 도움을 주는 AI 기능을 모은 GitLab Duo를 설명했습니다.

**세션 2에서는 신철호(Dexter) 인포그랩 이사가 ‘GitLab MR에서 코드 리뷰하기 - GPT & Plumber를 활용한 코드 리뷰 자동화’**를 주제로 발표를 진행했습니다. 주요 내용으로 리뷰의 중요성 및 다른 IT 회사의 모범사례, 코드 리뷰 자동화 방안을 설명해 주었고요. 코드 리뷰에 사용하는 도구로 ‘Plumber’도 소개했습니다. Plumber는 CI/CD 파이프라인을 손쉽게 구축하도록 도와주는 제품으로, 인포그랩이 개발했습니다.

최근 AI를 활용한 업무 자동화로 생산성을 높이는 것이 큰 화두인데요. 두 세션 모두 공통적으로 AI를 활용하여 업무를 효율적으로 수행하는 기능 및 방법을 알아보는 시간이었습니다. 이 글에서는 이번 밋업의 주요 발표 내용을 살펴보겠습니다.

ChatGPT는 OpenAI에서 개발한 대화형 인공지능(AI) 도구입니다. 이는 2022년 말에 공개되었으며, 전례 없는 놀라운 성능으로 전 세계에 GPT 열풍을 불러일으켰습니다. 그 결과, ChatGPT가 나온 지 반년이 지난 지금도 생성형 AI 뉴스는 끊임없이 쏟아지고 있습니다. AI API를 이용한 다양한 도구도 계속 등장하고 있고요.

OpenAI에서 개발한 ChatGPT가 출시된 지 반년이 조금 지났습니다. 반년 동안 ChatGPT를 필두로 여러 인공지능(AI) 모델이 하루가 멀다하고 등장하는 중이며, 다양한 산업에서 파동을 일으키고 있습니다. 우리는 이를 견뎌내기 위해 빠르게 대처하고 있지만, 마치 빠르게 달리는 열차를 쫓는 느낌을 받습니다.

이렇게 끊임없이 학습과 적응이 필요한 상황에서, 생산성 향상을 위해 많은 사람이 ChatGPT를 사용하고 있습니다. 마케팅 팀은 ChatGPT로 새로운 인사이트를 얻고, 고객 서비스(CS) 팀은 ChatGPT를 이용하여 고객 질문에 답변을 더욱 빠르게 제공할 수 있습니다.

DevOps 엔지니어도 ChatGPT를 업무에 활용할 줄 알아야 합니다. 엔지니어는 그 누구보다도 발빠르게 새로운 기술을 학습하고 변화하는 환경에 적응해야 하기 때문입니다. ChatGPT가 바로 그 ‘새로운 기술’입니다. DevOps 엔지니어가 ChatGPT로 효율적이고, 생산적인 작업 흐름을 만들려면 어떻게 해야 할까요?

이번 블로그에서는 내부 개발자 포털(IDP)인 Port를 사용해 사내 블로그 포스팅 프로세스를 자동화한 썰을 풉니다. 인포그랩에서는 블로그를 포스팅하기 위해 매일 10분 이상씩 하던 단순 반복 작업을 클릭 한 번에 동작하도록 했습니다. 그 결과, 개발자, 테크니컬 라이터의 스트레스를 줄여 더 중요한 업무에 집중할 수 있는 환경을 만들었습니다.

반복 작업을 줄이는 건 단순히 시간만 단축하는 것이 아닙니다. 수많은 사람이 단순 작업을 반복하느라 더 유용한 가치를 만드는 데 시간을 쓰지 못하고 있습니다. 이러한 작업을 줄이면 더 큰 가치를 창출하는 업무 시간을 확보할 수 있습니다. 이에 인포그랩에서는 수많은 교육 자료와 블로그의 배포 프로세스를 자동화하여 멤버들이 더 가치 있는 작업에 주력하도록 돕습니다.

빠르게 변화하는 소프트웨어 개발 세계에서 시간은 귀중한 자원입니다. 개발자는 워크플로의 생산성과 효율성을 개선하기 위해 끊임없이 노력합니다. 이 글에서는 일상적인 개발자 경험을 혁신하는 대규모 언어 모델(LLM) 기반 기술인 ‘코드 제안’을 소개합니다.

다음은 코드 제안의 사용 사례입니다:

• 작업 간소화
• 신규 개발자의 언어 탐색 지원
• 숙련된 개발자의 잦은 웹 검색 필요성 제거

이 모든 사례는 코드 제안이 어떻게 일상적인 개발자 경험을 향상하는지 보여주는 예시입니다. 이러한 사용 사례의 구체적인 예를 살펴보겠습니다.

거의 모든 최신 소프트웨어 인프라에는 필수적으로 모니터링 또는 로깅이 존재합니다. 1980년대에 Unix 시스템에 syslog가 출시되면서 ‘시스템 내부에서 무슨 일이 일어나고 있는지 감사하고 이해할 수 있다’는 가치와 이러한 메커니즘 분리의 아키텍처적 중요성이 모두 확립되었습니다.

그러나 시스템 동작의 가시성의 가치와 중요성에도 불구하고 모니터링과 로깅은 자주 우선순위가 뒤로 밀릴 때가 많습니다. 거기다 중요한 정보를 수집하거나 로그를 분석하지 않고 로그를 내보내는 시스템의 사례는 무수히 많습니다. 또는 레거시 모니터링 시스템이 10년 전에 설치되어 최신 표준으로 업데이트되지 않은 인프라도 있습니다.

최근 운영 환경의 변화로 인해 Observability라는 개념이 등장했습니다. 엔지니어가 정적 측정값을 사용해 애플리케이션의 성능 자체에 가정을 세우는 대신, Observability로 애플리케이션 동작의 전체 그림을 볼 수 있습니다. 아울러 사용자가 성능을 어떻게 인식하는지를 알 수 있습니다.

Observability 란?

Observability의 가치를 이해하려면 먼저 ‘모니터링이 무엇인지’, ‘정보와 콘텍스트 측면에서 모니터링이 제공하는 것과 제공하지 않는 것이 무엇인지’에 대해 이해하는 게 도움됩니다.

모니터링의 핵심은 특정 시스템 또는 소프트웨어 스택의 다양한 값과 출력의 측정 결과를 제시하는 것입니다. 측정의 일반적인 메트릭은 CPU 사용량, RAM 사용량, 응답 시간 또는 Latency 등입니다. 기존 로깅 시스템도 이와 유사하며, 시스템 작동 중에 발생한 이벤트의 정적 정보를 제공합니다.

모니터링은 시스템의 더 큰 문제를 나타낼 수 있는 제한된 콘텍스트 측정값을 제공합니다. 기존 모니터링 도구를 사용하여 집계 및 상관관계를 파악할 수 있지만, 전체적인 관점을 제공하려면 일반적으로 수동 구성 및 튜닝이 필요합니다. 업계가 발전함에 따라 효과적인 모니터링의 개념은 CPU, RAM과 같은 정적인 측정값을 넘어서는 수준으로 발전했습니다. 유명한 사이트 신뢰성 엔지니어링(Site Reliability Engineering·SRE) 책에서 Google은 "Golden Signals"로 알려진 네 가지 주요 지표에 집중해야 한다고 강조합니다.

• Latency: 요청을 처리하는 데 걸리는 시간
• Traffic: 전체 네트워크를 측정한 것
• Errors: 요청이 실패하는 비율
• Saturation: 리소스 사용량을 전체의 일부분으로 측정하는 것, 일반적으로 제한된 리소스에 중점을 둠.

이러한 메트릭은 전반적인 시스템 성능을 더 잘 파악하는 데 도움이 됩니다. 완전한 모니터링 시스템을 설계, 구축, 통합, 구성하려면 적지 않은 엔지니어링 투자가 필요합니다. 장애 상황을 측정하려면 상당한 노력이 필요합니다. 간단한 상황에도 올바른 상관관계를 정의하고 연결하는 데는 많은 시간이 소요될 수 있습니다.

이러한 데이터와 지표를 기반으로 시스템의 내부 상태를 파악하고 추론하는 능력이 바로 Observability입니다. Observability로 빠른 문제 파악, 해결, 의사 결정에 도움을 줘 시스템 안전성이나 확장성에 기여할 수 있습니다. 또한 CI/CD 실행 중에 중요한 성능 피드백을 제공하여 개발자에게 코드 운영 피드백을 제공합니다. 이로써 소프트웨어 개발 수명 주기(SDLC)를 더 확장할 수 있습니다. 궁극적으로 Observability는 더 전체적인 디버깅과 시스템 이해를 지원합니다. Observability가 중요한 '이유'를 더 자세히 알아보기 위해 다음 섹션에서 모니터링만으로는 부족할 경우를 소개합니다.

Observability가 중요한 이유

Observability에 집중하면, 가동 중단을 줄이고 평균 해결 시간(MTTR)을 단축할 수 있습니다. 이로써 애플리케이션 성능을 개선하고 고객 경험을 개선할 수 있습니다. 모니터링이 같은 이점을 제공하는 것처럼 보일 수 있지만, 다음과 같은 사례가 있을 수 있습니다.

Observability는 비기술 분야 이해관계자 및 비즈니스 부서에도 중요합니다. 기술이 주요 수익 사일로와 더욱 밀접하게 얽히면서 소프트웨어 인프라 KPI는 비즈니스 KPI가 되었습니다. Observability는 KPI 성과에 더 나은 인사이트를 제공할 뿐만 아니라 여러 팀용 셀프 서비스 옵션을 제공할 수 있습니다.

한 엔지니어링 조직이 회계 부서에서 이메일을 받았습니다. '클라우드 서비스 청구서가 너무 비싸서 CFO가 이를 알아차릴 정도다.' DevOps 엔지니어는 모니터링 시스템을 면밀히 살펴봤지만 메모리, CPU, 디스크 I/O 등 시스템의 모든 부분이 지속적으로 정상으로 보고되었습니다. 알고 보니 근본 원인은 또 다른 'Unknown' 이벤트였습니다. CI/CD 파이프라인의 DNS 지연으로 인해 빌드 실패율이 높아진 것입니다. 더 많이 빌드를 함으로써 많은 클라우드 리소스를 소모했습니다. 그러나 이러한 영향은 모니터링 시스템에 반영될 만큼 오래 지속되지 않았습니다. Observability 도구를 추가하고 환경의 모든 이벤트 유형을 수집함으로써 운영팀은 문제의 원인을 정확히 파악하고 문제를 해결할 수 있었습니다. 기존 모니터링 시스템에서는 조직이 DNS 지연 문제를 사전에 알고 있어야 했습니다.

최신 소프트웨어와 애플리케이션은 우수한 사용자 경험(UX)을 제공하는 데 크게 의존합니다. 이전 사례에서 알 수 있듯이, 정적 메트릭을 모니터링한다고 해서 UX 또는 시스템 성능의 완전한 이야기를 항상 알 수 있는 것은 아닙니다. 겉보기에 정상적으로 보이는 지표 대시보드 뒤에 심각한 문제가 숨어 있을 수 있습니다.

Observability 메트릭

Observability 도구를 구현하기로 결정한 조직은, 다음 단계로 Observability 의 핵심 목표와 이를 스택 전체에서 가장 잘 구현할 방법을 식별할 수 있습니다. 다은 Observability의 세가지 기본 요소로 시작하는 것이 좋습니다.

• Logs: 정보 및 이벤트
• Metrics: 특정 메트릭 및 성능 데이터의 측정
• Tracing: 런타임 동안 엔드투엔드 성능 요청

이 작업이 부담스러울 수 있습니다. 그러나 OpenTelemetry 같은 프로젝트는 Logs, Metrics, Tracing의 광범위한 표준 수용을 촉진합니다. 이로써 Observability를 구현하는 조직이 OpenTelemetry 표준에 기반한 도구를 사용해 더 일관된 생태계를 구축하고, 가치 실현 시간을 단축하도록 돕고 있습니다

추가적인 Observability 데이터 및 요소는 다음과 같습니다.

• Error 추적: 집계가 포함된 더욱 세분화된 Log
• 지속적인 프로파일링: 세분화된 코드 성능 평가
• 실제 사용자 모니터링(RUM): 실제 사용자의 관점에서 애플리케이션 성능 이해

이러한 요소를 살펴보면 중심 주제가 드러나기 시작합니다. 최신 분산 시스템에서는 더 이상 시간과 공간의 작은 조각을 보는 것만으로는 충분하지 않습니다. 전체적인 10,000 피트 뷰가 필요합니다. 애플리케이션 성능의 이해는 실제 고객이 경험하는 대로 샘플링한 다음, 소프트웨어와 상호 작용할 때 전체 성능과 동작을 추가로 모니터링하는 것에서 시작됩니다.

기존의 애플리케이션 모니터링을 넘어 Observability는 모든 엔지니어링 조직의 운영 환경을 개선하는 데 도움이 될 수 있습니다. 잘 만들어진 알림 및 인시던트 관리 프로그램은 대개 실제 중단을 통해 얻은 혹독한 교훈에서 비롯됩니다. 카오스 엔지니어링을 구현하면 결과가 알려진 통제된 환경에서 실제 장애가 발생하는 동안 Observability 플랫폼을 테스트할 수 있습니다. 프로덕션 워크로드뿐만 아니라 CI/CD 파이프라인, 공급망, DNS 등 'Unknown'이 숨어 있을 수 있는 시스템에 카오스 엔지니어링을 도입하면 운영 기반에서 상당한 이점을 얻을 수 있습니다.

Observability의 중요성

Observability는 데브옵스뿐만 아니라 조직 전체에 매우 중요합니다. Observability는 레거시 모니터링 솔루션의 정적 데이터를 대체하여 애플리케이션 인프라의 전체 스펙트럼을 보도록 지원합니다.

DevOps 팀은 이해관계자와 협력하여 조직 전체에 도움이 되는 방식으로 Observability 메트릭을 공유하고 구현을 개선하는 조치를 취해야 합니다. 앱 계측의 이점을 학습하고 개발 팀에 전파하면 Observability를 더욱 효과적으로 만들 수 있습니다. 또한 DevOps 팀은 프로덕션 인시던트의 근본 원인을 더 빨리 파악할 수 있으며, 잘 계측된 애플리케이션 코드는 인프라 문제와 쉽게 구분할 수 있습니다. 마지막으로, CI/CD 파이프라인을 따라 Observability가 달라집니다. 잠재적인 서비스 수준 목표(SLO) 델타를 프로덕션에 도달하기 전에 발견할 수 있습니다.

애플리케이션 성능과 비즈니스 성과에 의미 있는 개선을 제공하고자 하는 DevOps 팀은 두 가지를 모두 제공하는 방법으로 Observability를 고려할 수 있습니다.

Reference

• Observability vs. monitoring in DevOps

지난 포스팅에서는 ‘커밋 메시지가 무엇이며 인포그랩은 어떤 커밋 컨벤션을 사용하는지’ 알아보았습니다. 이모지를 쓰고 이슈 번호도 넣은 커밋 메시지는 추적하기 쉽고, 보기에 좋습니다. 하지만 커밋 메시지가 길고 복잡할수록 매번 불편하고 실수도 잦아집니다.

지난달 27일 GitLab 코리아 15번째 밋업이 온라인으로 진행됐습니다. 이날 밋업 주제는 **‘GitLab이 옵저버빌리티(Observability)를 만드는 방식’**이었는데요. Observability는 ‘외부 데이터에서 시스템 내부 상태를 얼마나 잘 유추할 수 있는지’ 나타내는 척도이죠.

밋업은 세션 1, 2로 나눠 진행됐습니다. 세션 1에서는 유인철 GitLab 코리아 이사가 ‘Observability를 향한 GitLab의 새로운 여정’을 주제로 발표했고요. Observability 개념과 GitLab의 Observability 전략, 원칙, 올해 출시할 기능을 공유했습니다.

세션 2에서는 신철호(Dexter) 인포그랩 이사가 ‘오픈 소스로 시작하는 Observability’를 주제로 발표했고요. Observability를 바라보는 엔지니어 관점과 Observability 필요성, 발전 과정을 소개했습니다. 또 Observabilit 도구인 Open Telemetry, SigNoz를 알아보고, SigNoz 데모도 선보였죠. 이 글에서는 지난 밋업의 주요 발표내용을 살펴보겠습니다.

GitLab 및 여러 기업은 페어 프로그래밍(짝 프로그래밍)을 통해 혼자 해결하기 어려운 과제들을 해결해 나가고 있습니다. 이 글에서는 페어 프로그래밍이 무엇이고, 어떤 장점이 있는지 확인해보고, 또 원격 페어 프로그래밍의 장점 및 적절한 활용을 위한 4가지 팁을 알아보겠습니다.

최근 IT 업계에서 마이크로서비스 아키텍처, 클라우드 네이티브와 같은 최신 기술 트렌드가 빠르게 채택되고 있습니다. 그러나 규모가 확장되면서 복잡해진 아키텍처에 대해 사용자들이 어려움을 겪고 있습니다.

git 커밋 메시지가 모든 소프트웨어 엔지니어에게 중요하다는 것은 이미 알고 계실 거라 생각합니다. 잘 만든 커밋 메시지는 다른 개발자에게 변경 사항을 전달하는 가장 쉽고 간편한 방법이기 때문입니다. 그래서 기업의 대규모 프로젝트는 당연하고 협력의 비중이 낮은 소규모의 사이드 프로젝트에서도 커밋 컨벤션을 따로 만들어서 규칙을 지키기도 합니다.

이번 포스팅에서는 좋은 커밋 메시지의 중요성과 커밋 메시지 잘 쓰는 법을 알아봅니다. 더불어 인포그랩 프로덕트 팀의 커밋 컨벤션을 소개합니다.

DevOps 개발자들은 쿠버네티스를 설정하고 사용할 때 주로 매니페스트로 작업합니다. YAML 파일이나 Helm 파일을 이용해서 쿠버네티스를 설정하는데요. 오늘은 GUI를 이용하여 쿠버네티스를 설정하고, Node.js의 서버 프레임워크인 NestJS로 개발한 백엔드 애플리케이션을 배포하는 방법을 알아보겠습니다. 클라우드 플랫폼은 GCP를 이용하겠습니다. 우선 클러스터 생성, DB 생성, 클러스터와 DB를 연결함으로써 쿠버네티스 환경을 세팅하고, 세팅 이후에는 배포하고 싶은 애플리케이션을 쿠버네티스 환경에 배포함으로써 외부에서도 접근이 가능하도록 진행하겠습니다.

1. 쿠버네티스 사용 환경 세팅하기

1.1 클러스터 만들기

GCP에서 Kubernetes Engine > 클러스터로 들어갑니다. 그 다음 만들기를 클릭한 후 AutoPilot을 선택합니다. 쿠버네티스를 잘 알거나, ‘이 클러스터를 생성할 때 메모리, CPU가 얼마나 필요한지’ 알아서 아키텍처를 잘 설계할 수 있다면 ‘Standard’로 선택해도 됩니다. 하지만 쿠버네티스가 처음이라면 AutoPilot을 사용하는 걸 추천합니다. AutoPilot을 선택한 이후 이름과 리전(서울 : asia-northeast3)을 선택한 뒤 클러스터를 생성합니다.

‘AutoPilot’은 유저 접속량에 따라 노드 개수를 자동으로 늘리는 기능입니다. 접속자가 없으면 리소스를 낭비하지 않도록 필요없는 노드를 줄이고, 접속자가 많으면 노드를 자동으로 필요한 만큼 늘립니다.

1.2 CloudSQL를 이용한 데이터베이스 생성

클러스터를 생성했으니 이제는 SQL을 이용해 데이터베이스를 생성합니다. 먼저 SQL 대시보드에 접속합니다. 그다음 인스턴스 만들기를 클릭합니다. 여기서 사용하고 싶은 데이터베이스를 선택합니다. 또 인스턴스 ID 와 비밀번호를 설정합니다. 시작할 구성 선택에서는 Development를 선택합니다. 만약 Production을 선택하면 컴퓨터가 2대이기 때문에 요금이 2배로 부과됩니다. 리전은 asia-northeast3, 영역가용성은 단일영역을 선택합니다. 많은 차이가 나지는 않지만, 비용을 절약하려면 머신유형 에서 CPU를 줄여서 선택합니다. DB이므로 공개가 되면 안 되기 때문에 연결 에서는 비공개IP 를 선택합니다. 네트워크 는 default를 선택합니다. 그다음 인스턴스 만들기 클릭하면 DB 생성이 완료됩니다.

DB를 생성했다면 DB의 데이터베이스를 생성합니다. 데이터베이스 이름은 쿠버네티스 작업부하에서 배포했던 환경변수에 입력한 데이터베이스 이름으로 변경하면 됩니다. 만약 작업부하에서 배포했던 환경변수에 입력한 데이터베이스 이름이 기억나지 않는다면 쿠버네티스의 Kubernetes Engine > 보안 비밀 및 ConfigMap에 들어가서 확인할 수 있습니다. 구성 맵 세부정보에 들어가 보면 데이터 부분에서 데이터베이스 이름(=DATABASE_DATABASE)을 찾을 수 있습니다.

1.3 DB와 클러스터 연결

클러스터와 DB를 생성했으니, 이제는 이 둘을 연결하는 작업을 할 것입니다. SQL과 애플리케이션을 연결하려면 쿠버네티스의 보안 비밀 및 ConfigMap > 데이터에 gcloudSQL의 DB HOST를 적어야 합니다. 만약 DB HOST가 기억나지 않는다면 SQL 대시보드에서 확인할 수 있습니다. SQL > 개요 > 이 인스턴스에 연결 > 비공개IP 주소안의 주소를 복사한 뒤 보안 비밀 및 ConfigMap의 환경변수에 붙여넣기합니다. DB를 생성할 때 DB를 비공개 설정했기 때문에 비공개IP주소로 공개됩니다. 이렇게 확인한 HOST와 PASSWORD 등 DB 연결 정보를 입력하여 애플리케이션과 DB를 대응합니다. (또한 만약 환경변수를 수정해야 한다면 이곳에서 수정하면 됩니다)

1.4 Container Registry

쿠버네티스에서 도커 이미지를 사용하기 위해서는 도커 이미지를 생성 후 Container Registry에 해당 이미지를 업로드 해야합니다. 업로드 방법은 아래와 같습니다.

1. docker build . : 현재 경로에서 이미지 빌드
2. docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG] : 도커이미지 경로/태그변경
3. docker push REGISTRY/PROJECT-ID/IMAGE:TAG : 레지스트리에 이미지 올리기

[TAG]는 변경된 코드가 있을 때마다 버전을 다르게 해서 업로드 해야 합니다. 태그를 다르게 해야 GCP가 변경을 감지하기 때문입니다.

Kubernetes Engine 클러스터에서 Container Registry 이미지를 등록시키기 위해 image의 경로를 작성한 뒤 코드를 Push 합니다. Push가 완료되면 image: HOSTNAME/PROJECT-ID/IMAGE:TAG 경로를 찾아 해당 태그의 이미지가 Container Registry에 업로드됩니다. Push를 위한 명령어는 아래와 같습니다.

• docker-compose -f docker-compose.prod.yaml build
• docker-compose -f docker-compose.prod.yaml push

생성된 이미지를 Container Registry에서 확인하실 수 있습니다.

1.5 Container Registry 이미지와 K8s 컨테이너 연결하기

쿠버네티스 클러스터를 만들었다면 이제는 Kubernetes Engine > 작업부하에서 컨테이너를 지정해야 합니다. 이미지 Push가 제대로 완료되었다면 Container Registry에 올라온 컨테이너 이미지를 선택할 수 있습니다. 원하는 이미지를 선택하고 환경변수를 설정합니다. VM 인스턴스에서는 $ vi .env.docker 같이 .env 파일을 생성한 뒤 설정했는데 GUI를 이용하면 환경변수를 UI에서 따로 지정할 수 있습니다. 만약 환경변수를 따로 지정하지 않으면 애플리케이션을 실행할 때 참조할 .env 파일이 없으므로 배포 시 에러가 발생합니다. 그러므로 애플리케이션을 개발할 때 사용한 .env가 있다면 반드시 환경 변수로 설정해야 합니다. 환경변수와 이미지를 선택한 뒤 하단의 구성 YAML을 보면 아래와 같은 YAML파일이 생성된 것을 확인할 수 있습니다.

---
apiVersion: "v1"
kind: "ConfigMap"
metadata:
  name: "nginx-2-config-f3jn"
  namespace: "default"
  labels:
    app: "nginx-2"
data:
  DATABASE_DATABASE: "sampleDB"
---
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "nginx-2"
  namespace: "default"
  labels:
    app: "nginx-2"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: "nginx-2"
	template:
	  metadata:
	    labels:
	     app: nginx-2
	 spec:
     containers:
      - name: my-container
        image: my-image
				env:
        - name: nginx-2-config-f3jn
          value: DATABASE_DATABASE

2. 쿠버네티스로 배포하기

2.1 배포한 NestJS에 접속

지금까지 쿠버네티스에 작업했던 백엔드 애플리케이션 코드를 push 하는 작업까지 진행했습니다. 그러나 아직은 외부에서 백엔드 서버에 접속할 수 없습니다. 이유는 외부 IP를 노출시키지 않았기 때문인데요. 클러스터에 외부 IP를 통해 노출해 줘야 외부에서도 NestJS 애플리케이션에 접속할 수 있습니다.

외부 IP 노출은 작업부하에서 해줄 수 있습니다. 작업부하에서 노출을 해주면 되는데, 확인은 서비스 및 수신에서 할 수 있습니다. 배포된 작업부하에 들어가면 노출 중인 서비스의 노출 버튼을 클릭합니다. 이 전에 서비스 유형을 선택해 주어야 하는데, DB처럼 외부에 공개하는 게 위험하고, 클러스터 내부에서만 접속할 수 있게 하려면 클러스터 IP를 선택하고 만약 외부에서도 접속할 수 있게 하려면 부하 분산기를 선택하면 됩니다. 포트와 대상포드1도 애플리케이션이 실행되는 포트로 설정해 줍니다. 예를 들어 백엔드 서버 작업을 3000번 포트로 작업했다면 3000으로 작성합니다. 노출 버튼을 클릭하여 노출해 주면 서비스 및 수신에서 확인할 수 있습니다.

설정을 마치면 엔드포인트가 생성된 것을 확인할 수 있습니다.

이 엔드포인트로 브라우저에서 접속하면 접속이 되는 것을 확인할 수 있습니다.

2.2 이미 실행중인 클러스터 Update

DB와 애플리케이션을 연결했으니 이제 애플리케이션이 제대로 실행되는지 확인해야 합니다. 또한 더 좋은 코드를 위해 계속해서 수정하다 보면 이미지를 업데이트해야 하는 상황이 발생합니다. 이때는 새로운 태그를 생성한 뒤 실행 중인 쿠버네티스 클러스터를 업데이트해 주어야 합니다. 그래야 새로운 코드를 반영할 테니까요. 재시작 혹은 업데이트는 터미널에서 할 수 있는데, 터미널에 접속하기 위해서는 현재 실행 중인 클러스터에서 Kubernetes Engine > 클러스터 > 실행 중인 클러스터의 '...' 메뉴 > 연결을 클릭합니다. 클러스터에 연결이라는 창이 새로 뜨면 CLOUD SHELL에서 실행 버튼을 클릭합니다.

클릭하게 되면 브라우저 아래에 터미널 창이 뜨는데, 거기서 자동으로 현재 클러스터의 위치를 잡아줍니다. 자동으로 경로를 잡아주기 때문에 커서가 깜박이는 상태로 enter를 쳐주면 해당 클러스터 터미널에 접속한 것입니다. 터미널에서 쿠버네티스 pods를 업데이트하는 명령어를 적어줘야 합니다. 그런데 이때 클러스터와 프로젝트 등 여러 가지 내용을 적어야 합니다.

이 정보를 확인하는 방법에는

• GUI로 확인하는 방법
• YAML파일로 확인하는 방법

총 2가지가 있습니다.

1. GUI에서 확인하는 방법: Kubernetes Engine > 작업부하 > 배포 세부정보로 들어가면 pods사양으로 확인할 수 있습니다.

   

2. YAML파일에서 확인하는 방법: kubectl get pods -o yaml cli명령어를 통해 확인할 수 있습니다.

containerStatuses:
- containerID: containerd://b25
  ...중략...
  lastStatus:[]
  name: new-backend-sha256-1  //컨테이너이름
  ready: true
  restartCount: 0
  started: true

위 2개의 방법 중 하나를 선택해서 정보를 확인했으면 아래 명령어를 통해 쿠버네티스 업데이트를 해줍니다.

$ kubectl set image deployment/작업부하배포이름 컨테이너이름=ContainerRegistry이미지이름

그래서 1.4 Container Registry에서 예시로 든 이미지를 예로 들자면 kubectl set image deployment/mybackend-nestjs new-backend-sha256-1=asia.gcr.io/new-backend-372105/new-backend:0.9 으로 작성해 줄 수 있습니다. 업데이트가 완료되면

$ deployment.apps/mybackend-nestjs image updated

라는 명령어를 통해 업데이트가 완료되었는지 확인할 수 있습니다. 그리고 업데이트가 되고 pods가 잘 작동하는지 확인하려면

$ kubectl get pods

명령어를 통해 pods의 상태를 확인할 수 있습니다.

NAME								READY	STATUS		RESTARTS	AGE
mybackend-nests-65f6cdd775-rh6sg	1/1		Running		0			22h
mybackend-nests-b69869589-arrzp	    0/1		Pending		0			31s

현재 Pending 상태라는 것을 확인할 수 있는데 새로 만들고 있는 것을 확인할 수 있습니다. 새로 만들어진 pods는 Pending이었다가, Container Creating이었다가 시간이 조금 더 지나면 Running으로 변경됩니다. 그러면 기존에 Running이었던 것들이 Terminating으로 바뀌면서 사라집니다. 이제 새로 생성된(=업데이트된) pods가 잘 실행되고 있는지 확인해 봐야 합니다.

$ kubectl logs -f pods의NAME

pods의NAME은 NAME을 -f 뒤에 적어주면 됩니다. 그러니까 위 예시의 pod의 상태를 확인하려면 kubectl logs -f mybackend-nests-65f6cdd775-rh6sg 라는 명령어를 사용하여 현재 애플리케이션의 상태를 확인할 수 있습니다.

맺음말

지금까지 GCP에서 K8s와 Docker를 이용해서 NestJS 배포하는 법을 알아보았습니다. 주변에서 Backend 개발자들이 Backend와 배포를 모두 담당해야 하는 경우도 종종 찾아볼 수 있는데요. 이럴 때 GUI를 이용한다면 조금 더 쉽게, 낮은 진입장벽을 가지고 DevOps에 접근할 수 있을 것 같습니다.

인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.

<참고자료>

Google Cloud에서 Container Registry 사용

docker tag

Google Cloud Container Registry 이미지 가져오기 및 내보내기

Kubernetes 1.26에서 Scheduling gates라는 새로운 파드 옵션이 도입되었습니다. 이 옵션은 파드를 Readiness 상태로 두어, 스케줄러는 해당 파드를 무시하며 궁극적으로 스케줄링 주기의 속도를 향상시킬 수 있습니다. 그렇다면 스케줄링 게이트란 무엇일까요? 먼저, 파드의 스케줄링 방식을 알아봅시다.