도커 - 배경

---

배경

개발을 하다보면 다양한 환경이 있고, 이에 맞춰 여러 라이브러리들을 설치합니다.
하지만 로컬에서 잘 돌아가던 프로그램도 배포 환경이 개발 환경과 다르면 예상치 못한 동작을 할수도, 배포가 실패하기도 합니다.

only my machine

---

VM

가상머신을 이용하면 라이브러리가 설치된 상태를 추출할 수 있고, 이를 이미지라고 합니다. 이걸 배포하면 됩니다!
환경이 완전히 일치하니 별로 해줄것도 없고요. 다만

1. 이미지 파일의 용량이 너무 큽니다.
   즉, 공유하기도 어렵습니다
   예를 들어, 우분투에 파이썬을 설치하고, pillow 라이브러리를 설치하고 싶습니다.
   하지만 pillow 까진 아니더라도, 이미 무수히 많은 사람들이 우분투에 파이썬을 설치해뒀을텐데, 이걸 재활용하는게 편하지 않을까요? 하지만 가볍게 공유하기엔 너무 큰 파일이네요
2. 라이브러리 추가/삭제의 히스토리를 깃처럼 관리하기도 어렵습니다.
   우리가 만든 로그인 서버를 다른 사람들도 호스팅 할 수 있게 하고 싶습니다! VM이미지를 공유하면 개발자들은 로그인 기능은 구현할 필요 없이 우리가 만든 로그인 서버만 받아와서 쓰겠죠. 하지만 만약 로그인 서버를 업데이트한다면? 파일명에 따라 다르게 하고 웹서버에 올릴까요? 사용자는 어떤 변경점이 있는지 어떻게 보죠?
3. 성능이 너무 무겁습니다
   가상 머신을 한번이라도 켜 본 사람이라면, 네이티브로 부팅하는것보단 확실히 느립니다.
4. 버전업은요..?
   용량이 큰지 히스토리는 뭐 모르겠고 대기업들이 알아서 최적화해주고, 잘 만들어주겠죠. 저희 서버는 성능이 좋으니 괜찮습니다.
   하지만 이전 버전에서 취약점이 발견되어, 버전을 빠르게 업데이트해야해요! 하지만 이전 vm에 디스크가 그대로 들어 있으니 우리 설정 파일만 옮기고, 네트워크 설정도 옮기고, ... 만약 서버를 여러대로 구성했다면, 이를 위한 스크립트를 작성하거나, 각각 전부 들어가서 옮겨줘야겠죠. 음.. 이거 맞나요? 이런 네트워크, 메모리, 디스크 자원등을 가상화하여 관리하면 좋을텐데..

---

Docker

1. 아키텍쳐만 일치한다면 어느 곳에서나 실행이 가능합니다
2. 가볍습니다.
   가상머신은 이미지에 운영체제, 커널 등이 모두 포함되어있다면, 도커로 만든 이미지에는 커널이 포함되어 있지 않습니다.
   이미지로 만든 컨테이너간 커널을 모두 공유합니다. 실행 자체도 가볍지만, 이미지 파일 크기도 작습니다
3. 보안, 가상화
   이미지에는 네트워크, 디스크같은 인프라 요소들이 포함되지 않습니다. 인프라 요소들은 모두 가상화되어있어 쉽게 붙이고 뺄 수 있습니다
   애플리케이션 내부에서 5000번으로 서버가 돌아간다고 해도, 가상화되어 있기 떄문에 호스트의 80번 포트와 연결해줄 수 있습니다!
   데이터가 저장되는 위치만 가상 디스크를 마운트하면 됩니다.
   또, 이러한 격리 덕분에 보안적으로도 우수합니다.
4. 이미 업계 표준입니다.
   다양한 이미지들이 공유되고 있고, ubuntu-pythonn, nginx 등을 끌어올 수 있습니다.
5. 일관된 환경 제공
   vm과 마찬가지로, 일관된 환경을 제공합니다.
   도커를 이용하여 테스트를 완료하고, 배포 환경에 이미지를 보내면 됩니다.

용어

daemon - 백그라운드에서 동작하는 프로세스
registry - 도커 이미지를 업로드, 다운로드하는 장소를 의미합니다. 도커 허브, aws ecr 등이 있습니다.
docker host - 이미지를 만들거나, 실행하는 도커 데몬과 이미지, 컨테이너들을 포함합니다.
client - api를 사용해 도커 데몬에 명령을 보냅니다.
container - 도커 이미지로 만든 인스턴스입니다. 시작하고 중지될 수 있습니다.