DevOps2016.04.30 10:45

Today Key : REX-Ray, REXRAY, Container, Docker, Mesos, Storage, Persistent, Plug

 

 

 

REX-Ray

• Docker나 Mesos 같은 Container runtime에서 Persistent Storage를 제공하기 위한 Plug-in.
• 일반적인 스토리지 / 가상화 / 클라우드 플랫폼 등과 같이 다양한 환경을 Container에서 손쉽게 스토리지 기능을

  사용할 수 있게 하는 쉬운 인터페이스를 제공.
• 현재 버전은 0.3.3 (Release : 2016년 4월 21일)
• Docker 1.10+ 이상에서 Docker Volume Driver Plug-in으로 Recommend 됨.

     ※ 현재 16개의 Docker Plug-in이 홈페이지에서 안내
• REX-Ray 공식 [ 바로가기 ]  /  REX-Ray Git [ 바로가기 ]

 

 

 

Goal

Docker Container Mesos Frameworks 에서 지속적으로 사용 가능한 저장소(persistent storage) 제공

    Container Host 이동 시에는 Container에서 동일한 데이터 저장 공간을 사용 가능

 

실행방식

• Service 혹은 CLI 로 설정 가능.

    CLI의 경우에는 env 값으로 설정.

    ※ 현재 설정 값 확인 : rexray env
• Service로 구동 시에는
     /etc/rexray/config.yml
     의 정보를 이용해서 환경 값 설정.
     실행은 rexray start

 

지원 플랫폼

•플랫폼에 상관없이 REX-Ray 동일한 기능을 제공

      - Cloud : AWS EC2, OpenStack(Cinder), Google  Compute Engine(GCE)

      - IsilonScaleIO,VMAX, XtremIO     

 

 

 

지원 OS

 

 

 

 

지원 Container Platform

 

 

 

 

 

 

 

 


 

AWS EC2에서 EBS를 REX-Ray를 통해서 Host 이동 시에도 동일한 Data를 사용할 수 있도록 Persistent Storage로 사용하는 예제

본 예제에서는 하나의 Host에서 REX-Ray를 통해서 EBS 볼륨을 만들고, 

이 볼륨으로 Container를 만든 후에 임의의 데이터 값을 입력한 이후에 해당 Container를 삭제.

다시 다른 Host에서 동일한 볼륨명으로 Container를 생성하게 되면, 기존에 Container가 생성한 임의 데이터 확인 가능.

즉, 서로 다른 Host에서도 접근 가능한 볼륨을 통해서 Container가 이동 시에도 동일한 데이타 볼륨을 가질 수 있도록 하는 예제.

 

 

• REX-Ray의 config.yml에서 AWS를 사용을 위한 설정

 

 rexray:
  storageDrivers:
  - ec2
aws:
  accessKey: MyAccessKey
  secretKey: MySecretKey

 


 

• REX-Ray로 사용 가능한 볼륨 리스트

    

 

• Docker에서 REX-Ray driver를 이용해서 Volume 생성 및 해당 Volume을 사용하여 Container 생성

 

•Container에 임의로 파일을 생성

 

•Container 삭제

 

• 다른 Host에서 기존의 Host에서 생성한 Storage Volume을 사용하여 새로운 컨테이너 생성 후,

    기존의 Host에서 생성한 파일이 그대로 있는 것을 확인 가능.

• 즉, Container가 서로 다른 Host에서 생성 시에도 동일한 볼륨을 사용할 수 있음.

 

 

 REX-Ray에서 Volume 리스트를 확인해보면, 처음에 생성한 Volume이 List 상에 있는 것을 확인할 수 있다.

 

 

 

• 실제 AWS Console에서 확인해보면서, REX-Ray를 통해서 AWS에 생성된 EBS 볼륨 확인

 

 

 

 

 

 

 

 

 

           

          

 

 

Posted by 네떡지기
분류없음2016.04.02 23:11

Today Key : DUCP, UCP, Docker, Universal, Control, Plane, 도커, 클러스터, CaaS

 

이번 포스팅은 Docker의 Enterprise의 On-Promise 솔루션인 DUCP에 대한 첫 번째 포스팅입니다.

UCP의 첫 번째 포스팅에서는 UCP에 대한 간략한 소개 내용과 Controller 노드의 설치에 대한 내용입니다.

이어질 UCP 포스팅에서는 Controller Node 이외의 설치 및 기능에 대해서 알아 볼 예정입니다..

 


 

 

 

DUCP (Docker Universal Control Plane)
  

  ▪ Enterprise 의 On-Promise 솔루션
  ▪ Production 환경에서 UCP를 사용하여 Docekrized Application들을 배포하고 관리  가능
  ▪ Agaility & Portability 제공
  ▪ Provision, Cluster Docker Host, Resource에 디자인 된 Docker Native 솔루션
  ▪ Docker API를 모두 지원

 


UCP 아키텍처

Docker UCP는 다수의 노드로 구성된 클러스터로, 각 노드는 Commercially Supported (CS) Docker Engine이 설치
클러스터를 구성하는 노드는 다음의 3개의 노드로 구분할 수 있음.


  ▪ UCP controller node
      사용자의 요청을 받아서 UCP Node를 제어하는 역할


  ▪ UCP replica nodes
      Controller의 High-availability를 위한 Node


  ▪ UCP nodes
       Container가 실제 실행될 노드
 

  

 

UCP 요건

  ▪ 하드웨어 및 소프트웨어
      - 1.50 GB 메모리
      - 3.00 GB 이상의 여유 디스크 용량
      - 다음과 같은 OS 버전 설치
           RHEL 7.0, 7.1
           Ubuntu 14.04 LTS
           CentOS 7.1
           Kernel version 3.10 or higher
      - CS Docker Engine
           ※ CS Engine :  Commercially Supported Docker Engine  

 

  ▪ 서비스 포트

      - UCP 서비스를 위하여 다음과 같은 서비스 포트를 사용

 

 

 

 

  ▪ Subject alternative names (SANs)
       - UCP에서 각 노드 간의 통신은 Mutual TLS로 보호되며, TCL 설정은 UCP 설치

       - 이를 위해, UCP의 모든 클라이언트는 UCP Swarm Root CA에 서명된 Swarm TLS Certificate 체인을 사용

       - Ceritificate system 제공하기 위해 SAN을 사용

       - 즉, UCP Node간의 통신 보호를 위한 시스템을 위해서 사용

  ▪ IP address & FQDN 설정
      - UCP install 명령은 FQDN을 사용하여 Host를 찾음.
      - FQDN이 설정되지 않은 경우에는 설치 시에 Host 주소를 입력하라는 메시지가 표시
      - 설치 시에 --host-address  옵션 사용 가능
      - AWS, Digital  Ocean같은 클라우드 환경에서 설치 시에 Private IP를 할당 받게 되는 경우에는 모든 node간의 통신이 되어야

        UCP 동작이 가능

  ▪ Data volumes
      - UCP는 데이터 유지를 위해서 특정 볼륨을 사용하기 때문에 Production을 위한 UCP 설치 시에는 다음과 같은 볼륨을 생성

  


      - 만약 이러한 볼륨 생성하지 않은 경우, ucp install 시에 default volume driver/flags를 사용하여 만들어짐.

 

 

 


 

 

 

UCP 설치 단계 [Controller 설치까지]

UCP를 테스트하기 위한 설치 방법으로 Windows나 MAC에서  boot2docker를 사용하여 설치하는 방법과 Production 환경에서의

UCP를 설치하는 방법이 있음.  Production 환경의 설치 중 아래의 6개 단계까지 진행을 하면 Production 환경에서의 UCP Controller Node를 설치할 수 있음.

 

○ 테스트용 설치 링크 : https://docs.docker.com/ucp/evaluation-install/

○ Production 환경에서의 설치

Step 1
  ▪ 필요한 서비스 포트 오픈(방화벽 등)

 

Step 2
  ▪ CS Docker Engine  설치  
        : https://docs.docker.com/docker-trusted-registry/install/install-csengine/

 

Step 3
  ▪ Customize user-named volumes (optional)

 

Step 4
  ▪ Customize the CA used (optional)

 

Step 5
  ▪ Install the UCP controller

Step 6
  ▪ License your installation
         : https://hub.docker.com/


※ 참조 : https://docs.docker.com/ucp/production-install/

 

 


 

 UCP 실행

 

◎ 설치 환경

    - Microsoft Azure

 

 

 

 

 

  ▪ 설치 후, 접속 화면

 

 

 

  ▪ Dashboard

      - 현재 UCP에 대한 정보를 확인할 수 있음.

      - 초기 설치 시에, UCP 구동을 위해서 Controller Node는 7개의 이미지로 7개의 Container가 기본 동작

 

 

 

※ UCP Images

 

 ※ UCP 기본 Container

 

 

 

 

 

  ▪ UCP에서 지원되는 기능들에 대한 메뉴

    - Application, Container 등의 기능을 위한 메뉴가 있음.

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2015.11.03 01:38

Photon, VMware, Integrated, Container, install, git, iso, platform, os, 컨테이너, 포톤, vm웨어, Docker, rkt : Today Key

 

VMware의 Container 전략(?), 지원 방향(?)인 Photon에 대한 2번째 포스팅입니다.

지난 번에 설치해 본 Photon OS에 대해서 간략히 알아보고,

실제 Container 지원에 대한 내용인  vSphere Integrated Containers & Vmware Phton Platform에 대해서 각각 알아봅니다.

Photon OS에 대해서만 현재 TPv2로 나오고, 그 이외는 아직 출시가 되지 않았기 때문에 정리된 내용이 일부 실제 내용과

다를 수도 있지 않을까? 싶습니다.

혹시 수정해야 되는 내용이 있다면 알려주시면 감사하겠습니다.

 


 

 

 

 

Photon OS 란?
▪ vSphere에 최적화된 Linux Container host runtime
▪ 확장 가능하며, 매우 가벼우며 대부분의 Container 포맷을 지원
- Docker, Rocket(Core OS), Garden(Pivotal)
▪ 현재 OpenSource로 Photon v1.0 Tech Preview 2로 공개됨.

 

 

 

 


VMware의 Photon/Cloud Native App 관련 진행 일정
4월 : Cloud-Native Apps을 위한 새로운 오픈 소스 프로젝트를 Announce
           - Photon OS : Container에 최적화된 Linux distro.
           - Lightwave : Container와 CAN을 위한 인증 및 인증서 관리 시스템
5월 : Lightwave source를 Github를 통해서 release
6월 : AppCatalyst 발표. : CAN를 개발을 가속할 수 있는 fee Desktop hypervisor.
         Project bonneville  : vSphere에 Container가 통합될 수 있는 혁신적인 방안
         Open Container Initiative Founding members로 가입
 7월 : Cloud Native computing Foundation에 Founding members로 가입
 8월 : AppCatalyst와 Photon OS의 기술 Preview 2 release.
*dirstro : set of software components, often open source

 

 

Photon OS 설치를 위한 요구사항
•VMware vSphere 5.5 or VMware vSphere 6.0 installed
     ※ Photon OS가 Linux kernel 3.X로 설치되어야 하는 데, 5.5에서는 3.X 항목이 없어서 불가로 추정
     ※ VMworkstation의 경우네는 Ver.12에 Linux 3.X으로 설정하여 설치 가능하며, Photon 항목도 있음.
•ESXi host with recommended 2GB of free RAM
•ESXi host with recommended 2GB of free disk space
•Photon ISO
                                                                 【 Recommend 】   2 vCPU, 1024MB memory, 20GB hard disk. 

 

Photon 설치 파일
• Photon OS, Tech Preview 2 – Full ISO

         - Full Version 선택 시, Photon OS를 모두 선택 할 수 있음.
• Photon OS, Tech Preview 2 – Minimal ISO
• Photon OS, Tech Preview 2 - OVA
     ※초기에는 일반 ISO만 지원했으나, Minimal ISO와 OVA가 추가됨.

 

Photon OS 종류
• Photon Micro
• Photon Minimal
• Photon Full
• Photon OSTree Host
• Photon OSTree Server

 


 

 


 vSphere Integrated Containers & Vmware Phton Platform
    - VIC : Unified Hybrid Platform
    - Photon Platform : Cloud-Native Platform

 

 

 

vSphere Integrated Containers
▪ 기존 vSphere에서 Container를 관리할 수 있도록 확장
▪ 다양한 Feature Set 지원
     -  기존 ESXi에서 지원하던 다양한 기능을 지원 (DRS, vMotion, HA/DR, Storage & Network Integration)
▪ 기존 서비스에 대한 Re-Building이나, Re-Architecture가 필요하지 않음.
▪ Enterprise급의 Container Infrastructure를 구축 가능.
     - 개발자에게는 Container의 Portable, Fast, Lightweight의 장점을 가져다 주며,
       IT 운영자에게는 Security, Visibility, Management를 효과적으로 할 수 있도록 함.

▪ 다른 Container ecosystem 솔루션(CoreOS Tectonic, Docker, Kubernetes, Mesosphere Data Center OS, Pivotal CF)과

  손쉽게 통합 가능

 

 


 

 

Photon Platform
▪ Container와 CNA에 최적화 된 Platform
Core Components
   - Photon Controller(Host 컨트롤러, 스케쥴러)

       : Container의 분산컴퓨팅 관리, 스케쥴링 관리, 오케스트레이션
       : 단일 API 엔드포인트

             - 실제 Photon Controller가 내부적인 동작을 하는 것이 아니라, 기본 Container 기반의 ecosystem에 대한  API를 제공

               Photon Platform 사용자는 동일한 API 사용을 통해서 원하는 ecosystem을 그대로 사용 가능

       : 현재 미 출시

   - Photon Machine(Compute Host)
       : Photon OS, Microvisor(based on ESX)
         - Photon OS가 내장된 ESX기반의 Lightweight한 microvisor. 

 

Photon Platform 아키텍처

  

 

 

 

vSphere Integrated Containers와 Photon Platform 간의 비교

 


 

 

Posted by 네떡지기
분류없음2015.10.27 10:09

 

 

Photon, VMware, Container, install, git, iso, platform, os, 컨테이너, 포톤, vm웨어, Docker, rkt : Today Key

 

VMWare에서 Container를 위한 Container 전용 OS인 Photon을 VMWorld 2015에서 발표하였습니다.

Photon과 관련한 2가지 방향인 VIC와 Photon Platform은 곧 다음 포스팅에서(빠르면 이번 주내?) 다뤄질 예정이며..

우선 무작정 누구나 따라하기 쉬운 Photon OS 설치를 이번 포스팅에서 다뤄봅니다.

 

 


 

 

VMWare Photon OS 설치하기

 

Photon OS

VMWare에서 Container를 위한 내놓은 Container OS

ISO(Full, Minimal), OVA로 현재 제공되고 있음.

• 현재 Version은 Photon 1.0 TP2

 

설치

• 설치 시, Linux Kernel 3.X 64bit로 설치(혹은 Photon OS)

• 아래 설치 예제는 ISO Full Version으로 진행

 

 

 

 

 

 

• Photon 이미지를 실행하면 아래와 같이 Install 화면 표시

 

• Accept !

 

 

 

• Disk 선택.

 

• Disk 초기화

 

 

• Photon OS 종류 선택. 여기서는 Full Version으로 설치

  당연히, full 버전이 Micro나 MInimal 버전보다 많은 기능을 포함하고 있지만, 조금 무거운 이미지이다.

  하지만 기존 Linux OS에 비해서는 가볍다.

 

 

• Hostname 설정

 

• Root Password 설정

 

• 설치가 끝나면, 시스템 리부팅

 

 

 

• 설치가 완료.

 

 

 

 

• Photon의 현재 Version을 확인

 

 

• Photon에서 Docker를 활성화하고, VMware에서 CNA(Cloud Native Application) 예제로 올려놓은 이미지를 받아서 실행합니다.

 

 

 

• Photon OS에 Docker Container를 띄워서 웹서비스를 간단하게 올린 예제입니다.

 

 

• Photon 예제에서 사용한 이미지의 Linux 정보는 아래와 같습니다.

 

 

• 본 예제에서 설치한 Photon OS은 Full 버전입니다. 현재 사용량을 확인해보면 약 232M 정도입니다.

 

• Full Version의 경우에는 yum도 가능합니다.

 

 

• 다음은 Photon OS은 Minimal을 설치했을 때의 모습입니다. 현재 사용량을 확인해보면 약 46M 정도입니다.

 

 

• 다음은 Photon OS은 Micro를 설치했을 때의 모습입니다. 현재 사용량을 확인해보면 약 25M 정도입니다.

 

 

• 이상으로 아주 간단한 Photon OS의 설치와 간단한 CNA 예제를 실행해보았습니다.

  Photon에 대한 정리는 다음 포스팅에서 보다 자세히. ^^ 하도록 하겠습니다.

Posted by 네떡지기
분류없음2015.08.21 13:49

Docker,Remote, API,client,  library, python,host, 원격, 리모트, 도커, git : today Key

 

 Docker의 6번째 포스팅입니다. 이번 포스팅에서는 Docker를 Remote에서 제어할 수 있도록 제공되는 Remote API client libraries에 대해서 다뤄봅니다. 보안적인 측면보다는 최대한 우선 쉽게 접근하는 걸 목표로 잡고 있기 때문에 이 점은 감안해서 봐주시면 감사하겠습니다. ^^

이런 식으로 Docker를 Client에서도 다룰 수 있다는 것 정도로 보면 어떨까 싶습니다! ^^

물론 이러한 API를 활용하여 Docker Host를 관리하도록 한다면 Docker의 명령을 직접 입력하지 않고 Application을 클릭하는 것만으로도

docker를 관리할 수 있을 것입니다.


 

Docker Remote API Client libraries

    Docker에서는 Client가 Docker Host를 제어하기 위한 다양한 언어로 구성된 API Library에 대해 있음  

    Docker를 작성한 Go를 비롯한 다양한 언어에 대한 Library가 Git을 통해서 제공되기 때문에 원하는 언어를 선택 가능. 

    Client는 Host를 제어하는 역할이기 때문에 별도의 Docker Engine를 설치할 필요가 없으며,

       Windows,Mac 등에서도 직접 사용 가능.

    본 포스팅에서는 Windows기반의 PC에서 Python Library를 사용하여 Docker Host를 제어

   • Docker API LINK : https://docs.docker.com/reference/api/remote_api_client_libraries/

   

  

 

 

Docker Remote API Client libraries - Python

    Python용 Library를 설치

          - pip install docker-py  [ Docker Python Library가 있는 Git 페이지에도 나와있음 ]

          - https://github.com/docker/docker-py

 

 

    Python Shell에서 Docker Host에 접속 및 정보 확인

          - docker.client 라이브러리를 Load

          - Docker Host에 접속

              ※ Docker Host에서 기본 Unix Sock 접속이 아닌 TCP로 접속할 수 있도록 설정 필요.

          - info() 메서드를 사용하면 현재 Docker Host에 대한 정보를 확인할 수 있음.

 

 

   Docker Image 정보 확인

          - images() 메서드를 통해서 Docker Host에 있는 이미지 정보를 출력

          - docker images 역할

 

 

   Docker Image 정보 확인 변형

          - 위에 표기된 대로, 모든 정보가 다시 결과 값으로 리턴될 때의 사용자가 보기에는 조금 어렵게 리턴이 되게 되기 때문에 결과 값을

            아래와 같이 가공이 필요로 함.

          - originList() 메서드는 간략하게 결과 값을 가공하기 위해 만든 별도의 메서드

 

 

 

   Docker Image 정보 확인 변형2

      - originList() 메서드는 처음이 결과 값보다는 보기가 편하지만 그래도 여전히 보기가 쉽지 않고 필요한 정보 뿐만 아니라,

        필요 없을 수 있는 모든 정보들에 대한 결과를 보여주기 때문에 아래와 같이 필요한 정보에 대해서만 간략하게 보여줄 수 있도록

        메서드를 작성하는 것이 좋음.

      - ImageList() 메서드는 Image ID와 Repo, Tags, Virtual Size 에 대한 값만을 보여주도록 가공하도록 작성한 별도의 메서드.

 

 

   Docker Container 생성

      - create_container() 메서드를 사용하여 Container를 생성

      - start() 메서드에 매개변수로 생성된 Container 객체를 포함하여, Container를 Running 상태로 만듬.

      - start() 메서드에 의해 생성된 Container가 정상적으로 동작하는지 확인하기 위해서, 해당 Container에서 동작 중인 웹서비스 호출

 

 

      - containers() 메서드를 사용하면, 현재 동작 중인 Container의 정보를 볼 수 있음.

           : docker ps 역할

 

      - 아래의 실행 결과 값은 마찬가지로 originList() 메서드를 사용하여 전체 정보를 보기 쉽도록 가공.

 

 

 

 

Posted by 네떡지기
분류없음2015.08.20 00:30

 


Docker,layer, image, aufs, parent, size, build, container, aufs, device mapper  : today Key

 

개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인

Docker의 5번째 포스팅입니다.  

지난 포스팅에 이어서 Docker의 Layer 이미지에 대한 두 번째 내용입니다.

지난 포스팅에서 나눈 이유가 길어져서 였는 데, 테스트 한지가 조금 되다보니 뒷 부분 정리한게 생각보다 길어지진 않았습니다. ^^;

물론 추후 언제라도 동일한 주제로 해당 내용은 업데이트 될 수 있습니다! ^^

그럼 먼저 Docker의 이미지에 대한 간단한 몇 가지 정리에 이어서, 지난 포스팅과 마찬가지로 테스트한 내용을 중심으로 이해해보겠습니다.

다음 포스팅도 대략적으로 50% 이상 써 놓은 상태여서 다음 포스팅까지는 멀지 않은 시일내에 업데이트 하도록 하겠습니다.

 


 

Docker Layered Image.

 

▪  Docker는 하나의 Image에 Layer를 결합하기 위해서 Union File System을 사용.
▪  Union 파일 시스템은 branches 알려져 있는 각 파일 시스템 내 파일 및 디렉토리들을 transparent하게 오버레이 형태로 적용되어

    하나의 일관된 파일 시스템을 형성
▪ Docker Image가 변경될 때, 새로운 Layer가 생성
▪ Docker Image에서 새로운 Layer를 생성되는 과정을 'instructions'이라 함.
▪ instructions이 발생하는 경우
    - Command 실행
    - File이나 directory 생성
    - 환경변수 생성
    - Image로 Container를 생성하여, 어떤 Process를 실행할 경우
▪ Dockerfile : Instructions 들을 모아 놓은 파일
▪ Docker가 이 Dockerfile을 읽어서, instructions을 수행하고 최종 image를 생성
▪ Docker에서 지원하는 파일 System
     - AUFS / Device Mapper /  Btrfs
▪ Docker에서는 Default로 AUFS (Advanced multi layered Unification File System)를 사용

 

root@ubuntu:~/Docker# docker info | grep Storage

Storage Driver: aufs

 

 


Docker 이미지 이해하기

  ▷ 현재 조건

    현재 Docker의 이미지는 아래의 그림과 같이 Base Image로 부터 zigiweb:latest 가 만들어 지고,

       다시 zigiweb2:0.1 이미지가 만들어진 상태.

       ※ 물론 이미지 생성 과정에서 다수의 이미지가 생성되기 때문에 그림에는 다수의 이미지가 생략된 상태.

    zigiweb 이미지를 통해서 modizigi 라는 Container가 생성된 상태

 

  

 

  ▷ 테스트

   Step 1

     - modizigi Container를 삭제 [ Container는 현재 Stop된 상태라고 가정

   Step 2

     - zigiweb:latest 이미지를 삭제

   Step 3

     - zigiweb2:0.1 이미지를 삭제

 

 

 

   •Step 1에서 Container를 삭제 시에는 해당 Container만 삭제된다.

   •Step 2에서 Image를 삭제 시에는 해당 이미지에 대해서 Untagged만 되었다고 표기된다 

   •Step 3에서 zigiweb2:0.1 Image를 삭제 시에는 해당 이미지에 대해서 Untagged되고, 다수의 이미지가 삭제된다

   •위의 현재 Layer된 이미지에서 보듯이 zigiweb2:0.1은 기존 base image부터 시작하여 zigiweb:latest 이미지까지의 계층화된

      이미지에 추가로 덧붙여져 만들어진 이미지이다.  따라서, 해당 이미지보다 상위(그림에서는 아래)의 이미지를 삭제를 하더라도

      실제 이미지는 삭제되지 않으며, 해당 이미지에 대해서 Untagged라고 표기가 된다.

      즉, 기존 이미지를 Parent Image로 사용하는 경우에는 Parent Image를 삭제하더라도 해당 이미지에 변경된 사항에 대해서

      계층화 된 이미지를 사용하기 때문에 실제 이미지가 삭제되지 않는 것이다. 

   •즉, 모든 이미지는 상위 이미지에 대해서 의존성을 가지고 있다는 것을 알 수 있다.  

 

 

 •실제 Step 2를 수행하기 전과 후의 Disk 상태를 보면 용량이 변화가 없다. (바로 위의 그림)

 

 

 

 •하지만, Step 3을 수행하게 될 경우에는 수행 전과 후의 Disk 사용량이 해당 이미지 크기 만큼 변경됨을 알 수 있다.

 

 

 

Posted by 네떡지기
분류없음2015.08.17 23:54

Docker,layer, image, aufs, parent, size, build, container : today Keay

 

개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인

Docker의 4번째 포스팅입니다.  이래저래 개인사에 힘입어, 정리만 대략적으로 하고 포스팅이 많이 늦어졌습니다.

이번 포스팅에서는 Docker를 보면서 나오는 Docker 이미지가 Layer로 구성되어 있다는 것을 어떤 의미인지 알아보려고 합니다. 

정리하다보니 조금 길어져서, 이번 편은 Part 5에서 다시 이어질 예정입니다.

(이미 대략적인 정리가 된 상태에서 포스팅용 정리만 필요로하니, 오래 걸리지 않도록~ 하겠습니다.)

혼자 정리하고 시일이 조금 길어져서, 포스팅이 약간 메끄럽지 않더라도~ 이해하시는 크게 어렵지는 않도록 최대한 많은 사진 예제로

정리해보았습니다.

 


Docker 이미지

    Docker의 이미지는 Layer들의 모임으로 구성있다. 

    Docker의 Lightweight한 특징이자, 강점의 이유 또한 이러한 Layer 구성 때문이기도 하다. 

    그럼 지금부터, Docker 이미지의 Layer 구성이 어떤 것인지 예를 가지고 하나씩 이해해보자.

 

 

 

 

Docker 이미지 생성하여 이미지 크기 확인하기

    현재의 디스크 사이즈 확인 : Used 5739664

 

 

 

 

Ubuntu:14.04(188.3MB)를 기본 이미지로, zigiweb 이미지를 새로 Build함.

  

 build 시 사용한 Dockerfile

FROM ubuntu:14.04

MAINTAINER ZIGI  SPACE<zigispace.net>

RUN apt-get update                                          

RUN apt-get install -y nginx

RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf

RUN chown -R www-data:www-data /var/lib/nginx

VOLUME ["/data", "etc/nginx/site-enabled", "/var/log/nginx" ]

WORKDIR /etc/nginx

CMD ["nginx"]

EXPOSE 80

 

•새롭게 생성된 zigiweb 이미지의 사이즈를 보면, 227.9MB로 표기가 된다.

•이 때, zigiweb 이미지의 history를 확인해 보면, 실제 Base 이미지(여기서는 ubuntu:14.04)에서 부터 어떠한 과정을 거쳐서

   최종 zigiweb 이미지가 생성되었는지를 알 수 있다.

•History에서의 우측의 Size를 보면, 최초 Base Image가 Size로부터 각 단계별로 이미지가 어떻게 증가되고 있는지를 볼 수 있다.   

 

 

•zigiweb 이미지가 생성되었으니, 다시 한 번 현재 디스크 사이즈를 확인해보면

   Used : 5780780 으로 변경되었음을 볼 수 있다.

 

•이제 현재까지 확인한 디스크 사이즈와 이미지 사이즈를 가지고 정리를 해보면 아래의 표와 같이 구성된다.

•최초 베이스 이미지는 192,614.4KB(188.1MB * 1024)       

   거기에 각 zigiweb build를 수행하면서 Size상에 나타난 Step별 용량을 모두 더한다. (모두 KB로 변환)

•Base Image Size와 Build Step별 수행 시 증가한 사이즈의 합을 보면 233,332.1KB이 되고 이를 MB로 전환하면

   227.9MB (zigiweb 이미지 크기)이 됨을 알 수 있다.

•이제 df -k 확인 했던 이미지 크기를 가지고 다시 Used 이미지 크기를 비교하면

   Build 전에는 5739664였던 used size가 zigiweb build 후에는 5780780이 됨을 볼 수 있고, 이 크기의 차이를 구해보면

   약 40MB 차이가 난다.

•ubuntu:14.04의 이미지와 zigiweb 이미지의 차이도 약 40MB가 됨을 알 수 있다.

•즉, 하나의 Docker 이미지를 생성하게 될 경우에 새롭게 이미지가 모두 만들어 지는 것이 아니라, 기존 base 이미지 위에 추가 된 내용만

   덧붙여진 이미지가 Layer 형식으로 구성됨을 알 수 있다.

 

 

 

•다음의 그림을 현재 Docker 버전에서는 지원되지 않는 명령인,

   Docker image --tree 

   명령을 수행한 결과이다. 

이 명령어는 이미지 history에 따른 Image ID와 각 이미지의 용량을 확인할 수 있는 데, 이 이미지의 크기는 전체 이미지가 아니라,

   기존 이미지 + 증가분 크기를 나타내게 된다.

   

 

 

 

Docker Container 생성 시의 디스크 사용량 확인

이번에는 Docker Image를 가지고 Container를 생성한 후에 디스크 사이즈를 비교해본다.

•Container 생성 전에 df -k로 현재 used 용량을 확인하고, Container를 생성한 후에 다시 Used 용량을 비교해보면

   실제 용량이 증가가 거의 일어나지 않음을 알 수 있다. 즉, 이미지를 가지고 Container를 생성 시에도 Docker 이미지의 크기만큼

   새롭게 만들어서 Container화 시키지 않고 Container는 해당 이미지의 공간을 그대로 사용함을 알 수 있다.

 

 

•그렇다면, 생성된 Container에서 Disk를 추가로 사용하게 될 경우에는 디스크 사이즈에는 어떤 변화가 생길 것인가?

   아래와 같이 Container에서 임의 20MB를 사용하는 것처럼 할당해보면,

 

•Used 사이즈가 약 20MB (5788224 → 5799224 :KB) 변화하였음을 볼 수 있다.

    

 

 

Docker Layerd 이미지 확인

이제부터 실제 Docker의 Layerd 이미지가 어떻게 구성되는지에 좀 더 알아보자.

•docker inspect 명령을 사용하게 되면, 현재 이미지의 상세 정보를 볼 수 있는 데, 여기에 나온 정보를 이제부터 확인해보자.

 

•먼저, Ubuntu:14.04에 대한 정보의 일부를 살펴보면, 상단에 이미지 ID, Parent ID 등의 정보와 함께 아래 쪽에는

   VirtualSize라는 항목이 188304295 임을 볼 수 있다.  그리고 Size는 0이다.

 

 

 

•다음으로 zigiweb 이미지의 정보를 보면, 마찬가지로 이미지 / Parent ID정보와 함께 아래 쪽에는

   VirtualSize 항목이 227877825임을 볼 수 있다.   마찬가지로 Size는 0이다.

 

 

 

•이 정보만으로는 어떤 내용인지 알기가 어려우니, 아까 전에 살펴 본, history 명령으로 zigiweb 이미지가 만들어진 내용을 다시 보자. 

 

 

•제일 앞의 IMAGE ID가 위의 inspect에서의 ID의 앞 12자리임을 알 수 있는 데, 매치시켜보면

   ubuntu 14:04의 이미지는 아래의 history에서 아래부터 4번째 이미지이고 (즉, ubuntu 이미지도 몇단계의 작업을 거친 이미지이다)

   zigiweb 이미지는 제일 위의 이미지인 것을 확인할 수 있다.  

 

•먼저 inspect에서 표기되는 Image ID는 자신의 Image ID인 것은 이미 알고 있고, Parent ID는 history에서 살펴보면, ID 바로 아랫 줄의

   ID와 동일한 것을 알 수 있다. 즉, Parent ID는 자신의 Image의 바로 직속 Base Image를 뜻하는 것이다.

  (마치 OOP에서의 클래스 상속처럼..)

 

•다음으로 위에 나온 VirtualSize와 Size가 이제 어떤 뜻인지 보면,

   VirtualSize는

        현재 가리키고 있는 이미지의 Base이미지 + 현재 Step에서 증가된 이미지 크기

   이다.

 

•즉, zigiweb이라는 이미지의 크기는 227877825인데, 이 이미지의 ID는 5242- 이다.

   이 때 zigiweb의 base 이미지는 ubuntu:14.04로부터 만들어지지만, 각 step을 거치면서 각 step마다 이미지가 생성이 된다.

   즉, 이미지 ID 5242의 base 이미지는 d374-(2번째 줄)이 되고, d374-의 Base 이미지는 다시 0a5a-(3번째 줄)가 된다.

 

•그렇다면, Size가 0인 것은 해당 이미지의 Step에서는 추가로 Size가 증가되지 않았기 때문에 '0'이라는 것을 알 수 있다.

 

•다음은 8aaf98371fcb 이미지의 inspect 정보이다.

  이 이미지는 1615(1.615KB)가 증가한 step이기 때문에 Size가 1615로 표기되고, Virtualsize는 1615를 포함한 전체 사이즈가 된다.

 

 

 

Posted by 네떡지기
분류없음2015.05.26 17:08

Docker, Dockerfile, run, commit, built, attach,  image , container : today Keay

 

개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인

Docker의 3번째 포스팅입니다.  이번 포스팅에서는 Docker File을 사용하여 Docker 이미지를 만들어 봅니다.

Docker Image로 Container를 생성하고, 생성된 Container의 내용을 변경하고 변경된 Container를 이용하여

다시 새로운 Docker 이미지를 생성해봅니다. 그리고 그렇게 만들어진 이미지가 새로운 Container에 적용되는지를 알아봅니다.

 


 

Docker File로 이미지 생성하기

   - 기존 Docker 이미지와 Docker File을 사용하여 새로운 Docker Image를 생성

   - Docker File에는 필요한 내용들에 대해서 명세해 놓음. [Docker File에 대한 포스팅은 추후 포스팅 할 예정입니다]

   - Docker 이미지를 생성은 build 명령을 사용합니다.  이 때 tag 옵션을 사용하여 해당 이미지의 repository name을 지정하며,

     이 이름은 소문자, 숫자, '_', '.' 으로 이뤄지며, 대문자는 되지 않습니다.

   - # docker build --tag repository_name:tag

 

 

 

   - 생성한 이후의 dockar images 명령을 사용하여, 생성된 이미지를 다음과 확인할 수 있다.

 

 

   - Docker 이미지를 생성하는 데, 사용된 Docekrfile의 내용이다.

     추후에 다룰 예정이지만, 간단하게 몇 가지만 보면

     * FROM으로 생성한 이미지의 base 이미지를 지정합니다

        이 이미지는 Local에 존재하면 그 이미지를 사용하며 없으면 Docker Hub에서 가져옵니다.

     * MAINTAINER는 해당 이미지를 만든 사람을 기록한다.

     * RUN 으로 생성된 이미지에 적용된 명령을 넣는다.

     * VOLUME, WORKDIR, CMD, EXPOSE 등 나머지 옵션은 다음 포스팅에서 다룰 예정입니다.

   - Dockerfile에 기록된 항목은 Dockerfile에 기입하기도 하지만, Container 생성 시에 옵션으로 적용하기도 합니다.

     이 경우에는 Dockerfile보다는 옵션 값이 더 우선 시 됩니다.

 

 

 


 

 

 

Docker File로 생성한 이미지를 Container 만들고, 확인하기

 

    - Docker Image로 이제는 Container를 만들고 실행해 봅니다.

    - 방금 전에 위에서 생성한 nginx를 설치한 Docker image를 사용하여 Container를 만듭니다.

    - Container는 docker run 명령을 사용하며 각종 옵션을 사용할 수 있습니다.

      아래에서 사용된 옵션 중 -p는 Port Redirection을 하는 역할을 합니다. Host_Port:Contaner_Port 로,

      아래 예제는 Host의 8001 포트로 접근하는 것을 Container 80으로 전달합니다.

    - # docker run <option> <image_Repo | image ID> <runnning_process>

    - 현재 동작 중인 Container 확인은 docker ps  명령을 사용하여 볼 수 있습니다

 

 

    - 위와 같이 Container를 만들어서 구동 시키게 되면, Host의 8001로 접근하여 해당 Container의 80서비스를 열 수 있습니다.

      아래는 8001로 접근하여 nginx! 초기 페이지가 열린 것을 확인 할 수 있습니다.

 

    - 이번에는 다른 옵션을 사용하여 Container를 만들어서 실행해봅니다.

    - 마지막 Container에서 실행 할 값을 /bin/bash 로 입력했습니다.

    - 위의 에제에서는 Dockerfile에서 nginx를 구동하도록 되어 있지만 /bin/bash로 변경하였기 때문에 해당 명령을 쉘을 제어하게 됩니다.

    - Container 생성 후, 상태를 보면 아래와 같이 COMMAND 부분이 /bin/bash로 된 것을 볼 수 있습니다.

 

 

 

 

    - Host에서 Container로 docker attach 명령을 사용하여 접근하여, nginx 구동 후 동일하게 서비스가 되는 것을 볼 수 있습니다.

    - # docker attach [Container_name | Container_ID ]

 

 

 

 

 


 

 

Docker Container의 데이터 수정 후, 변경된 Container을 Docker 이미지로 Commit

    - 이번에는 Container 내부의 데이터를 수정하여, 변경된 사항에 대한 Container를 가지고 이미지를 생성해봅니다.

    - Docker 이미지로 Container를 만드는 것과 반대로, Container로 Docker 이미지를 만드는 작업입니다.

    - 테스트를 위해서 nginx의 index.html을 아래와 같이 변경해보았습니다.

    - 8001로 접속 시에, 초기 메시지가 변경된 것을 볼 수 있습니다.

 

  

 

   - 새로운 이미지를 만들기 전에, 현재 이미지를 확인해봅니다.

   - docker commit 명령을 사용하여 새로운 이미지를 만듭니다.

   - docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]   

      * -a , --author=""   : Image 제작한 사람

          -m, --message="" : commit 메시지

   - zigi/nginxubuntu:0.2 이미지가 생성된 것을 볼 수 있습니다. 이 이미지는 zigi1 Container를 통해서 만들어졌습니다.

 

 

   - 새로 만들어진 이미지로, 새로운 Container(zigi2)를 생성합니다. 

   - 새로운 Container는 8002포트에서 대해서 80포트로 Redirection 되도록 하였습니다. 

 

 

   - 새로운 Container의 nginx 서비스가 구동하고 나면, index.html이 변경된 nginx가 구동된 것을 확인할 수 있습니다.

 

  

Posted by 네떡지기
분류없음2015.05.24 21:52

 


Docker, Openplatform, install, setup, image , container : today Key

 

개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform인

Docker의 2번째 포스팅입니다.  이번 포스팅에서는 Docker를 사용하기 위해서 설치하고, 간단하게 Docker를 이용하여

Container를 만들어서, 동작/정지 등의 기본적인 기능을 수행해보며, 마지막에는 전체 Flow를 간단하게 알아봅니다. 


Last Updated : 2015. 08. 26  


 

 

Docker 설치하기 (Ubuntu 14.04 기준)

    - docker.io 패키지를 아래와 같이 설치

 

 

          ※  리눅스 배포판을 자동으로 인식해서 Docker를 설치하려면 다음과 같이 하면 된다.

                 wget  -q0- https://get.docker.com/  | sh

 

 


 

Docker 시작하기

 

•Docker에서 사용 가능한 이미지 조회

     -  # docker search TERM

   - 엡에서 설치 가능한 이미지 조회하기 : https://registry.hub.docker.com

   - 이미지 이름에 / 들어간 이미지의 경우에는 일반 User Docker Hub 업로드한 이미지로,

     공식 이미지의 경우에는 User명이 붙지 않음. 

 

 

[Web에서 확인]

 

 

 

 

•Docker 이미지 다운받기

    - Docker Hub에서 원하는 이미지를 다운 받고자 할 떄 사용.

    -  # docker pull <image_Repo>:<TAG> 

    - TAG는 Version이 되며, 미 지정시에는 Latest(최신 버전)으로 다운받게 된다.

 

•Docker 이미지 리스트 확인(Local)

    - 현재 Local 에 있는 Docker 이미지 정보 확인

    - # docker images 

 

 

 

 

   

•Container 생성하기

    - Docker Image와 Docker File을 가지고, Docker Container을 생성.

    - # docker run <option> <image_Repo | image ID> <runnning_process>

 

•Container 프로세스 확인

    - 현재 생성된 Container 확인.

    - default로는 현재 구동 중인 Container에 대한 정보만 표기되며, 정지된 Container까지 보려면, -a 옵션을 사용한다.

    - # docker ps <option> 

 

 

 

 

•Container 정지 / 시작 / 재시작

    - 생성된 Container를 시작(Start),정지(Stop),재시작(Restart)

    - # docker < start | stop | restart > <container_ID | NAMES>

 

 

 

•Container 삭제

    - 생성된 Container 삭제 (Container가 정지된 상태에서 삭제)

    - # docker rm <container_ID | NAMES>

 

 

 

•Docker 이미지 삭제

    - Docker 이미지 삭제 

    - # docker rmi <Repo:Tag | IMAGE_ID>

 

 


Docker Flow  

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2015.04.14 21:21

 

 

Docker 란?

 

 - 개발자와 Sysadmin을 위해서 빌드(Build)하고, 이동(Ship)하고, 분산된 어플리케이션을 실행(Run)하기 위한 OpenPlatform이다.

 - Docker는 Application이 개발, QA, Production 등의 각기 다른 환경의 차이에 따라 발생할 수 있는 문제점을 제거한다.

 - 결과적으로 Laptop, Datacenter의 VM,  혹은 어떠한 Cloud 환경이든 상관없이 빠르게 동일한 어플리케이션을 실행할 수 있게한다.

 

 

 

 

 

 

Docker Concept

 - 기존의 VM이 Hardware와 OS의 모든 부분까지 가상화하는 것에 비해서, Docker는 기존의 Host OS의 기본 Kernel 등을 그대로 

   공유해서 사용하여, 기존의 VM에서의 Guest OS 전부 가상화 하지 않아도 된게 해준다. 

 - Docker에서의 Guest OS는 Host OS를 기본 Kernel을 사용하며, 그 위에 필요한 부분만 Packing을 하게 되기 떄문에 기존의 VM방식

   보다 성능에 대한 이슈가 줄어들게 된다. 

 - 이러한 Docker의 Guest OS는 Linux Container(LXC)를 사용하는 방식으로 사용된다. 

 - LXC를 사용하므로써, Guest OS를 Host OS로 부터 Isolation하게 동작하게 한다. 

 - 기본적 Linux에서만 동작하지만, Windows와 Mac에서도 VM을 포함하여 Docker를 사용할 수 있다.  

 - 즉, 어플리케이션을 구동하기 위한 최소한의 Dependency한 요소만을 Docker Container에 포함하여, 어느 곳에나 실행할 수 있는 

  형태의 Docker Image로 Shipping(Boxing)하는 것이다. 이러한 작업은 기존의 프로그래밍 언어에서 객체의 직렬화를 Serialized라고

  한 것처럼, Dockerized라고 부른다. 이렇게 Dockerized된 이미지는 어느 환경에서나 동일하게 실행될 수 있다.  .

 

 

○ VM에서는 애플리케이션을 구동하기 위한 Binary/Library 뿐만 아니라, Guest OS의 모든 부분까지 가상화 한다.

○ Docker에서는 애플리케이션을 구동하기 위한 최소한의 Binary/LIbrary만 포함하며, Host OS에서 User공간에 격리된 Process로

   동작하여, 기존 VM과 같은 효과를 가지면서 Mobility를 최대화 한다.

   (Host OS와 Docker Image의 Linux가 서로 상이해도 기본적인 Kernel은 동일하게 사용하기 때문에 사용 가능하다) 

 

 

 

Docker의 용어 정리

  • Docker : Linux Container(LXC)를 관리하는 도구

  • Docker Container : Docker가 관리하는 LXC Process.

  • Docker Host : 하나 이상의 Docker Container를 실행하는 Linux 서버

   Docker Daemon : Docker의 실제 Process Daemon으로, Docker Client로부터 요청을 받아서, Docker Container를 관리

  • Docker Client : Docker 명령을 실행하는 장비로, Docker Host가 그 역할을 할 수도 있고, 별개의 장비일 수도 있다.

                        또한, Linux가 아닐수도 있다.

  • Docker Image : Docker Container의 초기 상태를 기록한 파일. 즉, 원하고자 환경을 만들어 놓은 이미지 파일.

                         즉 VM과 유사한 파일이라고 볼 수 있다.

  • Docker Hub : Git Hub와 유사하게 다양한 Docker Image를 보관하는 이미지 저장소

 

 

Posted by 네떡지기

티스토리 툴바