Sprint2 추가 강의가 업로드 됐어요! (https://inf.run/NzKy)

이번 강의에서는 배포를 하기전에 반드시 알아야 될 것들 이라는 주제로 설명을 드릴 건데, 배포에 관련된 툴 공부를 바로 시작하는 것보단, 어떤 걸 써야 되는지, 왜 써야 되는지를 아는 게 더 중요하다고 생각해서 준비한 강의 입니다.

저는 예전에 최신 솔루션을 많이 알고, 신규 업데이트 된 기능을 빨리 쓰는 사람이 능력 있어 보였고, 저도 그렇게 되고 싶었는데 여러 프로젝트를 해보니 프로젝트 상황에 따라 적합한 기술을 쓰는 게 더 중요하더라고요.

신규 기술이라고 빨리 도입했다가 레퍼런스가 별로 없어서 프로젝트 내내 구글링하고 이슈 수정 요청을 하느라 고생했던 적도 있고, 원대한 포부를 가지고 한번에 많은 툴 들을 적용 하려고 했다가, 운영이 시작되면서 예상하지 못한 문제 때문에 장애처리에 시달리는 경험도 해보면서 진취적인 성향에서 일을 단계적으로 하려는 성향으로 바꼈는데, 결국 이렇게 일을 하는 게 월급을 높이는데도 효과가 더 좋았다고 말씀드릴 수 있습니다.

부디 적재적소에 맞는 도구를 사용할 줄 아는 사람이 되길 바라면서 이번 블로그도 시작해 볼께요.

CI/CD 파이프라인을 구성할 때 고려해야 하는 요소

첫번째로, 파이프라인을 구성 할 때 [관리 담당]에 대한 부분을 고려해야 합니다.

이 그림상으로만 보면 굳이 작업을 분리할 필요가 없이 젠킨스 파이프라인을 쓰는게 깔끔해 보이죠? 수정할 일이 생겼을 때, 세 군데 들어가서 보는 것보다 한 곳에서 보는 게 편하기도 하고요. 그래서 일반적으로는 젠킨스 파이프 라인을 선택하는 게 기능적으로는 좋다고 볼 수 있습니다.

근데, 실무에서 일하다 보면 기능적인 구분 보다 보다 담당하는 사람에 따라 구성을 분리를 하는 게 좋을 때도 많아요. 각각 역할을 구성하는 관리 담당자가 다를 수가 있거든요. 실제 프로젝트에서는 기능이 만들어져 있고, 그에 따라 담당자를 정하는 게 아니고, 담당자가 먼저 정해지고, 함께 기능을 만들어가기 때문에 그래요.

그리고 내가 이런 큰 그림을 그리는 위치라면, 기능보다 이렇게 관리 담당자 별로 구성을 나누는 게 업무 분장 측면이나 관리 책임적으로 더 효율적입니다.

그래서 배포 파이프라인을 구성할 때, 기능적인 측면과 관리적인 측면을 고려해서 현재 뭘 중시하는 게 효율적인 지를 고민해 볼 필요가 있는 요소에요.

다음으로 [운영정책]인데,

젠킨스에서는 소스 빌드랑 컨테이너 빌드만 하고요.  ArgoCD라는 쿠버네티스 전용 배포툴을 이용하면 각각에 쿠버네티스 환경에 배포를 할 수 가 있어요. 그럼 이때 이 배포 툴들은 이제 젠킨스가 아닌 argoCD를 통해서 사용 되는 겁니다.

그리고 밑에 아래 그림 처럼 배포 영역을 빌드와 구분해서도 많이 쓰기도 해요. 근데 여기서 제가 얘기 하려는 부분은 배포와 인프라 환경의 관계를 이렇게 1대 다로 구성할 수도 있고, 이렇게 각 환경마다 ArgoCD를 둬서 1대 1로 구축 할 수도 있다는 거죠. (후자 방식을 더 많이 쓰긴 하지만)

이런 구성에 장단점은 명확 합니다. 위 구성은 ArgoCD를 이중 관리 해야되는 부담감은 있지만, 개발환경에서 뭘 하던 장애가 나도 운영환경에는 영향이 없죠. 반대로 아래 구성은 하나만 관리해서 편의성은 좋은데, 개발 환경 때문에 장애가 나면, 운영환경도 배포를 못하는 거고요. 지금은 배포와 argoCD를 가지고 말씀 드리는 거지만, 이런 구조적인 상황에 따른 장단점은 IT 전반에서 시스템을 설계를 할 때 흔히 볼 수 있는 상황이예요.

그럼 이때, 그래도 실무에서는 운영환경에 영향도가 중요할 텐데, 관리가 불편하더라도 당연히 이 방식을 선택해야 하지 않을까?라고 생각 할 수 있을 것 같아요. 근데 이건 정말 회사마다 운영 방침에 따라 관리 편의를 중시할 꺼냐, 장애 영향도를 중시할 꺼냐에 따라 다릅니다. 

하지만 관리 편의를 중시한다는 게 장애가 나도 된다는 말은 아니고, 이 배포 부분이나 CI/CD 전체 서버가 죽더라도, 새로운 배포를 못할 뿐이지, 현재 돌아가고 있는 서비스에 문제가 되는거 아니잖아요? 그래서 좀 유연한 운영 정책을 가지고 있는 곳에서는 이렇게 서비스에 지장이 없는 경우라면, 이렇게 중앙 구성을 하고, 심지어 이 구성에 이중화를 안 시키기도 해요. 왜냐면 그만큼 안전을 중시하기 위해 들어가는 비용도 만만치가 않거든요.

그래서 배포를 단일 구성으로 갈지, 분리 구성으로 갈지에 대한 고민도 필요하다는 말씀을 드립니다.

다음으로 [제품 선정]이에요.

온라인 용 CI/CD 툴로는 GitHub Actions가 있고, 오프라인 용으로는 Jenkins랑, jenkinsX, 그리고 TEKTON이란 게 있어요. 온라인은 인터넷 환경에 연결해서 쓰기 때문에,  당연히  CI/CD 서버를 별도로 만들 필요가 없다는 장점이 있죠.

그리고 오프라인으로 JenkinsX는 젠킨스에서 컨테이너 환경에 맞춰서 새롭게 만든거고, Tekton 역시 컨테이너 환경에 최적화된 CI/CD를 목적으로 만들어진 도구이에요.

그럼 이제 여기서 CI/CD 제품을 선정할 때, 큰 기준이 되는 게 온라인이랑 오프라인인데 대체로 Github와 같은 글로벌한 제품들은 보안이 잘 되기 때문에, 기업에서 인터넷 환경에 접속해서 쓴다고 문제 될 건 없어요. 기업이라고 해서 무조건 내부에 서버실을 만들어서 내 서비스를 운영할 필요는 없다는 거죠. 지금은 클라우드 서비스에 내 시스템을 다 올려서 많이들 쓰고 있으니까 잘 공감이 되리라 생각 됩니다.

근데 그럼에도 불구하고 자사에 시스템이 인터넷 상에 있으면 안되는 기업도 많아요.  금융권 내지는 의료기관이나 공공기관들이 대표적이고, 그 밖에도 많은데 정확히는 시스템에 대한 제한이 아니라, 그 시스템이 다루는 데이터가 중요하기 때문에 인터넷 영역으로 올리면 안되는 거죠.

이 CI/CD 서버 역시 개발 소스나 릴리즈 파일들에서 중요한 정보들이 많거든요. 그래서 이럴 때는 오프라인 툴을 쓸 수 밖에 없는거고 추가적으로 CI 전용 Tool에는 이런게 있고, CD 전용 툴로 이렇게 ArgoCD랑 Spinnaker라는 툴도 있어요. 다 컨테이너 환경에 최적화 된 툴 들인데 이렇게 오프라인을 써야 한다고 하더라도  비슷한 기능에 툴 들이 참 많죠.

이전 에도 말씀드렸지만, 이럴 땐 레퍼런스가  많이 쓰는 걸 선택하는 게 가장 후회가 적습니다.

이렇게 제품 선정에 있어서, 데이터 보안 상황에 따른 온라인과 오프라인 제품의 선택 그리고 레퍼런스가 많은 제품 인지를 보는 게 좋은데 한 가지 더 추가를 하면,

제품을 도입하고, 계속 유지보수로 계약할 수 있는 업체가 있냐 없냐의 유무도 중요합니다. 이건 레퍼런스를 떠나서, 어차피 회사 내부에 해당 제품을 직접 다루는 사람이 없거나, 아니면 유지보수 인원에 비해서 엄청 많은 제품들을 사용하고 있는 상태인 회사에서 한번 설치한 이후에 잦은 관리가 필요 없는 제품일 경우, 최소한에 유지보수 비용만 들여서 필요할 때 해당 제품에 전문가를 부르는 게 나으니까요.

그리고 다음으로 도커 대체가 있습니다.

이게 뭐냐면, 컨테이너 빌드를 할 때, 도커말고 다른 제품을 쓰려고 하는 이유가 있어요. 처음 도커가 나오고 대중적인 인기를 끌다 보니, 안 좋은 점도 많이 부각됐죠. 물론 단점은 꾸준히 보완 돼 왔고, 여전히 편하게 쓰고 있긴 하지만 그래도 개선되기 힘든 두 가지를 말씀드리면

"Docker가 무겁다는거"랑, "Daemon이 필요하다는 거"예요. 도커가 기능이 많기 때문에 새로 만들지 않는 이상 가벼워지기 힘든 부분이고, 그러다보니 자원을 많이 사용하긴 해요.  근데 다행이도 빌드 속도가 느리다는 건 아닙니다. 오해하시면 안되고 또 하나가, 도커 Daemon이 항상 띄어져 있어야지, 컨테이너가 돌아간다는 거예요.

이 Daemon이라는 게 리눅스에 백그라운드로 항상 돌아가고 있어야지, 실행 가능한 제품이라는 거예요. 우리가 kubectl을 쓸 때는, 별도로 kubectl을 띄어 놓지 놓지 않아도 그냥 명령어를 칠 때만 실행하고 쓰고 끝나잖아요? 이런건 daemon-less app 이라고 말하고, 반면에 도커는 daemon이 필요한 app 이라는 거죠.

그래서 도커로 컨테이너를 여러게 띄었는데, 도커 데몬이 죽으면 모든 컨테이너가 같이 다운됩니다. 좀 치명적인 단점이긴 한데, 근데 이건 도커를 CI/CD 빌드용으로 고민할 땐 그리 문제 되진 않아요.

빌드할 때 도커가 내려가져 있으면, 올리고 빌드하면 되는거고, ci/cd 서버에 컨테이너를 띄어 놓을 일은 없기 때문에 도커가 갑자기 죽는 상황에 대한 문제는 없습니다. 그래서 저는 그래도 도커를 아직 까진 선호하는 입장이지만, 자원 활용에 중시 한다면, 혹은 상황에 따라 다른 솔루션 들을 쓰게 될 수도 있는 거고요.

그럼 이 상태에서, 컨테이너 빌드로 빌다라는게 있습니다. 근데 이걸 쓸 경우, 함께 써야하는 친구들이 있어요. 각각에 역할을 보면, 먼저 podman을 이용해서 도커 로그인을 하고, 이미지를 가져오는 기능이 있어서 openjdk 같은 베이스이미지를 가져 옵니다. 

그리고 buildah로 컨테이너 빌드하고, 이미지가 만들어지면, skepo가 이미지 푸시 기능이 있어서, 도커 허브로 이미지를 업로드 해요. 그리고 앞에서 처럼 argoCD를 통해서 쿠버네티스 배포가 되는 구성 되고요.

좀 복잡해 보이긴 하지만,  도커보다 자원 사용률은 낮고요.  또 이 자원 사용률을 무시할 순 없는 게, 젠킨스에서 소스빌드랑 컨테이너 빌드가 갑자기 많아 졌을 때 가끔씩 도커빌드를 하다가 메모리가 부족하다는 에러를 낼 때도 있거든요. 그리고 buildah는 백그라운드 실행이 필요 없는, Daemon-less App 입니다.

그래서 이젠 컨테이너 빌드에 대한 선택의 폭이 생겼고, 추가적으로 하나 더 말씀드리면, 쿠버네티스 위에서만 돌아가는 제품도 있어요. Kaniko라고 해서 컨테이너 환경에서 돌아가도록 만들어 졌는데, 이건 다행이 하나만 있으면 되니까 도커 대체로 시도해 볼 만 하겠죠?

이 후 내용은 해당 강의에서 추가적으로 다루는 내용들입니다.

배포 전략을 세울 때 고려해야 하는 요소

단계별로 구축해보는 배포 파이프라인

ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)