DEVOPS 전반적인 것에 대해서 소개를 한 자료입니다.
http://wiki.tunelinux.pe.kr/display/sysadmin/DEVOPS
https://groups.google.com/forum/#!topic/sysadminstudy/g4bM_xbZPC8
DevOps 시작
DevOps 정의
Dev vs Ops 충돌
DevOps 유래
참고자료
애자일 방법론
ITIL
린스타트업
린 생산방식
애자일을 OPS로 확장
DevOps 관점 : 측정지표 관점, 프로세스 관점, 기술 관점
DevOps가 아닌 것은?
DevOps 소개
프로젝트 세팅 : 전통적인 프로젝트 세팅, 애자일 프로세스 세팅
하나의 팀
핵심
가치와 목적
프로세스
도구
DevOps 구성하기
측정지표 : cycle time, 변경(change)
흐름 개선하기
배포 개선 및 가속화 : batch size 줄이고 더 자주 배포하여 cyclle time 줄이기.
못 다한 이야기 : Metrics and Measurement View / Process View / Technical View
Top 11 Things About DevOps
DevOps의 기초 원리 : 전체 시스템적인 사고, 피드백 루프를 확대하기, 지속적인 실헝과 학습
자동화 도구
이상적인 프로젝트란?
버전관리
티켓관리
지속적인 통합(CI)
지속적인 배포(CD)
프로비저닝 툴체인
OS설치
설정
오케스트레이션(배포)/워크플로우
이제 무엇을 할까?
나가면서
참고자료
위메프에서 DevOps를 적용하기 위해서 공부하고 경험했던 내용을 정리한 자료입니다. DevOps를 왜 해야 하는 지, 그리고, 정확히 DevOps가 뭔지 이해하기 위해서 DevOps의 유래, CAMS/CALMS, 또, Gene Kim의 The three ways와 Patrick의 4 Areas에 대해서 설명하고 DevOps의 다양한 패턴에 대해서 설명했습니다.
그리고, Facebook, Flickr, Etsy, Netflix, Google에서는 어떻게 개발하고 배포 하는 지 사례를 설명 드리고 마지막엔 위메프에서 1년 동안 DevOps를 적용하기 위해 어떤 노력들을 했는 지 설명하려 노력했습니다.
DevOps를 적용하려 고민하는 분들께 조금이나마 도움이 되었으면 좋겠습니다.
DEVOPS 전반적인 것에 대해서 소개를 한 자료입니다.
http://wiki.tunelinux.pe.kr/display/sysadmin/DEVOPS
https://groups.google.com/forum/#!topic/sysadminstudy/g4bM_xbZPC8
DevOps 시작
DevOps 정의
Dev vs Ops 충돌
DevOps 유래
참고자료
애자일 방법론
ITIL
린스타트업
린 생산방식
애자일을 OPS로 확장
DevOps 관점 : 측정지표 관점, 프로세스 관점, 기술 관점
DevOps가 아닌 것은?
DevOps 소개
프로젝트 세팅 : 전통적인 프로젝트 세팅, 애자일 프로세스 세팅
하나의 팀
핵심
가치와 목적
프로세스
도구
DevOps 구성하기
측정지표 : cycle time, 변경(change)
흐름 개선하기
배포 개선 및 가속화 : batch size 줄이고 더 자주 배포하여 cyclle time 줄이기.
못 다한 이야기 : Metrics and Measurement View / Process View / Technical View
Top 11 Things About DevOps
DevOps의 기초 원리 : 전체 시스템적인 사고, 피드백 루프를 확대하기, 지속적인 실헝과 학습
자동화 도구
이상적인 프로젝트란?
버전관리
티켓관리
지속적인 통합(CI)
지속적인 배포(CD)
프로비저닝 툴체인
OS설치
설정
오케스트레이션(배포)/워크플로우
이제 무엇을 할까?
나가면서
참고자료
위메프에서 DevOps를 적용하기 위해서 공부하고 경험했던 내용을 정리한 자료입니다. DevOps를 왜 해야 하는 지, 그리고, 정확히 DevOps가 뭔지 이해하기 위해서 DevOps의 유래, CAMS/CALMS, 또, Gene Kim의 The three ways와 Patrick의 4 Areas에 대해서 설명하고 DevOps의 다양한 패턴에 대해서 설명했습니다.
그리고, Facebook, Flickr, Etsy, Netflix, Google에서는 어떻게 개발하고 배포 하는 지 사례를 설명 드리고 마지막엔 위메프에서 1년 동안 DevOps를 적용하기 위해 어떤 노력들을 했는 지 설명하려 노력했습니다.
DevOps를 적용하려 고민하는 분들께 조금이나마 도움이 되었으면 좋겠습니다.
Source : http://www.opennaru.com/cloud/devops/
DevOps는 “비즈니스 가치를 높이는 것을 목적으로 제품 및 서비스를 신속하고 지속적으로 사용자로 전달하기 위해 IT 시스템의 개발 팀 (Dev)과 운영팀 (Ops)가 협력하는 것”을 뜻하는 말입니다.
Atlassian Product Overview (아틀라시안 제품 소개) - 2016년 4월 버전Atlassian 대한민국
아틀라시안(Atlassian)의 회사 소개 및 제품 오버뷰 슬라이드 입니다.
아틀라시안의 모든 제품은 공식 홈페이지 https://ko.atlassian.com/ 또는 공식 파트너사를 통해 구매하실 수 있습니다.
대한민국 내의 공식 파트너사 리스트는 다음 링크를 참조하세요: http://goo.gl/qwh6ix
Pivotal 에서는 GE, AllState, VolksWagen 등 세계 유수의 기업들과 긴밀한 협업 관계를 이루고 있습니다. 본 세션에서는 클라우드 네이티브 및 Digital Transformation 을 위한 조직 구조, 문화, 환경을 알아보고 Pivotal 에서 어떻게 도움을 드릴 수 있는지 알아봅니다.
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
Source : http://www.opennaru.com/cloud/devops/
DevOps는 “비즈니스 가치를 높이는 것을 목적으로 제품 및 서비스를 신속하고 지속적으로 사용자로 전달하기 위해 IT 시스템의 개발 팀 (Dev)과 운영팀 (Ops)가 협력하는 것”을 뜻하는 말입니다.
Atlassian Product Overview (아틀라시안 제품 소개) - 2016년 4월 버전Atlassian 대한민국
아틀라시안(Atlassian)의 회사 소개 및 제품 오버뷰 슬라이드 입니다.
아틀라시안의 모든 제품은 공식 홈페이지 https://ko.atlassian.com/ 또는 공식 파트너사를 통해 구매하실 수 있습니다.
대한민국 내의 공식 파트너사 리스트는 다음 링크를 참조하세요: http://goo.gl/qwh6ix
Pivotal 에서는 GE, AllState, VolksWagen 등 세계 유수의 기업들과 긴밀한 협업 관계를 이루고 있습니다. 본 세션에서는 클라우드 네이티브 및 Digital Transformation 을 위한 조직 구조, 문화, 환경을 알아보고 Pivotal 에서 어떻게 도움을 드릴 수 있는지 알아봅니다.
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
15. Dev VS Ops - 충돌
• Dev : 고객에게 제공한 변경을 빠르게 보기 원함
• Ops : 안정성에 관심이 더 많음
15
16. Dev와 Ops간에 문제가 발생하는
이유
• 동기 : Dev 와 Ops 간에 서로 다른 목표 때문에 생김
• 프로세스 : 변경을 관리하는 방식, 실 서비스에 반영
하는 방식 및 관리하는 방식이 다름
• 도구 : Dev와 Ops가 서로 별도의 프로그램을 사용
함
16
17. DevOps란?
• 동기를 맞추고 프로세스와 도구에 대한 접근을 공유
하여 차이를 줄임
• 애자일 프랙티스를 운영으로 확장하여 더 강한 협업
및 소프트웨어 배포 프로세스 강화
• 문화, 사람이 프로세스보다 중요하며 도구보다 더 중
요함.
17
21. 전통적인 프로젝트 세팅
• 프로그래머 -> QA -> OPS
• OPS가 프로그래머, 테스터, QA에 항상 관여하는 것
은 아니지만 최종 결과는 OPS에서 진행이 됨.
• 분리된 팀, 공통의 언어가 없음.
• 서로간에 두려움이 있음.
21
22. 애자일 프로젝트 세팅
• 프로그래머와 QA가 함께 developer 가 되고 한 팀이
됨.
• 애자일에서 운영은 분리가 되어 있음.
• 운영의 경우 개발 팀에서 만든 소프트웨어를 배포함.
• Cycle time ( 아이디어에서 사용자에게 실제 서비스
하는데 걸리는 시간) 은 여전히 길어짐.
22
33. 이상적인 프로젝트란?
• 티켓 관리 시스템에 이슈 등이 집약되어 있다.
• 버전 관리 시스템을 이용.
• 반복 검증 가능한 CI 시스템을 도입
• 환경의 영향을 최소화하고 항상 배포 가능 상태로 둔다.
• 모두 기록해서 추적 가능하게 한다.
33
34. 지속적 통합(Continous
Integration)
• CI란?
• 통합이란 빌드, 테스트를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시하는 것
을 CI 라고 함.
• 통합을 지속적으로 수행하는 것이 CI
• 원래 CI는 애자일 개발 방법의 하나로, 익스트림 프로그래밍 방법론으로 고안되었음.
• 가치 있는 소프트웨어를 고품질로 신속하게 전달하는 것을 목표로 하는것.
• 애자일 개발 중에서도 가장 기본이자 핵심 방법론임.
• 통합 작업을 미루지 말고 개발 중에라도 실시해서 소프트웨어 개발의 복잡성을 제거 하자는 것.
• 왜 CI 같은 방법론이 요구되는 걸까?
• 비용 면에서의 이점
• 시장 변화 속도
• 속도와 품질 둘 다 확보
34
35. CI 에 필요한 것
• 버전 관리 시스템 : subversion, Git
• 빌드 도구 : make, Scons, Ant, Maven, Gradle, Rake
• CI 도구 : Jenkins, Travis CI
35
37. 우리의 문제는 무엇인가? 무엇을 할
것인가?
• 큰 이야기
• 같은 목적을 향해 달려가고 있는가?
• 같은 프로세스를 사용하고 있는가?
• 같은 도구를 사용하고 있는가?
• 작은이야기 1
• 도구부터 접근하기
• 공통의 배포 프로그램, 워크플로우 프로그램 사용
• QA / Staging 환경을 구축해보기
• 작은 이야기 2
• 오늘 해커톤을 통하여 효과를 검증해 보기(만들고 측정하고 배우기)
37
Editor's Notes
안녕하세요 이번에 devops에 대해 발표를 진행하게될 정해균 이라고 합니다. 발표 시작 하겟습니다.
devops 시작 - 기존에 개발과 운영으로 나뉜상황에서 일어나는 일, devops 정의
소개 - 기존 프로젝트 팀의 단점, devops를 하면 하면 좋은점
구성 - 전통적인, 애자일 측정지표 비교 / devops로 변경하면서 얻는 이점
자동화 도구 - CI소개
이제 무엇을 할까 - 열심히 합시다.
devops 의 가장 핵심적인 목적은 의사소통, 협업, 융합 이라고 생각합니다.
하지만, 개발팀과 운영팀은 서로 입장이 다르죠. 개발팀은 개발만 운영팀은 운영만 하기 때문에..
개발이 완료 되고, 운영팀은 개발의 이슈를 해결해야 하는 상황이 오는데, 사실 이마저도 쉽지 않습니다.
막말로 운영팀 내 똥 받아라! 이거죠
운영팀에서 일어나게 되는 상황을 다섯가지로 나눠 봤습니다.
먼저 장애가 터지죠.
아~ 또 어떤놈이야? , 어떤놈이 건드렸어? 하고 범인 찾기에 나섭니다.
예를 들어 DB문제네~ 서버문제네~ 하면서 담당 개발자들에게 책임을 전가 하며 심하겐 욕까지 하는 상황이 벌어집니다.
중요한건 어떤 부분에서 장애가 발생 했는지 정확하게 확인하지 않고 대충 파악만 하죠
이런식으로 문제를 다른 사람들에게 넘기다 보면 맘에 금이 가기 시작합니다.
이쯤 되면 정확한 원인 분석을 위해 회의를 하기 시작합니다.
아~ 이제 정확한 원인을 알게 됐으니 해결만 하면 되겠군요?
문제는 해결 됐는데, 이 방법은 정말 맘에 상처도 입고 나몰라라 하는 식의 문화를 보여주는 하나의 예 입니다.
개발 레벨에서 처리하지 않은 이슈를 운영에 와서야 해결하려고 하니 힘듬
결국엔 개발팀과 운영팀이 서로 부딪히게 되는 상황까지 오게 됩니다.
그렇다면, 도대체 왜 개발팀과 운영팀의 충돌이 일어나는 것 일까요?
개발팀은 고객에게 제공한 변경을 빠르게 보기 원하고, 운영팀은 변경보단 지금 현재 안정성에 관심이 더 많기 때문입니다.
dev와 ops 간에 문제가 발생하는 이유는 서로 다른 목표 때문에 문제가 생기게 됩니다.
변경, 서비스에 반영하는 방식이 서로 다르고, 또 서로 다른 프로그램을 사용하는 부분도 문제를 발생하는 하나의 원인이 됩니다
결국 devops는 한마디로 정의 하자면 개발과 운영을 합치고 모두가 한곳을 바라보면서 진행 하자 라고 생각 하시면 될것 같습니다.
다시한번 정리하자면
devops에서 중요한 것은 문화와 사람이며 그 다음이 프로세스와 도구 입니다.
그렇다면 dev와 ops가 합쳐지긴 했는데 잘못 생각 하고 계시는 분들이 계실수 있을거라고 생각 하는데요
devops는 새로 만들어지는 팀도 아니고, 새로 생긴 일자리 이름도 아니고, 새로운 툴도 아닙니다.
이어서 devops에 대해 설명
전통적인 프로젝트 세팅은 프로그래머에서 테스터 운영으로 이관 되고, 서로 분리된 팀이라는것
반면에 애자일은 프로그래머와 테스터가 한팀이 되긴 하지만 , 여전히 운영은 분리가 되어 있습니다.
그러면 dev와ops를 합치면 이 모든게 해결이 될까요?
devops의 핵심은 크게 가치와 목적/ 프로세스/ 도구로 나누게 되는데요,
목적과 가치를 공유하고 공동의 소유권을 갖습니다. 물론 서로간의 존중은 기본 이겠죠.
dev와 ops 간에 동일 프로세스 공유하고 통합하여 cycle time 아이디어에서 사용자에게 실제 서비스 하는데 걸리는 시간 을 줄여야 합니다.
프로세스도 중요하지만 도구도 여전히 중요 하고, 모든 단계 에서 자동화 된 도구가 필요합니다.
전통적인 측정기준 ( 예를 들어 예전엔 몇만라인 짜리 프로그램이면 좋은 거다)
애자일 측정기준 ( 꾸준한 고객의 피드백을 반영함)
변경, 즉 많은 변경을 처리하는 것이 중요하다는 말입니다.
예를들어 배치 사이즈를 크게 잡았을때는 그만큼 배포의 주기가 길다는 말이 되는거고 변경사항이 많기 때문에
위험도가 커지게 됩니다.
반대로 배치 사이즈를 작게 잡았을때는 배포의 주기가 짧기 때문에 그만큼 위험도가 작아지게 됩니다.
그렇기 때문에 배치 사이즈를 작게 잡고 배포 하는것이 중요합니다.
버전관리 - 시스템 - 테스트 - ci -배포 를 모두 기록하기 때문에 추적이 가능하게 만드는것
ci란 빌드, 테스트를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시하는 것을 CI 라고 합니다
ci를 함으로서 얻는 이점은 비용, 시장에 대한 변화속도, 품질을 지속적으로 얻을수 있기 때문입니다.