Watch & Learn

< 도커 기본 명령어 차례 >

● 시스템 명령

docker version

docker system info

docker system df

docker system prune

docker login

locker logout

●이미지 관리 명령

docker pull

docker image ls

docker images

docker image inspect

docker image tag

docker push

docker search

docker image rm

docker image prune

docker container commit

● 컨테이너 실행 및 조작 관련 명령

docker container create

docker container run

docker container attach

docker container exec

● 컨테이너 정보 확인 명령

docker container ps

docker container stats

docker container inspect

docker container top

docker container port

docker container diff

docker container logs

docker container ls

● 컨테이너 관리 명령

docker container stop

docker container start

docker container kill

docker container restart

docker container prune

docker container pause

docker container unpause

docker container rename

docker container cp

● 컨테이너/이미지 백업 명령

docker container export

docker container import

docker image save

docker image load

● 네트워크 명령

docker network ls

docker network create

docker network connect

docker network disconnect

docker networkinspect

docker network rm

brctl show

● 볼륨 명령 
docker volume create 
docker volume ls 
docker volume rm 
docker volume prune 
docker volume inspect

docker version

설명

- 설치한 도커의 버전 정보 확인

- root로 실행해야 함

- 도커 데몬이 내려간 경우, Server: Docker Engine 부분이 제대로 나오지 않음.

- Client 엔진은 도커 명령어를 쓰는 환경 같은 것이며, Server가 실제 도커 데몬이다.

- Version: 19.03.5 은 연월일과 동일하다. (19년 3월 5일)

- Go version : go라는 언어로 도커를 만들었음.

옵션

- 미확인

예시

docker system info

설명

- 도커 실행환경 정보 확인

- 아래에 warning 등의 메시지가 나올 수 있는데, 확인해서 해결해 줘야 함.

옵션

- 미확인

예시

Containers: 0 - 컨테이너 수
Images: 1 - 이미지 수
Server Version: 19.03.5 - 도커 버전
Storage Driver: overlay2 - 스토리지 드라이버 종류
Volume: local - 로컬 파일시스템 /루트를 사용한다는 것
Network: bridge host ipvlan macvlan null overlay - 여러종류의 네트워크들
Swarm: inactive - 도커 스웜은 안쓰고 있음
OSType: linux - 운영체제 종류
Architecture: x86_64 - 아키텍쳐
CPUs: 8 - 호스트OS의 코어 수
Total Memory: 7.625GiB - 호스트OS의 메모리 양

docker system df

설명

- 도커 디스크 사용 상태 확인

옵션

-v : 이미지별, 컨테이너별, 볼륨별 정보 등을 상세히 확인

예시

docker system prune

설명

- 사용하지 않는 이미지, 컨테이너, 볼륨, 네트워크 등을 일괄 삭제한다.

옵션

예시

docker login

설명

- 도커 허브 레포지토리를 사용하기 위해 로그인이 필요하다.

- docker login [옵션] [서버]

- 옵션을 지정하지 않으면 사용자명과 비밀번호를 물어본다.

- 서버명을 지정하지 않으면 도커 허브에 자동으로 액세스된다.

옵션

예시

docker logout

설명

- 도커 허브 로그인한 것을 로그아웃한다.

- docker logout [옵션] [서버]

- 서버명을 지정하지 않으면 도커 허브에 자동으로 액세스된다.

옵션

예시

여기서는 CentOS7, Docker CE 19.03 버전 기준으로 설명합니다.

https://docs.docker.com/engine/install/centos/

그 외 다른 버전은 해당 Docker Document에서 확인할 수 있습니다.

1. Repository 준비

- yum-config-manager를 사용하려면 yum-utils를 설치해야 한다.

- yum-config-manager 명령으로 Docker CE를 보유한 Repository를 서버에 등록한다.

$ sudo yum install -y yum-utils

$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

2. Docker Engine 설치

$ sudo yum install docker-ce docker-ce-cli containerd.io

- 아래와 같이 설치할지 물어본다.

- 위에 명시한 패키지 외에 다른 패키지들도 설치되는데, 위에 명시한 패키지에 Dependency가 있는 패키지이기 때문이다.

- GPG key 관련해서 맞는지 물어보는데, Docker Document 사이트에서 명시한 아래 내용과 일치하는지 확인한다.

- 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35

- 일치한다면, 진행한다.

3. Docker Engine 기동

- Docker를 기동하며, 리부팅해도 자동으로 Docker가 기동되게 한다.

# systemctl start docker
# systemctl enable docker

4. 작동 테스트

- 아래 구문으로 결과가 잘 나오는지 확인한다.

- hello-world 라는 이미지를 구동하며, 이 이미지는 도커 엔진 설치를 테스트하기 위해 도커에서 제공되는 이미지이다.

# docker run hello-world

- 위와 같이 나오면 제대로 잘 설치된 것이다.

- 아래 명령어로 도커 상태를 확인한다.

# docker version

5. 도커 전용 유저 생성 및 권한 전달

- 도커를 사용할 계정에게 docker 에 대한 권한을 줘서, 해당 유저가 sudo를 쓰지 않고 사용하도록 하기

# useradd dockeradmin (원하는 이름 자유롭게)
# usermod -aG docker dockeradmin
# systemctl restart docker

- 아래 명령 실행 후, dockeradmin 계정으로 로그인하면 도커 명령어를 자유롭게 쓸 수 있다.

도커 레지스트리란?

도커 이미지를 사용자들끼리 공유할 수 있도록 하는 플랫폼이다. 이러한 레지스트리는 크게 2가지 종류, Public 레지스트리, Private 레지스트리로 나뉜다.  Public 레지스트리는 도커의 공식 레지스트리인 도커 허브와 기타 다른 벤더 업체들의 레지스트리가 존재한다.  Private 레지스트리는 사용자가 직접 레지스트리를 구축해서 자신의 내부망에서 사용(팀원이나 회사에서 공유)하거나 외부망과 연결해서 사용할수도 있다. 

도커허브

도커 허브는 도커의 Official 이미지 공유 사이트이다. 도커 허브에서 이러한 이미지를 자신의 도커로 다운받을 수 있고, 자신이 만든 이미지를 올릴 수도 있다. 도커허브에서는 대부분의 오픈소스 소프트웨어와 상용 소프트웨어는 제작사들이 Official하게 자신의 소프트웨어를 이미지로 만들어 공유하고 있다. (물론 라이센스는 주의해야 한다) 예를들어 오라클 이미지는 라이센스를 구매해야 하지만, 오라클XE 버전이 있는 이미지가 있다. 이러한 이미지는 사용할 수 있다.

우리가 상상하는 모든 서비스는 다 도커 허브에 이미지화 되어 있다고 생각하면 편하다. 또한 도커 엔진이 올라간 운영체제와 상관없이, 모든 이미지가 서로 호환되고 컨테이너화 가능하다.

도커허브는 github, bitbucket같은 소스코드 관리 툴과 연계가 가능하다. 예를들어 github상에서 dockerfile(도커 이미지를 만드는 스크립트)를 관리하고, 거기서 도커 이미지를 자동으로 생성하여 도커 허브에 업로드하는 등 여러가지 방법으로 사용 가능하다.

도커허브의 이미지 변조 방지 및 취약성 검사 기능

도커허브 또는 공개 레지스트리는 아무래도 오픈되어 있으므로 변조하여 공격을 하거나 취약점을 만들어 내는 위험한 이미지가 있을수도 있다. 보통으로 사람들이 자주 사용하는 official 한 이미지를 잘못 다운받게 하여 공격하는 방식이 많이 사용된다. 이러한 위험을 막기 위해 도커 이미지를 검증 및 확인하는 기능들이 도커 허브에 포함되어 있다.

docker container trust 
도커 이미지 제공자를 검증하는 기능. 이미지 제공자는 도커 레지스트리에 이미지를 송신하기 전에, 로컬 환경에서 비밀키를 사용하여 이미지에 서명을 한다. 그 후 그 이미지를 이용할 때는 이미지 제공자의 공개키를 사용하여 실행하려고 하는 이미지가 정말 제공자가 작성한건지 확인한다. 만일 이미지가 변조된 경우 이미지를 무효로 만든다.

docer security scanning
도커 이미지를 검사하여 이미 알려진 보안상의 취약성이 없다는 것을 확인하여 이미지의 안전성을 확인한다.

도커허브 사용하기

1. 접속하기

- https://hub.docker.com/ 에 접속한다.

2. 계정을 만들고 로그인한다.

- 로그인이 되면 다음과 같이 자신의 화면이 나온다. 여기서 자신이 올린 이미지 정보를 확인 및 설정할 수 있다.

3. 원하는 어플리케이션의 이미지를 검색한다.

- 화면 상단 돋보기로 원하는 이미지를 검색할 수 있다.

- 검색된 이미지에서 official image는 이전에 언급한대로 해당 어플리케이션 제조사가 공식적으로 만든 이미지이다.

- 보통 이러한 공식 이미지를 바탕으로 자신의 설정에 맞게 변경하여 사용하게 된다.

- Stars 는 SNS의 좋아요 랑 비슷하다고 생각하면 되며, 일반적으로 Stars가 많으면 신뢰도가 높다.

4. 해당 이미지의 상세사항을 살펴본다.

- 영어를 몰라도, 천천히 읽어보면 어느정도 이해할 수 있다.

- mariadb가 무엇인지 개요, 실행하는 법, 다른 어플리케이션과 연결하는 법, 라이센스, 주의사항, 메뉴얼 등 유용한 자료들이 포함되어 있다.

- 이러한 어플리케이션을 모르는 상태에서는 메뉴얼 등 자료들을 봐도 아무런 의미가 없고 이해도 못할 것이다. 따라서 도커를 제대로 배우기 위해서는 어플리케이션도 잘 알아야 한다.

- 도커허브에 있는 이미지는 "이미지명:태그" 의 형식을 취한다.

- 오른쪽에 검은바탕의 글자로 docker pull mariadb 라는 cli명령으로 도커가 설치된 호스트에서 이미지를 다운받을 수 있다. 여기서는 태그를 넣지 않았는데, 태그를 넣지 않으면 latest 태그를 사용한다.

# 태그란?

- 태그는 이미지의 버전, 속성 등을 의미한다.

- 태그 탭을 들어가면, latest, bionic, beta, 10.5.1등이 있다.

- latest는 항상 그 시점의 최신 버전을 의미하며, 10.5.1 등은 특정 버전을 의미한다.

- 즉, 버전 별 이미지를 받아 각기 다른 버전의 동일한 프로그램을 각각 동시에 띄울수도 있다.

- 태그 지정하여 명령어를 입력하는 경우, docker pull mariadb:latest 이렇게 : 이 붙은 형식으로 입력한다.

5. 해당 이미지의 환경변수 값을 찾아본다.

- 해당 이미지를 사용하기 위해서는 정확한 환경변수를 사용할 줄 알아야 한다.

- 이러한 환경변수는 다른 블로그나 구글링보다는 offcial한 도커 허브에서 찾는것이 가장 정확하고 신뢰도가 높다.

- 대부분의 도커 이미지는 이러한 환경변수를 가지고 있고 이미지를 컨테이너화 (실행) 하기 전에 이러한 환경변수를 원하는 세팅에 맞게 입력해주어야 한다.

- 아래 환경변수는 도커 이미지로 실행할 mysql의 유저정보, 비밀번호 정보, 데이터베이스 명 등을 변수로서 설정하는 방법을 알려준다.

이렇게 도커 허브를 통해 이미지 다운로드 및 개요, 설정정보 등을 확인할 수 있다. 이후 도커 엔진이 설치된 호스트의 cli 화면에서 도커 허브에 로그인을 한 후 이미지 다운 및 업로드가 가능하다. (즉, 도커허브를 쓰려면 호스트가 인터넷에 연결되어야 한다)

도커 이미지란?

도커는 대부분의 소프트웨어를 "이미지" 라는 개념으로 만들 수 있다. "이미지"란, 어플리케이션 실행에 필요한 프로그램 본체+라이브러리+관련 미들웨어(필요한경우)+OS/네트워크 설정값 등을 모아서 하나의 객체로 만든 것이다.  파일시스템적으로 "이미지"는, 애플리케이션의 실행에 필요한 파일들이 저장된 디렉토리를 모은 것이다.

도커에서 이러한 이미지를 기반으로, 실행환경에서 움직이는 컨테이너를 만들게 된다. 하나의 이미지에 여러 어플리케이션을 합칠 수도 있지만, 도커의 기본 이념은 "한 컨테이너에 한 어플리케이션" 이다.

단순히 운영체제(CentOS, Ubuntu) 의 이미지가 있을수도 있고, mysql이나 apache 이미지가 있을수도 있고, wordpress 같은 이미지가 있을수도 있다.  이미지는 미들웨어, 운영체제, 3rd 소프트웨어, 상용 소프트웨어, 오픈소스 소프트웨어 모두 다 존재한다.

이미지 실행 : "컨테이너화"

이미지를 도커에서 실행하면, 그 이미지를 기반으로 컨테이너가 생성되고 가동된다.  이미지는 컨테이너의 베이스일 뿐이라 한 이미지로 여러 개의 컨테이너를 만들 수 있다. 실행된 컨테이너를 가지고 서비스를 띄우고 운영하는 것이다. 예를 들어, mysql 이미지와 httpd 이미지를 다운받은 후, mysql 이미지와 httpd 이미지를 각각 컨테이너로 만들어서 서로 연동하여 웹서비스를 만들 수 있다.

다른 가상화 기술로 서버 기능을 실행시키려면, os의 실행부터 시작하므로 느릴 수 밖에 없지만, 도커는 이미 움직이고 있는 os 상에서 프로세스를 실행시키는것과 거의 똑같은 속도로 빠르게 실행 가능하다.

생성된 컨테이너의 개념

컨테이너는 OS 파일시스템이 있지만 커널이 없다. 호스트OS(도커가 설치된 장비)의 커널을 공유한다. 따라서 가상머신보다 훨씬 가볍다. 이 컨테이너에는 프로세스가 있으며, 해당 프로세스는 컨테이너 내에 "격리되어 있다" 라고 표현된다. 즉 호스트OS와는 분리되어 있다는 것.

컨테이너 안에서 작동하는 프로세스를 하나의 그룹으로 관리하고, 그룹마다 각각 파일시스템이나 호스트명, 네트워크 등을 할당하고 있다. 그룹이 다르면 프로세스나 파일에 대한 액세스를 할 수 없다. 이러한 구조를 사용하여 컨테이너를 독립된 공간으로서 관리하고 있다. 이를 위해 linux 커널 기능인 namespace, cgroups 등의 기술이 사용된다.

호스트OS 입장에서는 컨테이너는 프로세스로 보이며, ps 명령으로 확인할 수 있다. 컨테이너는 호스트OS와 통신을 하며, 그 통신은 네트워크로 이루어진다.  단순하게 그룹으로 관리되는 것이므로, 컨테이너와 호스트OS는 별개가 아니다. 컨테이너 내부와 호스트OS에서 둘다 uname -r을 치면, 호스트와 동일한 커널이 나온다. 호스트와 컨테이너의 OS 종류,버전은 상관없다.

# 참고 : 호스트OS=Redhat / 컨테이너=Ubuntu 버전 비교
root@457b2eb299ee:/# cat /etc/lsb-release (컨테이너457b2eb299ee의 운영체제 정보 확인)
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
root@457b2eb299ee:/# uname -r (컨테이너457b2eb299ee의 커널버전 확인)
3.10.0-957.el7.x86_64
[root@CENTOS7-docker ~]# cat /etc/redhat-release (호스트OS의 운영체제 정보 확인)
CentOS Linux release 7.6.1810 (Core)
[root@CENTOS7-docker~]# uname -r (호스트OS의 커널버전 확인)
3.10.0-957.el7.x86_64 (동일하다)

도커의 이미지 데이터 저장/관리 방식 : CoW (Copy on Write)

데이터를 복사할 때 새로운 빈 영역을 확보하고 거기에 복사하는 것이 일반적인 방식이지만, 복사될 데이터에 변경이 없다면 굳이 복사를 해서 용량을 낭비할 필요가 없다. 그래서 복사를 요구받아도 바로 복사하지 않고, 원래 데이터를 그대로 참조시키고, 원본 또는 사본에 수정이 가해진 시점에 비로소 새로운 빈 영역을 확보하고 데이터를 복사하는 방식이 있다.

이것을 Copy on Write 방식이라고 하며, 도커에서는 이 방식을 사용하여 이미지를 저장하고 관리한다. 이미지의 여러 부분을 분할된 "레이어"를 합쳐 하나의 이미지로 만드는 개념이다. 예를 들어 apache 이미지는 아래 그림과 같이 여러개의 레이어로 이루어져 있다.

예시처럼, 이미지는 apache를 실행할 운영체제 이미지 레이어, 운영체제 업데이트 레이어, 아파치 프로그램 레이어, custom file 부분엔 아파치 값 설정이 레이어가 될 수도 있고, 또 추가적으로 레이어를 올릴 수도 있다. 그리고 마지막 부분은 read/write가 가능한 레이어로 마운트하여 사용자가 추가/수정을 할 수 있도록 하는 것이다. 각각의 이미지 레이어는 51136EA3C5A 같은 코드로 관리된다.

즉, 도커 이미지는 여러개의 레이어가 겹쳐저 있고, 구성 변경이 있으면 변경이 있는 부분도 레이어로 만들어서 관리하게 된다. 이 방법은 매우 혁신적이며 2가지 큰 장점을 가지고 있다. 

공간 활용.하나의 이미지 레이어를 여러 이미지에 사용할 수 있다. 즉, 우분투 베이스 이미지 레이어 부분을 위 예시의 apache가 아닌 elastic search 라는 프로그램 이미지에서도 우분투 베이스 이미지를 쓸 수 있으므로  한 이미지 레이어가 여러 이미지에 적용되는 것이다. 따라서 이미지의 사본을 만들지 않아 공간을 아주 많이 절약할 수 있다.

속도 향상 및 효과적인 자원 사용. 도커 이미지를 만들(build) 때,  raw 데이터를 가지고 빌드하는 게 아니라, 빌드할 내용 중 원래 만들어 놓은 이미지 레이어가 있다면 빌드하지 않고 그 레이어를 가져다 쓰므로 속도도 빠르고 자원도 사용하지 않는다.

이러한 방식을 쓰는 파일시스템을 Union Filesystem 이라고 하며, 여러가지 파일시스템 종류가 있다. AUFS, OverlayFS, loop-lvm, direct-lvm, zfs 등이 있다.

가상머신 VS 컨테이너

우리가 기본적으로 아는 가상머신은, 하나의 호스트OS 위에 가상머신 (가상 하드웨어) 를 만들고, 거기에 운영체제를 설치하고 사용하는 것이다. 즉 각 가상머신머다 커널이 다르다.

컨테이너 기술은, 가상머신과 다르게 따로 가상 하드웨어를 만들지 않는다. (따라서 BIOS에서 설정하는 CPU 가상화 설정도 필요 없다!) 아래와 같이 하나의 호스트OS 위에 컨테이너 엔진을 설치하고, 그 위에 컨테이너를 만드는 것이다.

간단하게 말하면 호스트OS(물리적 서버) 위에 논리적인 구획(컨테이너) 를 만들고 어플리케이션을 작동하기 위해 필요한 라이브러리나 애플리케이션을 하나로 모아 컨테이너 안에 집어넣어 마치 컨테이너 하나가 별도의 서버인 것처럼 사용할 수 있게 하는 것이다. 

여기서 컨테이너는, 마치 가상머신처럼 운영체제도 있는것처럼 보이고, 원하는 프로그램도 깔려있고, IP도 있다. 가상머신으로 착각할 만 하다. 하나의 호스트OS에 여러개의 컨테이너를 올릴 수 있고, 해당 호스트OS의 자원을 나눠서 사용하게 된다. 즉 컨테이너 자체에는 OS가 없고, 호스트OS의 커널을 컨테이너가 공유받는다.

가상머신과 컨테이너는 사용자가 봤을 때 기능상으로는 비슷하지만, 각 기술들은 서로 지향하는 바가 다르다.

- 컨테이너 기술은 애플리케이션의 실행환경을 모아서 이식성을 높이고 확장성이 좋은 환경에서 작동하는것을 지향한다.
- 가상화 기술은 서로 다른 환경을 어떻게 효율적으로 에뮬레이트할지를 지향한다.

각 기술마다 장단점이 있고 사용하는 적절한 용도가 있지만, 단순히 성능적으로 봤을 때는 가상화보다 컨테이너가 overhead(어떤 처리를 위해 추가되는 간접적인 처리시간) 가 적어 가볍고 고속으로 작동한다.

그래서, 도커란 무엇인가?

도커는 애플리케이션 실행에 필요한 환경을 이미지로써 만들어 모아두고, 이미지를 사용하여 다양한 환경에서 애플리케이션 실행환경을 구축/운용하는 컨테이너를 만들어 사용하는 오픈소스 플랫폼이다. 2013년 3월 오픈소스 프로젝트로 시작되었고 어떤제품보다도 파급력이 컸다.

컨테이너는 생각보다 오래된 기술이다. FreeBSD 라는 오픈소스 유닉스의 FreeBSD JAIL, 선마이크로시스템즈(현 오라클 합병됨)의 상용 유닉스 Solaris의 Containers (Zone), 그리고 리눅스에서는 리눅스 컨테이너 (Linux Container ; LXC) 라는 기술로써 컨테이너 기술이 있었다. 또한 구글은 직접 컨테이너 기술을 만들어 사용했다. (lmctfy ; Let Me Contain That For You)

도커는 리눅스 커널에 포함된 LXC 기능을 사용하여 컨테이너 기술을 사용한다. LXC가 제대로 사용되지 못한 이유는 사용 및 배우는 것이 복잡하고 어려웠기 때문. (LXC의 cgroups와 namespace 등이 사용하기 쉽지 않았다.) 도커를 통해 애플리케이션이 LXC를 사용하고, 사용자는 쉬운 도커 명령어를 사용하여 컨테이너 기술을 쓸 수 있도록 했다.

도커의 장점

1. 빠르고 편한 어플리케이션 설치
- 우분투는 apt-get을 사용하고, 레드햇은 yum install 을 사용하는 등 os 별로 설치 명령이 모두 다르다.
- 도커는 항상 동일한 명령을 사용하며 훨씬 빠르다.

2. 관리의 용이함
- 사내 문서 등으로 서버 변동 내역을 기록하는 것은 시간과 인력을 많이 사용하는 일이다.
- 도커는 이러한 기록을 코드화하여 일원화하므로 따로 관리를 할 필요가 없다.
- 또한 버전별로 컨테이너를 만들수 있으므로 버전관리 및 호환성 유지가 용이하다.
- 담당자가 세팅한 설정을 스크립트화 하여 자동화할 수 있다.

3. 효율적이며 자유로움
- 동일한 컨테이너 여러대를 한번에 배포할 수 있다.
- 필요한 프로그램들을 도커허브에서 이미지의 형태로 제공받을 수 있다. (github과 유사한 방식, open share)
- 해당 이미지를 받고 내가 원하는대로 수정 및 설정하여 다시 또 배포할 수 있다.

- 서버의 견고함을 보장하면서도 동적으로 바꿀 수 있는 유연함을 가진다.

- 수평적 확장(Scale out) 이 자유롭다.

# 참고 : Scale out과 Scale up

4. 여러가지 변경점이나 예외사항들을 배제하기 쉬움
- 도커는 통일된 환경에서 동일한 이미지를 가지고 어플리케이션을 가동한다.
- 따라서 몇년동안 운영한 동일한 서비스를 중간에 더 추가하거나, 다른 하드웨어끼리의 차이 등에 있어서 생기는 문제 자체가 발생하지 않는다.

5. 높은 이식성
- 환경에 상관없이 컨테이너를 통해 애플리케이션을 동일한 환경에서 가동 가능.
- 온프레미스<->클라우드, 클라우드<->클라우드 등의 마이그레이션을 쉽고 빠르게 수행할 수 있다. 예를들어, 어떤 퍼블릭 클라우드 서비스의 비용이 저렴해지면 그쪽으로 쉽게 넘어갈 수 있다.

6. 개발 환경에 최적화된 기능
- 환경에 따른 차이가 없어 개발,테스트,서비스 환경을 신경쓰지 않고 프로젝트 관리가 가능하다.
- 개발을 위한 인프라 환경설정, OS 환경설정, 미들웨어, 라이브러리 설정 등을 빠르고 편하게 할 수 있다.

도커 사용을 위한 버전과 플랫폼

* 도커 CE가 지원하는 플랫폼
- 서버OS용 : 우분투, 데비안, CentOS, 페도라, 레드햇 등
- 퍼블릭클라우드용 : azure, AWS
- 클라이언트OS용 : 윈10, 맥OS 

- 기타 : Synology NAS 등

# 참고 : x86이 아닌 다른 아키텍쳐에서 사용

IOT 디바이스같은 arm 아키텍쳐에서 작동하는 디바이스에서는 Docker Community Edition (ARM)을 사용할 수 있다. 우분투와 데비안을 지원한다. https://docs.docker.com/install 참고할 것.

* 도커 에디션

- 무료버전 (CE) : Community Edition이다. 로컬사용 및 상용 지원이 불필요한 환경에서 애플리케이션을 실행할 때 적합하다.
- 유료버전 (EE) : Enterprise Edition 이다.  상용 이용에 적합한 버전. EE는 BASIC, STANDARD, ADVANCED 3종류가 있다.
    - BASIC : 도커사의 지원 및 도커 스토어에서 인증이 끝난 컨테이너, 인증이 완료된 플러그인을 제공한다.
    - STANDARD : 베이직 내용에 더해, LDAP, Active Directory와 통합 가능한 도커 데이터센터를 이용할 수 있음.
    - ADVANCED : 보안 기능을 추가로 제공한다.

* 도커의 Release history

- 에디션에 따라 정기적으로 릴리즈가 있다.
- 버전 번호는 연도2자리, 월2자리로 나타난다. 2017년 3월에 릴리즈된 버전은 17.03이 된다.
- 도커CE는 매월 보안 지원과 버그 수정 지원인 EDGE의 릴리즈, 4분기별로 안정판인 STABLE이 릴리즈된다.
- 도커EE도 CE의 STABLE과 똑같은 시기에 릴리즈된다.

도커의 구성요소

도커는 다음과 같은 컴포넌트로 구성되어 있고, 이러한 컴포턴트들이 조합하여 어플리케이션 실행 환경을 구축한다. 

* Docker engine
- 도커의 핵심 기능. 도커 이미지를 생성, 컨테이너를 기동한다.
- docker 명령과 dockerfile 이미지 생성도 수행한다.

* Docker Registry (이미지 공개 및 공유)
- 컨테이너의 바탕이 되는 도커 이미지를 공개 및 공유하기 위한 레지스트리 기능
- 도커의 공식 레지스트리인 도커허브도 이 Docker registry를 사용한다.

* Docker Compose (여러 컨테이너 통합 관리)
여러 개의 컨테이너 구성 정보를 코드로 정의하고, 명령을 실행함으로써 애플리케이션의 실행환경을 구성하는 컨테이너들을 일원관리하는 툴

* Docker Machine ( 도커 실행 환경 구축)
- 로컬 호스트용인 버추얼박스등을 비롯하여 AWS EC2나 MS AZURE와 같은 클라우드 환경에 Docker 실행 환경을 명령으로 자동 생성하기 위한 툴.

* Docker Swarm (클러스터 관리)
- 여러 도커 호스트를 클러스터화하는 툴
- 클러스터를관리하거나 api를 제공하는 역할은 Manager 가 수행하며, 도커 컨테이너를 실행하는 역할은 node가 담당한다.
- 쿠버네티스와 비슷하지만, 쿠버네티스는 복잡하고 명령어도 많음. 간단하게 사용할 때는 Docker Swarm을 사용할 수 있다.

클라우드 컴퓨팅이란?

- 내 장치가 아닌 다른 제3의 공간인 클라우드에서 원하는 기능을 제공받는 것.
- 제3의 공간은 중앙집중화된 대형 데이터센터+관리 소프트웨어로 이루어져 있다.
- 이러한 기능은 IaaS, PaaS, SaaS 등이 있다.
- 이러한 기능들을 구매하거나 소유하지 않고, 필요한 만큼 사용료를 주고 쓰는 것.

WEB+DB 서버를 구축하는데 클라우드가 아닌, 직접 모두 구매해서 사용한다면?

이렇게 자체적으로 직접 하드웨어와 소프트웨어를 구축하는 방식을 온프레미스(On-premise 라고 한다. 클라우드가 아니므로, 모든 인프라 요소 (서버,스토리지,네트워크장비,케이블,공간,보안,공조,운영체제,미들웨어,유지보수) 등을 직접 해야한다. 이러한 내용을 나열해본다면 다음과 같을 것이다.

먼저 계획을 해야한다. 시스템 구축의 범위, 인프라에서 요구하는 사항들 정리, 예산 책정, 프로젝트 구체화, 기존 시스템 연계성 확인등을 수행하고, 이후 인프라를 설계한다. 인프라 아키텍쳐, 네트워크 토폴로지 설계, 장비(서버,스토리지,네트워크장치,케이블 등) 선택 및 조달, 운영체제 및 미들웨어 선택, 데이터센터 대여 또는 회사 내 서버실 구축(공조,보안,쿨링,소화설비등), 시스템 운용 설계 등을 수행한다. 이제 실제로 인프라를 구축한다. 네트워크 부설, 서버 설치, 운영체제 설치, 미들웨어 설치, 애플리케이션과 라이브러리 등의 환경 구축, 정상화 테스트 등. 모두 완료되면 이후에는 자원 모니터링, 데이터 정기 백업 및 하드웨어 유지보수(펌웨어 및 드라이버 업데이트), 운영체제 및 소프트웨어 유지보수(버전 업그레이드), 시스템 장애 대응, 사용자 문제 서포트 (헬프데스크) 등등등등 뭔가 할게 엄청나게 많다.

클라우드의 기능상 구분

IaaS (Infrsatructure as a Service)

– CPU, Memory, Storage, Network, IP, 등의 인프라 자원을 제공 
– 예시 : 상용 IaaS : AWS (AWS S3 스토리지), GCP, Azure 등 / 오픈소스 IaaS : 오픈스택 등 (오픈스택 SWIFT 스토리지)

SaaS (Software as A Service)

– 클라우드로 별도의 전용 소프트웨어를 제공. 사용자는 어플리케이션을 자신의 장비에 깔지 않아도 사용 가능. 즉 장비 사양을 무시할 수 있다. 클라우드 환경에서 동작하는 모든 어플리케이션을 SaaS라고 할 수 있다. 
– 예시 : 오피스365, 구글독스, 네이버 클라우드, 레드햇교육서버제공, 드랍박스나 원드라이브 , ERP 프로그램, 엔비디아 게임서비스 등

PaaS (Platform as a Service)

– 서비스를 개발할 수 있는 안정적인 환경과 그 환경을 이용하는 응용프로그램을 개발할 수 있는 API까지 제공. SaaS 개념을 개발 플랫폼으로 확장한 것으로 이해할 수 있다.
– 웹사이트를 구축하기 위해서 개발자는 DB서버와 웹서버가 있어야 한다. 이런것들은 개발자가 하는 게 아닌 인프라 엔지니어가 수행하는데, 그럴 필요 없이 개발자가 클라우드로 제공받는 것이다.
– 예시 : 클라우드에 올라간 대부분의 개발 소프트웨어/미들웨어. apache, DB 등. 또한 참조하는 API 서비스도 PaaS의 일부이다.

# 참고 : 미들웨어 종류
– 웹서버 : nginx, apache, apache tomkat 등
– 데이터 메시지 서버 : RabbitMQ, PostgreSQL, redis, mongoDB, mysql 등
– 웹 프레임워크 : django, mojollcious, spring, catalyst, Flask, Pyramid 등
– 개발 언어 : ActivePerl, java, ruby, nodejs, scala, php, python 등

# 참고 : PaaS 와 SaaS 구분
– PaaS와 SaaS의 개념은 어떻게 보면 비슷해 보인다. 
– 이러한 차이는 개발자(운영자)로서 또는 일반 사용자로서 클라우드에 소프트웨어를 사용하는지의 차이이다.

클라우드의 범위상 구분 

Public (공용 클라우드)
– 인터넷을 통해 클라우드 제공업체를 통해 클라우드 서비스를 제공받음. (AWS, Azure, GCP 등)

# 참고 : 멀티클라우드
– 공용 클라우드 업체가 많은데 각 업체의 강점을 적재적소에 활용하여 여러 공용 클라우드를 사용하는 것 (예를들어 기간 시스템은 AWS 가 적합하고 머신러닝은 GCP가 더 적합하다)

private (사설 클라우드)
– 외부서비스 목적이 아닌 사내에서 온프레미스를 구축하고 그것을 클라우드화한다. 보안을 확보하기 쉽고 독자적인 기능과 서비스를 추가하기 좋다.
– 직접 구축하므로 오픈소스를 사용하는 경우가 많다. 오픈스택 등

hybrid (하이브리드 클라우드)
– 공용과 사설 클라우드가 혼재하는 것. 예를 들어 금융권에서 인터넷뱅킹은 공용 클라우드로, 그외 내부에서 도는건 사설 클라우드로 운영하는 것
– 두 종류의 클라우드를 관리하기 위해 하이브리드 클라우드 관리 시스템이 필요하다. 이러한 시스템을 통해 공용이든 사설이든 인스턴스를 자유자재로 이동시킬 수도 있다.

클라우드의 장점

- 속도가 빠르다. 필요한 자원 및 어플리케이션을 적재적소에 빠른 시간에 배포할 수 있음. 
- 자원관리가 용이하다. 온프레미스는 필연적으로 자원이 낭비되거나 부족한데, 클라우드는 필요한 만큼 적절하게 자원을 사용하고 부족하거나 남는 경우 유동적으로 자원을 늘리고 줄일 수 있다. 
- 운영관리가 편하다. 운영 표준화를 스크립트나 템플릿으로 만들어 GIT 등으로 관리를 자동화하고 비효율적인 부수작업 (변경관리,버전관리, 패치검토,서버실관리,출입관리,환경관리 등)이 줄어든다. 
- 유지보수 부담이 적다. 복잡한 유지보수 (펌웨어 업데이트 등) 및 장애 유지보수 (부품수급, 교체작업 등) 를 신경 쓸 필요가 없고, 사람의 터치가 적어 실수 발생 가능성이 적고, 해당 유지보수를 위한 기술을 배울 필요가 없음. 
- 비용이 절감된다. 데이터 센터 대여(또는 공간 및 항온항습 유지), 하드웨어 및 소프트웨어 유지보수 계약, 관리자 인건비 등의 모든 비용들을 절감 
- 가용성이 확보된다. 클러스터 형식으로 높은 가용성을 제공

클라우드 사용 적합성 판단 

클라우드가 적합한 경우
– 자원 트래픽 변동을 예측하기 어려운 시스템 (AUTO SCALE 기능) 
– Disaster Recovery (DR) 
– 빠른 서비스 제공이 필요한 경우. (온프레미스는 구축이 오래걸림) 

온프레미스가 적합한 경우
– 높은 가용성이 필요한 경우. 클라우드 업체가 제공하는 가용성보다 더 확실하게 가용성을 보장하는 환경을 직접 만드는 경우. 
– 기밀성이 높은 데이터를 사용하는 경우. 
– 특수한 요구사항 (범용적이지 않은 장치, 특수한 플랫폼)