도커 탄생 이전
1. 개발자가 installation & configuration 설명서를 제작하여 OPS팀에 전달
2. OPS팀은 설명서를 참고하여 서버에 애플리케이션과 dependency를 설치하고 배포
➔ 만약 그 과정에서 다른 버전을 사용하는 기존 dependency들과 충돌이 생긴다면?
➔ 텍스트로 된 설명서를 이해하는 과정에서 의사소통에 오류가 생긴다면?
도커 탄생 이후
OPS팀은 Docker artifact를 가져오고 run하기 위한 명령어만 실행
➔ 서버에서 앱과 dependency를 하나하나 설치하고 구성하는 번거로운 과정을 생략하는 효과
OS는 OS Application Layer와 OS Kernel로 구성
이미지
▪ 애플리케이션의 스냅샷
▪ 특정 프로세스를 실행하기위해 필요한 모든 설정값들을 포함
▪ 한번 만들어지면 불변의 성질
컨테이너
▪ 이미지를 도커 엔진에서 실행한 상태
▪ 애플리케이션의 종속성과 함께 애플리케이션 자체를 패키징, 캡슐화 하여 격리된 공간에서 프로세스를 동작시키는 기술
Dockerfile
▪ 컨테이너를 만드는 레시피
▪ Dockerfile을 빌드하면 이미지를 생성
▪ 정의하는 내용
▪ Copy files
▪ Install dependencies
▪ Set environment variables
▪ Run setup script (구동 방법)


▪ FROM : 도커 이미지 생성의 기초가 되는 이미지를 지정
▪ ARG : 변수 선언
▪ COPY : 이미지를 생성하는 과정에서 해당 이미지 안에 특정 파일을 미리 넣어두는 역할
▪ ENTRYPOINT: 컨테이너가 생성되고 최초로 실행할 때 항상 수행되는 명령어를 지정
키워드
▪ FROM : 도커 이미지 생성의 기초가 되는 이미지를 지정
▪ RUN : 이미지를 생성하는 과정에서 실행되는 것
▪ CMD : 이미지로부터 컨테이너가 만들어져 가동될 때 기본적으로 실행되는 명령어
▪ COPY : RUN처럼 이미지를 생성하는 과정에서 해당 이미지 안에 특정 파일을 미리 넣어두는 것
▪ VOLUME : CMD처럼 컨테이너가 생성되어 실행될 때 컨테이너와 호스트 간의 연결이 가능한 볼륨을 지정
▪ EXPOSE : 컨테이너와 호스트 간 연결이 가능한 포트를 지정
그밖에도 다양한 명령어를 이용해 Dockerfile을 작성할 수 있음
docker build
▪ 이미지 생성
docker push
▪ docker hub에 이미지 업로드
docker pull
▪ docker hub로부터 이미지 다운로드
docker run
▪ 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구
▪ YAML 파일을 이용하여 애플리케이션의 서비스를 구성
▪ docker run 명령어를 여러 개 모아 놓은 것과 같으며
컨테이너와 주변 환경(네트워크, 볼륨 등)을 한번에 생성 가능
▪ 도커 : “애플리케이션 패키징 툴” , “가상화 툴”
▪ 이미지는 애플리케이션의 스냅샷
▪ 컨테이너는 이미지를 이용하여 격리된 공간에서 애플리케이션을 동작시킨 것
▪ Dockerfile로 컨터이너 생성 방법을 정의, 빌드하면 이미지 생성
➡️ 결론 : 잘만 쓰면 배포가 편해진다