이제까지는 애플리케이션 코드와 실행하는 환경이 포함된 애플리케이션 컨테이너를 사용했다.
도커의 핵심 아이디어고 전형적인 컨테이너이다.
유틸리티 컨테이너는 특정 환경만 포함하는 컨테이너를 의미한다.(Nodejs 나 Php환경 등)
도커는 특정 환경을 전역적으로 설치하는 것과 반대로 격리된 환경에만 설치하는 개념으로 등장했다.
예를 들어 호스트 머신에 node가 없다면 docker run -it node로 nodejs를 도커환경에 설치해 호스트 머신에는 독립적으로 사용할 수 있다.
docker run -it -d node를 실행하면 node가 인터렉티브하게 백그라운드에서 돌면서 입력을 기다리게 된다. 이때 docker exec <실행중인 컨테이너> 를 수행하면 실행중인 컨테이너의 기능을 사용할 수 있다. (마치 dockerfile의 CMD 명령어를 동적으로 사용하는 개념)
예를 들어 npm init이 필요하다고 가정하면 다음과 같이 명령어를 수행하면 된다.
docker run -it -d --name node-app node
docker exec -it node-app npm init
하지만 슬프게도 package.json 은 컨테이너 내부의 디렉토리에 저장이 된다.
-it는 연결을 유지하는 옵션이라고 생각하면 쉽다.
docker run -it node 를 수행하면 node의 디폴트 명령이 수행된다.(node의 디폴트 명령은 node 실행 파일 그차제이다.)
docker run -it node npm init을 수행하면 디폴트 명령을 오버라이드 한다.
docker exec 는 실행중인 컨테이너 내부에 작성된 로그 파일을 읽는데 유용하다.
package.json 만들기
FROM node:14-alpine
WORKDIR /app도커파일에서 CMD를 넣지 않는 이유는 사용자에게 node의 모든 권한을 부여하기 위함이다.
docker run -it -v "<마운트바인딩 디렉토리>:/app" node-util npm init
그 후 마운트바인딩을 이용해 컨테이너 내부 디렉토리와 미러링한 디렉토리를 연결하고 npm init을 수행한다.
EntryPoint
node-util 은 npm 명령을 실행할 수 있는 유틸리티 이미지가 되었다.
도커파일에 CMD ["node","--version"] 인 test 이미지가 있다고 가정하고 docker run test을 하면 노드의 버전이 출력될 것이다.
이때 docker run -it test node 를 수행한다면 CMD가 무시되고 node라는 명령어가 수행된다.
EntryPoint는 CMD와 다르다. 엔트리포인트는 뒤에 붙은 명령앞에 붙어 수행된다.
// mynpm
FROM node:14-alpine
WORKDIR /app
ENTRYPOINT [ "npm" ]docker run -it --rm -v "<바인드마운트>:/app" mynpm init
이렇게 package.json 이 생기면 install 또한 마찬가지로 진행한다.
(컨테이너가 수행되면서 바운트마운트된 로컬폴터에서 package.json을 가져간다.)
docker run -it --rm -v "<바인드마운트>:/app" mynpm install express --save
긴 코드를 줄이기 위해 도커 컴포즈를 사용하자
version: '3.8'
services:
npm:
build: ./
service-container_name: mynpm
volumes:
- "./:/app"
stdin_open: true
tty: true docker-compose up을 해야될 것 같지만 이 명령어는 yaml파일에서 정의된서비스를 불러오기 위한 것이다. 애플리케이션 컨테이너는 시작된 후 계속 실행된다.
docker-compose exec 는 이미 도커 컴포즈에 의해 이미 실행 중인 컨테이너에서 명령을 실행하기 위해 사용한다.
docker-compose run 은 여러 서비스중 단일로 지정해 명령을 전달한다.
docker-compose run --rm npm init
run 에는 up, down이 없으므로 --rm 을 붙여 실행이 끝난 컨테이너는 자동삭제되도록 해야한다.
(down이 --rm 기능을 한다.)
