도커 학습기 #1

Docker 기반의 DevOps 인프라 구축 WORKSHOP 이 수업을 수강하고 있다. 비싼 수업인 만큼 1회차 수업을 듣고 나름의 정리를 한다.

강의는 도커 초보자, 그리고 데브옵스 초보자를 대상으로 한다. 실습 위주로 많이 써봐야 도커 실력이 는다고 하셨다.

강의 목표는 다음과 같다.

• 도커가 무엇인지 설명할 수 있다.
• 현재 진행하는 프로젝트에서 활용할 수 있을거 같다.
• 도커기반 DevOps 시스템 구축에 대한 감이 잡힌다.
• 도커 전문가가 되기 위해서 무엇을 공부해야 하는지 알겠다.

오늘의 커리큘럼

공식 홈페이지에 올라와있는 커리큘럼이다. 도커를 사용할 수 있는 환경을 로컬에 구성할 수 있다. 도커 이미지와 컨테이너를 이해하고 나에게 맞게 커스텀 해본다.

• 도커의 이해 및 환경 구성
  • 도커 히스토리
  • 리눅스 컨테이너 기술의 이해
  • 도커 툴박스를 이용한 도커 로컬 환경 구성
• 도커 이미지
  • 도커 이미지 이해
  • 도커 이미지 사용
  • 나만의 도커 이미지 만들기
• 도커 컨테이너
  • 도커 컨테이너 이해
  • 도커 컨테이너 만들기
  • 컨테이너 연결하기

도커로 로컬 개발환경 구축하기 다양한 형태의 컨테이너를 만들 수 있다. 도커 머신으로 로컬에 개발환경을 꾸밀 수 있다.

• VM 활용
  • Docker Machine, Vagrant 이해
  • 로컬에서 VM 환경 구성하기
• 컨테이너 활용
  • Dockerfile 의 이해
  • 컨테이너 환경설정
  • 데이터 볼륨 컨테이너
  • 컨테이너 데이터 백업

잡담

나 말고는 다들 현업에 계신 분들이었다. 회사에서 도커를 쓰고 있어서, 또는 이제 적용하려고 배우러 오신 분들이 많았다.

도커는 무엇인가

리눅스 컨테이너 기술을 이용해 어플리케이션 패키징, 배포를 지원하는 경량의 가상화 플랫폼 엔진은 Go 언어로 개발(Go 언어의 가장 큰 성공 사례 중 하나) 도커를 깊게 쓰기 위해서는 Go 언어도 배우는게 좋다.

키워드는 다음과 같다

• 리눅스 컨테이너 기술
• 패키징
• 배포
• 경량
• 가상화

짧게 말하면, 도커는 패키징과 배포 도구다.

이제는 거의 stable 하다. 업데이트마다 큰 변화가 없음.

도커를 써야하는 이유

도커를 써야하는 이유. Matrix From Hell을 해결했다. 도커라이징 = 박스로 감싼다. 도커라는 상자를 이용해서 우리 어플리케이션을 넣기만 하면 됨 어떤 OS/Device에서도 동일한 방식으로 배포가 가능하다.

또한 Guest OS가 필요없기 때문에 가볍고 빠르다. 하이퍼바이저 기반 가상화 서비스 VMWare같은거 최소 10기가

Immutable Infrastructure

이미지 기반의 어플리케이션 배포 파라다임을 말한다. 많은 서버를 동적으로 관리하는 클라우드 환경에서 효과적이고 유연한 배포 방식

마치 CD를 굽듯이 사용하는 것이다. 도커가 변경불가능한 인프라를 가능하게 해주는 기술이다

De Facto

도커는 이미 업계 표준이 되었다. 금방 나온기술이 아니다. 한 10년에 걸쳐서 쓰여지고 쓰여지고 하다가 나온게 도커이다 구글같은 회사는 내부적으로 2004년부터 쓰고 있었다.

리눅스 컨테이너 기술은 소개된지 10년이 지난 기술이다. 설정이 복잡하고 사용하기 어려워 널리 사용되지 못했다. 하지만 도커는 사용하기 쉽다. 그래서 사람들이 널리 쓰기 시작했다. (영상 참고 : future of linux containers)

만만한 기술은 아니다. 배워야할 것과 알아야할 것이 많다.

도커 CE와 Enterprise의 차이

도커 CE 도 충분히 다 쓸수있다. 그냥 안정화와 관련된 기능을 내가 다 해야하는것 뿐이다

도커의 사용

CLI를 사용하자. 한번 익숙해지고 나면 이게 훨씬 편하다. 그리고 실제 운영할 때 CLI 쓸 수 밖에 없다.

도커 데스크탑을 다운로드하는순간 아주 작은 가상서버를 만들어서 띄워놓은거 명령어를 치면 맥에 깔려있는 조그만 가상머신에서 실행되는거

조그만 가상머신은, xhyve/bhybe를 기반으로 하는 HyperKit을 임베디드 하이퍼바이저로 사용하는 것이다. (윈도우는 또 다르다.)

각 클라이언트별로 가상화 기술에 대해 세팅이 잘되어있느냐에 따라서 다르다 맥은 좀 잘되고 윈도우는 케바케 윈도우는 도커를 사용하기에 좋은 환경은 아닌데, 많이 좋아졌다. 리눅스가 최고의 환경임. 네이티브니까.

도커의 제품군

• Docker for Mac
• Docker for Windows
• Docker for Linux
• Docker Engine
• Docker Compose
• Docker Hub
• Docker Cloud
• Docker Trusted Registry
• Docker Universal Control Plane
• Docker Machine

Kitemetic

도커 클라이언트 단에서 사용하는 프로그램. 도커 엔진과 통신. 이거말고 Docker Desktop, Docker ToolBox 존재한다.

써보면 좋긴함. 클라이언트에서 재미삼아서 써볼만 하다 근데 프로덕션에서 쓰려면 이런걸로는 쓰지 못한다.

Docker Engine

리눅스 서버에 도커 데몬 다운받음 (이 리눅스를 도커 호스트 오에스라고 부른다) 깔고나면 REST API가 드러나게 되고, 도커 클라이언트가 이 인터페이스를 통해서 도커 엔진을 계속 호출한다.

도커 클라이언트는 사실상 하는게 없다.

도커 엔진과 도커 오케스트레이션 도구와 통합되어 있다. Swarm, Kubernetes가 도커 엔진과 Native level에서 다 통합이 되어있음.

Docker Machine

로컬, 리모트 서버에 도커 엔진을 설치하고, 설정을 자동으로 해주는 프로비저닝 클라이언트이다.

하이퍼바이저 기반의 가상 서버를 쉽게 만들어주는 도구이다. 한땀한땀 할수도 있는데, 그런걸 귀찮게 하지않고 한방에 해주는 거임.

Docker Hub

도커가 성장하게 된 가장 큰 요인중에 하나이다. 왠만한 오픈소스는 다 들어있음. 그냥 이미지를 pulling해와서 쓰는 경우가 훨씬 많다.

Docker Trusted Registry

도커 이미지 저장소를 구축할 수 있다. 설치형, 인증 지원 Registry무료, DTR유료 DTR은 필수이다. 호스트나 컨테이너가 많아지면 필수일 수 밖에 없다.

DUCP

Docker Universal Control Plan 도커 클러스터 관리도구이고, 설치형(유료) 이다. 대시보드 어플리케이션이고 사람이 관리하기 힘드니까 쓴다. 하지만 비추라고 하셨다.

Docker Conference

도커전문가가 되기 위해서 이것을 공부해야 한다. 도커 컨퍼런스의 과거 영상들이 다 무료로 공개되어 있다. 최신 도커 흐름을 파악할 수 있는 기회이다. 매년 미국/ 유럽에서 개최한다.

DockerCon 2018 - Docker Promise

• Choice
  • 클라우드, OS에 종속되지 않는다.
• Agility
  • 생산성, 효율증가
• Security
  • 어플리케이션으로부터 데이터 분리

도커를 쓰면 어느 클라우드에 다 가지고 갈 수 있다

잡설 : 도커는 시리즈 A, B, C, D, E … 투자 다 받았다고 한다. 시리즈 단계 올라갈때마다 10배의 금액 상승이 있다. 거의 조 단위로 투자 받은 돈이 많은 회사. 잡설 : 윈도우에 윈도우 컨테이너 띄우는게 네이티브라는거 리눅스 컨테이너 띄우려면 여전히 가상화 머신 사용해야함.

도커는 IoT 기반의 OS로 성장하고 있다

라즈베리파이에도 도커를 올릴 수 있다. Uni-kernel로 만들면 5메가 이하로 해서 올릴 수 있음

총평 : 서비스를 클라우드에 배포하는데 도커를 안쓰는 것은 바보같은 짓이다. Vendor의 Lock-in을 피할 수 있다.

Toolbox와 Desktop 차이

Toolbox는 작은 가상머신이 아니라 오라클 버츄얼박스가 깔리고, 거기에 Default라고 하는 가상머신이 깔려있다. 툴박스가 옛날에 나온거임.

실습 1

• eval $(docker-machine env default)
• docker version
• docker info
• 공유폴더 설정 확인

도커 아키텍쳐

Hypervisor, 하이퍼바이저는, 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼이다.

가상화 기술의 거의 표준이다. 하나의 베어메탈 머신에서 물리서버 하나를 여러대의 가상 서버로 쓰는것이 일반적이다. 그것이 비용적으로 효율적인 것이기 때문이다. 하이퍼 바이저가 하나의 호스트 컴퓨터에 다수의 운영체제가 논리적으로 실행이 가능하게 한다.

하이퍼 바이저의 종류는 크게 Type1, Type2로 나뉜다.

Type1 기술은 호스트 OS가 아예 없다. 맥에서 패러렐즈 쓰는거가 Hypervisor의 Type2 를 쓰는 것이다. Type1이 사실 훨씬 효율적이긴 하다

컨테이너와 하이퍼바이저

VM이 주택이면, Container는 아파트이다. 큰 차이는 하이퍼바이저에는 Guest OS가 있다.

컨테이너는 OS가 있긴있는건데 호스트 오에스를 빌려 쓰는 것이다. 초반에 뚜드려맞은 이유가 이것때문에 위험하다고 판단됐음. 게스트 오에스에 비해서 격리수준이 떨어지기때문에 덜 안전한거 같다라는 우려였다.

리눅스 컨테이너 LXC, Linux Container

도커와 의존성이 있는 기술이 아니다. LXC 기술을 구현해놓은 구현체는 따로 있다. Libvirt

도커의 기반 기술

• Namespaces
  • 가벼운 프로세스 가상화 기술이다.
  • 격리된 작업공간(컨테이너)를 구성해준다.
  • 프로세스별 리소스 격리
• Control groups(==cgroups)
  • 실행중인 어플리케이션이 원하는 만큼 리소스를 사용하게 한다.
  • 특정 컨테이너가 지정한 만큼 리소스를 쓰도록 제한한다.
  • 리소스 관리

Union Filesystem

리눅스 파일 시스템으로는 ext4, btrfs, xfs 등 다양하게 있다. 다른 파일 시스템을 Union mount 하도록 해주는 리눅스 파일 시스템 서비스이다. read-only 레이어들의 통합이다.

도커에 다양한 파일시스템으로 만들어진 이미지가 되게 많다. 근데 이걸 도커 하나로 사용할 수 있는게 Union Filesystem 때문에 쓸 수 있는 것이다.

예를 들어, host: ubuntu, container:CentOS 여도 서로 마운트해서 쓰는거 가능하다

권한 수준

root user 와 동일한 수준의 권한 필요하다. docker daemon 실행하기 위해서는 root 사용자 필요하다. TCP 포트가 아닌 Unix 소켓과 데몬이 바인딩 하기 때문이다. (사용자 그룹 docker, 사용자 docker)

이 사용자가 달라지면, 도커 허브에 있는 수많은 이미지를 갖다 쓸때, 수많은 난관에 부딪힌다. 가능하면 디폴트를 맞추는 것이 여러모로 편하다. 아니면 권한수준을 맞춰라. 권한수준이 다르면 바인딩에서 에러가 난다

도커 이미지

서비스를 배포할때, 배포하는 최소 단위가 이미지이다. 한 가지 유형의 이미지는 한가지 유형의 컨테이너를 만들 수 있다.

붕어빵 틀이라고 생각하기

도커이미지는 층층히 쌓여있다. 베이스 이미지는 보통 리눅스의 운영체제. Debian, CentOS 게스트 OS 대신 베이스 이미지가 있다고 생각해도 상관없다. 시스템, 서비스, 라이브러리 들이 층층히 올라가는 것이다. 도커 이미지는 여러층을 가진 파일시스템이다. 레이어파일시스템 각 파일시스템이 곧 이미지이다.

boots

도커 엔진이 사용하는 파일시스템이다. root 파일 시스템 레이어(OS 설치 영역)이다. 우리가 쓰는거 아니다. 도커이미지는 컨테이너를 만들기 위한 읽기전용 파일 시스템이다.

union mount, read-only 파일 시스템을 root 파일 시스템 위에 쌓는 구조, 여러 파일 시스템을 마운트하지만 하나의 파일 시스템처럼 쓸 수 있는 것이다.

copy-on-write CoW

이미지 파일 공유 효율을 높이기 위한 전략이다.

• 실제로 이미지가 굉장히 많은데도 불구하고, 차지하는 공간이 적다
• 이미지를 만들시간도 굳이 복사를 안해도 되니까 적게 된다.
• 근데 분명히 하다보면 이미지 빌드를 하는 경우가 오래 걸리는 경우가있다
• 이게 바로 CoW를 하는 순간이다
• 그래서 이걸 적게 만드는 형태로 이미지를 빌드할 수 있어야함.
• 도커가 레이어를 쪼개는 경우가 이 시점이다

도커 이미지 저장위치

도커 호스트 서버의 파일 시스템에 저장된다. 도커 루트 디렉토리 아래이다.

클라이언트에 저장되는거 절대 아니다. path로 찾아도 안나옴. 도커 서버에서도 찾아도 안나온다.

git도 그 파일이름으로 그대로 들어가지 않는다. 다 해시로 쪼개져서 들어간다.

베이스 이미지

항상 이미지를 만들때는 베이스 이미지부터 시작한다.

처음에는 공식 베이스 이미지는 우분투였는데, 알파인으로 바뀌었다.

• 베이스 이미지가 작으면 내 이미지가 작아지는것이다. 엄청 효율이 높다.
  • 알파인이 아무래도 작다.
• 근데 작다보니까 패키지 매니저도 다르고 제한이 있긴하다.

도커는 이미지의 변경된 부분만 저장한다

변경된 부분만 따로 이미지 만들고 해시 아이디 부여해서 저장한다.

git도 이렇게 저장해서 merge할때 합치고 하는거다.

도커가 레이어드 이미지를 가져가기 때문에, 전체 이미지를 복사하지 않는다. 구분해서 저장하고 가져오기 때문에, 어떻게 보면 git 의 장점을 비슷하게 구현했다.

Image Layers

도커 이미지 계층구조를 확인할 수 있다. 내가 만든 이미지가 몇개의 레이어를 가지고 있는지.

docker history

Dockerfile

도커 이미지를 만들기 위해 설치할 SW, 필요한 설정을 정의할 파일 항상 FROM으로 시작한다, 이게 베이스 이미지를 지정하는 명령어. 여기서도 #가 주석이다. MAINTANER는 누가 이 도커파일을 만들었느냐. RUN은 몇번이던 넣을 수 있음 처음 볼수도 있는 apt-get은,

• 우분투의 패키지 매니저
• RUN apt-get update 는 패키지 매니저를 업데이트함
• RUN apt-get install -y nginx 이건
• -y옵션 넣으면 안물어보고 바로 설치하게 yes 넣는거

도커파일이 이미지 제작 과정을 투명하게 한다. Configuration Management 에서 말하는 프로비저닝 역할을 수행한다.

도커파일 말고도 이미지를 만드는 방법이 있기는 하다. 컨테이너에서 바로 commit하면 되긴함 이 방법은 스냅샷 정도의 용도로만 사용하자.

이미지 검색

dockerhub에서 찾지 말고 바로 CLI에서 찾을 수 있다

• docker search
  

• ex:

  docker search whalesay
  

그리고 pull로 이미지 바로 가져온다

• docker pull docker/whalesay
  

• 이렇게 가져올때, hashid 쭉 리스팅 되는데 이게 레이어들이다.

• docker images
  

  • 현재 다운로드된 이미지들 확인

• docker run docker/whalesay cowsay boo
  

• docker ps -a
  

  • 현재 실행 중인 컨테이너 확인 + 전체 컨테이너 확인 옵션

내 이미지 만들기

내가 풀 해온 이미지가 마음에 안들어, 그럼 그 이미지를 베이스 이미지로 정하고, 내가 도커파일 만들어서 수정해서 사용하는 것이다.

• FROM docker/whalesay:latest
• RUN apt-get -y update && apt-get install -y fortune

• CMD /usr/games/fortune -a

  cowsay

• docker build -t docker-whale
  

• docker run docker-whale
  

도커파일 치트 시트

• FROM
• RUN
  • 리눅스 명령어를 실행한다
• CMD
  • 이미지를 실행하는 명령을 지정한다.
• EXPOSE
• ENV
  • 이 이미지가 80 포트로 서비스를 한다는 것을 알려주는 것이다.
  • 이 80을 어디에 붙일지는 실제로 컨테이너 실행하고 붙여야 한다.
• ADD, COPY
  • ADD 쓰면 도커가 jar파일 자동으로 폴더에 풀어서, 바로 사용할 수 있게함
  • 그냥 복사만 하려면 COPY 쓰자
• ENTRYPOINT
• VOLUME
• USER
• WORKDIR
• ONBUILD
  • 이미지를 만든 후, 컨테이너를 실행할 때 실행되는 명령어를 지정한다.

이미지 삭제

• docker history docker-whale:latest
  

  • 이미지 레이어 확인

• docker rmi docker-whale:latest
  

  • 이미지 삭제
  • 도커 컨테이너 지우는건 rm
  • 이미지 참조하는 컨테이너가 있으면 삭제가 안된다. 컨테이너 부터 지워야 한다.

모든 명령어들이 파이프라인으로 명시될 수 있다. 이를 사용하면 한번에 이미지를 삭제하는 등의 활용이 가능하다!

도커 이미지 크기를 줄이는 방법

처음에는 작은데 근데 깔다보면 금방 1기가 2기가 된다 처음 습관을 잘 들이는게 좋다. 처음부터 이미지를 가볍게 만드는 습관을 가지기.

이미지를 만들면 이 이미지를 베이스로 또 만들고, 그걸로 또 만들고 그러게 된다. 이미지 크기를 줄이는 방법은 크게 4가지이다.

1. 가벼운 베이스 이미지를 사용한다.
   1. 알파인으로 하면 또 안되는 경우가 있다.
   2. 그럴때는 고생하지말고 우분투 쓰고, 나중에 다시 내리던지 하자.
2. Dockerfile 명령을 체인으로 사용한다.
   1. RUN 두줄로 쓰지말고 && 이용해서 체인으로 쓴다
   2. 체인으로 쓰지 않으면 레이어 하나가 더 만들어진다.
   3. 무조건 다 체인으로 엮는건 아니다.
3. 빌드 도구를 설치하지 않는다.
   1. 빌드는 별도로 따로 해서 결과를 넣으면 된다.
   2. 런타임만 넣어라.
4. 패키지 관리자를 정리한다.

지금은 중요해보이지 않겠지만, 이미지 조금만 만들어보면 용량 금방 늘어나고, 한참 걸리고하면 생각난다 여러가지 많이 나오는데, 그냥 이 4가지만 기억해라

Top Technologies running on Docker

1. REGISTRY
2. NGINX
3. REDIS
4. ELASTICSEARCH
5. MYSQL
6. …

이 순서대로 도커라이징하면 된다. 남들이 많이 하니까

Sysdig 2017 survey

한 호스트에 10개씩 띄우는게 평균이다. = 한 호스트 컴퓨터 한대에 10개 컨테이너를 띄운다.

• 관리도구를 많이 쓰는게 쿠버네티스이다.
• Key-value 스토어들은 대부분 컨테이너로 사용한다.
• Registry 없이 도커를 쓸 수 없다.

도커를 얼마나 잘 사용하느냐는 Registry가 있느냐 없느냐 이기도 하다.

도커 컨테이너는 어플리케이션이다. 서버가 아니다

이미지를 실행한 상태이고, 읽기 쓰기가 가능한 파일 시스템이다. 실행된 독립 어플리케이션이다.

어플리케이션 이상하면 내리고 다시 올리고 한다. 반면에 서버관리하는건 ssh로 들어가서 고치고 한다. 도커 컨테이너는 그냥 하나의 프로세스다. 컨테이너는 가상서버가 아니다.

실습 2

일단 한다. 먼저 띄워보고, 안되면 ps 해보고, docker logs <img-ID>로 본다

• docker run -e
  

  • 환경변수 설정하는 옵션

• docker run --name mydb
  

  • 컨테이너의 이름 설정하는 옵션

• docker run -d
  

  • detach 모드로, 백그라운드에서 계속 돌아가게 실행한다.
  • 그냥 실행하면 루트 프로세스가 터미널이라서 바로 꺼진다.
  • = 컨테이너를 데몬으로 실행한다.

• docker rm mydb
  

• docker run --name myweb -d -p 80:80 nginx
  

  • p옵션은 포트를 외부에 오픈한다.
  • -P 옵션은 포트 알아서 설정한다. 당연히 ps로 볼 수 있다.

ps에서 보이게 되는 0.0.0.0은 anyware이다. 모든 IP 가진 서버에서 접근할 수 있다는 뜻이다.

-p 80:80 하기 전까지는, 호스트 서버 바깥으로는 서비스를 하지 않는 것이다.

• docker run -v /home/docker/nginx.conf:/etc/nginx/nginx.conf ~
  

• -v 옵션이 볼륨 옵션이다.

어느 옵션이나 호스트:컨테이너, 왼쪽이 호스트, 오른쪽이 컨테이너이다.

/home/docker/nginx.conf은, 리눅스에서 home/사용자(도커)/ 밑에 바로 파일이 있는 것이다.

/etc/nginx/nginx.conf와 같이, 바인딩할 위치는 어떻게 알 수 있나? 도커파일에 보면 알수있다. 그 이미지의 도커파일보고 찾으면 된다.

• docker logs myweb
  

• -f옵션은 로그를 연속해서 보여준다.

• docker inspect myweb
  

• nginx 컨테이너 상세 내용을 확인한다.

• docker ps -s
  

• nginx 컨테이너 크기를 확인한다.

• docker run -d -p 8080:8080 -p 5000:5000 --name myjenkins jenkins
  

• 이렇게 포트 여러개 연달아 지정해줄 수 있다.

• docker run ~~~ --link myjenkins:jenkins -d nginx
  

• –link 옵션으로 컨테이너 간 링크해줄 수 있다.
• 링크해주지 않으면 컨테이너는 격리된 애플리케이션이므로 서로가 서로의 존재를 알 수 없다!

File Sharing 어떻게 하는지 다시 찾아서 실습 따라해두기

듣게 된 용어들, 정리할 용어들

• 프로비저닝
• nginx
• 패키징
• 배포
• 리눅스 파이프라인
• jenkins