도커를 왜 사용할까?
도커라는 기술을 처음 들으면 컨테이너 얘기를 많이 듣곤한다. 격리되어 있는 공간에 시스템을 구축하기 때문에 컨테이너라는 이름을 사용하는 것인데, 오랫동안 사용하면서 그 장점을 느끼기 전까지는 왜 격리를 해야할까? 라는 생각이 머릿속에 맴돈다.
개발자로서 다양한 서비스를 다루거나 다양한 환경에서 테스르를 해보고 싶은 경우에는 이 도커가 굉장히 유용하다. 사실 나도 예전엔 연구 위주로만 개발을 했기 때문에 ‘그냥 필요한 라이브러리 같은 것은 로컬에 설치해서 사용하면되지 왜 도커를 사용할까?’라는 생각을 했기 때문에 자주 사용하지 않았다. 어차피 도커 컨테이너를 만드는 것 자체도 필요한 라이브러리를 설치해야하기 때문이다.
하지만 다양한 서비스를 다루기 시작하면서 도커의 힘을 느끼기 시작했다.
##버전이 중요한 환경을 구축할 때
아마 이 이유 때문에 docker를 많이 사용하지 않나 싶다. 예를들어 내 로컬 환경의 자바 버전은 jdk1.8 인데, 개발한 코드는 jdk1.7 이라면? jdk1.7 을 다운로드 받아서 jdk1.7/bin/java test.java 로 직접 bin파일을 찾아 실행할 것이다. 그런데 이렇게 버전이 안맞아서 매번 버전확인하고 해당 버전의 라이브러리를 설치하고… 이런 짓은 분명 귀찮을 것이다. 게다가 하다보면 내 노트북에 라이브러리의 모든 버전이 설치되어 있을 것이다. Project 1이 있다면 여기에 사용되는 라이브러리들이 버전에 맞게 도커 컨테이너 위에 설치만 해주면 내 로컬 환경에 영향을 받지 않는다.
위와 같이 컨테이너 2개와 로컬 (총 3개의 환경)은 서로 다른 버전의 jdk를 가지고 있다. 위와 같이 jdk 버전에 따라 나눠져 있는 docker 이미지를 받아보자. 도커는 설치되어 있다는 가정하에 진행한다. (도커 홈페이지에 가면 정말 간단하게 설치할 수 있다.)
먼저 jdk1.7이 설치되어 있는 컨테이너 1번을 올려보자.
$ docker search jdk1.7
도커 이미지는 이미 누군가가 레시피대로 만들어 놓은 포장식품이다. 우리는 그걸 까서 먹기만 하면된다. 나중에는 레시피도 작성하고 요리를 하는 방법도 배워보자.
위의 명령어는 도커 이미지를 검색하는 명령어이다. 원하는 이미지가 없다면 내가 이미지를 만들어야겠지만, 많은 이미지들이 이미 만들어져 있는 경우가 많다.
믿음직스럽지 못하다면 openjdk의 docker hub를 방문해서 도커 이미지를 다운로드하자. Docker hub는 전 세계에서 만든 도커 이미지가 올라가는 공간이다. 계정별로 올린 도커 이미지를 확인할 수 있다.
- https://hub.docker.com/_/openjdk?tab=tags
태그 중에서 원하는 버전을 찾아서 도커 이미지를 다운 받으면 된다. 도커 이미지는 pull 명령어로 다운로드 받는다.
$ docker pull openjdk:7-jdk-alpine3.8
이제 로컬에 도커 이미지가 다운로드 된 것이다. 로컬에서 images 명령어로 다운받은 도커 이미지를 확인할 수 있다.
$ docker images
이제 도커 이미지라는 포장식품을 사온 것이다. 이제 밥상 차리듯이 컨테이너를 올려보자.
$ docker run -d -it --name container1 openjdk:7-jdk-alpine3.8
도커를 실행해서 컨테이너를 올릴 때에는 수많은 옵션을 상황에 맞추어서 사용해야하는데, 컨테이너가 백그라운드에서도 계속 실행되어 있게 하려면 -d 옵션을 주어야 한다. 또한 -it 는 컨테이너를 종료하지 않고 터미널에서 입력을 계속 이어나갈 수 있는 옵션이다. --name 은 컨테이너의 이름을 지정해주는 것이다. 마지막에는 포장을 뜯을 도커 이미지를 적어주면 된다. {REPOSITORY:TAG}와 같은 식으로 적어줘야한다.
$ docker ps
이제 위 명령어로 도커 컨테이너가 올라간 것을 확인할 수 있다. 도커 컨테이너 안으로 들어가서 jdk 버전이 1.7로 잘 설치가 되었는지 확인해봐야 하는데, 아래와 같이 들어갈 수 있다.
$ docker exec -it container1 /bin/sh
자바 버전을 확인해보면 아래와 같다.
/usr/local/bin # java -version
java version "1.7.0_181"
OpenJDK Runtime Environment (IcedTea 2.6.14) (Alpine 7.181.2.6.14-r0)
OpenJDK 64-Bit Server VM (build 24.181-b01, mixed mode)
그리고 이번엔 jdk1.8을 탑재한 컨테이너를 띄워볼텐데, 도커 이미지를 받는 부분에서 1.8 버전으로만 변경하고 나머지는 똑같이 진행하면 된다. (컨테이너 이름은 container2로 설정)
$ docker pull openjdk:8-jdk-alpine3.8
컨테이너2까지 올리고 ps 로 확인해보면 아래와 같다.
이제 container2에 들어가서 jdk 버전을 확인해보면 아래와 같다.
/usr/local/bin # java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (IcedTea 3.10.0) (Alpine 8.191.12-r0)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
이상으로 위에 컨테이너 2개의 그림을 직접 구현해본 결과이다. (물론 tomcat, mySQL 등은 설치하지 않았지만…)
이제 자바7로 구현되어 있는 프로젝트는 container1, 자바8로 구현되어 있는 프로젝트는 container2에서 돌려보면 될 것이다. 이렇게 환경을 자유자재로 구축할 수 있고 로컬에는 전혀 영향을 안준다는 점에서 도커는 굉장히 깔끔하다고 볼 수 있다. 마치 포장식품을 간편하게 조리해서 먹고 깔끔하게 쓰레기통에 버리는 느낌이다.
만든 제품을 다른 사람도 편하게 사용한다면
내가 만든 제품을 다른 사람도 편하게 사용한다면
내가 개발한 제품을 다른 사람도 환경에 구애받지 않고 실행시킬 수 있다면 정말 편리하다. 이것저것 설치하라고 설명해주지 않아도 된다. 도커를 아는 사람이라면 도커 이미지 하나 올려두고 명세만 달아놓으면 된다. 그러면 사용하고자 하는 사람은 컨테이너 안에 들어가는 라이브러리, 버전과 같은 모든 환경을 정의한 도커 이미지를 사용해 도커 컨테이너를 띄우고 사용만 하면된다.
도커는 클라우드 시스템에서 굉장히 핫한 기술이고 편리하다고 알려져 있지만 막상 그 장점을 제대로 느끼기에는 나에겐 너무 오버스펙 같은 느낌이 들 때가 있다. 여러가지 서비스를 다루고, 내가 만든 기능을 배포하여 편하게 사용하게 하는 일이 잦다면 도커를 적극 활용해볼 필요가 있다.