ROOT

모니터링의 중요성을 체감해보지는 못했지만, 그 중요성만큼은 느껴집니다. 예를 들어서, 분산 애플리케이션을 배포하고 이를 오케스트레이션해야 할 때, 가용성을 높이기 위해 오토스케일링 기준을 정해야 합니다. CPU는 어느 정도로 요청하고 제한해야 할지, 그리고 특히 메모리는 CPU와 달리 비압축 리소스이기 때문에 요청과 한계를 설정하는 것이 매우 중요하게 되죠. 이런 간극을 확인하고 설정하기 위해서 모니터링 도구는 메트릭을 집계하고 계속해서 모니터링하여 확인할 수 있으므로 유용하게 사용할 수 있습니다. 비단 위와 같은 예시 뿐만 아니라, 어느 시각에 트래픽이 몰리는지 한 눈에 확인할 수 있고, 어느 호스트가 장애를 겪고 있는지도 모니터링을 통해 손쉽게 확인할 수 있습니다. 여기에 훅을 통해 ChatOps까지..

CI/CD를 사용할 때는 gitlab을 주로 사용한다고 합니다. GitHub와 달리 기본적으로 CI/CD에 집중한 원격 저장소라는 점이 특징이기 때문입니다. GitHub가 많은 사용자와 자유로운 기능이 장점이라면, GitLab은 통합적으로 서비스를 사용할 수 있다는 것이 장점이라 각각 고유의 메리트가 있습니다. GitLab 레포지터리에 들어가보면 바로 Set CI/CD 버튼이 보이네요. 이번에는 gitlab ci를 통해 웹서버를 레포지터리에 업로드하고, 원격으로 웹서버를 띄우는 간단한 실습을 진행해보겠습니다. CI 단계만 진행하므로 서버로의 배포는 수동으로 진행합니다. 준비물 간단한 테스트를 위한 서버 애플리케이션을 생성합니다. 기본적으로 헬스 체크 기능을 만들어 연결을 확인했습니다. 레지스트리는 ECR..

쿠버네티스는 API 서버를 사용하여 리소스들의 생성을 감독합니다. 실제로 API 서버를 사용하는 리소스들을 살펴보면 아래와 같습니다. etcd를 제외하고서 거의 대부분의 중요한 리소스들이 API 서버를 의존하고 있습니다. API 서버는 그 이름처럼 API를 받아서 이를 처리하는 리소스인데, 외부 클라리언트가 kubectl 등으로 요청을 전송하면, RESTful API로 변경하여 클러스터를 조작합니다. API 서버 내부에서는 그 요청을 보낸 주체가 누구인지 인증 플러그인을 거치고, 권한 승인 플러그인으로 리소스에 대해 요청을 수행할 수 있는지 결정한 다음, 승인 제어 플러그인을 통해 리소스를 수정/삭제 혹은 거절합니다. 최종적으로 리소스의 상태와 데이터 등을 etcd에 저장합니다. API 서버가 직접 리소..

오늘은 자동화의 꽃인 파이프라인을 구현해보도록 하겠습니다. 배포 자동화는 다양한 방법으로 구현할 수 있습니다. 예를 들어서, github actions로 beanstalk에 패키지를 전송하여 배포할 수도 있으며, code pipeline을 통해 빌드와 배포를 자동화할 수도 있고, github actions로 빌드한 파일을 code deploy에 전달하는 방법도 있습니다. 파이프라인을 추상적으로 보자면, 빌드 -> (테스트) -> 배포의 과정을 가지고 있습니다. 이번에는 kubernetes를 활용하는 환경에서 github action과 argocd를 활용해 빌드 및 배포를 자동화하는 방법을 구현합니다. 나름대로 구조를 구체화했을 때, 아래와 같은 형태를 따릅니다. 과정은 아래와 같습니다. 개발 내용 커밋/..