도커 개념들에 대해 배워보자!
작성자 : 정소영
도커의 기초
기본적인 도커 개념들에 대해 상세하게 알아보겠습니다.
먼저 도커의 전반적인 아키텍처와 이를 기반으로 하는 기술들을 살펴볼 것입니다.
다음으로 도커 이미지, 네트워킹 컨테이너, 볼륨에 있는 데이터를 처리하는 방법들에 대해서 자세하게 살펴보겠습니다.
마지막으로 나머지 도커 명령들을 간단하게 살펴보겠습니다.
도커 아키텍처
도커 플랫폼의 내부적인 구성에 대해서 개략적으로 파악해보겠습니다.
-
도커 데몬(Docker daemon) 은 컨테이너를 생성, 실행, 모니터링뿐만 아니라 이미지를 생성,저장하는 역할까지 합니다.
docker daemon 명령을 실행하여 시작되며
해당 명령은 일반적으로 호스트 OS에서 관리됩니다. -
도커 클라이언트(Docker client) 는 HTTP를 통하여 도커 데몬과 통신하는데 사용됩니다.
통신은 기본적으로 유닉스 도메인 소켓을 통하여 이루어지지만, 원격 클라이언트 또는 systemd가 관리하는 소켓의 파일 기술자(file descriptor)를 활성화하여 TCP 소켓을 이용하는 방법도 있습니다.
모든 통신은 HTTP를 통해서 이루어지기 때문에, 원격 도커 데몬에 연결하고 프로그래밍 언어 바인딩을 개발하는 것은 쉽지만 기능 구현 방법에 대한 전제 조건이 필요한 경우도 있습니다.
데몬과의 통신에 사용되는 API는 잘 정리되어 문서화되어 있습니다.
이를 이용하면 개발자는 도커 클라이언트를 이용하지 않으면서 데몬에 직접 연결하는 프로그램을 작성할 수 있습니다.도커 클라이언트와 데몬은 하나의 바이너리로 배포됩니다.
-
도커 레지스트리 는 이미지들을 저장하고 배포합니다.
기본 레지스트리는 도커 허브로, “공식”이미지라고 하는 수천 개의 공용 이미지들을 운영하고 있습니다.
docker pull 요청을 받으면, 도커 데몬은 레지스트리에 있는 이미지들을 다운로드 합니다.
docker run 요청에 명시된 이미지 또는 도커파일의 FROM 설정에 명시된 이미지가 없는 경우에도 자동으로 이미지를 다운로드하게 됩니다.
기반 기술
도커 데몬은 실행 드라이버(execution driver) 를 이용하여 컨테이너를 생성한다.
실행 드라이버는 기본적으로 도커의 독자 runc 드라이버를 사용하지만,
LXC의 레거시를 지원하는 드라이버도 제공된다.
runc 는 다음과 같은 커널 기능들과 밀접한 관계를 가지고 있다.
-
cgroups 는 컨테이너에 의해서 사용되는 리소스(ex CPU, 메모리 사용량)를 관리하는 역할을 담당
docker pause 기능에서 사용되는 것처럼 컨테이너를 일시 중지(freezing) 하고 일시 중지 해제(unfreezing) 하는 역할도 담당 -
namespaces 는 컨테이너를 격리시키는 역할도 수행
컨테이너의 파일 시스템, 호스트 이름, 사용자, 네트워킹, 프로세스 등을 시스템의 나머지 부분과 분리시킴
도커의 기반을 이루는 또 다른 주요 기술에는 유니온 파일 시스템(Union File System, UFS)이라는 것이 있습니다.
UFS는 컨테이너의 계층들을 저장하는 데 사용됩니다.
UFS는 AUF, 디바이스 맵퍼, BTRFS 또는 오버레이와 같은 다양한 저장소 드라이버의 하나로 제공됩니다.
관련 기술
Swarm
도커의 크러스터링 솔루션
여러 개의 도커 호스트를 하나의 그룹으로 묶을 수 있게 해 줌
사용자 입장에서는 하나의 리소스처럼 사용할 수 있음
Compose
여러 개의 도커 컨테이너로 구성된 응용프로그램을 작성하고 실행하기 위한 도구
운영 목적보다는 개발 및 테스트 용도로 사용
Machine
로컬, 원격 리소스에서 운영되는 도커를 설치하고 구성하는 기능
도커 클라이언트도 구성, 간단하게 구성 환경 간에 전환이 가능
Kitematic
도커 컨테이너를 실행하고 관리할 수 있는 GUI (맥 OS용, 윈도우용 제공)
Docker Trusted Registry
도커 이미지들을 저장, 관리하기 위한 도커의 온-프레미스 솔루션
도커 허브의 로컬 버전이라고 할 수 있음
기존 보안 인프라와 통합될 수 있고 기업이 데이터 저장소 및 보안과 관련된 법규를 지킬 수 있도록 해 줌
메트릭, 역할 기반 접근 제어, 로그와 같은 기능 제공, 모든 작업은 관리 콘솔을 통해서 이루어짐
현재 도커사의 제품 중에서 유일하게 오픈소스화되지 않았음
네트워킹
호스트의 경계를 넘어서는 컨테이너의 네트워크를 만드는 작업은 매우 중요한 문제로 다양한 방법으로 해결 가능
도커 운영
아마존, 구글, 디지털오션과 같은 기존 클라우드 서비스 제공자들은 어느 정도의 도커 서비스를 제공하고 있습니다.
클라우드 서비스 제공자가 어떠한 도커 서비스도 제공하지 않는 경우에는 일반적으로 도커 컨테이너를 실행할 수 있는 VM을 프로비전하는 방식을 사용할 수 있습니다.
이미지가 만들어지는 과정
새로운 이미지를 작성하는 가장 효율적인 방법 : 도커파일과 docker build 명령을 이용
이 과정에서 어떤 일들이 벌어지는지, 도커파일을 이용하면서 사용할 수 있는 다양한 설정들에 대해 알아볼 것입니다.
(생각했던 것과 다르게 동작할 수 있기 때문에 이미지 작성과 관련된 명령의 내부적인 동작 방법을 이해해 두는 것이 좋음)
빌드 컨텍스트
docker build 명령을 실행하려면 도커파일과 빌드 컨텍스트(build context) 가 있어야 합니다.
도커 파일 안에 명시된 ADD나 COPY 같은 설정에서 참조할 수 있는 일련의 로컬 파일들과 디렉터리들을 말합니다.
주로 디렉터리에 대한 경로 형태로 명시됩니다.
-
docker build -t test/cowsay - dockerfile .
‘.’은 컨텍스트를 현재 작업 중인 디렉터리로 설정하겠다는 의미
해당 경로에 있는 모든 파일들과 디렉터리들은 build 컨텍스트를 만들고, build 과정의 일부로 도커 데몬에게 전달됨
컨텍스트가 명시되지 않고, 도커파일에 대한 URL만 주어지거나 도커파일의 내용이 STDIN– 으로 부터 연결되었다면, 빌드 컨텍스트는 빈 것으로 간주 -
http or https로 시작하는 URL이 주어지면, 도커파일에 대한 직접적인 연결로 간주
(도커파일과 관련된 컨텍스트가 없ㅅ고 아카이브에 대한 연결이 허용되지 않기 때문에 유용한 방식은 아님) -
빌드 컨텍스트에 git 저장소도 사용할 수 있음
도커 클라이언트는 저장소와 모든 하위 모듈들을 임시 디렉터리로 복제하여, 빌드 컨텍스트로 도커 데몬에게 전달
github.com/,_git@,_git:// 으로 시작하면, git 저장소를 컨텍스트로 간주
(이 방법보다는 직접 저장소를 확인하는 것을 권장 - 변경하기 쉽고 혼선의 가능성을 최소화) -
빌드 컨텍스트 대신 - 인자로 주어진 STDIN의 입력값도 받을 수 있음
입력값은 컨텍스트가 없는 도커파일(ex docker build - < Dockerfile)이나
컨텍스트를 구성하고 도커파일을 포함하는(ex docker build - < context.tar.gz) 아카이브 파일이 될 수 있음 (아카이브 파일 형식은 tar.gx, xz, bzip2) -
컨텍스트 안에 있는 도커 파일의 경로는 -f 인자로 명시
(ex docker build -f dockerfiles/Dockerfile.debug .)
. 명시하지 않으면 컨텍스트의 루트에서 Dockerfile이라는 파일을 찾게 됨
이미지 계층
도커파일에 있는 각 설정들은 컨테이너를 시작하는데 사용될 수 있는 새로운 이미지 계층(Layout) 을 만든다.
새로운 계층은 이전 계층의 이미지를 이용하는 컨테이너를 시작함으로써 생성된다.
도커파일 설정이 정상적으로 완료가 되고 –rm=false 인자가 명시되지 않으면, 중간 컨테이너는 삭제된다.
각 설정은 정적 이미지를 만들기 때문에, 설정 안에 있는 모든 실행 중인 프로세스들은 중지된다.
(RUN 설정에 있는 데이터베이스, SSH 데몬과 같이 오랫동안 실행되는 프로세스들을 시작할 수는 있음
But, 다음 설정이 처리되거나 컨테이너가 시작되면 해당 프로세스들은 실행되지 않음)
컨테이너에서 서비스, 프로세스를 시작하려면 ENTRYPOINT or CMD 설정에서 실행해야한다.
docker history - 이미지를 구성하고 있는 전체 계층들을 볼 수 있음
- 빌드가 실패하게 되는 경우에는 실패하기 이전 계층을 실행하자
1 설정을 적용하기 위해서 도커가 시작안 임시 컨테이너의 ID
2 컨테이너에서 생성된 이미지의 ID
3 해당 시점에서 임시 컨테이너가 삭제됨
이런 경우 오류에서 문제의 원인을 확인할 수 있기 때문에,
마지막으로 성공한 계층에서 생성된 이미지를 실행하여 설정을 디버그할 수 있음
주의!
마지막 컨테이너의 ID(e4b31d0550cd)가 아니라, 마지막 이미지의 ID(85b49a851fcc) 이용
예시
busybox 이미지에 bash 쉘이 포함되어 있지 않기 때문에 오류 발생
캐싱
이미지 생성 속도를 높이기 위해서 모든 계층을 캐시에 저장
캐싱 방법은 호율적인 작업을 위해서 매우 중요
- 캐시가 사용되는 경우
캐시 이전 설정이 존재하고,
캐시에 있는 계층이 정확하게 같은 설정과 상위 계층을 가지고 있는 경우
COPY와 ADD 설정의 경우 체크섬 또는 메타데이터가 변경된 파일이 있으면 캐시는 무효화됨
RUN 설정이 여러번 호출되더라도 같은 결과를 반환한다는 보장이 없어도 캐시에는 저장된다는 것을 의미한다.
(파일들을 다운로드, apt-get update 실행 또는 소스 저장소를 복제하는 등의 작업을 하는 경우)
- 캐시를 무효화하는 방법
–no-cache 인자 이용
캐시를 무효화하려는 지점 바로 전에 설정을 추가하거나 변경하기
이러한 이유때문에 다음과 같은 줄이 추가됨
(나중에 이미지를사용할때 혼란스러울 수 있음,
추가된 줄에서 기술된 날짜와 다른 날짜에 생성된 이미지의 경우 더 헷갈릴 수 있으니 주의)
기본 이미지
나만의 이미지를 작성하는 경우 기본 이미지 결정하는 것부터 시작한다.
선택할 수 있는 기본이미지는 다양하고, 각 이미지가 가지고 있는 장단점을 파악하는 것이 좋다.
- 이미지를 직접 작성할 필요 없는 경우
(데이터베이스, 웹 서버 등과 같이 공식 이미지가 제공되는 일반적인 응용프로그램인 경우) 기존에 만들어져 있는 이미지를 이용하여 구성 파일, 데이터를 이미지에 올려서 사용하기만 하면되기 때문에 가장 좋음
나만의 이미지를 만드는 것보다는 공식 이미지를 이용하는 것을 추천
다른 사람들이 작업한 것과 컨테이너 안에서 응용프로그램이 동자가는 데 가장 적합한 방법을 찾아낸 경험 등을 그대로 적용할 수 있음
배포의 성능과 용이성이 목적이라면 이미지를 작게 만드는 것이 가장 중요
디버깅과 유지 관리 측면에서
busybox 에 작업할 수 있는 도구들이 충분하지 않고, scratch를 사용할 때 쉘 조자도 사용할 수 없다는 점을 주의해야 한다.
바이너리만 가지고 있는 이미지들을 만들고 배포하는 것도 가능
scratch 이미지(완전히 비어있는 파일 시스템)라는 특별한 이미지로부터 상속받도록 도커파일을 작성하고, 직접 작성한 바이너리를 이미지에 복사하고 적당한 CMD 설정 적용
직접 작성한 바이너리를 위해 관련된 라이브러리들(동적 연결, 외부 호출 불가)도 포함시켜야 함
바이너리는 컨테이너의 아키텍처(도커 클라이언트가 실행되는 머신 아키텍처 아님)에 맞춰서 컴파일되어야함
도커파일 설정
여전히 내용이 변경되고 있기 때문에 도커 웹사이트(http://docs.docker.com/reference/builder/)에서 확인하는 것을 추천
ADD
빌드 컨텍스트나 원격 URL에서 이미지로 파일 복사
COPY를 이용하여 빌드 컨텍스트에 있는 파일들과 디렉터리들을 복사하고
RUN 설정을 curl(또는 wget)과 같이 이용하여 원격 자원을 다운로드하는 방법을 선호
CMD
컨테이너가 시작되는 시점에서 실행
docker run 이미지 이름 다음에 오는 인자에 의해 재정의 됨
마지막 CMD 설정만 유효(기본 이미지에 있는 설정도 유효) 이전의 모든 CMD 설정들은 모두 재정의
COPY
빌드 컨텍스트에서 이미지로 파일들을 복사할 때 사용
COPY src dest_
COPY [“src”,”dest”]
두 형식 모두 빌드 컨텍스트의 src에 있는 파일이나 디렉터리를 컨테이너 내부의 dest로 복사
(경로에 공백이 있는경우 JSON 배열 형식으로 작성)
빌드 컨텍스트 외부의 src경로 사용할 수는 없음
ENTRYPOINT
컨테이너가 시작될 때 실행되어야하는 실행 파일(과 기본 인자들)을 설정
주어진 모든 인자들을 해석하기 전에 변수와 서비스들을 초기화하는 ‘시작’스크립트를 제공하기위해 사용되기도 함
RUN 주어진 설정을 컨테이너 내부에서 실행하고 결과 반영
컨테이너를 외부와 연결하기
-p 또는 -P 명령으로 포트 게시 컨테이너 안에 웹 서버를 실항하고 있을 때, 외부에서 해당 웹 서버로 접근할 수 있음
-p 명령은 할당된 포트들을 계속해서 파악하고 있어야 할 필요가 없다는 장점
여러 개의 컨테이너들이 포트를 게시하고 있을 경우,
docker port를 이용하면 도커가 할당한 포트들을 확인할 수 있음
-p 8000:80은 호스트의 8000번 포트를 컨테이너의 80포트로 전달하도록 도커에게 알려줌
-P 이용하면 호스트로 전달할 여분의 포트를 도커가 자동으로 선택할 수 있음
컨테이너 연결하기
도커 링크(links) 는 같은 호스트에 있는 컨테이너들끼리 통신할 수 있는 가장 간단한 방법이다.
도커의 기본 네트워킹 모델을 이용하는 경우 컨테이너 간의 통신은 내부 도커 네트워크를 통해서 이루어진다.
(통신은 호스트의 네트워크로는 노출되지 않음)
- 링크 초기화 방법
docker run –link CONTAINER:ALIAS
CONTAINER에는 링크 컨테이너(link container)의 이름을,
ALIAS에는 마스터 컨테이너(master container) 내부에서 링크 컨테이너를 참조할 때 사용하는 로컬 이름
alias와 링크 컨테이너의 ID를 마스터 컨테이너의 /etc/hosts에도 추가하여,
마스터 컨테이너에서 이름으로 링크 컨테이너를 찾을 수 있음
링크의 구성 여부와 상관 없이 컨테이너들은 서로 통신이 가능하다.
링크 되지 않은 컨테이너는 통신할 수 없도록 하려면,
도커 데몬 시작할 때 –icc=false 와 –iptables 인자를 사용
- 도커링크의 단점
정적이다.
(컨테이너가 재시작되더라도 그대로 유지되어야 하지만, 링크 컨테이너가 대체되면 갱신이 되지 않음)
양방향 링크는 불가능하다.
(마스터 컨테이너가 시작되기 전에 링크 컨테이너가 시작되어 있어야 함)
볼륨과 데이터 컨테이너를 이용한 데이터 관리하기
도커 볼륨은 컨테이너에 바인드 마운팅된(bind mounted) 호스트의 일반 디렉터리를 말한다.
볼륨 초기화 방법 3가지
-
-v 플래그를 이용하여 볼륨을 선언하는 방법
컨테이너 내부의 /data 디렉터리가 볼륨으로 만들어짐
/data 디렉터리 내부에 가지고 있는 모든 파일은 볼륨으로 복사
호스트에서 새로운 쉘을 열고 docker inspect 명령을 실행하면 위치 확인 가능 -
도커파일에서 VOLUME 설정을 아용한다.
docker run을 -v /data 와 함께 실행하는 것과 정확하게 동일한 효과 -
docker run -v HOST_DIR:CONTAINER_DIR 호스트에서 바이드하려는 디렉터리를 명시적으로 지정한다.
(이동이 불가능하고 보안적인 위험때문에 도커파일로는 불가능)
호스트에 있는 /home/adrian/data 디렉터리를 컨테이너 안에 /data라는 이름으로 마운트시키게 됨
/home/adrian/data 디렉터리에 있는 파일들은 컨테이너 내부에서도 그대로 사용 가능
이미지에 있는파일들은 볼륨으로 복사 안됨, 도커로 볼륨을 삭제할 수 없음
데이터 공유하기
-v HOST_DIR:CONTAINER_DIR
컨테이너들 간에 파일을 공유하는데 사용
구성 파일은 호스트에 있고 일반 이미지로부터 만들어진 컨테이너 마운트 되도록 할 수 있음
docker run 실행하면서 –volumes-from CONTAINER 인자 사용하면 컨테이너 간에 데이터 공유 가능
데이터 컨테이너
컨테이너들 간에 데이터를 공유하기 위한 용도로만 사용되는 컨테이너이다.
–volumes-from 을 이용하여 간단하게 볼륨을 장착하는 장점
볼륨 삭제하기
docker rm -v 를 이용하여 컨테이너가 삭제되는 경우
또는 docker run에 –rm 플래그가 같이 사용되고 볼륨에 연결된 컨테이너가 없는 경우,
볼륨에 명시된 호스트 디렉터리가 없는 경우(-v HOST_DIR:CONTAINER_DIR 구문 사용X)
일반적인 도커 명령어
run 명령어
새로운 컨테이너를 시작할 때 사용되는 가장 일반적인 명령어
가장 복잡하면서 많은 인자 지원
대표적인 인자 지원 기능에는
이미지 실행 방법, 도커파일 설정, 네트워크 설정, 컨테이너의 권한과 리소스 설정 등이 있음
컨테이너의 라이프사이클과 기본 운영 모드 제어
-a, –attach
주어진 스트림을 터미널에 연결
옵션이 지정되지 않으면 stdout과 stderr이 연결됨
옵션 지정 X, 컨테이너가 대화형 모드(-i)로 시작되었다면 stdin도 연결
-d 와 같이 사용 X
-d, –detach
컨테이너를 분리모드(데몬 모드)로 실행
컨테이너를 백그라운드로 실행시키고 컨테이너 ID를 반환
-i, –interactive
Stdin을 열어둔 상태로 유지
대화형 컨테이너를 시작하기 위해서 -t와 같이 사용
–restart
도커가 종료된 컨테이너가 어떤 경우에 재시작할지 구성
no : 컨테이너를 재시작하지 않음
always : 종료 상태와 상관없이 항상 재시작 시도
on-failure : 컨테이너가 0이 아닌 상태로 종료된 경우에만 컨테이너의 재시작 시도
ex) docker run –restart onfailure:10 postgres
postgres컨테이너를 시작하고, 0이 아닌 코드로 종료된 경우에는 재시작을 10번 시도한다는 의미
–rm
컨테이ㅓ가 종료되면 자동으로 컨테이너 삭제
-d 와 같이 사용 X
-t, –tty
가상-TTY를 할당
대화형 컨테이너를 시작하기 위해서 -i와 같이 사용
[컨테이너 이름과 변수들을 설정하는데 사용]
-e, –env
컨테이너 내부의 환경 변수 설정
–env-file 옵션 이용 시 파일로 환경 변수 전달 가능
-h, –hostname
컨테이너의 유닉스 호스트 이름을 NAME으로 설정
–name NAME
NAME이라는 이름을 컨테이너에 할당
여기서 할당된 이름은 다른 도커 명령어에서 해당 컨테이너를 찾을 때 사용됨
[볼륨을 구성할 때 사용]
-v, –volume
볼륨은 두가지 인자 방식 사용
- 컨테이너 안의 디렉터리만 명시
(디렉터리는 도커가 정한 호스트 디렉터리로 바인드 됨) - 바인드할 호스트 디렉터리 지정
-volumes-from
지정된 컨테이너의 볼륨 마운트
주로 데이터 컨테이너와 같이 사용
[네트워킹 설정할 때 사용]
–expose
도커파일의 EXPOSE 설정과 동일
컨테이너에서 사용되는 포트 범위 지정, 포트를 열지는 않음
일반적으로 컨테이너를 연결하면서 -P와 함께 사용됨
–link
지정된 컨테이너에 사설 네트워크 인터페이스 구성
-p, –publish
호스트에서 컨테이너로 접근할 수 있도록 컨테이너에 포트를 게시
호스트 포트 정의 X, 포트 번호 무작위로 설정
docker port로 포트 번호 확인
-P, –publish-all
컨테이너에서 노출된 모든 포트들을 호스트로 노출(포트는 무작위로 선택됨)
컨테이너 관리하기
docker run 이외에도 컨테이너를 관리할 수 있는 다양한 docker 명령어들이 제공됨
docker attach [OPTIONS] CONATINER
attach는 사용자로 하여금 컨테이너 내의 메인 프로세스를 보거나 같이 상호 동작할 수 있도록 해줌
docker create
이미지를 이용하여 컨테이너를 생성하지만 컨테이너를 시작하지 않음
docker run에서 사용되는 대부분의 인자를 그대로 사용 가능
docker start로 생성된 컨테이너 시작함
docker cp
컨테이너와 호스트 간에 파일과 디렉터리들 복사
docker exec 컨테이너 내부에 있는 명령 실행
docker kill
컨테이너의 메인 프로세스(PID 1)로 신호 보냄
SIGKILL는 컨테이너를 즉시 종료시킴
docker pause
지정된 컨테이너 내부에 있는 모든 프로세스들 일시중지
일시중지된 프로세스들은 어떠한 신호도 받을 수 없음, 종료 또는 정리도 안됨
docker unpause 실행시 프로세스 다시 시작
docker restart
하나 또는 여러개의 컨테이너들을 다시 시작
컨테이너에 대해 docker stop, docker start를 차례대로 호출하는것과 거의 동일
-t 이용하면, SIGTERM으로 강제 종료하기 전에 컨테이너가 종료되기까지 기다리는 시간 지정 가능
docker rm
하나 또는 여러개의 컨테이너 삭제
기본적으로 어떠한 볼륨도 삭제하지 않음
-f 사용하여 실행 중인 컨테이너 삭제
-v 사용하여 컨테이너가 생성한 볼륨들을 삭제
docker start
중지(stop)된 컨테이너를 시작
종료된 컨테이너를 다시 시작하거나 docker create로 생성되었지만 한번도 실행된 적이 없는 컨테이너를 시작하는데 사용
docker stop
컨테이너를 중지(삭제 X)
컨테이너에 대해서 docker stop이 호ㅜㄹ되면 컨테이너는 종료(exited)상태가 됨
docker unpause docker pause로 일시 중지된 컨테이너를 다시 시작
도커 정보
docker info : 도커 시스템과 호스트의 다양한 정보 출력
docker help : 주어진 명령어의 사용방법과 도움말 정보 출력
docker version : 컴파일에 사용된 Go 버전과 함께 클라이언트와 서버의 버전 정보 출력
컨테이너 정보
실행 중이거나 중지된 컨테이너들에 대한 상세 정보를 제공한다.
docker diff : 이미지로부터 컨테이너가 만들어진 이후에 컨테이너의 파일시스템에 적용된 변경사항을 보여줌
docker events : 데몬의 실시간 이벤트 출력
docker inspect : 주어진 컨테이너, 이미지에 대한 상세 정보 제공
(대부분의 구성 정보, 네트워크 설정, 볼륨 매핑 등의 정보 반환)
docker logs : 컨테이너의 로그 출력
(컨테이너의 STDERR, STDOUT에 쓰여진 모든것 출력)
docker port : 지정된 컨테이너의 노출된 포트 매핑 목록 반환
docker ps : 이름, ID, 상태 등 현재 컨테이너들의 개괄적인 정보 제공
(-a 모든 컨테이너의 정보 반환)
docker top : 지정된 컨테이너에서 실행중인 프로세스들에 대한 정보 반환
이미지 관리하기
이미지 생성과 관리방법을 제공한다.
docker build : 도커파일을 이용하여 이미지 생성
docker commit : 지정된 컨테이너로부터 이미지 생성
docker export : 컨테이너의 파일 시스템 내용을 STDOUT에 tar 형식으로 저장
(docker import로 저장된 결과를 이용, 로드해서 이미지 생성
파일시스템만 저장됨)
docker history : 이미지의 각 계층에 대한 정보 출력
docker images : 로컬 이미지들의 목록을 저장소이름, 태그이름, 크기 등과 같은 정보와 함께 반환
docker import : docker export로 생성된 이ㅣ지처럼 파일시스템을 포함하고 있는 아카이브 파일로부터 이미지 생성
docker load : STDIN을 통해서 전달된 tar 아카이브로부터 저장소 로드
docker rmi : 지정된 이미지들을 삭제
docker save : 명명된 이미지 또는 저장소를 STDOUT으로 스트림하여 tar 아카이브로 저장
docker tag : 이미지에 저장소와 태그이름 지정
레지스트리 이용하기
도커는 자격 증명을 홈디렉터리에 .dockercfg 확장자를 가진 파일로 저장한다는 점을 기억하자
docker login : 지정된 레지스트리 서버를 등록하거나 로그인
(서버가 지정되지 않으면 도커허브를 사용하는 것으로 간주)
docker logout : 도커 레지스트리로부터 로그아웃
(서버가 지정되지 않으면 도커허브를 사용하는 것으로 간주)
docker pull : 지정된 이미지를 레지스트리로부터 다운로드
레지스트리는 이미지 이름으로 결정되고 기본값은 도커허브
docker push : 이지미나 저장소를 레지스트리로 올림
태그가 지정되지 않으면 저장소에 있는 모든 이미지들을 레지스트리로 올림
docker search : 도커 허브에서 검색하려는 단어와 일치하는 공용 저장소 목록 출력
최대 25개의 저장소만 출력됨