도커 이미지로 동일한 환경을 구성하면

이 환경을 개발/테스트/운영 모두 동일한 환경에서 의존성 문제없이 사용할 수 있다.

동일환경 배포라는 문제를 해결하기 위해 등장한 도구들

• 가상화 도구 : VMware, KVM, VirtualBox, HyperV
• 클라우드 플랫폼 : OpenStack, CloudStack
• 서버설정 자동화 : Puppet, Chef
• 배포도구 : Capistrano, Fabric
• 작업부하 관리 : Mesos, Fleet
• 개발환경 설정 : Vagrant

도커와 함께 쓰이기도 하고 따로 쓰이기도 한다.

도커를 일주일정도 쓰면서 프로젝트에 적용하고나니 이제서야 감을 좀 잡겠다.
도커관련 책이 많이 나와있는데… 이걸 다 외울게 아니라면 한번훑어보고 넘어가는게 좋겠다.
명령어는 인덱스만 잡아놓고 그때그때 찾아서 쓰다보면 외워지는게 제일 나은것같다.

도커 개념을 잡으려면 먼저 써보는게 좋다.

일단 명령어 하나도 몰라도 윈도우/맥에서 쉽게 설치해서 쓸 수 있게 나와있다.
Docker(https://www.docker.com/)
GUI도구 (https://kitematic.com/)

도커의 아키텍처

리눅스의 컨테이너가 발달한 형태로
iptables, virtual bridge, cgroups, namespace.. 등의 커널매커니즘이 얽혀서 돌아간다.
(자세한 것은 리눅스커널을 먼저 이해해야 알 수 있을 것 같다.)

도커는 클라이언트, 서버데몬, 레지스트리로 나뉜다.

서버데몬이 우리가 생각하는 도커 컨테이너를 구동하는 녀석이고
docker 명령어를 친다고 생각하는게 클라이언트
레지스트리는 도커허브의 역할이다.
(자세한 것은 책에 잘 나온다)

도커 도구

도커 도구가 많이 나왔던 것같은데…
초기에 나온것들은 많이 정리가 됐는지 책에 나와있는것들도 바뀐게 좀 있는 것 같다.
최신 방법론은 도커 최신 공식문서를 찾아봐야 하지 않을까

활용법

도커 컨테이너는 쓰고버리는 1회용품으로 생각하면 쉽다.
영구적으로 저장하는 데이터를 여기 저장하면 안되겠지
API서버를 돌린다면 사용자 정보와 디비는 별도로 돌아가도록…
테스트에 한해서 DB를 돌리기도 한다. 저장경로를 컨테이너 외부로 잡으면 디비를 직접 돌려도 상관없지 않을까 싶기도 하지만… 디비를 업그레이드 하면서 파일이 깨질가능성도 생각해보면.. 좋은 생각은 아니다.

사용법

http://tutorial.polypia.net/w/Docker

설치방법

다운받아서 깔아도 되고 apt yum 등.. 자동설치 지원이 잘 된다.

사용후기

적용을 하려면 이해가 좀 필요할 것 같다.
그리고 도커에 맞춰서 아키텍처의 변형도 좀 필요해 보인다.
지금까지 gradle bulid 를 war로 만드는게 목표였다면
docker내에서 사용하는 방법은 좀 다를 수 있다.
docker이미지 내에 maven/gradle빌드환경을 구축 해 놓을수도 있고
docker하에서는 spring boot에서 기본옵션으로 사용하는 embedded was컨셉이 기존 별도 was실행하는 방식보다 더 적합해 보인다.
embedded하는게 spring boot가 꼭 필요하진 않지만…
어쨌든 오래된 자바 컨셉에 적합한 구조는 아니다. 도커에 맞춰서 설계를 새로 잡아야 할 것 같다. 설정파일 관리부터 많은 부분이 바뀌어야한다.