도커 컴포즈가 어쩌구. 쿠버네티스와 도커 스웜이 저쩌구

이 글은 실습 코드가 없습니다. 귀찮아서요 실습 코드는 다음에 올려볼 생각입니다

글을 쓰게 된 비동기

저는 프로젝트를 할때 도커를 애용합니다.

회사에서도 도커를 하지만 (사실 도커 이미지를 사용하는 쿠버네티스를 하는거지만) 개인 프로젝트나 팀 프로젝트에서도 도커 만큼 꼭 필요한게 없는거 같습니다.

사실 요즘같이 마이크로 서비스 아키텍쳐와 쿠버네티스 같은 도구를 사용하는 시대에서는 도커의 중요성이 점점 늘어나고 있죠

사실 제목 어그로를 좀 끌었지만 도커가 무너진적은 없습니다. 무너질수 있는건 버그 때문에 미친 제 뇌 밖에 없습니다.

하지만 도커 스웜이 뭔지를 모르시던 분이 이 글을 읽으면 그 분의 도커 지식이 무너질수도 있지 않을까요?

장난이고 이 글을 읽어보시고 도커 스웜을 사용해보실수 있는 분들은 써보길 바라겠습니다

쿠버네티스

도커 얘기한다고 하고서 쿠버네티스로 시작하게 된 점 죄송합니다.

사실 쿠버네티스 얘기를 꺼내는 순간 머리가 아파지는 개발자들이 많죠?

쿠버네티스가 정확히 뭔지는 벨로그에 찾아보시면 많이 나옵니다. 네?
저번글에서부터 계속 말하지만 저는 귀차니즘이 아주 심각한 개발자로서 벨로그에 잠깐만 찾아보면 몇백 까지는 아닌가 개의 게시글들이 있는 주제는 좀 피해보려고 하겠습니다.

간단하게 정리를 해드리면:

1. 쿠버네티스는 클러스터로 관리를 한다
2. 클러스터에는 여러개의 노드가 존재 한다 (노드 = 인스턴스)
3. 노드에는 여러개에 파드가 존재한다 (파트 = 서비스)
   

뭐 대충 이렇게 말하면 구조는 이해하시는거고 쿠버네티스의 장점은 그 외에도 자가치유, 롤백 기능, 등등 여러 인스턴스의 올라가있는 서비스들은 클러스터로 묶어서 관리를 자동으로 해주고 필요에 따라 서비스 스케일링 까지 해주는 사실상 카프카와 함께 요즘 마이크로서비스 아키텍쳐에서 빼놓을수 없는 툴입니다. (제가 틀린 부분이 있을수 있습니다. 원래 블로그 글들은 믿거나 말거나 아닌가요)

뭐 하여튼 빼 놓은 부분도 있고 부족한 부분도 있지만 그런거는 다른데서 찾아보시면 됩니다.

그리고 이 쿠버네티스는 ci/cd를 특별하게 젠킨스나 깃허브 액션이 아닌 argo/flux cd를 많이 사용하는데... 그건 다음 얘기에

도커 - 도커 컴포즈

도커가 뭔지는 대충 다들 아신다고 생각하고 바로 도커 컴포즈로 넘어가겠습니다. (다시 말씀 드리지만 이건 벨로그 찾아보시면 저보다 더 잘 쓰신 개고수들 많ㅇ...)

도커 컴포즈는 도커 컨테이너, 네트워크, 볼륨, 등등을 한번에 올려주고 설정해주는 기능을 갖고 있습니다.

보통 docker-compose.yml 파일에 작성을 해서 docker-compose up, docker-compose build, docker-compose down 뭐 엄청나게 다양한 명령어를 통해 제어를 할수 있죠.

docker run ...어쩌구 저쩌구 를 10번 해서 서비스 10개를 띄우는걸 한번에 해준다는 장점이 있고 yaml 파일에 작성을 해두니 나중에 수정이나 다시 서비스를 띄울때 편합니다.

여러 컨테이너를 관리하고 사용하기 편하게 해주는 툴이라고 생각하시면 됩니다.

사고 싶다

그럼 도커 스웜은 뭐임?

미안하다 이거 보여주려고 어그로 끌었다

앞에 "도커" 라는 이름이 붙어있지만 도커 스웜은 도커 컴포즈와 많이 다릅니다.

도커 스웜은 경량화된 쿠버네티스 라고 생각하는게 맞는거 같습니다.
물론 그만큼 부족한 기능이 많지만 더 좋은 부분도 존재하죠.

장점:

1. 가볍다
2. 설정이 간단하다
3. 도커 컴포즈 문법이랑 차이가 거의 없다
4. 새로운 cli (kubectl 같은) 를 설치 안해도 된다

단점:

1. 애매하다
2. 기능이 부족하다 (자동 스케일링 등등)
3. 사실상 도커가 유기한 느낌이 가끔 난다
   

사실 개인 프로젝트에서는 도커 컴포즈로 싱글 호스트 기반 베포에서는 충분 합니다.

하지만 제가 최근 진행하고 있는 프로젝트는 나름 마이크로서비스 아키텍쳐인데 쿠버네티스를 직접 운영하던가 EKS, GKE를 사용하기에는 너무 돈이 많이 들기에 짠돌이 도커 스웜을 사용 했습니다.

쿠버네티스처럼

1. 여러 노드를 클러스터 처럼 묶어서 관리
2. 서비스 로드 밸런싱
3. 네트워크 오버레이로 관리
4. 지속적인 볼륨 (사실 이건 도커가 쿠버보다 더 먼저한 기능인거로..)

등등 도커 컴포즈에서는 없는 괜찮은 기능들은 사용할수 있습니다.

특히 멀티노드 아키텍쳐에서 서비스 orchestration을 할수있는 도구는 스웜이나 쿠버네티스가 정배 입니다.

직접 쿠버와 스웜을 써본결과 전체 서비스 사이즈가 크지 않을경우 스웜으로 충분하고 특히 돈도 더 절약되는걸 확인 할수 있었습니다.

결론

요즘 채용공고를 보면 규모가 크든 작든 다 쿠버네티스 경험있으신분 구합니다 또는 신입한테는 말도 안되는 조건들은 걸어두던가 하는 경우가 좀 많은거같습니다.

특히 회사 규모가 작으면 쿠버네티스를 쓰는게 배보다 배꼽이 더 큰 경우도 많을탠데 말이죠. 그만큼 신입한테는 허들이 점점 높아지는거 같습니다.

그래서 친구들한테 물어보니 많은 회사에서 쿠버네티스가 정말 필요해서 도입하기 보다는 이직을 할때 대기업들이 원하는 기술 스택을 위주로 맞출수 있게 자기 회사에 도입을 하는 경우가 좀 있는거 같더군요. 회사돈으로 쿠버 돌리면 좋긴 합니다

물론 이력서 주도 개발 (Resume Driven Development)가 나쁜건 아닌거 같습니다. 대기업을 따라하려고 하다보면 대부분 더 좋고 실서비스에 유리한 기술들은 쉽게 접하게 될수 있으니까요. 하지만 그런 회사들 조차 신입들이 들어가려고 하면 너무 힘들어지는게 문제인거 같습니다.

이력서 주도 개발 - by. O RLY? (아 그래?)

말이 길어졌지만 쿠버네티스를 사용하시다가 지칠때나 비슷한 경험을 더 싼? 가격에 해보고 싶으신 분들에게 도커 스웜은 어떨까요?

읽어주셔서 감사합니다.