쿠버네티스 (1-4-2) | 개발자가 바라보는 도커의 필요성

도커라는 게, 기존의 퍼블릭 클라우드 이미지 기반 인스턴스 관리 기법의 연장선이기도 하다. 
가장 중요한 것은 왜 쓰기 시작했는가! 의 문제라 볼 수 있다. 

시니어 개발자님이 공유해주신, 도커의 사용 이유에 대해 정리해보았다.

 

https://aws.amazon.com/ko/docker/

 

도커는 왜 쓰기 시작했을까?

도커는 커스텀 환경을 빠르게 구축할 수 있다 - 도커 이미지

일단, 이미지의 경우, 결국은 개발 환경과 연관된다.
개발자 입장에서, 서버를 만들어서, 서버에서 개발하기도 한다.
예를 들어 자바 환경이라 하면, 서버나 클라이언트 환경을 꾸미고 나서, 환경 변수 설정 후 개발한다.

그런데 도커를 쓰고 나서는, 환경을 내부적으로 구성해서 독립적으로 환경을 빠르게 만들 수 있다.

우분투의 JVM 1.8을 빠르게 빌드해서 개발하고 싶을 때, 

예전에는 서버를 띄우고 설치하고 환경 구성하고 등등 사전 작업이 길었는데, 

지금은 도커를 쓰면 빠르게 환경을 구축할 수 있다.

로컬이나 서버에 빌드 환경을 맞추려면 비슷한 디펜던시 패키지 구성이 복잡한데,

이미지 패키징으로 빠르게 환경을 갖춰서 사용할 수 있는 측면이 강하다. 

이와 연계된 한가지는,

예전에는 앱이든 서버든, 설치를 할 때 깃랩이나 스피내커나 오픈스택이나 여러 앱들을 하나의 인스톨러를 만들어 자동 설치했다면,

도커를 통해 나만의 다른 빌드 환경을 만들 수 있어서, 이미지만 당겨오면 가상 환경 구축이 간편해진다.
환경에 대한 동일성을 간편하게 이뤄낼 수 있다는 것이다. 개발 자체를 빠르게, 테스트를 빠르게

도커에 대해서 원론적으로 들어가면 네트워크 문제도 있겠지만, 
일반 개발자는, 어떤 서버환경이든 로컬 설치 없이도 빠르게 구축할 수 있다!

 

도커는 빠르게 배포할 수 있다

예전 클라우드의 머신 이미지를 만들고 자동화해서 패커 툴을 통해 코드 형태로 소스를 밀어넣어

나의 이미지로 오토 스케일링 그룹으로 연동해 배포하는 플로우는,

지금의 도커, 쿠버네티스와 매우 비슷하다. 

즉, 기존 가상 머신이 컨테이너 형태로 바뀌는 이유에는 플로우 및 방식보다 근본적인 차이를 주목해야 한다.

가상 머신과 컨테이너의 차이는 이미지 사이즈. 이미지의 크기다.

가상 머신은 OS 정보를 포함해 매우 사이즈가 크다. 
빌드 속도도 차이가 나고, 배포 속도도 차이가 나는데, 컨테이너는 레이어 기반으로 작고 가볍다.
즉, 빌드도 빠르다, 배포도 빠르다. 

가장 큰 차이점은 결국 배포의 속도라는 뜻이다.
배포의 속도가 빠르다는 것은, 또다시 우리에게 하나의 장점을 더 가져다 준다. 
이미지를 빠르게 배포하면, 우리의 패러다임이 바뀐다.

서버 배포를 위해서는 배포 타임과 ha, 페일오버 등 인프라 고민거리가 많았다. 

오토 스케일링 그룹이라 해도 페일 오버, 블루그린 등 배포 전략 사항이 많았는데, 

컨테이너로 빠르게 진행이 가능하니, 스케일링 등이 기존 가상 머신 대비 빨라진다는 것이다.

배포가 빨라져서 얻게된 또 하나의 부차적인 장점으로,

빠르기 때문에, MSA까지 유연하고 빠르게 대처가 가능해졌다.
예전에 클라우드를 가지고 마이크로서비스를 구축하기보다, 

서버 단위가 아닌 앱 단위로 쪼개서 빠르게 배포할 수 있는 것까지 인프라의 패러다임이 바뀐 것이다.