도커(docker)

도커(docker)는 가상실행환경을 제공해 주는 오픈소스 플랫폼 

 

이는 가상실행 환경은 컨테이너(Containner)가 제공해 주는 것이며 도커는 컨테이너를 오케스트레이션 하는 오픈소스 플랫폼이라고 볼수 있음

 

컨테이너(Container)

왜? 컨테이너를 써야 하는가?

   - 웹 개발환경을 예로 들어보면 웹을 개발하기 위해선 DB, WAS, 웹서버 등이 필요하다.

   - 여러가지 소프트웨어가 필요하기 때문에 매번 여러가지 개발 환경을 만들기도 번거롭고 개발환경을 여러가지

     버전으로 만들기도 힘듬

   - 한대의 컴퓨터에 여러 개발환경을 만든다면 해당 컴퓨터의 장애시 모든 개발환경이 영향을 받음

   - 결국 가상머신을 생각하게 되는데 가상머신은 Hypervisor 위에 OS를 설치하여 운영되기 때문에 리소스의 영향을

     많이 받게됨(운영체제 위에 Hypervisor 설치하고 또 운영체제를 설치하는 번거로움 포함)

 

이런 여러가지 문제점을 개선하기 위해 개발자들은 한대의 컴퓨터에서 여러 어플리케이션 들이 서로 영향을 주지 않고 격리된 리소스만 활용하는 패키징(패키지에는 OS가 설치된  것이 아니라 앱을 실행하는데 필요한 라이브러리와 실행파일만이 존재 함) 화를 생각 하게 되고 그것을 컨테이너(Container)라 함

 

리눅스는 프로세스 1개(systemd)로 모두 운영되고 컨테이너 또한 프로세스 1개(격리된 프로세스)를 사용해서

필요 프로세스를 fork해서 사용하기 때문에 리눅스가 컨테이너고 컨테이너가 리눅스라고 해도 크게 무리가 없다

동작방식이 같기 때문에

 

Docker VS VM 환경비교

컨테이너화 된 이미지는 컨터이너를 동작시킬수 있는 환경만 된다면 어디에서나 실행이 가능함

도커를 이용하여 우분투 리눅스에서 센트OS컨테이너 실행도 가능함

  Host 와 컨테이너의 Kernel이 다른데 정상적으로 동작이 가능한 이유는 무엇일까?

   - LBS(Linux Base Standart)는 소스 코드를 컴파일한 시점에서 호환성있는 머신코드를 생성하도록 ISO 규격으로

     표준화 되었다

   - 리눅스 ABI(Application Binary Interface)로 인해 리눅스 커널의 버전이 올라가도 유저 공간에서 동장하는

     바이너리(머신 코드) 레벨의 호환성은 유지된다 

   - 아래 그림에서 보면 커널변역기라고 표시한 곳에서 Application(CentOS) 과 OS(Ubunbu)사이에서 

     언어 번역기 역활을 하기 때문에 서로 커널이 달라도 정상 동작이 가능하다고 볼수 있음

   - ABI동작으로 인해 서로 100%호환이 가능하지만 일부 동작하지 않는 것도 있다고 함

 

리소스 같은 경우는 OS를 별도로 설치할 필요가 없는 컨테이너 환경이 더 좋을수 있지만 

보안적인 측면에서는 각 어플리케이션들이 완전히 독립적으로 운영되는 VM 환경이 더 좋다고 볼수 있음

 

컨테이너는 리눅스의 가지 기능에 의해 구현됨

   - chroot  : 프로세스의 루트경로를 변경할수 있는 기능

                 아래 그림처럼 Process K는 하위 디렉토리인 A를 루트로 인식할수 있게 해주는 기능

                 과거에 주로 원격유저(FTP 등)를 특정 디렉토리 경로에 가두기 위한 용도 등으로 사용됨

           

            문제점

                ▶ 탈옥코드가 존재하기 때문에 격리된 프로세스가 Root 탈취가 가능함 (Pivot_root를 사용하여 방지 가능)

                ▶ 자원이 따로 격리된게 아니기 때문에 Host의 자원을 제한없이 사용 가능

                ▶ 외에 다수의 문제를 가지고 있음

             

   - Namespace  :  프로세스에 격리된 환경과 리소스를 제공함

            ▶ 모든 프로세스들은 네임스페이스 타입별로 특정 네임스페이스에 속합니다

                  - Mount namespace : 마운트 포인트를 격리하여 다른프로세스로 부터 격리 시키킴

                  - UTS namespace : 호스트 네임과 도메인네임을 격리시킴

                  - IPC namespace : system V IPC, Posix message queues를 격리시킴

                  - PID namespace : 프로세스 ID를 격리시킴 격리된 프로세스는 두개의 PID를 가짐

                  - cgroup namespace : cgroup의 자원할당을 격리하는것이 cgroup namespace

                  - NET namespace : 네트워크 자원을 격리시킴

                  - USER namespace : 네임스페이스의 안과 밖의 UID/GID를 다르게 설정할 수 있음

            ▶ child는 Parent의 네임스페이스를 상속 받음

            ▶ 프로세스는 네임스페이스 타입별로 일부는 호스트(root) 네임스페이스를 사용하고 일부는

                컨테이너 네임스페이스를 사용할수 있음

   - cgroup : 하드웨어 자원을 그룹별로 관리 제한할수 있는 리눅스 모듈

                 파일 시스템 기반으로 HW자원을 할당 관리

 

 

컨테이너 라이프 사이클

[그림 출처:책] 15단계로 배우는 도커와 쿠버네티스

   - 이미지 : 컨테이너의 모형이 되는 것으로 실행되기 전의 상 태

   - 실행 : 컨테이너 위에서 프로세스가 실행 중인 상태를 의미

   - 정지 : 프로세스의 종료 코드, 로그가 보존된 채 정지한 상태

 

도커(Docker)

도커 아키택쳐

도커는 CD플레이어로 비교 될수 있음

  CD만 있으면 어느 플레이어에서나 내가 원하는 음악을 들을 수 있는 것 처럼 도커는 CD(컨테이너)만 있다면 어디에서나 CD(컨테이너)를 실행할수 있음

   - 도커 이미지(Image) : 사용자가 실행할 코드가 들어있는 바이너리 한번 생성하면 수정이 불가함

   - 도커 파일(Dockerfile) : 도커 이미지를 생성하기 위해 필요한 문서

   - 도커 컨테이너(Container) : 도커 이미지가 메모리 위에 상주하여 실제 코드가 수행되는 프로세스

                                        컨테이너는 종료 시 모든 데이터가 휘발됨

   - 도커 데몬(Docker Daemon) : 컨테이너가 정상적으로 수행될 수 있게 실행 환경을 제공함

   - 도커 호스트(Docker Host) : 도커 데몬이 동작하는 운영체제

   - 원격 레지스트리(Registry) : 도커 이미지를 저장할 수 있는 원격 저장소. 공개(Public) 비공개(Private)

   - 도커 클라이언트(Client) : 도커 클라이언트는 컨테이터를 조작하는 커맨드 라인 유저 인터페이스

                                      명령어가 입력되는 곳

 

도커 설치 및 상태 확인 

도커 설치 

   - curl  -fsSL https:// get.docker.com | sh  > 설치 명령어 옵션의 의미는 아래와 같음

       -f : HTTP 서버 오류시 자동으로 종료함(별도출력 없음)

       -s : 오류메시지를 표시하지 않음

       -S : -s와 함께 사용하면 실패할경우 오류메시지를 표시함

       -L : 서버가 리다이렉션 되어 있는경우 해당 리다이렉션을 끝까지 따름

 

도커 정보

   - Docker info

서비스 상태 확인

   - systemctl status docker

         우분투는 아래와 같이 설치시 자동으로 서비스가 활성화(active)되며

         센트OS의 경우 별도의 systemctl start docker 명령어를 통하여 활성화 하여야 함

 

리눅스 상의 현재 동작중인 서비스 확인     

   - systemctl list-units --type=service

도커의 루트 디렉토리 확인

   - tree -L 3 /var/lib/docker

        -L : 보여지는 하부 디렉토 단계 설정

        지정한 경로의 하부 디렉토리 확인

 

리눅스의 프로세스 확인

   - ps -ef

 

리눅스의 네트워크 인터페이스 확인

   - ip -c link

       도커에서 컨테이너가 정상적으로 실행되면 위와 같이 Docker 인터페이스가 UP 상태가 되며 해당 인터페이스가 UP

       상태가 되면 Host에서 컨네이터로 정상 통신이 가능한 상태가 됨

 

리눅스의 브릿지 정보 확인

   - brctl show

         도커를 사용하기 위한 가상의 L2를 리눅스에 생성했다고 보면 됨

          도커에서 정상적으로 컨테이너가 실행되면 도커의 Virtual interface와 docker0 interface 가 

          브릿지로 연결되는 것을 알수 있음

 

리눅스의 IPtables 필터 정책 확인

   - iptables -t filter -S

        도커 인터페이스 관련 포워드 정책이 눈에 띈다

iptables의 NAT 정책 확인

   - iptables -t nat -S

           컨테이너에 할당되는 IP 대역의 SNAT 정책이 눈에 띈다

컨테이너 실행 및 확인

컨테이너 실행

   - docker run <컨테이너ID> OR <컨테이너 이름>

         컨테이너 이미지 ID 실행시 먼저 Local에 이미지가 존재하는지 확인 후 도커허브에서 가지고 옴

컨테이너 중지

   - docker run <컨테이너ID> OR <컨테이너 이름>

 

컨테이너 중지된 컨테이너 재시작

   - docker start <컨테이너ID> OR <컨테이너 이름>

 

컨테이너 삭제

   - docker rm -f <컨테이너ID> OR <컨테이너 이름>

         -f : 현재 실행중인 컨테이너까지 모두 강제 삭제하는 옵션

 

도커로 실행중인 컨테이너 프로세스 확인

   - docker ps

        현재 실행중인 프로세스 정보 확인

   - docker ps -a

        중지된 컨테이너 프로세스 정보 확인

 

도커가 로컬에 가지고 있는 이미지 확인

   - docker images

 

도커가 로컬에 가지고 있는 이미지 삭제

   - docker rmi <이미지 이름>

 

중지된 컨테이너 프로세스의 컨터이너 ID 출력

   - docker ps -a -q

ngnix 컨테이너를 백그라운드로 실행

   - docker run -d nginx

        -d : Detached모드 실행 옵션으로 컨터이너를 백그라운드에서 동작하는 어플리케이션으로 실행

              Detached모드는 컨테이너에서 반드시 프로그램이 실행된 상태여야 하며 프로그램이 중단되면

              컨테이너도 종료 됨

 

컨테이너의 상세정보 확인

   - docker inspect <컨테이너 ID> or <컨테이너 네임>

     위와같이 입력시 아래와 같이 컨테이너의 정보를 확인 할수 있음

 

컨테이너의 로그 확인

   - docker logs -f <컨테이너 ID> 

       -f : follow output 옵션 실시간으로 로그를 출력해 주는 옵션

 

컨테이너에 명령어 전달

   - docker exec <컨테이너ID> <명령어>

 

컨테이너안으로 접속

   - docker run -it <컨테이너 이미지파일 이름> bash

         -it : interactive 대화형 쉘 접속 옵션 bash 명령어와 같이 사용시 이미지의 bash 쉘로 접속이 가능