도커 이미지라고 하는 일종의 패키지로 만들어 운영 서버에 전달하기만 하면 되기에 배포가 쉬워진다. 컨테이너에서 사용되던 운영 서버에서 새롭게 패키지를 설치할 필요도 없으며 각종 라이브러리 설치 등으로 인한 의존성을 걱정할 필요도 없다.가상 머신의 이미지와 달리 커널을
도커 이미지는 컨테이너를 생성할 때 필요한 요소이다이미지는 여러 개의 계층으로 된 바이너리 파일로 존재한다. 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다(iso 파일과 비슷하다)도커 이미지는 우분투, CentOS, 아파치 웹 서버, MySQL, 하둡, 스파크,
\-i -t는 컨테이너 내부로 진입하도록 attach 가능한 상태로 설정한다.컨테이너 내부로 진입하면 사용자 입출력이 가능하다.\-d 는 detached 모드로 컨테이너를 실행한다. detached 모드는 컨테이너를 백그라운드에서 동작하는 애플리케이션으로써 실행하도록
대부분의 서비스는 단일 프로그램을 동작하지 않는다. 여러 에이전트나 DB 등과 연결되어 완전한 서비스로써 동작하는 것이 일반적이다. 이런 서비스를 컨테이너화(Containerize)할 때 여러 개의 애플리케이션을 한 컨테이너에 설치할 수 있다(All in one 컨테이
컨테이너는 가상 머신과 마찬가지로 가상 IP 주소를 할당 받는다.기본적으로 도커는 컨테이너에 172.17.0.x의 IP를 순차적으로 할당한다.외부에 컨테이너의 애플리케이션을 노출하기 위해서는 eth0의 IP와 포트를 호스트의 IP와 포트에 바인딩 해야한다.docker
도커는 컨테이너에 내부 IP를 순차적으로 할당하며, 이 IP는 컨테이너를 재시작할 때마다 변경될 수 있다.컨테이너를 시작할 때마다 호스트에 veth...라는 네트워크 인터페이스를 생성함으로써 도커 컨테이너의 인터페이스와 바인딩 된다.이를 통해 도커 컨테이너는 호스트 외
컨테이너를 생성하면 기본적으로 docker() 브리지를 통해 외부와 통신할 수 있는 환경을 사용할 수 있지만 사용자의 선택에 따라 여러 네트워크 드라이버를 쓸 수도 있다.브리지(bridge)호스트(host)논(none)컨테이너(container)오버레이(overlay)
브리지 네트워크는 기본 docker0 브리지가 아닌 사용자 정의 브리지를 새로 생성해 각 컨테이너에 연결할 수 있다.컨테이너는 연결된 브리지를 통해 외부와 통신할 수 있다.기본적으로 존재하는 docker0를 사용하는 브리지 네트워크가 아닌 새로운 브리지 타입의 네트워크
네트워크를 호스트로 설정하면 호스트의 네트워크 환경을 그대로 사용할 수 있다.브리지 드라이버 네트워크와 달리 호스트 드라이버의 네트워크는 별도로 생성할 필요 없이 기존의 host라는 이름의 네트워크를 사용한다.컨테이너의 네트워크를 호스트 모드로 설정하면 컨테이너 내부의
none은 말 그대로 아무런 네트워크를 쓰지 않는 것을 뜻한다. 다음과 같이 컨테이너를 생성하면 외부와 연결이 단절된다.
컨테이너 네트워크 --net 옵션으로 container를 입력하면 다른 컨테이너의 네트워크 네임스페이스 환경을 공유할 수 있다. 공유되는 속성은 냅부 IP, 네트워크 인터페이스의 MAX 주소 등이다.
도커는 컨테이너의 표준 출력(stdout)과 에러(strerr) 로그를 별도의 메타데이터 파일로 저장하고 이를 확인하는 명령어 제공docker logs "name" 명령어로 확인 가능EX) mysql 컨테이너를 정상적으로 생성하고 로그 확인EX) 로그의 끝에 2줄 확인
syslog는 유닉스 계열 운영체제에서 로그를 수집하는 오래된 표준 중 하나이다. 커널, 보안 등 시스템과 관련된 로그, 애플리케이션의 로그 등 다양한 종류의 로그를 수집해 저장대부분의 유닉스 계열 OS에서는 syslog를 사용하는 인터페이스가 동일하기 때문에 체계적으
컨테이너를 생성하는 run, create 명령어에서 컨테이너의 자원 할당량을 조정하도록 옵션을 입력 할 수 있다.제품 단계의 컨테이너를 고려한다면 컨테이너의 자원 할당을 제한해 호스트와 다른 컨테이너의 동작을 방해하지 않게 설정하는 것이 좋다.
설정할 수 있는 최소 메모리는 4MB 이다기본적으로 swap 메모리는 메모리의 2배로 설정되지만 별도로 지정할 수 있다.
해당 컨테이너가 CPU를 상대적으로 얼마나 사용할 수 있는지 설정즉 컨테이너에 CPU를 한 개씩 할당하는 방식이 아닌, 시스템에 존재하는 CPU를 어느 비중만큼 나눠(share) 쓸 것인지를 명시아무런 값을 할당하지 않았을 때 컨테이너가 가지는 값은 1024, 이는 C
EX) --device-write-bps초당 제한을 설정하며 kb, mb, gb 단위로 제한 가능단 Direct I/O의 경우에만 블록 입출력이 제한되며, Buffered I/O는 제한되지 않는다.EX) --device-write-iops블록 입출력 제한을 상대적으로
도커는 기본적으로 도커 허브(Docker Hub)라는 중앙 이미지 저장소에서 이미지를 내려 받는다.도커 허브는 도커가 공식적으로 제공하고 있는 이미지 저장소러서, 도커 계정을 가지고 있다면 누구든지 이미지를 올리고 내려받을 수 있다.docker create, docke
이미지를 단일 바이너리 파일로 저장(save) 가능하다EX) 이미지 추출(save)추출된 파일을 도커 엔진에 불러오기(load) 하는 것도 가능하다EX) 이미지 추출(load)save, load 명령어와 유사하게 사용할 수 있는 명령어로 export, import가 존
이미지를 생성해다면 이를 다른 도커 엔진에 배포할 수 있어야 한다. 파일 배포 save, export와 같은 방법으로 이미지를 단일 파일로 추출해서 배포할 수도 있지만 이미지 파일의 크기가 너무 크거나 도커 엔진의 수가 많다면 이미지를 파일로 배포하기 어렵다. 또한
이미지 생성 방법 수동 Ubuntu:14.04, Centros:7 같은 이미지로 컨테이너 생성 컨테이너에 어플리케이션을 위한 환경을 설치, 소스소드 복제하고 잘 동작하는 것을 확인 컨테이너를 이미지로 커밋 형상 관리, 자동화 안됨 도커 파일 Dockerfile이
Dockerfile에서 사용될 환경변수를 지정. ${ENV_NAME} 또는 $ENV_NAME의 형태로 사용할 수 있다.EX)run 명령어에서 -e 옵션을 사용해 같은 이름의 환경변수를 사용하면 기존의 값은 덮어 쓰여진다.Dockerfile에서 환경변수의 값을 사용할 때
/user/bin/docker컨테이너나 이미지를 다루는 명령어를 다룬다./usr/bin/dockerd도커 엔진의 프로세스실제로 컨테이너를 생성하고 실행하며 이미지를 관리하는 주체도커 데몬은 API 입력을 받아 도커 엔진의 기능을 수행한다.API를 사용할 수 있도록 CL
자원이 부족할 때마다 더 성능이 좋은 서버를 살 수는 없다. 높은 가격의 서버를 사고 유지하는 비용 또한 무시할 수 없기 때문 이런 문제를 해결하기 위해 가장 많이 사용하는 방법은 여러 대의 서버를 클러스터로 만들어 자원을 병렬로 확장하는것이다. 필요한 만큼 많은 서버
스웜 모드 서비스 개념 도커 클라이언트에서 사용하는 명령어가 제어하는 것은 컨테이너이다. 그러나 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스이다. 서비스는 같은 이미지에서 생성된 컨테이너의 집합이며, 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이
여러 개의 컨테이너가 하나의 어플리케이션으로 동작할 때 이를 테스트하려면 각 컨테이너를 하나씩 생성해야 한다.EX)매번 run 명령어에 옵션을 설정해 CLI로 컨테이너를 생성하기보다는 여러 개의 컨테이너를 하나의 서비스로 정의해 컨테이너 묶음으로 관리할 수 있다면 좀