DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개

1. DevOps 소개 ver 0.2 2015.10.27 http://tunelinux.pe.kr 문태준

2. 변경내용 •2015.10.27 : DevOps Tools 의 orchestration 일부 업데이트 및 ansible,saltstack 추가 •2014.11.18 : 문서 작성

3. DevOps 시작 DevOps 소개 DevOps 구성 Top 11 Things About DevOps 자동화 도구 이제 무엇을 할까? 참고자료

4. •DevOps 시작 •DevOps 정의/DevOps 충돌/DevOps 유래 •참고자료 : 애자일, ITIL, 린스타트업, 린 생산방식 •애자일을 OPS로 확장 •DevOps 관점 •DevOps가 아닌 것은? •DevOps 소개 •프로젝트 세팅/하나의 팀 •핵심 : 가치와 목적, 프로세스, 도구 •DevOps 구성 •측정지표 •흐름 개선하기 •배포 개선 및 가속화 •못 다한 이야기 •Top 11 Things About DevOps •자동화 도구 •이상적인 프로젝트 •버전관리/티켓관리/CI/CD •프로비저닝 툴체인 : OS설치/설정/오케스트레이션(배포)/워크플로우 •이제 무엇을 할까? •참고자료

5. DevOps 시작하기

6. DevOps 시작 - 정의(Wikipedia) •DevOps 라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사 소통, 협업, 융합 을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개 발과 IT 운영간의 상호 의존관계에 대한 산물이다. •DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산 하는 것에 도움이 되는 것을 목적으로 한다.

7. Dev VS Ops - 충돌 출처 : http://dev2ops.org/2010/02/what-is-devops/

8. Dev VS Ops - 충돌 출처 : http://dev2ops.org/2010/02/what-is-devops/

9. Dev VS Ops - 충돌 •Dev VS Ops •Dev : 고객에게 제공한 변경을 빠르게 보기 원함 •Ops : 안정성에 관심이 더 많음 •Dev와 Ops 간에 생기는 차이 •동기 (incentives) : Dev 와 Ops 간에 서로 다른 목표 때문에 생김 •프로세스 : 변경을 관리하는 방식, 실 서비스에 반영하는 방식 및 관리하는 방식이 다름 •도구 : Dev 와 Ops 가 서로 별도의 프로그램을 사용함 •세 가지 중 어떤 것이 가장 중요하다고 생각하세요??? •DevOps란? •동기를 맞추고 프로세스와 도구에 대한 접근을 공유하여 차이를 줄임 •애자일 프랙티스를 운영으로 확장하여 더 강한 협업 및 소프트웨어 배포 프로세스 강화 •문화, 사람이 프로세스보다 중요하며 도구보다 더 중요함.

10. DevOps 의 유래 •2009년 Belgium 에서 첫 DevOps 컨퍼런스 개최 (Patrick DeBois) •Velocity 컨펀러스. especially the seminal “10 Deploys A Day” presentation given by John Allspaw and Paul Hammond •“인프라로 코드 관리” 운동 (Mark Burgess and Luke Kanies), “애자일 인프 라스트럭쳐” 운동 (Andrew Shafer), 애자일 시스템 관리 운동 (Patrick DeBois) •린 스타트업 운동 (Eric Ries) •지속적인 통합 및 배포 운동. CI, CD (Jez Humble) •아마존 웹서비스와 같은 각종 cloud, PaaS 기술의 확대

11. 참고자료 – 애자일 •폭포수 방법론 vs 애자일 방법론 •폭포수 방법론은 1970 년에 창안된 첫 번째 소프트웨어 개발 방법론이며 애자일 방법론은 폭포수 방법론의 과도한 문서업무 때문에 내재하는 낭비를 줄이고자 1990 년대에 고안된 방법론임 •폭포수 방법론은 소프트웨어 개발방법론의 첫 번째 모델로 환영 받았지만 느린 단계별 접근법으 로 중복프로세스가 발생하고 릴리즈 간 긴 시간차가 발생함 •폭포수 방법론은 요구사항 - 분석 - 디자인 - 코딩 - 테스트 - 릴리즈의 단계를 지님 •애자일 방법론은 빠르고 모듈식의 주기적인 방식을 통해 개발 전 단계에 걸쳐 요구사항을 지속적 으로 분석 , 반영하여 릴리즈 간 시간차를 최소화함 •애자일은 무엇인가? (Wikipedia) •애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치 게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. •계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있다. •애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code- oriented, 실질적인 코딩을 통한 방법론이라는 점이다. •애자일 개발 방법론 : 익스트림 프로그래밍, 스크럼 등

12. 참고자료 – 애자일 출처 : “성공으로 이끄는 팀 개발 실천 기 술＂

13. 참고자료 – 애자일 (애자일 프랙티스) •애자일 소프트웨어 개발 선언문 •우리는 직접 개발하면서 또 남이 개발 하는일을 도와주면서 소프트웨어 개발의 더 나은 방법을 발 견하고 있다. 이 작업을 통해 우리는 아래 것들을 더 가치 있게 여기게 되었다. •‘프로세스와 도구’보다는 ‘개인과 상호작용’을 •‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어 ‘를 •‘계약 협상 ‘보다는 ‘고객과의 협력 ‘을 •‘계획 준수 ‘보다는 ‘변화에 대응‘ 을 •이 말은, 왼쪽에 있는 것들에도 가치가 있긴 하지만, 우리는 오른 쪽에 이는 것들에 더 많은 가치를 둔다는 것이다. •애자일 정신 •사람, 협조, 반응성, 동작하는 소프트웨어 강조 •빠르게 반응하고 상호 협력하는 사람들과 논증 가능한 구체적인 목표(실제 동작하는 소프트웨어) 를 결합하는 것 •계획에 기반한 접근 방법에서 자연스럽고 끊임없이 지속하는 방식으로 이동 •프로젝트의 끝으로 테스트를 미루지 않고 월말까지 통합을 미루지 않아야 하며 코딩을 시작하면 서 요구사항과 피드백을 모으는 일을 멈추지 않아야 한다. •프로젝트의 전 생애 주기 동안 일시적인 아닌 지속적인 개발 •고도의 협력적인 환경에서 지속적인 조정을 위해 피드백을 사용한다.

14. 참고자료 – ITIL •ITIL은 무엇인가? •ITIL(IT Infrastructure Library)은 IT 서비스 관리에 대한 프레임워크 구현을 돕기 위한 문서들의 집합 •과거에 많은 기업들의 IT 조직이 내부적으로 기술 중심으로 업무를 집중하는 반면, 현재의 IT조직 은 비즈니스 조직의 요구사항에 따라 IT서비스 품질 향상에 역량을 집중하고 있으며 고객 지향적인 접근방식을 채택 •ITIL은 영국뿐 아니라 전 세계 IT 서비스 관리에 대한 사실상의 표준(de-facto standards) •다음 항목으로 구성 •서비스 전략 •서비스 설계 •서비스 전환 •서비스 운영 •지속적인 서비스 개선

15. 참고자료 – 린스타트업 •린 스타트업이란? (Wikipedia) •린 생산 방법, 디자인 중심 사고, 고객 개발, 애자일 개발 같은 기존 경영 방법 및 제품 개발 방법론 의 토대 위에서 만들어진 경영 전략 •시장에 대한 가정(market assumptions)을 테스트하기 위해 빠른 프로토타입(rapid prototype)을 만 들도록 권함. •고객의 피드백을 받아 기존의 소프트웨어 엔지니어링 프랙티스(폭포수 모델 같은) 보다 훨씬 빠르 게 프로토타입을 진화시킬 것을 주장. 지속적 배포(Continuous Deployment)라는 기법을 사용한다. •때론 린 사고방식 (Lean Thinking)을 창업 프로세스에 적용한 것으로 설명. •린 사고방식의 핵심은 낭비를 줄이는 것임. 린 스타트업 프로세스는 고객 개발(Customer Development) 을 사 용하여, 실제 고객과 접촉하는 빈도를 높여서 낭비를 줄임. •이를 통해 시장에 대한 잘못된 가정을 최대한 빨리 검증하고 회피 •시장에 대한 가정들을 검증하기 위한 작업들을 줄이고, 시장 선도력(market traction)을 가지는 비즈니스를 찾는데 걸리는 시간을 줄인다. 이것을 최소 기능 제품 (Minimum Viable Product)이라고도 한다. •린 스타트업의 다섯 가지 원칙(The Lean Startup) •창업가는 어디에나 있다 : 극심한 불확실성 속에서 제품, 서비스를 만드는 조직이라면 모두 스타트 업임. •창업가 정신은 관리다 : 스타트업은 새로운 방식의 관리가 필요 •유효한 학습 : 지속 가능한 사업을 어떻게 만들지 학습. 여러 비전을 빈번히 실험하면서 과학적으 로 검증 •만들고 측정하고 배운다 : 제품만들기->고액 반응 측정-> 고수 또는 방향전환. 피드백 순환을 빠르 게. •혁신 회계 : 지루한 것들에 집중해야 한다. 성과 측정, 마일스톤 세팅, 일의 우선순위 어떻게 정할것 인가?

16. 참고자료 – 린 생산방식이란? •린 생산방식은? (도요타주의) •20세기 경제발전 및 경영방식, 포드주의, 포스트 포드주의에 대한 이해 필요. •포드주의 : 소품종 대량생산, 획일적/표준화, 전용기계, 대규모 재고, 집중화, 규모의 경제 •포스트 포드주의 : 다품종 소량생산, 다양화/유연화 , 범용기계, 무재고, 분산화, 범위의 경제 •협동조합 : 영리보다 상호부조, 경쟁보다는 협력, 연대의 가치를 더 높이 평가함. 그러면서도 생산성, •일본식 생산방식 (도요타주의)가 각광 받았던 이유는? •다른 선진국들이 포드주의의 위기 속에서 정체와 위기를 겪고 있을 때 압도적인 경쟁력으로 불황을 헤쳐 나 온 방식이기 때문 •생산체제 : 적기생산방식(just-in-time), 혼류생산(다양한 모델의 자동차가 하나의 라인 위를 흐르는 것), 작은 로트 생산(단위생산 당 생산대수를 적게 하는 방법), 범용기계의 활용 등 •노동력 편성과 활용 : 다능공화, 품질관리서클(QC), 직무순환, 노동자들의 자발작 참여와 생산 문제 개선 등 •긍정적 입장 : 생산체제, 작업조직을 개선 •부정적 입장 : 포드주의에 비해 질적으로 새로운 방식이 아님. 노동강도를 강화하기 위한 수단임. 노동자 참여도 제한적임. 노동자 간의 경쟁관계를 이용. 승진과 임금 차별. •일본식 생산방식 안에는 부정적인 측면과 긍정적인 측면이 함께 공존하면서 전체적으로 고도의 경쟁력을 갖추는 교묘한 체제를 구성하고 있음.

17. DevOps – 애자일을 ops로 확장 출처 : Devops for Developers

18. DevOps – 애자일을 ops로 확장 •애자일은 개발에서 운영으로 프로그램을 넘겨주고 끝남 •DevOps 에서는 소프트웨어 배포를 포함하고 있음 •DevOps는 •이해관계자 끼리의 협력을 강화하고 •소프트웨어 배포 프로세스를 능률적으로 하는 프로세스와 도구를 사용함 •최종적으로는 Cycle time 을 줄임 (inception – Elaboration – Construction – Transition – Operations)

19. DevOps – 관점 •DevOps 가 성공하기 위한 기초 •신뢰의 문화 •동료의식 •”us vs. them” 문화 vs “we” 문화? •DevOps 에서 가장 중요한 것은 공유임 : 아이디어, 이슈, 프로세스, 툴, 그리고 목표! •Devops 에서 중요한 것은 문화와 사람이며 그 다음이 프로세스와 도구임. •DevOps를 어떻게 판단할 수 있는가? •측정지표 관점 : quality, testing, 공유된 동기의 정도 •프로세스 관점 : 합동, 빠른 피드백을 위한 흐름, 전체적인 프로세스 구성 •기술 관점 : 자동화를 통한 빠른 피드백. “인프라를 코드로 관리하기＂와 같은 자동화된 릴리즈

20. DevOps 가 아닌 것은? •DevOps는 새로운 팀이 아님 (이에 대해선 이견이 있을 수 있음) •DevOps는 새로운 일자리 이름이 아님 •DevOps는 새로운 Tool 이 아님 •“2014 state of devops report” 참고 •110여개 국가 9200명을 대상으로 조사 •DevOps 팀을 가진 경우가 16%에 달했음. (IT Ops 30.4%, Dev/Eng 28.8%) •DevOps Roles 에 DevOps Enginner가 31.3%였음. (Systems Engineer 23.4%, Automation or Tooling Engineer 31.3%, Architect 10.3%, Manage or Senior Manager 8.3%)

21. DevOps 소개

22. DevOps – 프로젝트 세팅 •전통적인 프로젝트 세팅 •프로그래머 -> QA -> OPS •OPS가 프로그래머, 테스터, QA에 항상 관여하는 것은 아니지만 최종 결과는 OPS에서 진행이 됨. •분리된 팀, 공통의 언어가 없음, 서로간에 두려움이 있음 •애자일 프로젝트 세팅 •프로그래머와 QA가 함께 developer 가 되고 한 팀이 됨 •애자일에서 운영은 분리가 되어 있음. •운영의 경우 개발 팀에서 만든 소프트웨어를 배포함. •배포단계에서 nonfunctional 요구사항이 생기며 실제 개발된 소프트웨어와의 격차가 생김 •배포 •안정성 •가용성 •테스트 환경에서는 빠르게 배포가 되지만 prod 에서는 정체가 됨 •Cycle time (아이디어에서 사용자에게 실제 서비스 하는데 걸리는 시간)은 여전히 길어짐 •매우 빈번한 소프트웨어 배포는 OPS에서 병목 현상이 됨

23. DevOps – 프로젝트 세팅 출처 : Devops for Developers

24. DevOps – 하나의 팀 출처 : Devops for Developers

25. DevOps 의 핵심 •DevOps의 핵심은? •가치와 목적 •프로세스 •도구

26. DevOps 의 핵심 – 1. 가치와 목적 •DevOps의 핵심은? •가치와 목적 •프로세스 •도구 •가치와 목적 •서로간의 존중 •공유된 목적에 대한 합의 •공동의 소유권(ownership) •가치의 공유 •전체 차원의 “동기, 목적＂ 조정 -> “quality” 정의 -> 가시성, 투명성 -> 하나의 팀으로!

27. DevOps 의 핵심 – 2. 프로세스 •DevOps의 핵심은? •가치와 목적 •프로세스 •도구 •프로세스 •소프트웨어를 어떻게 개발하고 배포할지 정의하는 프로세스가 툴보다 중요함 •롤이 아닌 최종 만들어진 제품에 대한 책임을 조정 •개발에서 운영에 전달하는 속도를 관리하기 위한 프로세스를 만들고 최적화하기 •Dev와 Ops 간의 전체적인 배포 프로세스 •운영을 애자일 프레임워크와 프로세스에 포함시키기 •Dev와 Ops 간에 동일 프로세스를 공유 •두 그룹이 초점을 맞춤 : 최대의 빈도와 품질로 사용자에게 애플리케이션 변경을 배포 •통합된 프로세스를 통해서 cycle time 을 줄임

28. DevOps 의 핵심 – 3. 도구 •DevOps의 핵심은? •가치와 목적 •프로세스 •도구 •도구 •프로세스가 도구보다 중요하지만 도구는 여전히 중요함. (특히 배포 프로세스) •DevOps 의 능률은 자동화에 의존함 •빌드 시스템 •소스코드 관리 시스템 •기술적, 기능적, acceptance 테스트 •패키징 •제품 배포 •모든 단계에서 자동화된 적절한 도구가 필요함 •코드와 스크립트는 모두 버전 관리 시스템에 저장이 되어야 함 •코드와 스크립트는 빌드, 테스팅, 배포 및 puppet 등의 설정 관리 프로그램도 포함을 함. (인프라를 코드로 관리)

29. DevOps 구성하기

30. DevOps 구성하기 – 측정 지표 •측정기준을 무엇으로 할 것인가? •Dev와 Ops간에 가장 중요한 측정지표는 cycle time임 •전통적인 측정 기준 •숫자 / 정적 코드 분석, 테스트 coverage / 기능(function points) 등 •전통적인 측정 기준을 이용하면 자주 팀이나 개인을 비교하는데 악용이 됨 •가장 도움이 안 되는 것은 이러한 프로세스 메트릭으로 사람을 판단하는데 쓰는 것임 •이슈 10개 처리한 사람과 100개 처리한 사람을 비교하는 것은 현명한 방법인가? •애자일 측정 기준 •지속적으로 가치가 있는 소프트웨어를 배포할 수 있도록 고객 피드백, 지속적인 테스팅, 반복적인 개발을 보장할 수 있는지를 접근방법을 필요로 함 •가치를 추가하여 사용자 또는 고객을 만족시킨 애플리케이션을 “솔루션＂이라고 함. •새로운 업무를 시작하기 전 The Definition of Done(DOD) , 완성된 업무에 대한 정의를 하는 방법도 있음. •테스팅이 완료되지 않거나, 대상 시스템에 설치가 안 되었거나, 품질이나 모니터링을 보장하지 못하면 끝나 지 않음 •Broken Agile Metrics : Test pass/fail ratios, Number of defects created or resolved, Continuous deployments

31. DevOps 구성하기 – 측정 지표 •“변경” •변경은 Dev와 Ops 간에 사용할 수 있는 유용한 지표임. Ops 에서 변경은 실서비스를 변경한 부분임 •변경을 Dev와 Ops 간에 공유하는 조건으로 사용한다면 실 서비스에서 이슈가 발생하는 것을 효율 화하는데 도움이 됨

32. DevOps 구성하기 – 측정 지표 •“변경” 은 다음을 포함 •애플리케이션 코드 •미들웨어 •인프라스트럭쳐 (OS, Servers, switches, routers) •“변경＂을 장애 관점에서 보는 것이 아니라 일반적인 프로세스로 생각을 해야 함

33. DevOps 구성하기 – 흐름 개선하기 •DevOps는 Dev와 Ops에 모두 의미가 있는 접근법을 통해서 빠른 피드백을 얻고 배포 위험을 줄이는 것이 핵심임 •이러한 것을 달성하기 위한 가장 중요한 단계 중 하나는 inception 에서 availability 까지의 흐름을 개선하는 것임 •batch size 를 줄이는 것이 중요해짐 : batch size 는 새로운 버전으로 올리기 전에 완료해야 할 변경 또는 작업량의 크기. 더 적은 변경사항(batch size)을 자주 배포하는 것이 중요함. •Cycle Time •Cycle time은 하나의 operation, function, process 를 완료하는데 필요한 기간임. •개발 프로세스 시작부터 매출이 발생하기 시작하기 까지 시간 •특정 가치와 기능이 고객에게 전달이 되었을 때를 완료로 정의했을 때만 의미가 있음 •측정 가능한 시작 지점과 끝 지점을 동의해야 가능함 •Lead time, Takt Time, throughput •Lean time : 요청이 입력되고 완성된 시간 •Takt Time : 제조업에서 나온 개념이며 “rhythm of the process”를 가리킴. • throughput

34. DevOps 구성하기 – 배포 개선 및 가속화 •매우 자주 배포 •Batch size 를 줄이면 더 자주 배포하여 cycle time 을 줄일 수 있음. •실서비스에 더 자주 배포를 함으로써 변경을 더 간단하게 할 수 있고 변경에 초점을 맞출 수 있음 •일찍 문제 파악하고 처리가 가능 •이전 버전으로 롤백을 할 필요도 줄이고 롤백시 변경사항이 적으므로 롤백하기도 쉬움. •수백 개의 다양한 기능을 롤백 하는 것보다 한 개의 기능만 롤백을 할 수 있으므로 사업 관점에서도 관리하기가 쉬워짐 •Release 간격이 크면 batch size 도 크고 각종 기능도 나중에 서비스에 들어감 (고객에 대한 가치 전 달이 늦어짐) •Release 간격을 줄이면 적절한 batch size도 가질 수 있고 각종 기능도 더 빠르게 이용 가능함

35. DevOps 구성하기 – 배포 개선 및 가속화

36. DevOps 구성하기 – 배포 개선 및 가속화 •자동화된 릴리즈 •지속적인 통합 (Continuous integration) •Automatic tests •자동화된 릴리즈의 목표는 소프트웨어를 릴리즈 하면서의 위험을 줄이는 것 •Build, test, releasing 소프트웨어를 이용하고 반복 가능한 프로세스를 만든다. •가상 머신, 미들웨어, 애플리케이션 코드 등을 “반복” 가능하도록 Provisioning, deploy 함 •자동화를 할 대상 선택이 필요함 : 최대의 비용 고려, 자동화의 패러독스, 아이러니 등 고려(더 많 은 사람 필요, 운영자가 경험할 기회가 줄어드는 것 등) •기술적 관점이 아닌 비즈니스적인 관점에서 자동화가 필요 •효율적인 자동화는 사람을 더 중요하게 만들어야 함. •릴리즈를 자주, 반복적으로 함. •자동화된 릴리즈는 모니터링에 의해서 달성될 수 있음. •철저하게 모니터링을 해야 함. 애플리케이션 개발과 함께 개발을 해야 함.

37. DevOps 구성하기 – 배포 개선 및 가속화 •Deployment 와 Release 를 분리하기 •Deployment 와 Release 를 분리하는 여러 가지 방법이 있음 •Deployment : 특정 환경에 소프트웨어 Release 를 설치 •Release : 사용자가 사용할 수 있는 특정 소프트웨어 버전 •Deployment 와 Release 분리하는 방법 •Branch by Abstraction •Feature Toggles : 런타임시 사용할 기능을 선택 •Dark Launching : 전체 사용자에게 배포하기 전 prod에 일부만 배포 •Blue-Green Deployment : 구버전, 신규버전을 함께 운영하면서 로드밸런서 등을 이용 출처 : “성공으로 이끄는 팀 개발 실천 기술＂

38. DevOps 더 나아가기 •더 설명하지 못한 이야기들 •Metrics and Measurement View •무엇이 “질＂인가? “질＂을 개선하기 위한 패턴 •서로간의 동기를 공유하기 위한 방법. 무엇이 팀이고 팀을 어떻게 만들 것인가? •Process View •빠른 피드백을 얻는 방법, •통합적, 전체적인 접근 •Technical View •자동화된 릴리즈 •적절한 툴 선택을 위한 패턴 •인프라 코드로 관리하기

39. The Top 11 Things

40. The Top 11 Things About DevOps •정확한 제목은 Top 11 Things You Need To Know About DevOps •1. DevOps는 무엇이며 어디에서 왔나? •DevOps 는 Dev와 Ops 간의 협력적인 관계를 만들 수 있는 전문적인 운동을 말하며 이를 통해서 계 획된 작업을 빠르게 할 수 있도록 함. •동시에 서비스 환경에 대한 신뢰성, 안정성, 탄력성, 보안을 강화함. •왜 Dev와 Ops인가? 그것은 Dev와 Ops가 비즈니스와 고객 사이의 가치의 흐름이기 때문임. •DevOps 운동의 기원 •2. DevOps와 애자일의 차이점은? •애자일 프로세스는 폭포수 모델과 다르게 더 작게 더 자주 소프트웨어를 배포함. •애자일을 통해 더 빈번한 배포하면서 Ops 에서는 병목현상이 일어남. •DevOps는 애자일 방법론을 Ops 까지 확장하여 코드를 더 빨리 서비스에 넣고 고객에게 가치를 전 달할 수 있음 •DevOps는 IT 운영의 지속적인 작업 흐름을 가능하게 함. •DevOps는 문화를 바꾸는 것이며 작업 흐름과 측정 기준을 바꾸는 것임.

41. The Top 11 Things About DevOps •3. DevOps와 ITIL 또는 ITSM 과의 차이점은? •ITITL , ITSM 은 IT 운영에 대한 훌륭한 비즈니스 프로세스 명문화 작업임. •애자일, continuous integration, 릴리즈는 Dev에서의 출력이며 Ops 에서는 입력이 됨. ITIL 프로세스 의 많은 영역에서 자동화가 필요로 하며 change, configuration, 릴리즈 프로세스가 특히 중요함 •DevOps 의 목적은 변경의 횟수를 늘리는 것 뿐만 아니라 문제 없이 성공적으로 실서비스 환경에 기 능을 배포하는 것이며 문제가 생겼을 때 빠르게 확인하고 고치는 것임. 이러한 것은 ITIL 을 더 강화 함. •4. How does DevOps fit with VisibleOps? •생략

42. The Top 11 Things About DevOps •5. DevOps의 기초 원리는? •전체 시스템적인 사고

43. The Top 11 Things About DevOps •5. DevOps의 기초 원리는? •피드백 루프를 확대하기

44. The Top 11 Things About DevOps •5. DevOps의 기초 원리는? •지속적인 실험과 학습 문화

45. The Top 11 Things About DevOps •6. DevOps 패턴의 영역 •Area 1: Extend Development into Production •Area 2: Create Production feedback into Development •Area 3: Embed Development into IT Operations •Area 4: Embed IT Operations into Development •7. DevOps 의 가치는? •시장에 대한 빠른 대응 •“질” 향상 •조직적 효율성 증대 •8. 보안과 QA는 어떻게 DevOps에 합류할 수 있는가? •기능, 통합, 보안 테스트를 개발의 일일 운영에 통합하여 더 빠르게 문제를 찾아냄

46. The Top 11 Things About DevOps •9. My DevOps Favorite Pattern #1 •환경을 최대한 일찍 만듬 •자동화된 환경 생성 프로세스. Dev, QA, Prod •각 환경의 차이를 최대한 출임. •10. My DevOps Favorite Pattern #2 •Dev를 고객의 경험과 최대한 밀접하게 연결시킴 •Dev를 Level 3 기술지원에 포함 또는 코드 배포, 롤백 등에 함께 책임을 가지도록 함 •목표는 Dev가 Ops를 대체하는 것이 아님. 개발을 통한 변경 영향을 직접 확인하고 공동의 목표를 달성하기 위해서 Ops 와 함께 문제를 빠르게 고치기 위한 것임 •11. My DevOps Favorite Pattern #3 •표준화가 안 되어 있으면 문제가 생김. •재사용 가능한 배포 프로세스 정의 •환경을 표준화함.

47. 자동화 툴

48. 이상적인 프로젝트란? 출처 : “성공으로 이끄는 팀 개발 실천 기 술＂ •티켓 관리 시스템에 이슈 등이 집약되어 있다 •버전 관리 시스템을 이용 •반복 검증 가능한 CI 시스템을 도입 •환경의 영향을 최소화하고 항상 배포 가능 상태로 둔다 •모두 기록해서 추적 가능하게 한다

49. 버전 관리 •버전 관리 시스템이란? •버전 관리 시스템의 역사와 분산 버전 관리 시스템의 도입 •관리해야 할 것 •소스 코드 •요건 정의서, 설계서 등의 문서 •데이터베이스 스키마 및 데이터 •미들웨어 등의 설정 파일 •라이브러리 등의 의존 관계 정의 •시스템 설정 및 인프라 •브랜치, 태그 등을 사용한 효율적인 개발

50. 티켓 관리 •티켓 관리 시스템이란? •티켓 관리 시스템과 버전 관리 시스템의 연계 출처 : Jira와 subversion 연동하여 이슈 처리

51. 지속적 통합(Continous Integration) •CI란? •통합이란 빌드, 테스트를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시하는 것을 CI(Continuous Integration)이라고 함 •통합을 지속적으로 수행하는 것이 CI •원래 CI는 애자일 개발 방법의 하나로, 익스트림 프래그래밍 방법론으로 고안되었음. •가치 있는 소프트웨어를 고품질로 신속하게 전달하는 것을 목표로 하는 것 •애자일 개발 중에서도 가장 기본이자 핵심 방법론임. •통합 작업을 미루지 말고 개발 중에라도 실시해서 소프트웨어 개발의 복잡성을 제거하자는 것 •왜 CI 같은 방법론이 요구되는 걸까? •비용 면에서의 이점 •시장 변화 속도 •속도와 품질 둘 다 확보

52. 지속적 통합(Continous Integration) •CI 에 필요한 것 •버전 관리 시스템 : subversion, Git •빌드 도구 : make, Scons, Ant, Maven, Gradle, Rake, •테스트 도구 : 테스트 주도 개발 프레임워크, 행동 주도 개발 프레임워크. •단위 테스트(Unit Test), 통합 테스트(Integration Test), 사용자 테스트(User Acceptance Test), 회귀 테스트 (Regressoin Test) •CI 도구 : Jenkins, Travis CI

53. 배포 자동화(지속적 전달) 출처 : “성공으로 이끄는 팀 개발 실천 기술 ＂

54. 배포 자동화(지속적 전달) •배포 자동화의 이점 •작은 단위로 나누어 자주 배포하면 위험을 제어할 수 있음 •피드백을 빨리 받을 수 있다 •조직을 안정화 한다 •배포 자동화하기 •배포 자동화 기반 기술을 선택할 때는 개발자와 운영자 모두 공통으로 이용할 수 있는 것으로 해야 함 •개발부터 상용 환경에 배포하기까지 일관된 처리를 필요로 함 •배포 자동화시 공통으로 인식해야 할 것 •모든 것을 버전 관리한다 •모든 환경을 같은 방법으로 구축한다 •배포 작업을 자동화하고 사전 검증을 한다 •반복 테스트한다. •배포 파이프라인 : 애플리케이션 빌드/배포/테스트/배포라는 일련의 프로세스를 자동화 하는 것 •자동화를 통해서 배포 속도를 가속화 : 속도와 정확도 •누구든지 배포할 수 있도록 하는 것 이 중요

55. 프로비저닝 툴체인 출처 : “성공으로 이끄는 팀 개발 실천 기술＂ 출처 : Web Ops 2.0: Achieving Fully Automated Provisioning

56. Automated Provisioning + Automated Lifecycle 출처 : http://dtosolutions.com/fully-automated-infrastructure/fully- automated-provisioning/

57. 프로비저닝 툴체인 - Bootstrapping •Kickstart •Vagrant •Docker •Cloud 서비스

58. 프로비저닝 툴체인 - Configuration •Puppet vs Chef vs Ansible vs Salt vs Cfengine vs Etc 출처 : “성공으로 이끄는 팀 개발 실천 기술＂

59. 프로비저닝 툴체인 – Configuration - Puppet 출처 : http://theforeman.org/ https://forge.puppetlabs.com/

60. 프로비저닝 툴체인 – Orchestration •Capistrano : 병렬처리 •Fabric : 직렬/병렬처리 •순서가 필요한 경우 직렬 처리가 유용 •기타 : Func(Python) / Rex(Perl) •Jenkins : CI 도구이지만 배포 보조 도구로 활용 가능 •Mcollective •Ssh 대신 Publish Subscribe Middleware 기술 사용 (비 동기 메시징. MQ) •확장성이 용이하며 대규모 환경에서 사용 가능함. •Rundeck : workflow 기능 •Ansible/SaltStack : configuration + Orchestration •SaltStack 은 zeromq의 분산메시징 기술을 이용하여 성 능 및 확장성을 높임. •수작업으로 해야 한다면? ClusterSSH, Pssh, Dist, etc

61. 오케스트레이션 – Mcollective 출처 : https://docs.puppetlabs.com/mcollective/reference/basic/messageflow.html A : 노드c에 대한 정 보 요청 B : 전체노드에 브 로드캐스트 C : 모든 노드에서 메시지 받음 D : 해당 머신(c)만 응답 보냄

62. 오케스트레이션 – Jenkins 와 Fabic 조합 출처 : “성공으로 이끄는 팀 개발 실천 기술＂ •Fabic 실행을 Jenkins 슬레이브에서 실행함으로써 Fabic 실행 결과를 Jenkins 콘솔 로그로 남길 수 있음 •Fabric 은 원격 호스트 추가가 쉽고 코드로 관리할 수 있어서 버전 관리를 통한 본인 환경 검증 등 다양한 환경에서 동작시킬 수 있음

63. 오케스트레이션 – workflow Rundeck 활용 •워크플로우 기능 •Workflow 정의, 빌드, 실행 관리 가능 •Job 정의 -> 해당 팀에 job 넘겨줌 •사용용도 •표준 운영 프로시져 공유 •잡 스케쥴러 •빌드 후 자동화된 배포 •테스트 환경을 셀프서비스로 제공 •데이터 프로세싱 출처 : http://rundeck.org/

64. 이제 무엇을 할까?

65. 우리의 문제는 무엇인가? 무엇을 할 것인가? •큰 이야기 •같은 목적을 향해 달려가고 있는가? •같은 프로세스를 사용하고 있는가? •같은 도구를 사용하고 있는가? •작은 이야기 1 •공부하기 •도구부터 접근하기 •시스템 설정은 Puppet 에. •VM OS 설치는 vagrant 에. •모든 설정 파일/스크립트는 버전관리소프트웨어에. •공통의 배포 프로그램, 워크플로우 프로그램 사용 •QA/Staging 환경을 함께 구축하기 : Dev + Ops 공통 사용. 최대한 실제 환경과 비슷하게 구현 •작은 이야기 2 •파일럿 프로젝트 선정하여 효과가 있는지 검증하기 (만들고 측정하 고 배우기)

66. 참고자료

67. 참고자료 •DevOps 전반적으로 연관 있는 서적 lDevops for Developers l전반적으로 DEVOPS 에 대해서 설명을 하고 있는 책임. DEVOPS 정의, DEVOPS 가 아닌 것, DEV와 OPS간의 충돌문제, DEVOPS 의 핵심, (Values and goals, Processes, Tools), devops 구축하기, Values and goals, Processes, Tools 세가지 핵심의 관점에서 자세한 설명을 하고 있음 lThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win l소설임. 번역서 제목은 “피닉스 프로젝트 비즈니스를 승리로 이끄는 IT와 DevOps” l성공으로 이끄는 팀 개발 실천기술 l팀개발, 버전관리, 티켓관리, 지속적 통합, 배포 자동화(지속적 전달), 회귀 테스 트 lkickstart, puppet 류의 설정관리, capistrano 등의 오케스트레이션 을 골고루 다 루고 있음 l린 스타트업 •DevOps 인터넷 lThe Top 11 Things You Need to Know About DevOps l간략하게 Devops 에 대한 핵심적인 내용을 설명하고 있음. l출처 : http://itrevolution.com/11devops/ lhttp://www.slideshare.net/ds5apn/dev-ops-2013041801pdf 한글 자료. KTH 에서의 devops 경험담을 담고 있음. 주로 자동화에 촛점이 맞추어져 있음. l2014 STATE OF DEVOPS REPORT http://puppetlabs.com/2014-devops-report

68. 참고자료 •애자일 •실용주의 프로그래머 •애자일 프랙티스 지속적인 통합 (Continuous Integration) •실용주의 프로그래머를 위한 프로젝트 자동화 : 빌드, 디플로이, 모니터링 •자바 프로젝트 필수 유틸리티 : Maven, TeamCity, Subversion, Trac •윈도우 프로젝트 필수 유틸리티: Subversion, Trac, CruiseControl.NET •지속적인 전달(Continuous Delivery) •신뢰할 수 있는 소프트웨어 출시 •성공으로 이끄는 팀 개발 실천기술

69. 참고자료 •Puppet l초보자 : 시스템 관리자를 위한 Puppet3 (번역판) l중고급자 : Pro Puppet 2’nd edition, Puppet cookbook •자동화된 인프라 구축 lBuilding an Automated Infrastructure (O’REILY Velocity 2008) : lhttp://en.oreilly.com/velocity2008/public/schedule/detail/2238 lReliable, Repeatable, Reproducible Infrastructure lhttp://sysadmin.miniconf.org/presentations08.html#02 lWeb Ops 2.0: Achieving Fully Automated Provisioning lhttp://www.puppetlabs.com/wp- content/uploads/2010/03/FullyAutomatedProvisioning_Whitepaper7.p df lScalable System Operations (O’REILY Velocity 2012) lhttp://velocityconf.com/velocity2012/public/schedule/detail/23605 lUsing Open Source to Provide Infrastructure Services lhttp://blog.mague.com/?p=552 lSysadmin study

70. 나가면서 •인문학, 철학, 과학 을 공부하자!! •무엇이 인간적인 삶인가? •어떻게 살 것인가? •기술에만 매몰되지 말자. IT는 인간을 위한 도구이다.

71. 질의 응답