[오픈소스컨설팅]오픈소스 클라우드 개발플랫폼_및_Docker의_이해_v1

1. 클라우드 환경 개발 플랫폼 및 Docker의 이해 ㈜오픈소스컨설팅 2014. 08. 28 최 지 웅(jchoi@osci.kr)

2. 2 - Internal Use Only - Index 오픈소스 클라우드 개발 플랫폼 - PaaSI Docker 소개II

3. 3 - Internal Use Only - 모바일 확산 기존의 기업 모델의 변화, 수많은 스타트업의 등장, 린스타트업

4. 4 - Internal Use Only - 트렌드 변화 Mobile 클라우드 소셜 빅데이터 모바일(스마트폰) 에 의한 데이터, 애플케이션, 엔터프라이즈 아키텍처 변화

5. 5 - Internal Use Only - 클라우드 컴퓨팅 환경으로의 변화 1990 20102000 Web ITEnterprise IT Cloud IT  전용 Network  Appliance HW  License SW  확장성  Open API  고집적화  Open Source SW  Platform화  IOPS 예측 가능  IOPS 예측 불가  교환망/전송망 중심  IP망(Shared Network)  내부전용(Silo)  Service용(외부판매) 구축형, Manual  Commodity HW  종량제, 자동화  Expert only  Everyone 사용환경HW/SWNetwork  표준화/통합화  CDN  소용량 Data  대용량 Data  System Network 중요App에서 Network 이슈 없음 Data Traffic 210X ↑  SDN

6. 6 - Internal Use Only - 클라우드 컴퓨팅 서비스 • SaaS : 소프트웨어를 서비스로 제공하며, 사용료 지불 방식에 따라 서비스 비용을 지불, 표준화된 애플리케이션 프로세스 제공 (Salesforce.com, MS Office Live 등) • PaaS : 애플리케이션 개발과 조합 가능한 플랫폼 제공(SW 개발환경)(Google Apps 등) • IaaS : 서버, 스토리지, 네트워크 등 인프라 자원을 사용량 기반으로 제공, 기본 스토리지와 컴퓨팅 능력을 제공(CPU, Disk 등)(Amazon EC2, S3 등) 계산자원 가상화 스토리지 가상화 네트워크 가상화애플리케이션 IaaS SaaSPaaS Software as-a-ServicePlatform as-a-ServiceInfrastructure as-a-Service Salaesforce, MS Office LiveGoogle App Engine, MS Azure, AWSAmazon EC2/S3, BlueLock 프레임워크, API 제공 애플리케이션 제공

7. 7 - Internal Use Only - 가상화 전환 – 개발/테스트/운영 시스템SW 확장 OS Multi-App 환경 App App App OS x86 서버 아키텍처 App 장애/간섭, 선택/Hang 사용률 Virtualization 가상화 환경 OS App OS App OS App 고성능 H/W 단일 OS, 다중 애플리케이션 단일 H/W, OS, 애플리케이션 파티셔닝, 캡슐화, 격리 서버 사용률 개선, 서버 즉시 확장 등의 IT 자원의 효율화 서버 통합을 통한 TCO 절감, 유연성 및 확장성의 제고라는 다양한 효용성 제공 운영체제, 네트워크, 스토리지 등의 다양한 가상화 종류 즉시성 제공 – 새로운 서버 생성에 10분을 넘기지 않음

8. 8 - Internal Use Only - 클라우드 서비스 환경

9. 9 - Internal Use Only - 소프트웨어 개발환경의 변화 1세대 (Language) : OS 위에 컴파일러를 사용한 개발언어 중심으로 어플리케이션을 개발하던 세대. 이때는 개발자의 선택에 따라 모든 것을 정할 수 있었지만, 각각을 setting 해줘야 한다. 2세대(Library) : 공통 라이브러리들을 분리하면서, 라이브러리를 사용한 개발세대로 돌입했다. 개발자들은 자주 사용되는 함수(그래프, UI, 계산)등을 매번 구현할 필요없이 라이브러리를 사용하여 쉽게 개발할 수 있게 되었다. 하지만 개발환경 테스팅 환경이 필요하다. 3세대(Framework) : 공통 라이브러리와 함께 다양한 패턴 등이 발전하며, 공통 개발방식을 찾아내어, 개발을 좀 더 유연하게 효율적으로 할 수 있는 방법들을 찾기 시작했다. 이렇게 만들어진 프레임워크를 통해 DB Access 분리, Testing, 개발환경 등을 구축할 수 있게 되었다. 4세대(Platform) : 플랫폼으로 발전하면서 개발은 더욱 쉬워졌다. 각 벤더사에서 ALM 및 라이선스까지 관리해주며, App Store를 사용하여, 활성화 시켰다. 하지만 App은 플랫폼에 의존하게 되었다. 5세대(Cloud) : 클라우드 PaaS의 발전으로 하드웨어까지 통합하여 제공하게 되었다. 하드웨어, DB, WAS등도 선택할 필요가 없어졌다.

10. 10 - Internal Use Only - 플랫폼 개발 환경의 변화 PaaS 환경 1.업무 개발 계획 수립 2.예산 산정 3.코드 개발 4.테스트 5.실행 6. 자동 확장 1.업무 개발 계획 수립 2.예산 산정 3.VM 생성 요청 4.대기 5.framework/appserver 설치 6.테스트 툴 설치 7.테스트 툴 시험 8.코드 개발 9.운영 VM 구성 10.코드 업로드 11.실행 12.요구에 따라 운영VM 추가요청 13.대기 14.새로운 VM에 운영환경 구성 15.기타 작업 가상화 환경 1.업무 개발 계획 수립 2.예산 산정 3.하드웨어 구매 요청 4.대기 5.하드웨어 구매 6.하드웨어 설치 7.OS 설치 8.OS 패치 적용 9.사용자 계정 생성 10.framework/appserver 설치 11.테스트 툴 설치 12.테스트 툴 시험 13.코드 개발 14.운영 서버 구성 15.코드 업로드 16.실행 17.요구에 따라 새로운 서버 구매 18.대기 19.새로운 서버 구성 20.기타 작업 물리적인 환경 기존의 개발환경 시스템 구성에 상당한 시간을 애플리케이션 개발에 집중하는 것이 가능

11. 11 - Internal Use Only - 서비스 관점에서의 클라우드 플랫폼 권한별 사용자를 위한 셀프서비스 포털 제공 출처: DataNet - http://pdf.datanet.co.kr/207/207114.PDF

12. 12 - Internal Use Only - PaaS(Platform as as Service) 클라우드 공급자에 의해 지원되는 프로그래밍 언어, 라이브러리, 서비스, 툴들 을 이용하여 생성된 애플리케이션이나 인프 라 사용자에 의해 생성된 애플리케이션을 배포할 수 있는 능력(기술). 사용자는 네트워크, 서버, OS 같은 클라우드 인프라스트럭처를 관리하거나 컨트롤하지 않으나 배포 제어 가능. – NIST - 자료 : NIST’s Cloud Cube Model 특징 설명 확장성 사용자가 언제나 필요한만큼의 리소스를 할당받을 수 있도록 서비 스 제공 서비스 중심 인프라스트럭처 서비스 관점으로 구성한 플랫폼 서비스 카탈로그 형태 제공 셀프 서비스 사용자가 포털을 통해 서비스 카탈로그에서 필요한 리소스를 선택 하고 라이프 사이클 서비스를 제공 자동 프로비저닝 환경 요청된 서비스에 따라 운영체제, 네트워크, 스토리지, 시스템 소프트 웨어까지 자동화된 프로비저닝 제공. 서비스 회수를 위한 디-프로비 저닝 환경 가상화 빠르고 유연한 프로비저닝과 효율성을 위한 가상화 환경 제공 과금 사용량만큼의 과금 정책을 사용

13. 13 - Internal Use Only - PaaS 특장점 개발환경 접근용이 : 클라우드 기반 환경 개발시간 및 비용 절감 : 개발시스템,S/W 구매/도입/설치 등의 절차 불필요 개발 편이성 : 손쉬운 애플리케이션 설치 자동화 확장성 : 개발자별 사용 패키지 추가 및 배포 용이 개발 환경 및 개발 프레임워크 표준화 용이 : 표준화 버전 적용 소스 코드 관리 용이 배포 편리 : 빌드, 배포툴 기본 제공 개발자단에서의 제어와 배포를 할 수 있는 DevOps 가능 멀티테넌시, 공유, 셀프서비스, 유연성, 자동 프로비저닝, 확장성 등의 기능 제공

14. 14 - Internal Use Only - PaaS를 통한 DevOps 환경 DevOps는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합 을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다. DevOps 는 조직에서 소프트웨어 상품과 서비스 를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다. - Wikipedia – Best Practice 자동화된 빌드와 릴리즈 자동화된 인프라스트럭처와 시스템 프로비저닝 DevOps 팀간의 일관된 도구 사용 설정과 같은 코드는 어플리케이션 코드와 분리 공유가 가능한 버전 관리 도구 보유 감사시 릴리스 추적 가능(요구사항에서 운영까지) 모델화된 수명주기

15. 15 - Internal Use Only - 클라우드 환경의 소프트웨어 개발 소프트웨어 라이프사이클 영역의 클라우드 사용률 조사 소프트웨어 운영 환경의 as-a-Service 영역 When asked which cloud-based services they use in software production, the top two answers were PaaS and IaaS. This is not a surprise based on market perceptions, but it is surprising that PaaS is being used by 58% of respondents while slightly fewer are using IaaS (52%). This shows just how far PaaS has come in the last few years, offering more choices and flexibility than ever before. Based on these results, organizations seem to be very interested in the fast development speeds that PaaS can enable. 출처: Dzone 2014 Cloud Platform Report, 2014.03

16. 16 - Internal Use Only - PaaS 제공자

17. 17 - Internal Use Only - PaaS 솔루션 제공자 DotCloud Java, Ruby, Perl, Python, PHP 등 다양한 언 어, 프레임 워크, DB를 지원하는 PaaS Heroku Salesforce.com에서 제공하는 서비스로 Ruby 와 Node.js에 대응한 PaaS. Git 등과 연계하여 자체 애플 리케이션을 배포 Cloud Foundry vm ware 제공하는 PaaS. Spring (Java), Rails와 Sinatra (Ruby), Node.js와 Grails와 같은 프레임 워크와 MySQL, Redis, MongoDB 등의 DB를 지원 Google App Engine Google의 PaaS. Python과 Java를 지원 Windows Azure 마이크로소프트 PaaS. Windows 환경, SQL Server와 각종 언어에 대응. OpenShift Red Hat에서 제공하는 PaaS. Java, Python, PHP, Ruby 및 Spring, Seam, Weld, CDI, Rails, Rack, Symfony, Zend Framework, Twisted, Django, Java EE와 같은 프레임워크를 지원

18. 18 - Internal Use Only - CloudBees 항 목 내 용 특징 운영 환경에서의 애플리케이션 라이프사이클과 구동을 위한 개발, 디플로이 프로세스를 자동화. Jenkins를 사 용하여 개발팀과 DevOps 팀이 지속적 통합을 수행할 수 있는 기반 환경을 제공 장점 • PaaS 전체 라이프사이클 제공 • 지속적 통합을 위한 Jenkins 서비스 제공 • 고사양의 JVM 기반 런타임 운영 환경 제공 • 모바일 및 백엔드 서비스 통합 기능 지원 • APM, DBaaS, SaaS 개발툴과 네트워크를 통한 확장 가능 지원언어 Java, PHP, JavaScript, Groovy, Clojure, Scala 무료영역 5개의 애플리케이션, 월당 300분의 빌드시간 서비스 영역 Application Containers App Server-as-a-Service Integration PaaS(ESB-as-a-Service) Database-as-a-Service 고객사 Netflix, ChooseDigital, Groupe Adeo, Bullhorn Inc., Viridity Energy, Lose It

19. 19 - Internal Use Only - Stackato 항 목 내 용 특징 Cloud Foundry와 Docker를 지원하는 상용 PaaS 서비스 제공하며, 애플리케이션 미들웨어로써 클라우드 인프 라스트럭처 상에서 수행. 런타임, 웹 프레임워크, 데이터 및 메시징 서비스에 필요한 설정을 자동화 해줌. 관리자는 사용자 권한, 애플리케이션 컴포넌트, 스케일링과 메모리를 웹 인터페이스와 CLI를 통해 제공 장점 • Cloud Foundry, Docker를 포함하는 오픈 소스 기술 구현 • 프라이빗, 퍼블릭, 하이브리드 클라우드 IaaS 환경 지원 • 서비스, 클러스터 노드, 사용자, 모니터링을 제공하는 콘솔 제공 • 무중단 서비스 기능 제공 • 기존의 애플리케이션을 쉽게 마이그레이션 가능 지원언어 Java, Ruby, Python, Perl, PHP, JavaScript, Go, Groovy, Clojure, Scala, HTML/XML, Erlang, Haskell 무료영역 애플리케이션 4GB 메모리 제한 서비스 영역 Routing, Queuing, & Scheduling System Application Containers App Server-as-a-Service Database-as-a-Service 고객사 HP, Mozilla, MTN Communications, ExactTarget, Cisco, Nelnet

20. 20 - Internal Use Only - Pivotal CF 항 목 내 용 특징 Pivotal CF라는 이름의 Cloud Foundry 기반의 엔터프라이즈 PaaS. 다운타임없이 확장하고 디플로이 가능하도 록 서비스를 제공하며, 빅데이터 프레임워크를 통합한 첫번째 PaaS 서비스 장점 • 프로비저닝과 바인딩된 아파치 하둡 상에 애플리케이션을 구동하는 통합 플랫폼 제공 • 리눅스 상의 모든 프레임워크와 언어를 확장할 수 있는 유연한 런타임 서비스 제공 • Pivotal One 서비스로의 자동화된 프로비저닝과 바인딩 - Pivotal HD, Pivotal RabbitMQ and Pivotal MySQL • IaaS와 통합된 PaaS를 제공하고, vSphere 프라이빗 클라우드에 디플로이 가능 지원언어 Java, Ruby, JavaScript, Groovy 무료영역 Pivotal CF: Trial 90일 사용 가능 Pivotal Web Services (run.pivotal.io): Trial 60일 사용 가능 서비스 영역 Routing, Queuing & Scheduling System, Application Containers, App Server-as-a-Service, Database-as-a- Service 고객사 Warner Music, GE, Verizon

21. 21 - Internal Use Only - Apache Stratos 항 목 내 용 특징 대표적인 오픈소스 PaaS 솔루션으로 Tomcat 서버, MySQL, PHP 컨테이너 자원을 공유하고 확장하는 서비스 제공. 사용량, 자동화된 리소스 관리, 모니터링, 빌링을 포함하는 컴포넌트 제공하며, IaaS 서비스와 통합 가능 장점 • Cloud-native architecture • 확장형 카트리지 모델 • Amazon EC2, OpenStack 또는 vCloud에 디플로이 가능 지원언어 Java, PHP 무료영역 오픈 소스 서비스 영역 Routing, Queuing & Scheduling System, Application Containers 고객사 Cisco, Boeing

22. 22 - Internal Use Only - Google App Engine 항 목 내 용 특징 구글 인프라스트럭처상에 애플리케이션을 디플로이하기 위한 PaaS 솔루션. 자동 스케일링, 로드밸런싱, 스토 리지와 구글 클라우드 서비스와 통합 가능. 개발을 위한 무료 SDK를 제공하며 다양한 언어를 제공 장점 • 스토리지 저장 데이터에 대한 쿼리, 소팅, 트랜잭션 제공 • 자동 스케일링 및 로드 밸런싱 기능 지원 • 요청 범위를 벗어나는 작업을 수행하기 위한 비동기 태스크 큐 서비스 제공 • 특정 시간에 이벤트를 처리하는 스케줄 태스크 • 구글 클라우드 서비스 및 API와 통합 가능 지원언어 Java, Python, PHP, Go 무료영역 무료 애플리케이션의 경우 무료 서비스 서비스 영역 Application Containers, App Server-as-a-Service 고객사 Rovio, Khan Academy, blossom.io, Snapchat

23. 23 - Internal Use Only - Heroku 항 목 내 용 특징 사용자의 프로젝트에 적합한 기술을 신속하게 반복하고 채택하는 데 필요한 도구를 제공. 개발, 운영 영역에서 인프라스트럭처에 대한 고민없이 클라우드 서비스 제공자에서 제공하는 기능을 그대로 사용할 수 있음 장점 • 100 개 이상의 애드온 서비스를 제공하는 광범위한 라이브러리 제공 • 애플리케이션을 컴파일하기 위한 빌드 팩 모음 제공 • 소스로부터 특정 설정을 분리하고 관리 가능 • 임시 명령을 수행하기 위한 임시 인스턴스 환경 제공 지원언어 Java, Ruby, Python, JavaScript, Clojure, Scala 무료영역 각 애플리케이션당 512M 메모리, 1개의 Postgres DB 서비스 영역 Object Stroage, Routing, Queuing & Scheduling System, Application Containers, App Server-as-a-Service, Database-as-a-Service, Mobile Backend-as-a-Service (MBaaS) 고객사 Facebook, ASICS, MailChimp, GitHub

24. 24 - Internal Use Only - 오픈소스 클라우드 개발 플랫폼 조사 대부분의 클라우드 사용자들이 IaaS, PaaS 영역의 클라우드 서비스를 활용하여 개발, 테스팅, 디플로이를 수행 CloudFoundary, OpenShift 양대산맥 클라우드를 통한 생산성, 품질 향상이 이루어짐 자체 환경 구축과 클라우드의 차이점은 극명하게 나타남

25. 25 - Internal Use Only - CLOUD FOUNDRY vs OPENSHIFT 구분 Cloud Foundary OpenShift 아키텍처 작은 단위의 여러 개의 컴포넌트로 구성 2 개의 주요 컴포넌트로 구성 소스 저장구조 하나의 소스 저장 구조로 구성 다수의 소스 저장 구조로 구성 PaaS 설치 • BOSH 툴를 통한 설치 • IaaS 환경 필수적임 • 리눅스/가상머신을 통한 설치 • IaaS 환경이 선택적임 App 설치 컴파일 형태의(WAR) 저장 및 배포 소스코드 형태의 저장 및 배포 로드밸런싱 로드밸런싱 기능(Router) 내장 서비스(HA Proxy)를 통한 로드밸런싱 멀티테넌시 DEA 및 데이터 단위 멀티테넌시 Node 단위 멀티테넌시 확장성 Buildpack을 통한 서비스 확장 Cartridge를 통한 서비스 확장 출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07 각 기능 단위의 주요 차이점 요약

26. 26 - Internal Use Only - CLOUD FOUNDRY vs OPENSHIFT Health Manager Messaging(NATS) Service Broker DEA(Application Execution) 여러 컴포넌트의 조합 브로커(Broker) 노드(Node) 2개의 큰 단위 컴포넌트로 구성 기능항목으로 비슷하나 내부적인 아키텍처 구현 방법은 상이함

27. 27 - Internal Use Only - CLOUD FOUNDRY vs OPENSHIFT 출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07 구성 컴포넌트의 비교 맵핑

28. 28 - Internal Use Only - CLOUD FOUNDRY vs OPENSHIFT 웹 애플리케이션 배포 방식의 차이 출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07

29. 29 - Internal Use Only - 멀티테넌시 아키텍처 출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07 공유 데이터 vs 자체 보유 데이터베이스

30. 30 - Internal Use Only - PaaS 개발 환경에 대한 선택 조건 기업의 개발 문화, 라이프 사이클 사용의 편의성, 디버깅, 테스트, 확장성, 품질 관리 IaaS-like? SaaS-like? 서비스 vs 소프트웨어 운영환경 vs 개발환경 – 대용량 처리 트랜잭션 보안, 장애에 대한 대응

31. 31 - Internal Use Only - Index 오픈소스 클라우드 개발 플랫폼 - PaaSI Docker 소개II

32. 32 - Internal Use Only - 컨테이너 기반 플랫폼 Docker, Containers, and the Future of Application Delivery

33. 33 - Internal Use Only - Docker에 대하여 >50,000 pulls >4,000 github stars >100 컨트리뷰터 >150 개의 관련 프로젝트 • UIs, mini-PaaS, 원격 데스크탑 1000 개 이상의 docker 적용 애플리케이션 • Memcached, Redis, Node.js… Jenkins, Travis, Chef, Puppet, Vagrant and OpenStack과 통합 고객: Ebay, Uber, Mozilla, Cloudflare, and Rackspace, Google

34. 34 - Internal Use Only - Docker에 대하여 dotCloud 내부 프로젝트로 시작 (2013.01) python -> go docker는 현재 다음 기술들로 구현됨 • LinuX Containers • Control Groups & Namespaces • AUFS(ver1. Another Union FS, ver 2. Advanced Multi Layered Unification File System) docker는 어디서나 실행되는 경량화되고, 이식 가능한 컨테이너로 응용프로그램의 배포를 자동화하는 오픈소스 엔진 docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self sufficient container that will run virtually anywhere.

35. 35 - Internal Use Only - 개발, 테스트, QA, 배포 Static website Web frontend User DB Queue Analytics DB Background workers API endpoint nginx 1.5 + modsecurity + openssl + bootstrap 2 postgresql + pgv8 + v8 hadoop + hive + thrift + OpenJDK Ruby + Rails + sass + Unicorn Redis + redis-sentinel Python 3.0 + celery + pyredis + libcurl + ffmpeg + libopencv + nodejs + phantomjs Python 2.7 + Flask + pyredis + celery + psycopg + postgresql-client Development VM QA server Public Cloud Disaster recovery Contributor`s laptop Production Servers MultiplicityofStacks Multiplicityofhardw areenvironments Production Cluster Customer Data Center Doservicesandappsint eractappropriately? CanImigratesmooth lyandquickly?

36. 36 - Internal Use Only - 시스템 개발 구성의 악몽 – N x N Matrix Static website Web frontend Background workers User DB Analytics DB Queue Developme nt VM QA Server Single Prod Server Onsite Cluster Public Cloud Contributor’ s laptop Customer Servers ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

37. 37 - Internal Use Only - 1960년대 화물 운송 MultiplicityofGoods Multipilicityofmethods fortransporting/storing DoIworryabout howgoodsinteract (e.g.coffeebeans nexttospices) CanItransportquickly andsmoothly (e.g.fromboattotrain totruck)

38. 38 - Internal Use Only - 운송 또한 N x N Matrix ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

39. 39 - Internal Use Only - 화물 운송 해결책MultiplicityofGoods Multiplicityof methodsfor transporting/storing DoIworryabout howgoodsinteract (e.g.coffeebeans nexttospices) CanItransport quicklyandsmoothly (e.g.fromboatto traintotruck) 적재, 하적, 운반을 먼 거리까지 효율적 으로 수행하고 여러 곳으로 이동 될 수 있음(배->기차->컨테이너 트럭->목적지) 모든 상품이 적재될 수 있는 표준 컨테이너이며, 최종 목적지까지 봉 인 유지

40. 40 - Internal Use Only - N x N의 문제 해결

41. 41 - Internal Use Only - 복합 운송 컨테이션 생태계 활성화 90%의 모든 화물에 표준 컨테이너 안에 실려 운송 배에 선적, 하적시 시간과 비용, 도난 및 파손을 크게 줄임 최종 제품의 화물 운송 비용을 감소시킴 (from >25% to <3%) – 글로벌화 가능 5000대의 화물 운송성이 연간 2억개의 컨테이너를 수송 중

42. 42 - Internal Use Only - 코드를 위한 컨테이너 운송 시스템 Static website Web frontendUser DB Queue Analytics DB Development VM QA server Public Cloud Contributor’s laptop MultiplicityofStacksMultiplicityofhardw areenvironments Production Cluster Customer Data Center Doservicesandappsi nteractappropriately? CanImigratesmooth lyandquickly 가상화된 모든 하드웨어 플랫폼에서 표 준 기법을 사용하여 운영 모든 애플리케이션을 가볍고 이식 가능한 형태로 캡슐화하여 컨테이 너에 탑재

43. 43 - Internal Use Only - 보다 단순한 개발 운영을 가능케 함 Static website Web frontendUser DB Queue Analytics DB Development VM QA server Public Cloud Contributor’s laptop MultiplicityofStacksMultiplicityofhardw areenvironments Production Cluster Customer Data Center Doservicesandappsi nteractappropriately? CanImigratesmooth lyandquickly 운영자: 한 번 설정으로 모든 플랫폼에 적용 가능 개발자: 한 번의 빌드로 다양한 환 경에서 실행

44. 44 - Internal Use Only - 시스템 소프트웨어가 설치된 Live CD? Live CD, USB를 통한 운영체제 부팅 하지만 운영체제 자체가 RO(Read Only) 메모리에 하나의 운영체제만 로딩, 복수 개의 서버 불가 32 core, 128G 메모리 시스템을 하나의 OS로 처리?

45. 45 - Internal Use Only - 개발 vs 운영 관점 App A Bins/ Libs App A’ Bins/ Libs App B Bins/ Libs 서버 운영체제 DEVELOPMENT FOCUS ------------------------------------- APPS, CODE, DEPENDENCIES (LIBRARIES), DATA, AND PACKAGING OPERATIONS FOCUS --------------------------------- MONITORING, NETWORK CONFIGURATION, REMOTE ACCESS, AND LOGGING Code Test Deploy Monitor

46. 46 - Internal Use Only - 방법1 – 일반적인 개발환경 구성 정의: • 전통적으로 개발해온 환경 • 필요한 리소스를 계정을 통해 정의하고 시스템을 관리 단점: • 20년 이상 사용해온 시스템 관리 기법 • 서로 다른 사용자, 관리 부분에 대한 부담감 증가 Reduce#rowsviapolicy

47. 47 - Internal Use Only - 방법2 – 런타임 프로비저닝 환경 구성 Reduce # Columns via Chef/Puppet/etc. 정의: • Chef/Puppet과 같은 개발/운영환경 구성에 필요한 머신을 런타임시에 프로비저닝 단점: • Chef/Puppet은 시스템 프로비저닝의 강력한 도구 • 애플리케이션 혹은 소프트웨어 버전 업그레이드시 지속적인 버전 변경작업 필요 • 기업 외부에서 사용하기 어려움(보안)

48. 48 - Internal Use Only - 방법3 – 하드웨어 가상화 정의: • 각 애플리케이션을 위한 가상 머신을 생성하는 방법 단점: • 현재 가장 많이 사용하는 방법(서버 통합, 가상화) • 비용 및 시간이 많이 필요 • 하이퍼바이저 환경에 따른 상이한 가상 머신 • 소프트웨어 버전 변경시 새로 템플릿 구성해야 하는 번거로움(Chef 혼용 가능)

49. 49 - Internal Use Only - Foreman, PXEBoot, DNS 등 현재 - 가상화 기반 운영 관리 프로세스(1/2) 1 서버 입고 부팅과 함께 OS 설치 및 구성 2 Hypervisor 3 하이퍼바이저 등록 VM Pool VM Pool 4 VM 기본 템플릿 OS 컨트롤러 리포지토리 패치 관리 컨트롤러 VM 5 가상머신 생성 6 소프트웨어 설치/패치 관리 7 VM 할당 및 사용 복잡한 입고, 시스템 관리, 처리 프로세스를 사용

50. 50 - Internal Use Only - 현재 - 가상화 기반 운영 관리 프로세스(2/2) Middleware ③ 소프트웨어 분배 ⑤ OS deployment ② Compliance 위반 검사 배포서버 Control Server 배포 서버 ⑥ Report 스위치 스토리지 조작 지시 상황 표시 ① Inventory 수집 ④ 패치 분배 ⑦ Provisioning 소프트웨어 설치／제거 공개 및 상용 소프트웨어 제어 여러 서버로 에이전트/HTTP 동시 다운 로드 설치 대상 서버 제어 OS이미지를 네트워크 경유로 배포 설 치 에이전트 설치 및 구성정보 수집 OS 설정의 규정 위반 여부 검출 네트워크나 스토리지 장비 등에 대한 다양한 프로비저닝 기능 모든 변경이력・구성정보 등의 표준 report와 custom report 프로비저닝에 대한 자동화 프로세스를 중앙 관리 서버를 기준으로 진행

51. 51 - Internal Use Only - Like git, github vagrant@ienvyou:~$ Pulling repository centos 539c0211cd76: Downloading 61.8 MB/98.56 MB (63%) ~/workspace/usergrid-stack-origin:~$ git pull origin master remote: Counting objects: 291, done. remote: Compressing objects: 100% (121/121), done. remote: Total 210 (delta 79), reused 170 (delta 42) Receiving objects: 100% (210/210), 48.34 KiB, done. Resolving deltas: 100% (79/79), completed with 38 local objects. From github.com:apigee/usergrid-stack Git처럼 내가 필요한 그리고 업데이트된 항목만 받아볼 수 없을까?

52. 52 - Internal Use Only - Containers vs VMs App A Hypervisor (Type 2) Host OS Server Guest OS Bins/ Libs App A’ Guest OS Bins/ Libs App B Guest OS Bins/ Libs AppA’ Docker Host OS Server Bins/Libs AppA Bins/Libs AppB AppB’ AppB’ AppB’ VM Container 컨테이너가 분리되었지만, OS를 공유하고 바이너리/ 라이브러리를 사용 Guest OS Guest OS

53. 53 - Internal Use Only - 경량화 모델 Bins/ Libs App A Original App (No OS to take up space, resources, or require restart) AppΔ Bins/ App A Bins/ Libs App A’ Guest OS Bins/ Libs Modified App Union file system allows us to only save the diffs Between container A and container A’VMs 애플리케이션, 소프트웨어 변경시 새로 운 복제 서버(템플릿)를 생성하여 구동/배 포시켜야 함. App A Guest OS Bins/ Libs Copy of App No OS. Can Share bins/libs App A Guest OS Guest OS VMs Containers

54. 54 - Internal Use Only - Docker 기본 처리 로직 Source Cod e Repositor y Dockerfile For A Docker Engine Docker Container Image Registry Build Docker Host 2 OS 2 (Linux) ContainerA ContainerB ContainerC ContainerA Push Search Pull Run Host 1 OS (Linux)

55. 55 - Internal Use Only - 단순한 업데이트 Docker Engine Docker Container Image Registry Docker Engine Push Update Bins/ Libs App A AppΔ Bins/ Base Container Image Host is now running A’’ Container Mod A’’ AppΔ Bins/ Bins/ Libs App A Bins/ Bins/ Libs App A’’ Host running A wants to upgrade to A’’. Requests update. Gets only diffs Container Mod A’

56. 56 - Internal Use Only - 컨테이너 프로세스에 의한 성능 가상 머신이 아닌 Native를 직접 활용하므로 실제 베어메탈에 가까운 성능을 보임 프로세스들은 고립되어 있지만, host위에서 직접 실행 CPU performance • native performance ( 거의 차이 없음 ) Memory performance • a few % shaved off for (optional) accounting Network performance • 작은(small)의 오버헤드 발생 항목 방법 호스트 Docker CPU sysbench 1 0.9931 Memory sysbench seq 1(r) 0.9999 1(w) 0.9759 sysbench rnd 1(r) 1.0056 1(w) 0.9807 Disk dd 1 0.9716 Network iperf 1 0.7889 출처: Docker, lightweight linux container, Deview 2013 김영찬

57. 57 - Internal Use Only - 일반적인 빌드/배포 개발 테스트 git repository CI Jenkins Development Server Staging Server Production Server 개발, 스테이징, 운영에 대한 CI를 활용하여 라이프라이클 적용

58. 58 - Internal Use Only - 다양한 빌드/배포 방식 JENKINS CI RPM Repo DEV Hosts STG Hosts PRD Hosts Version Management Build and Reporting Automated Installation SVN (SRC) Develpoer PC SVN JENKINS CI Developer Admin Verification SVN Deploy Request RPM Build Proceed RPM REPO SERVICE HOSTInstall Update Manager 애플리케이션 코드와 운영 환경 소프트웨어에 대한 별도 패키징 및 디플로이

59. 59 - Internal Use Only - Docker를 활용한 통합 배포 개발 테스트 git repository git clone and docker build Development Server Staging Server Production Server Test Container Docker Container Image Registry 환경설정을 docker container에 포함하기 때문에 어디서나 동일하게 동작 애플리케이션 코드와 구동 환경을 항상 일치시킴

60. 60 - Internal Use Only - 요약 기존의 개발 방식에서 벗어난 새로운 형태의 개발, 운영 방식 등장함 가상화를 통한 서버 운용성 증대를 위한 노력이 진행됨 - IaaS 개발에 집중할 수 있는 기반 환경을 마련 – PaaS(Platform as a Service) 필요한 요소 기능만을 조립하여 하나의 컨테이너를 생성하고 서비스를 제공 – Docker VM vs Container • 별도의 분리된 영역이 아닌 상호 의존 관계 • VM: 하드웨어 리소스의 구성 단위를 할당하는데 가장 유용 • Container: 소프트웨어 전달 단위로서 프로세스로 작동되므로, 매우 가볍고 빠름

61. 61 - Internal Use Only - 참고자료 Introducing DZone's 2014 Cloud Platform Research Report : http://java.dzone.com/articles/introducing-dzones-2014-cloud Docker , lightweight linux container – Deview 2013, 김영찬 Portable, lightweight, & interoperable Docker containers across Red Hat solutions - Jérôme Petazzoni, Docker, Inc Docker, Containers, and the Future of Application Delivery – Docker, Inc

62. 62 - Internal Use Only - OPEN SHARE CONTRIBUTE ADOPT REUSE

[오픈소스컨설팅]오픈소스 클라우드 개발플랫폼_및_Docker의_이해_v1

Ji-Woong Choi

[오픈소스컨설팅]오픈소스 클라우드 개발플랫폼_및_Docker의_이해_v1