해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!

• 강의 링크 : https://inf.run/NzKy

이번 블로그에서는 아래 DevOps를 구성하는 오픈소스들이라는 주제로 데브옵스를 설명을 드립니다. 내용의 수준은 비전공자가 데브옵스에 대한 전반적인 내용을 이해하기 좋은 정도인 점 참고 바래요.

데브옵스를 구성하는 오픈소스들

DevOps가 개발에서 운영까지 원할한 흐름을 만드는 건데, 중간에 가장 중요한 역할을 하는게 CI/CD죠. CI는 통합된 소스를 가지고 빌드/테스트를 자동화 시키는 기능을 만드는 거고, CD는 배포를 자동화 시키는 기능을 만드는 거예요.

그래서 결국 개발을 해서 커밋을 하는 순간, 운영 환경에 App이 자동으로 배포가 되는 파이프라인이 만들어 지는데, 세부적으로 나누면 위 그림처럼 8가지 단계가 있습니다.

계획/개발, 빌드/테스트, 릴리즈/배포, 그리고 운영/모니터링 인데, 이걸 각 단계를 대표적으로 사용하는 오픈소스를 가지고 얘기를 해보겠습니다.

[계획] 단계부터 시작 할께요.

제가 개발할 당시에는 redmine을 많이 쓰긴 했는데, 지금은 Jira나 notion을 많이 써요. 기능은 비슷한데, UI가 요즘 스타일로 많이 세련되 졌고요. 개발 일정을 공유하거나 이슈 사항들을 기록해야 되기 때문에 이런 툴을 사용하죠. 협업은 서로 메신저를 통해서 개발에 관련된 대화를 하는 걸 말하는데, 사실 카톡이나 사내 메신저를 써도 되는 부분이긴 하지만  그래도 슬렉을 쓰는 가장 큰 이유가 하나 있습니다. 

그 이유는 가장 마지막에 설명 드릴께요.

 다음으로 [개발]인데

인텔리제이나, OpenJDK, 그리고 Spring Boot는 이전에 말씀 드렸고, 밑에 JUnit은 테스트 코드를 작성할 때 필요해요.

보통 개발할때 if문 3~4개에 for문도 여러개 섞어서 복잡한 로직을 만들어 내죠. 이게 처음 만들 때는 집중해서 만들기 때문에 로직이 이해 되는데, 하루만 지나도 이 로직이 이해가 안되기 시작해요. 아무래 내가 짠 코드라도 다시 이해하는게 힘들어 지는데, 이럴때는 차라리 입력값을 넣어서 돌려보고, 결과값을 보는 게 로직을 이해하는 데 쉽거든요.

그래서 바로 이런 테스트 코드를 만들어 놓는 게 좋고, 혹시라도 다른 사람이 이 로직을 수정하더라도, 테스트 코드를 돌려봐서 기대했던 값이 잘 나오면 안심을 할 수가 있죠. 그래서 코드를 개발할 때 조금만 고생해서 이렇게 테스트 코드도 같이 만들어 놓습니다.

다음으로 코드 분석 이라고 해서 FindBug나 PMD는 내가 짠 코드 패턴에 혹시 모를 버그가 있는지를 체크해줘요. 그래서 잘못된 로직을 짜지 않도록 도와주는데, 이런거 뿐만아니라 개발자간에 미리 코딩 스타일을 정해 놓거나, 개발 편의를 위해서 사용하는 툴 들은 엄청 많습니다.

다음으로 [빌드]를 볼께요.

빌드 대상은 소스와 컨테이너고 Gradle과 도커가 사용됩니다. 소스 빌드로 현재 Maven보단 Gradle을 많이 쓰지만 저장소 자체는 메이븐 저장소에서 라이브러리를 가져 오는 거고요. 도커도 이전 [컨테이너 한방정리]에서 많이 얘기를 해서 이번엔 넘어 갈께요.

이제 다음으로 [테스트] 예요.

테스트를 해야되는 요소에는 크게 3가지가 있는데, 기능이랑 성능 그리고 커버리지예요.

각각 Junit, Jmeter, JACOCO라는 툴 들이 쓰이고. 각자 개발단계에서 테스트 코드를 만들고 실행을 해봤더라도 코드들이 병합되고 나서 또 다른 결과가 나올 수 있기 때문에, 빌드 단계에서 이 JUnit을 실행시켜서 자동으로 테스트를 한번 더 돌려 보는 거예요.

그래서 위치는 이렇게 빌드에 연결되서 테스트가 같이 실행되는 거고, 테스트 이후에 Jacoco라는 툴을 돌리면 이 테스트를 돌렸을 때 사용된 로직들이, App 전체에서 어느정도 범위를 테스트 해본 건지, 커버리지를 결과를 알려줍니다.

그래서 내가 돌려본 테스트 케이스들이 전체 로직에서 많은 부분을 차지할 수록, 이 App에 대한 신뢰도가 높다고 판단을 해요.

그리고 JMeter는 성능 테스트를 하는 툴 인데, 이건 자동화 기능은 아니고, 여기 개발환경이나 검증환경을 대상으로 진행 합니다. 통상 별도의 성능 테스트 전문 인력이 날잡아서 수동으로 진행하고요.

이제 다음으로 [릴리즈]와 [배포] 입니다.

릴리즈는 배포 가능한 패키지를 만드는 과정이에요.

도커 빌드를 하기 위해서는 Dockerfile이라는 스크립트를 작성해야 되고, 또 쿠버네티스에 배포를 하기 위해서 yaml 파일들을 사전에 만들어 놔야 되는데 이렇게 배포를 하기 위한 별도의 패키지를 만드는 게 릴리즈고, 이 파일들도 변경관리가 되야 하기 때문에 작성한 내용들을 이렇게 Github에 올려 놓습니다.

그리고 배포할 때 사용을 하는데, 이 릴리즈와 이 배포 부분이 이번 Sprint2에서 다루게 될 주요 범위예요.

배포를 하기 위한 툴로는 대표적으로 kustomize와 helm 그리고 argoCD가 있고, 다 Sprint2 강의에서 배우게 됩니다. Sprint1 강의에서는 kubectl로 배포를 했지만, 이제 이런 도구들을 써서 쿠버네티스에 배포를 하게 되는 거죠.

이제 다음 단계로 [운영]입니다. 

이건 실제 운영환경을 구성하는 요소와 툴 들이라고 보시면 되요. 여기서 Nginx와 Istio는 네트워크 트래픽 관리에 대한 도구고, 나머지 들은 [쿠버네티스 무겁게 설치하기]에서 나왔던 익숙한 그림일 거예요. 이외에도 운영을 구성하는 환경들은 다 표현하기 힘들 정도 많지만, 이정도로만 하고

이렇게 인프라 환경 안에서 설치되고, 운영자는 이 툴들이 정상적으로 잘 돌아가고 있는지 확인해야 하는 역할을 하죠.

그리고 마지막으로 [모니터링]인데,

모니터링 요소는 주로 자원 사용량이나 App로그 그리고 트래픽 흐름을 많이 봐요. Grafana 나 Loki 그리고 Prometheus는 Sprint1에서 사용을 해봤고. 이게 자원 사용량이랑 App로그를 보기 위한 툴이였죠?

그리고 Jaeger랑 Zipkin은 트래픽 흐름을 보기 위한 도구예요. 이제 마이크로서비스 환경이 많아졌기 때문에 서비스들 간에 트래픽이 어떻게 흘러가는지 추적을 하는게 중요해 졌습니다. 그래서 이런 오픈소스들을 설치해야 되고

위치는 운영과 똑같이 인프라 환경 내에 설치가 되요. 이 App들은 다 쿠버네티스 클러스터 위에서 Pod로 띄어 진다고 보시면 됩니다.

그럼 여기까지가 모니터링까지 다 설명을 드린거고,

아까 [Slack을 쓰는 이유]를 마지막에 말씀드린다고 했는데, 

딴게 아니라 이렇게 연결되는 그림들이 있어야 되서 그래요. 이렇게 슬렉은 데브옵스에 중요 포인트 차지하고 있는 툴들이랑 연동이 할 수가 있거든요.

통상 메신저에는 개발자나, 데브옵스 엔지니어 혹은 운영자들이 모여 있는 방이 각각 있을 텐데, 슬렉을 쓰면 이 파이프라인에서 발생하는 알람들을 필요한 방에 울리도록 설정할 수가 있는거죠. 그래서 이게 협업을 위한 여러 메신저들 중에서, 그래도 슬렉을 쓰면 좋은 점 이었습니다.

자 그럼 여기까지가 데브옵스를 구성하는 오픈소스들에 대한 설명이였는데, 어떻게 데브옵스가 좀 실질적으로 와닿으시나요? 현재는 이렇게 데브옵스가 복잡해 졌습니다. 그래서 기업에서는 데브옵스 엔지니어를 별도로 뽑을 수 밖에 없는 거고요.

뭔가 많아 보이지만, 그래도 차근차근 하나씩 구성하다 보면 생각보다 금방 파이프라인이 만들어 지기도하고 여기 있는걸 한번에 다 만들 필요는 없어요. 배포를 한다고 처음부터 helm이나 argoCD를 적용할 필요는 없는 거고 Kubectl 배포부터 일단 연결을 해 놓은 다음에 하나씩 장비를 업그레이드 하는 마음으로 바꿔 나가면 되거든요.

이번 강의도 그런 스탭으로 구성을 했으니까, 끝까지 잘 따라오시길 바라고요!

아래 내용들은 강의에서 자세히 설명 드릴 내용들입니다.

쿠버네티스 어나더클래스 DevOps 전체 구성도

DevOps에서 가장 중요한 것 (개발->빌드->실행파일)

DevOps에 엮인 IT 직군들

DevOps 외 다른 Ops들

ps. ♡ make me want to be a better man :)