1. docker 서비스를 시작하고 시스템 부팅 시에 시작하도록 구성
systemctl enable docker
systemctl start docker
2. docker 호스트 인스턴스에 대한 버전 정보
docker version
3. info서브 명령을 사용하여 현재 구성 정보 살펴보기
docker info
4. dockerd가 시작할 때 생성한 디렉터리 계층구조를 살펴보기
ls -R /var/lib/docker
5. docker가 설치되어 있는 리눅스 환경 특징:
ip a
#명령어 실행 시 docker0로 사설 ip가 할당됨
#외부로 나갈 수는 있지만 패킷이 다시 돌아오지 못함
/var/lib/docker라는 폴더가 있는지 여부(있으면 docker가 설치되어 있는거임)

 


IP1       IP2       IP3

con1    con2    con3


docker 172.17.0.1/16



192.168.10.81



사설 IP가 할당되기 때문에 Container에서 나갈 때는 나갈 수 있지만

다시 돌아올 때는 패킷을 받을 수 없다(IP를 변경해준다)

Source NAT를 사용한다

컨테이너가 나갈 때만 역할 IP...Source IP를 변경해준다

- (Linux Bridge)L2, DHCP, 그리고 나갈 때만 SNAT 역할로 내보내준다.

 




1. docker 서비스를 시작하고 시스템 부팅 시에 시작하도록 구성
systemctl enable docker
systemctl start docker
2. docker 호스트 인스턴스에 대한 버전 정보
docker version
3. info서브 명령을 사용하여 현재 구성 정보 살펴보기
docker info
4. dockerd가 시작할 때 생성한 디렉터리 계층구조를 살펴보기
ls -R /var/lib/docker
5. docker가 설치되어 있는 리눅스 환경 특징:
ip a
#명령어 실행 시 docker0로 사설 ip가 할당됨
#외부로 나갈 수는 있지만 패킷이 다시 돌아오지 못함
/var/lib/docker라는 폴더가 있는지 여부(있으면 docker가 설치되어 있는거임)
6. /etc/docker/daemon.json 파일 생성하면 warning을 제거할 수 있다(SSL접속)
(
"insecure-registries" :["10.10.12.0/24"]
)
7. docker 재시작
systemctl restart docker
8. ubuntu 이미지 생성(이미지 저장소 레지스토리 - 일종의 파일서버에서 가져오기)
docker pull reg.cloud.com/ubuntu
docker images
로 이미지 확인
docker run -it reg.cloud.com/ubuntu
로 이미지 생성
9. apt명령어 실행으로 Ubuntu인지 여부 확인
apt
cat /etc/os-release
로 release 정보 확인


*레지스토리(registry) : 이미지를 저장하는 원격 저장소

docker에서 공식적으로 제공하는 저장소가 존재한다 :


docker hub : https://hub.docker.com/explore/


1
2
3
1. docker 저장소에서 이미지 가져오기(여기서는 busybox)
 
docker pull busybox
cs


*Repository : 여러 docker 이미지들의 콜렉션 네임스페이스


public과 private으로 구분된다.


- 버전을 public repository에서 가져오기 

#ubuntu:16.04


- 버전 입력안 할 시에는 자동으로 latest를 가져온다

#ubuntu


- docker images 명령어로 image tag를 확인 할 수 있다.


접근 repository가 private일 경우 로그인이 필요 : 


1
2
3
4
5
6
1. docker hub 로그인
docker login
docker logout
 
2. 로그인 정보 확인
cat ~/.docker/config.json
cs





*Docker Pull 받기 :

1
2
3
4
5
6
7
8
1. pull 받기
docker pull {registryAddress}/{namespace}/{repositoryName}:{tag}
docker pull {이미지}
 
#사내망에 저장 예시
docker pull {계정 or URL}/{이미지}
docker pull reg.cloud.com/busybox
 
cs


*Docker 이미지/프로세스 지우기 : 

1
2
3
4
5
6
7
8
9
1. docker process 및 이미지 지우기
docker rm -f {프로세스 명}
docker ps -
#로 조회
docker rm -f 0e60b5e39d5c
 
#docker 이미지 지우기
docker rmi <저장소 이름>/<이미지 이름, ID>:<태그>
 
cs


*이미지 수정(Commit & Push)

뒤에서 따로 설명하겠지만, Docker에서 Commit 및 Push를 할 경우,

이미지에서는 Layer를 (revision별?) 서로 공유 하며 Layer는 1개만 가지고 있다. 전체 이미지가 아니라 수정된 부분만 업로드 된 상태로 남는다. 

=> 이미지 전체를 또 받을 필요가 없다...빠르다...분산환경

(버전 컨트롤이 가능!!)


*이미지 레이어 구조 확인 :


1
2
3
4
5
1. 이미지 레이어 확인하기
ls /var/lib/docker/overlay2/ -l
#여러개가 출력되는데 이것을 조립해서 하나의 이미지로 보여준다.
ls -/var/lib/docker/overlay2/{이미지레이어 ID}
#diff link lower 
cs





*Docker 포트 매핑 및 실행: 


1
2
3
4
5
6
7
- 포트 매핑
 
docker run -d(백그라운드 실행) -p {HOST PORT}:{Container PORT} --restart=always --name registry registry:2.5
docker run --5000:5000 --restart=always --name registry registry:2.5
 
 
docker run --5000:5000 --restart=always --name hkregistry registry:2.5
cs


*Docker image명 변경 :


1
2
3
4
5
docker tag reg.cloud.com/ubuntu localhost/ubuntu
 
#Push 한 후에 localhost/ubuntu를 다운받을 수 
docker push localhost/ubuntu
docker pull localhost/ubuntu
cs


*Docker image tar파일로 백업/삭제/업로드

1
2
3
4
5
6
7
8
9
10
*Docker image를 아웃풋 tar 파일로 백업 받기
docker save -/tmp/ubuntu.tar reg.cloud.com/ubuntu
 
*기존 Docker 이미지 삭제
docker ps -a
docker rm -r {Container ID}
docker rmi {image name}
 
*백업받은 tar 이미지 파일 다시 업로드
docker load -i ubuntu.tar
cs


Container에 들어가서 ps -ef로 조회해보면

PID 1번은 컨테이너에 이미지를 띄워주는 프로세스임~

컨테이너 run 시 이미지에 내장된 명령어가 자동으로 실행됨!


*Docker Process 관리 


1
2
3
4
5
6
7
8
9
10
11
*Docker 컨테이너 프로세스 실행
docker container run {image} cat /etc/os-release 
 
*Docker 컨테이너 프로세스 
[root@host01-2 tmp]# docker ps
CONTAINER ID        IMAGE                  COMMAND             CREATED              STATUS              PORTS               NAMES
c02b501f1151        reg.cloud.com/ubuntu   "/bin/bash"         About a minute ago   Up About a minute                       compassionate_euler
 
- Ctrl+p+q 를 누르면 bash shell을 프로세스를 죽이지 않은 상태에서 빠져나올 수 있음
- 다시 bash shell 프로세스로 돌아갈려면  docker attach {container ID} 
 
cs

▶도커 설치 링크 : 


https://docs.docker.com/toolbox/toolbox_install_windows/





*컨테이너 개념 :
2가지 유형이 있다

1) Linux Container

2) Docker


VM환경에서 Container 개념으로 넘어가는 것에 대해서도 생각해봐야한다.


인프라의 변화에 대해 이야기를 해보면

1.물리머신

2.VM

3.Container

으로 변하고 있다!!


*비즈니스 관점에서 살펴보면

(ex: 어플을 각 인프라에 배포한다고 했을 때)

물리머신에서 VM으로 넘어가게 된 계기는 Enterprise 관점에서 이슈가 있었기 때문이다...이 변화는 우연히 바뀐것은 아님...

- 비즈니스에서 고민거리에 대해 누군가 방법론을 만듬

- 방법론을 해결할 수 있는 솔루션이 나옴

항상 이 순서로 진행되어왔다.


*서버 가상화

물리시스템에서 VMWARE로 바뀌면 하드웨어가 많이 사라지게 된다.

많은 인원이 필요 없어짐.

IT Provider에 있어서 원하지 않는 흐름

하지만 서비스 제공자, Business에 있어서는 비용(COST)을 줄일 수 있기 때문에 이 흐름을 환영.


*기존 물리머신 Hardware 비즈니스 관점 이슈

DATA Center가 계속 생겨나면 비용~전기세가 가장 많이 많이 듬

이걸 Business에 있어서는 VM을 통해 획기적으로 줄일 수 있음...

어플리케이션 유지...다른 Business와 같이 사용...규모의 경제

==>Hardware Consolidation

구성만 잘 하면 성능상에서도 기존 대비 별다른 이슈 없음


*Data Center의 주류가 VM으로 변경됨

70%이상의 시스템이 VM기반으로 넘어가게됨...CLOUD...





*Docker Container가 2013년에 시장에서 처음 언급됨...

2014년에 Release(Container의 등장)


MICRO SERVICE ARCHITECTURE, DEVOPS 관점

최근 IT에 있어서 원하는 희망사항?


1) 대규모 통합 서비스(시스템이 무거워짐, Dependency에 걸리는 Library 충돌이 일어나고...)

2) 모듈러 베이스 아키텍쳐(네트워크를 통해 모두 분산시킴)

3) MSA 방법론(분산컴퓨팅에서...하나의 시스템에는 한개의 어플리케이션만...Micro Service...가장 작은 단위의 서비스로 만들어냄)

RESTFUL...네트워크 단위로 분산


*OPERATION 관점에서 살펴보면 : 

- IT는 COST다

IT COST의 7:3에서 7이 유지보수 비용...


가상화를 통해 하드웨어에 대한 유지보수 비용이 줄어든다...S/W로 들어가면 유지보수 비용도 최소화된다.

7: 혁신에 더 많은 비용을 들이고

3: 유지보수는 최소화....



프로그램을 너무 크게 만들어서 문제(경쟁사에 밀리지 않기 위해 Release를 빨리 해야 함...대규모 시스템을 모듈화...최소화...)

=> 소스코드를 검증해서 바로 Release

Release는 자주하면 할 수록 소프트웨어는 신뢰도가 높아진다.

=>어플리케이션을 가장 작은 UNIT으로 잘라낸다.

단점 : 서로 커뮤니케이션이 안됨~전문성 부재(ex: 개발자<=>테스트)

개발팀을 다시 소규모로 줄임...전문성은 자동화?

"코드 한줄을 바꿔서 Release를 얼마나 할 수 있는가(Dependency ↓)?"




이제 PAAS, MSA, DEVOPS 간의 교집합...

VM을 가지고 이 3가지를 모두 접목하기가 어려워짐...한계!!

=>리눅스 컨테이너의 탄생(2008) 

=>Docker(2014)



구조 1) 


APP1, APP2


Kernel


H/W


그런데 이런 구조라면 네트워크 및 프로세스를 공유...무거워진다.



그럼 아래 같은 구조라면? (커널이 3개)

커널을 2번 타게 되면서...Native 보다 성능이 좋지 않다.

리소스 많이 사용.


구조 2) VM


APP1                                APP2

Kernel(4Core /8G)                    Kernel(4Core /8G)


Kernel OS(10Core/64G을 1개 어플리케이션이 모두 점유할 수 없다)


H/W




//위 2개의 중간~>Name Space 개념 도입(격리, Isolation!!)

네트워크, PID, IPC, User Group, Mount가 VM처럼 모두 독립적임, 

리소스를 상대적으로 적게 쓰게 됨(커널이 1개)

베어메탈에 준하는 성능


구조 3) Container


App1            App2

Centos(OS)    Ubuntu(OS)    


Kernel 공유(10Core/64G를 온전히 1개 어플리케이션이 모두 점유할 수 있다)


H/W




*Linux 컨테이너의 한계: 

Linux 컨테이너는 분산배포를 처리하는 개념이 없었다...단순히 VM을 경량화 시킨것

Docker는 컨테이너로 분산배포 지원

배송/배포가 핵심!!



- Linux Container : OS Container (1개의 OS에 여러 App을 띄움)

- Docker Container : App Container (각 OS에 Application을 독립적으로 띄운다, OS Container로도 구성이 가능 - MSA)




* 컨테이너를 때거지로 모아서 관리하는것...

Multi Container Management Solution : 

- Swarm, Compose (Docker : Multi Container 관리)

- Kubernetes(Google: Multi Container 관리)


가벼운 VM을 만들자!!

+ Recent posts