개발 배포의 패러다임변화

www.docker.com

뒤늦게 도커에 대해서 알게 되었고 이번에 교육을 통해서 정확하게 알게 되었다.

웹서버나 톰캣 서버 등을 셋팅하는 것에 편리한 점을 준다는 것은 예전에 몇가지 실습을 통해서 알고 있었지만 이번에 교육을 통해서 확실하게 알게 되었다. 어찌보면 참 늦게 알게 된 것이 너무나 후회되는 기술이다. 도커에 대한 설명은 정말 많은 곳에서 다루고 있기 때문에 도커를 이야기하기보다. 도커와 쿠버네티스를 배우고 알게 됨으로서 배포의 패러다임이 변화되었다는 것을 간단한 기록으로 남기고자 한다.

처음에 도커를 어렴풋이 이해했을때는 내가 설정해야되는 어떤 서버의 셋팅을 편하게 할 수 있는 유용한 도구쯤으로 이해를 하였다. 하지만 이번 교육을 받고 나니 개발해서 배포하는 패러다임이 변했다는 것을 알게 되었다. 도커의 기능적인 수준을 이해했을때는 편한 정도였다. 하지만 쿠버네티스를 배우고 나니 아 도커가 그냥 손쉬운 서비스를 배포하기 위한 단위로 사용되는 것이 아니라는 것을 절감하게 되었다.

도커는 서비스를 제공하는 제품을 컨테이너로 격리하고 손쉽게 배포하고 실행할 수 있도록 한 것이다. 그래서 도커를 이해하는 시점에도 지속적으로 그럼 우리 제품을 연겨하기 위해서 도커를 실행하고 나의 배포소스를 어디에 위치를 시키켜야될까? 가 주관심하였다. 그래서 항상 도커의 볼륨이 궁금하였다. 하지만 교육을 다 받고 난 후 생각이 180도 달라졌다.

기존에 우리가 어떤 하나의 웹프로그램을 개발하고 운영하는데 있어서 배포의 과정은 이러했다.

1. 소스서버로부터 최신소스 (혹은 특정소스)를 불러온 뒤 빌드를 한다.
2. WAS 서버에 컴파일된 WAR 파일을 옮긴다.
3. WAS 서버를 정지시킨다.
4. 컴파일된 WAR파일을 배포하는 위치에 옮겨둔다. 혹은 풀어둘수도 있을 것이다.
5. WAS 서버를 재가동시킨다. (2~3과정을 WAS의 수만큼 반복한다)

이런 과정을 거켜서 배포가 이루어졌다. 물론 이런과정에 무중단을 위해서 L4 스위치를 앞에두고 WAS서버를 여러대를 운영하면서 매 서버마다 상기 과정을 수행하였다.

하지만 도커를 이용하게 되면 이런 바뀐다.

1. 소스서버로부터 최신소스 (혹은 특정소스)를 불러온 뒤 빌드를 한다.
2. 도커파일을 이용하여 최신소스가 컴파일되어 탑재된 도커이미지를 만든다.
3. 도커이미지를 private repository나 hub.docker.com 유료서비스로 갱신한다.
4. WAS가 작동하고 있는 서버에서 WAS컨테이너를 중단시키고 새버전으로 다시 실행시킨다. (이과정을 컨테이너수만큼 반복한다.)

만약 이과정중에는 WAS 서버를 여러개를 작동시켜놓았을 수 있었을 것이다. 그러면 차례대로 작동중인 WAS 컨테이너를 중단하고 최신버전으로 실행하는 과정을 반복하면된다.

여기서 쿠버네티스로 도커서버를 관리하게 되면 배포의 과정에서 무중단을 위해서 하나씩 스톱시키고 다시 최신버전으로가동하던 행위가 쿠버네티스의 설정(기본설정으로도 Rolling 기능이 작동함. rolling기능 : 업데이트를 위해서 pod를 한번에 스톱시키고 가동하는 것이 아니라. 설정에 따라서 순차적으로 자동으로 실행시키고 가동시키는 방법)으로 가능하게 된다.

쿠버네티스를 이용하게 되면 배포방법은 이렇게 바뀐다.

1. 소스서버로부터 최신소스 (혹은 특정소스)를 불러온 뒤 빌드를 한다.
2. 도커파일을 이용하여 최신소스가 탑재된 도커이미지를 만든다.
3. 도커이미지를 private나 hub.docker.com 유료서비스로 갱신한다.
4. 쿠버네티스 마스터에서 최신버전의 컨테이너를 실행하도록 갱신명령을 준다. (롤링업데이트로 자동갱신이 된다)

개발 및 운영에 대한 패러다임의 대전환이다. 최종적으로 만들어진 서비스를 컨테이너에 탑재함으로서 배포의 기본단위가 빌드한 실행파일의 집단이 아니라 컨테이너 이미지로 바뀌었다. 이렇게 되면 더욱더 시스템의 의존적인 환경을 벗어나게 되는 것이다.

어떤 이들은 굳이 클라우드를 이용하면 클라우드에서 쿠버테니스를 이용하는 것을 보면서 무리한 시도라고 하기도 하지만 쿠버네티스의 자동화를 공부해보니 무리하다고 생각이 되지 않는다. 도커만으로 활용하기보다 쿠버네티스 베이스로 환경을 꾸미는 것이 더 많은 장점을 가져다 준다고 현재까지는 보여진다. 그래서 대부분의 클라우드가 쿠버네티스를 지원하고 있는 것 아니겠는가 싶다.

하지만 이렇게 환경이 바뀌려면 회사의 개발패러다임도 바뀌어야 한다. 배포 과정이 컴파일된 파일이 아니라 도커이미지로 만들어져야 하는 것이다. 회사에 차례대로 적용을 해보려니 여러가지 많은 생각이 같이 동반되기도 하다. 여러팀의 개발과 배포방식도 바뀌어야 하고 지금 셋팅되어있는 서버의 인프라환경도 바뀌어야 한다.

새로운 고민이긴 하지만 너무 늦게 알았다는 것이 너무나 아쉽다. 앞으로도 조금 더 적극적으로 인프라지식에 대해서 관심을 가져야 할 것 같다.