책 : 시작하세요! 도커/쿠버네티스 (개정판)을 이용한 Docker스터디 2W 주간 내용 정리
<오늘 이야기할 목차 note>
02장: 도커 엔진
2.1 도커 이미지와 컨테이너
도커 엔진을 구성하는 가장 중요한 기본 단위
이미지 + 컨테이너
- 2.1.1 도커 이미지
- 특정
- 컨테이너를 구성할때 필요한 요소 : 구지 비중으로 비교를 하면, 이미지 < 컨테이너 의 개념
- ISO파일과 같은 개념
- 여러개의 계층으로 된 바이너리 파일로 존재
- 읽기 전용
- 이미지의 이름 형태
- [저장소]/[이미지이름]:[태그]
- 저장소는 기본적으로 도커에서 제공하는 docker hub을 의미함
# 여기서 centos:7 의 명령어에서 centos앞에 저장소의 이름은 없다.
# 기존적으로 docker hub를 의미하는것이다.
docker pull centos:7
- 2.1.2 도커 컨테이너
- 정의 : (도커 이미지 + 필요한 설정 파일)을 통해서, 격리된 시스템 자원 및 네트워크 사용할수 있는 공간 생성
- 그림처럼 독립된 케이스가 생기는 개념입니다 (각티슈가 "도커 이미지" 파일 개념)
- 컨네이너 안에 여러개의 이미지 항목이 여러개 구성된다. (이 개념이 맞는지 확인)
- 개념 정립하기)
- docker run redis 을 여러번 하면, 1개의 컨테이너에 redis가 여러개 구성되는것이 맞을까?
- 아니면, 실행한 횟수 만큼 여러개의 container가 생성되는 것이 맞을까?
- 아래 화면을 보고 문득 1:1인지, 1:many인지 정립필요
# docker command 살펴보기
docker -help
<테두리 박스는 이번 스터디 내용중에 포함된 명령어>
- 실습에서 많이 나온 -i -t -d 옵션은 어떻게 보는 것일까요?
아래와 같이 조합해서 --help를 수행하면 됩니다.
2.2 도커 컨테이너 다루기
- 2.2.1 컨테이너 생성
- -i, -t 옵션은 컨테이너와 상호 입출력을 가능하게 함
- -i : 상호 입출력
- -t : tty를 활성화 해서 bash셀을 사용하도록 설정
TTY(teletypewriter) 항목은 리눅스 디바이스 드라이브 중에서 콘솔이나, 터미널을 의미합니다.
- docker접속 root@16진수 해시값중 앞에 12자리만 사용
| enetrypm@enetrypmui-MacBookPro ~ % docker run -i -t ubuntu:14.04 Unable to find image 'ubuntu:14.04' locally 14.04: Pulling from library/ubuntu 2e6e20c8e2e6: Pull complete 0551a797c01d: Pull complete 512123a864da: Pull complete Digest: sha256:64483f3496c1373bfd55348e88694d1c4d0c9b660dee6bfef5e12f43b9933b30 Status: Downloaded newer image for ubuntu:14.04 root@0ece8dceec45:/# |
- p.23 : docker inspect 해쉬12자리 입력하면 docker의 세부 사항민 16진수 hash값 전체 확인 가능
- p.22 : docker run 명령어 사용시, -i, -t를 함께 사용하지 않으면 셀을 정상적으로 사용 할 수 없습니다.
- 테스트1) -t를 제거하고 실행한 run화면 : root@~~ docker shell로 접속이 되지 않습니다.
- 테스트2) -i를 제거하고 실행한 화면
- 테스트3) docker 상태 파악
- -i, -t를 제거하고 실행하였지만 ps에서는 실행한 3개의 사항이 모두 나타납니다.
- Docker 컨테이너 shell안에서 빠져나오기
- exit, Ctrl + D : 해당 명령어는 Docker 종료가 됩니다.
- Ctrl + P, Q : 단순히 컨테이너의 셀에서만 빠져나오고, 실행은 계속 됨
- Mac에서는 Command가 아닌 Control Key를 이용
- 명령어) docker pull / docker images
- 이미지를 내려 받을때 사용합니다.
- 아직 컨네이너가 실행중인 상태가 아니며, docker ps를 하면 나타나지 않습니다.
- 명령어) docker create
- docker image가 있을때, 이것을 이용해서 docker container를 생성합니다. (!! 이때 컨테이너가 실행된것이 아닙니다.)
- create 수행시에도 -i -t 옵션을 이용합니다.
- 실행이 된것이 아니기 때문에 docker ps 수행시에 나타나지 않습니다.
- docker image가 있을때, 이것을 이용해서 docker container를 생성합니다. (!! 이때 컨테이너가 실행된것이 아닙니다.)
- <궁금증>
- 만약 pull로 이미지가 없는 경우, docker create를 수행하면 어떻게 될까?
- docker images에 없다면 그냥 새로 pull해서 download를 수행합니다.
- 없어도 무관합니다.
- 동일 이름으로 실행하면 어떻게 될까?
- -name 옵션을 처음 배웠는데, docker run을 할때도 한번 적용해보자
- 당연히, 잘 적용됩니다.
- 이때 name옵션은 --name으로 - 옵션이 2개 들어갑니다.
- 옵션에서 -, -- 의 의미가 차이가 있을것 같다
| enetrypm@enetrypmui-MacBookPro ~ % docker run -i -t --name ubuntu_name_test ubuntu:14.04 root@bba25a597b7d:/#  |
- docker run은 이미지를 다운받고, 실행까지 한번에 실행합니다.
- p. 24
- docker pull + docker create + docker start + docker attach // 의 기능을 한번에 수행함
- 결론 : 보통 run을 주로 사용합니다.
- 명령어) docker start, docker attach
- start : 컨테이너를 시작
- attach : 컨테이너 내부로 들어가기
| enetrypm@enetrypmui-MacBookPro ~ % docker start mycentos mycentos ~~~ enetrypm@enetrypmui-MacBookPro ~ % docker attach mycentos [root@df564345fa64 /]# [root@df564345fa64 /]# [root@df564345fa64 /]# |
- <궁금증>
- docker start를 할때, name이 없는 경우 실행할수 있을까?
- 당연히 repo, image id를 사용하면 실패
- 아래 그림 (docker desktop)에서 보이는 Name을 이용하거나, 고유 해쉬값을 이용하면 가능
- docker start 0ece8dceec45c50e4b5c24b93e49d4536040b26a14b38c8da82da69625c8b909
- docker start recursing_feynman (여기서 이 이름은 default로 생성된 부분이다!!)
- 이 과정은 매우 번거로운데..... 그러면 docker create // run 할때 --name 생성하는것이 매우 중요할거 같다
- p.24 // 컨테이너를 대상으로 하는 모든 명령어는 컨테이너의 이름 대신 ID를 쓸수 있다.
- 3번째 그림처럼 COMTAINER_ID를 사용하면 된다.
- 2.2.2 컨테이너 목록 확인
- 명령어) docker ps
- 동작중인 컨테이너만 출력함
- exit를 사용해서 나온 컨테이너도 정지상태여서 출력안됨
- -a 옵션
- 정지상태까지 포함한 모든 목록 출력
- 요소 설명
- Ports : 컨테이너가 개방한 포트와 호스트에 연결한 포트를 나열합니다.
- Names : 컨테이너의 고유한 이름 (--name : 이용해서 설정하고), 기본값은 형용사 + 명사를 무작위로 설정함
- 2.2.3 컨테이너 삭제
- 명령어
- 보통 삭제시 stop 후에 rm을 실행함
- docker rm (컨테이너 ID or 이름)
- docker rm -f : 실행중이여도 삭제함
- docker container prune : 한번에 모두 다 삭제함
- docker stop (docker -a -q)을 인자값으로 사용
- -a : 컨테이너 상태와 상관없는 모든 컨테이너
- -q : 컨테이너 ID값만 출력하는 역활
- 보통 삭제시 stop 후에 rm을 실행함
- 2.2.4 컨테이너를 외부에 노출
- 서비스를 하는 입장에서 해당 부분은 매우 중요한 개념
- 요약
- 컨테이너는 가상 IP주소를 할당 받습니다
- 172.17.0.X 의 IP를 순차적으로 할당 받습니다.
- -p 옵션을 사용해서 포트 설정을 합니다.
- [호스트포트]:[컨테이너포트] 형태입니다.
- [호스트의 특정아이피][호스트포트]:[컨테이너포트] 형태로 아이피를 넣을수도 있습니다.
- -p 192.123.222.3:7777:80
- 호스트의 IP가 192.123.222.3이고 7777포트를 docker container의 80포트와 연결
- 실습
- 설정시 기본적으로 ip는 0.0.0.0으로 연결된다.
- tcp항목이 있는것을 보면 udp형태등 다양한 프로토콜을 설정할수 있는것으로 보인다.
- 호스트의 IP와 포트를 통해 172.17.0.X:80으로 접근하는 개념
- 중요한 개념!!
- 내가 임의로 80:82로 설정은 할수 있지만 Apache가 잘 실행되지 않는다.
- Docker Container에 설치된 apahce config의 설정사항을 82로 변경하면 정상동작한다.
- apache2 ubnutu docker에 설치하기
- 172.17.0.2 의 docker 내부 eth0의 ip가 나온다.
- 구성을 하면 이렇게 localhost or 127.0.0.1로 호출하면 정상적인 apache 첫페이지 확인
- 호스트 IP의 80포트로 접근 -> 80번 포트는 컨테이너의 80번 포트로 포워딩 -> 웹서버 접근
- 2.2.5 컨테이너 애플리케이션 구축
- Container에 여러개의 어플리케이션을 설치하는것인 비추천!!
- 한 Container에 프로세스 하나만 실행하는 것이 도커의 철학
- mysql + wordpress 환경 구축 실습
- 실습시 주의점 : \ (줄바꿈 목적으로 사용시) \ 뒤에 공백을 주지 말고, 바로 Enter 필요
- 새롭게 나온 옵션
- -d : de-attached모드, 컨테이너를 백그라운드로 동작하는 애플리케이션으로 실행 설정
- 반대 개념 : -i -t 옵션은 Container내부로 진입하는 attached 모드
- run을 실행하면, 입출력이 없는 상태로 컨테이너를 실행
- mysql은 mysqld를 실행하기 위한 목적
- apache2는 apache2-forground를 실행하기 위한 목적
- 그러면, 언제 -d를 써야 하고 언제는 -i -t를 사용해야 하는가??
- OS는 -d가 필요없을것 같은데, 일반 SW(DB, WebServer...)등은 -d가 필요하지 않나??
- -d 옵션 사용시, 내부의 셀에 접속해도 의미가 없음 (이미 background로 실행중인 demon의 로그만 확인가능함!!)
- 이런경우 exec 명령어를 사용한다.
- ex: docker exec -i -t wordprocess /bin/bash
- --link : 서로 다른 Container간에 접근하는 방법입니다.
- 내부 IP를 정보 없이 Container의 별명(alias)으로 접근하도록 설정함
- 여기서 이상한점, 주의깊게 볼 사항
- --link wordpressdb:mysql에서 부분입니다.
- 책 설명 : wordpressdb의 ip를 몰라도, mysql이라는 호스트명으로 접근 가능
- --link의 저 부분은 hosts명?? 서비스명?
- 이것도 - 항목이 2개이다.
- 다 정리하니..... deprecated된 옵션이라고 한다.
- docker bridge를 통해서 link와 같은 기능을 권장함!
- -e : 예상한 대로 환경변수에 대한 설정 (!!! Container에서 사용하게 되는 변수이다)
- -d : de-attached모드, 컨테이너를 백그라운드로 동작하는 애플리케이션으로 실행 설정
- 위 실습을 진행하고 나서 특이한점 살펴보기
- command부분에 일반적으로 /bin/bash를 사용하는데, docker-entrypoint...라는 다른 메세지 확인 ?? 이거 무엇??
- mysql은 외부 host에 오픈하지 않고, 자체적인 실행 port만 있다. (화살표가 없다)
- wordpress에서는 docker run수행시 -p 80 만 수행했다.
- [host-port] : [container-port] 형태가 아니다.
- 화면에 있는 52484는 어디서 왔을까???
- wordproess의 기본 port인가?? --link를 수행하면서 설정된 사항인가??
- 이렇게 wordpress의 초기 화면이 정상적으로 호출됩니다.
- 책 (p.33)에서는 다른 32769 port를 이용해서 호출하기 때문에, 이것은 random?으로 설정된 포트로 추정합니다.
- P. 35 note에 나온 내용 파악
- "컨테이너는 각기 하나의 모니터를 기본적으로 가지고 있다고 생각하면 이해하기 쉽습니다"
- 책의 내용대로 동시에 같은 Container에 대해서 attach해본 화면
- 입력을 하면 동일하게 mirror처럼 함께 같은 결과가 출력됩니다.
- 책의 저 멘트를 다시한번 remind해보기??
- 2.2.6 도커 볼륨
- 볼륨은 특히 DB를 사용하는 입장에서는 매우 중요한 항목 (Docker를 삭제 하여도, Data는 영구적으로 보전이 되어야 함)
- 활용하는 방법에는 여러가지 방안이 있음
- 호스트와 볼륨을 공유
- 볼륨 컨테이너를 활용
- 도커가 관리하는 뷸륨을 생성 하는 방법
- 별도의 볼륨 설정을 따로 하지 않고, 현재까지 실습한 환경에서의 Docker Desktop의 Volume 섹션의 화면입니다. (참고용)
- 느낌상 화면의 볼륨은 2.2.6.3 절에서 설명되는 "도커 볼륨" 으로 생각됩니다.
- 추후에 "호스트불륨", "볼륨 컨테이너" 등을 연습해보면서 해당 화면에 어떻게 변화가 있는지 살펴보면 재미있을거 같습니다.
- 2.2.6.1 호스트 볼륨 공유
- 실습) mac에서는 책의 예시처럼 /home 위치에 권한문제가 있어서 경로 변경처리함
- -v : 호스트의 디렉토리를 컨테이너와 공유한다는 의미
[호스트의 공유 디렉토리]:[컨테이너의 공유 디렉토리]
- mysql의 기본 디렉터리의 볼륨이 호스트 폴더에 잘 공유되어 있는 모습
- 호스트와 Container에 동일한 디렉터리가 존재하는 경우
- 결론!! 호스트의 디렉터리&파일이 우선시 되어서 덮어진다
- -v 옵션 : 호스트의 디렉터리를 컨테이너의 디렉토리에 마운트 한다
- 2.2.6.2 볼륨 컨테이너
- 정의 : -v옵션으로 볼륨을 사용하는 컨테이너를 다른 컨테이너와 공유하는것!!
- 사용방법 : --volumes-from옵션을 통해서 작업한다.
- 대상 볼륨 : -v를 적용한 Container가 대상 (직접 볼륨을 공유하는 것이 아님!!)
- 요약
- -v를 통해서 한번 호스트의 LocalDisk와 연결이 한번 되고 난 후에
- --volumes-from을 통해서 n개의 형태로 연결이 수직적으로 늘어나는 개념
- 2.2.6.3 도커 볼륨
- 정의 : 도커 자체에서 제공하는 볼륨기능을 활용하는 방식
- 호스트의 볼륨을 사용하지 않는 방식
- 중요!!
- P.45
- 처음에는 이름이 도커 볼륨이라 Docker안에서 생성되는줄 알았는데, 아니였음!!
- 도커볼륨도 호스트 볼륨 공유와 마찬가지로, 호스트에 저장함으로써 데이터를 보존하지만, 파일이 실제 어디에 저장되는지 사용자는 알 필요가 없다.
- 명령어
- docker volume create
- 형식 : [볼륨의이름]:[컨테이너의 공유 디렉토리]
- 아래 보이는 DRIVER항목이 있다
- 여러 종류의 스토리지 백앤드를 쓸수 도 있다.
- 기본적으로 제공되는 드라이버인 local이 제공된다.
- 이 볼륨은 로컬 호스트에 저장되는 도커 엔진에 생성되고 삭제된다.
- 이 Driver부분을 변경하면 호스트 Disk를 -v로 연결한것처럼 사용할수 있는것일까???
- 실제 호스트에 저장되는 도커 볼륨 위치 확인하기
- inspect 옵션은 다양한게 사용된다.!!!
- 사용자가 지정을 못하니 답답하고, 관리가 어렵지는 않을까?? 하는 생각
- Disk full이 나는것들을 관리 못하지 않을까???
- inspect 명령어 : 이런식으로 [] 항목을 구성해서 특정 구성단위를 제어하는것을 확인 가능
- docker [container] inspect
[image] inspect
[volume] inspect
- docker [container] inspect
- 위에 docker volume을 생성한 위치를 조회하면, 실제 Mac(host)의 경로에는 관련 폴더가 없습니다.
- 개인적인 생각으로는 Docker입장에서 자동적으로 linux시스템 기반으로 경로를 자동 생성하는데,
MacOS인지 체크하지 않고 생성을 바로 하는것 같습니다.
- 개인적인 생각으로는 Docker입장에서 자동적으로 linux시스템 기반으로 경로를 자동 생성하는데,
- 실습
- 이것도 host disk공유하는것과 비슷한 원리이다.
- 같은 이름의 docker 볼륨을 사용하면, 같은 내용이 공유된다.
- 주의 : 여기서도 -v 옵션을 사용하는데, 입력하는 format이 다르다
- -v 말고 --mount 옵션을 사용해도 된다 (p.47 노트)
- 볼륨의 정보를 나타내는 방식이 다르다
- -v, --mount : -의 갯수 차이가 있다
- 2.2.7 도커 네트워크
- 2.2.7.1 도커 네트워크 구조
도커에서 내부적으로 할당되는 eth0의 아이피는 172.17.0.X 자동 할당된다.
서비스 하는 입장에서, docker stop / start 수행시, IP가 변경되면 서비스 하는 입장에서 위험요소를 가지고 있는것이다.
- 구성요소
- eth0 : 172.17.0.X ~ 형태로 docker에서 순차적로 할당
- lo : 127.0.0.1
- veth : docker와 외부를 연결하기 위한 네트워크 인터페이스
- docker0 : veth를 연결하는 브릿지
- 앞에서는 도커 Container 1개의 (eth0, lo)에 대해서만 살펴보았다.
- 확장하면, veth요소, 이것들을 묶어주는 docker0브릿지 요소, 그리고 또 eth0요소가 나온다??
- 2.2.7.2 도커 네트워크 기능
- 위 화면에서 설명한 docker0은 기본적인 브릿지이며, 사용자의 선택에 따라서 여러 네트워크 드라이버를 쓸수 있다.
- 대표적인 네트워크 드라이버 종류
- 브리지 (bridge) : docker에서 기본제공
- 호스트 (host) : docker에서 기본제공
- 논 (none) : docker에서 기본제공
- 컨테이너 (container)
- 오버레이 (overlay)
- 서드파티 (third-party) 플러그인 솔류션
- weave
- flannel
- openvswitch
- 기본적으로 제공하는 network 조회
- docker0 브릿지는 아래 bridge의 한 종류이다.!!
- 한 종류라는 것은 bridge를 docker0 아닌, 다른 형태로 구성이 가능하다
① 브리지 네트워크
- docker0 브릿지와 비슷하게 "브리지 네트워크"는 docker0이 아닌 사용자 정의 브릿지를 새로 생성해서
각 Container에 연결하는 네트워크 구조 - p. 51 : 기본적으로 존재하는 docker0을 사용하는 브리지 네트워크가 아닌, 새로운 브리지 타입의 네트워크를 생성할수 있다.
- 실습) 신규 브릿지 네트워크를 구성
- step1) network create를 통해서 mybridge 신규 생성
- step2) --net mybridge를 통해서 신규 생성한 네트워크를 사용하게 설정
- 이때 눈에 들어오는 사항이 IP의 B classe 대역대가 172.17이 아닌 172.18로 변경된 점이다.
기본적으로 docker0에서 사용하는 172.17이 아닌 다른 대역대를 사용한것으로 생각됨
- 궁금해서 한번더 신규 network를 생성해서 테스트해본 결과
- 아래 그림처럼 이번에는 172.19.x.x가 할당되었다.!!
② 호스트 네트워크
- 정의
- 호스트의 네트워크 환경을 그대로 쓸수 있다.
- 이 점이 개인적으로 매우 매력적으로 생각이 되는데, 이것이 docker의 초기 옵션은 아니다.
- 현업에서 많이 사용하는 옵션인지 궁금??
- 호스트 드라이버의 네트워크를 별도로 생성할 필요가 없다.
- 호스트 이름도 16진수가 아닌, 호스트 머신의 이름을 그대로 사용한다
- Container 내부의 애플리케이션을 별도로 포트 포워딩 필요없이 바로 서비스 할수 있다
- 실습
- --net host : 이 명령어를 이용해서 "호스트 네트워크"를 설정한다!!!
- -i -t를 사용하였는데, container내부로 들어거야 하고, 16진수가 붙어야 하는데 분명 다른 라인을 제공한다.
③ 논 네트워크
- 정의 : 아무런 네트워크를 사용하지 않는다는 의미
- 외부와의 연결이 단절됩니다.
- --net none을 이용함
④ 컨테이너 네트워크
- 정의
- 생성되어 있는 container의 네트워크를 같이 사용하는 개념 볼륨을 공유하는 개념과 비슷함
- 내부 IP, 네트워크 인터페이스의 MAC주소 등
- 형식 : --net container:[다른 컨테이너 ID]
- 실습
- -i -t -d를 한번에 사용했다
- p.54, 이렇게 함께 사용하면, Container내부에서 셀을 실행하지만, 내부로 들어가지 않으며, 종료가 되지 않습니다.
- 테스트용으로 컨테이터를 생성할때 유용하게 쓸수 있다.
- 아래 그림을 보면, 각기 다른 container의 eth0의 IP가 동일한 것을 볼수 있다
- -i -t -d를 한번에 사용했다
⑤ 브리지 네트워크와 --net-alias
- 정의 : 브리지 타입의 네트워크와 run명령어의 --net-alias 옵션을 함께 쓰면 특정 호스트 이름으로 컨테이너 여러개에 접근 할수 있다.
- 실습
- --net mybridge : 동일한 네트워크를 사용하도록 설정함
- --net-alias alice106 : 이 네트워크에 별칭(alias)를 설정하는 것이다.!!!
- 설정한 alias "alicek106"에 대해서 ping을 날려보면
- 라운드 로빈 방식으로 3개의 ip중에 1개라 return됩니다.
- 흔히 L4장비에서 load balancer의 역활하는 것과 동일한 방식입니다.
- --net-alias 옵션과 --link옵션는 비슷한 원리로 동작합니다.
- digs로 확인해본 network화면
⑥ MacVLAN 네트워크
- 정의
- 호스트의 네트워크 인터페이스 카드를 가상화 하는 것이다.
- 가상화의 주체가 호스트에 있다.
- 물리 네트워크상에서 가상의 맥(MAC)주소를 가진다.
- 기본적인 172.17.x.x가 아닌 네트워크 강비의 IP를 할당받는다.
- 사용하려면 적어도 1개의 네트워크 장비와 서버가 필요하다
- 2.2.8 컨테이너 로깅
- 2.2.8.1 json-file 로그 사용하기
- 도커는 컨테이너의 표준 출력(StdOut)과 에러(StdErr)로그를 별도의 메타데이터 파일로 저장하며, 이를 확인하는 명령어를 제공합니다.
- 명령어 : docker logs [Container ID or Name]으로 실행되는 로그 확인
- 실습
- mysql과 같은 애플리케이션은 포그라운드 mode로 실행됨
- 그래서 -d 옵션으로 백그라운드 모드로 container를 생성하는 경우가 일반적임
- 실행도 정상적으로 안된 환경에서는 attach 명령으로도 접근이 불가능해서 docker logs를 이용해서 로그 확인해야 함
- 저장위치
- Container로그는 JSON형태로 Docker내부에 저장된다
- 물리적으로 Docker안에 저장되어 있는 파일을 확인해보고 싶었지만, 확인은 불가했습니다.??
| docker inspect logstest --format "{{.LogPath}}" /var/lib/docker/containers/11732d6efd470ba12d2f7b94cb2b7e03fb8eea20ea924166d661963ec93a7b2f/11732d6efd470ba12d2f7b94cb2b7e03fb8eea20ea924166d661963ec93a7b2f-json.log  |
- 다양한 로깅 드라이버를 적용해서 기록 가능
- syslog
- jorunald
- fluentd
- awslogs
- 2.2.8.2 syslog 로그
- syslog는 unix 운영체제에서 기본적으로 사용하고 있는 로그 포맷
- (명령어) --log-driver=syslog를 사용
- 실습
- mac에서 Test수행시, 아래와 같은 오류 발생
- 2.2.8.3 fluentd 로깅
- fluentd는 각종 로그를 수집하고 저장하는 오픈소스
- json포맷을 사용
- AWS S3, HDFS, MongoDB등 다양한 저장소에 저장 가능
- 2.2.8.4 아마존 클라우드워치 로그
- AWS사용시, ClouddWatch 서비스가를 통해서 Docker로그를 전송하는 방법
- https://aws.amazon.com/ko/cloudwatch/
- AWS에서 docker 실행시, 아래와 같은 옵션으로 설정
- 2.2.9 컨테이너 자원 할당 제한
- 기본적으로 Docker를 사용할때 자원 할당량에 대한 제한이 없으면, 호스트의 자원을 무제한으로 사용가능합니다.
- docker inspect를 이용해서 해당 container의 다앙한 정보중에 자원에 대한 부분도 조회할수 있습니다.
- 2.2.9.1 컨테이너 메모리 제한
- 명령어 : --memory
- 실습
- 실수로 메모리 용량을 1로 입력하니, Check하는 메세지가 출력됨
- 정상적으로 1g = 1024*1024*1024 값이 입력되는것을 확인
- 2.2.9.2 컨테이너 CPU 제한
- --cpu-shares
- 시스템에 존재하는 CPU를 어느정도 share해서 사용할지 명시하는 기능
- ex : --cpu-shares 1024
- 예를들어 --cpu-shares 512 / --cpu-shares 1024 이렇게 실행시 1:2 비율로 CPU를 사용
- 해당 옵션 사용시, 100에 대한 기준을 내부적으로 잘 세워야 할것으로 생각됨
- --cpuset-cups
- 특정 cpu만 사용하도록 지정 할수 있는 기능
- ex: --cpuset-cpus=2 : 3번째 cpu를 사용하도록 설정하는 기능 (0부터 시작함)
- --cpu-period, --cpu-quota
- --cpu-period : CPU의 스케줄링 하는 시간을 조절
- --cpu-quota : CPU에서 할당받을 비중
- 컨테이너는 [--cpu-period 값] / [--cpu-quota 값] 만큼 CPU 시간을 할당받음
- --cpus
- --cpu-period, --cpu-quota 와 같은 역활이지만, 설정을 편하게 할수 있음
- 2.2.9.3 Block I/O 제한
- 기본 설정시 제한이 없음 : 컨테이너의 내부에서 파일을 읽고 쓰는 대역폭에 제한이 없음
- 사용되는 옵션
- 공통 : 단위는 kb, mb, gb
- --device-write-bps : 쓰는 것에 대한 초당 제한
- --device-read-bps : 읽는것에 대한 초당 제한
- --device-write-iops : 쓰는 것에 대한 상대적인 Cpu비중 조절값
- --device-read-iops : 읽는것에 대한 상대적인 Cpu비중 조절값
- 2.2.9.4 스토리지 드라이버와 컨테이너 저장 공간 제한
- 보편적이지는 않지만, Container 내부의 저장공간을 제한할수 있다
- 도커의 스토리지 드라이버나, 파일시스템등 특정 조건을 만족하는 경우에만 적용 가능
- 권장되지 않는다.
이미지 / 컨테이너 실행 / 내부 들어감
run : 이미지를 내려받고, 실행까지 함, 내부로 들어감
pull : 이미지를 내려받는것 까지, 실행 안함
create : 컨테이너 생성, 실행 안함, 내부 X
'docker' 카테고리의 다른 글
| 4W docker study (0) | 2023.01.24 |
|---|---|
| 3W docker study (0) | 2023.01.24 |
| 1W docker study (0) | 2023.01.24 |
