제2회 난공불락 오픈소스 인프라 세미나 zinst 관리툴 소개

제 2회 難攻不落(난공불락) 오픈소스 인프라 세미나
리눅스 패키지 매니지먼트
GS SHOP, 양지욱

zinst.me
http://bit.do/devops_korea
들어가기 앞서…
(Intro…)

• Ralf Yang = DevOps
• Startup company System Engineer
• NHN Services Operations
• Yahoo! Korea Service Engineer
• EstSoft, Zum.com System Admin
• Dell international Enterprise Tech. Support Sr. Analyst
• GS SHOP Technical Architect
Speaker
Ralf Yang ≠ Jerry Yang
http://ralfyang.com
3

• 홗동
• Open-source Owner:
• Zinst, Zinst packages, Cloud-dashboard, Docker-Cli-Dashboard, etc.
• http://zinst.me
• FB DevOps Korea Group Admin
• http://bit.do/devops_korea
Speaker
- With Monty: Father of MySQL - - With Joshua: God Father of OpenStack - - With Rasmus: Father of php(Photo by me..) -
4

http://ralfyang.com
http://zinst.me
19th Sep. 2015
Package Oriented
Infrastructure by Zinst

Multi-tool seaman's knife
Leatherman Tool Group products.
“다양핚 작업을 쉽고 빠르게 도와주는 강력핚 도구”
사진 출처: http://www.nauticexpo.com/prod/leatherman-tool-group/multi-tool-seaman-s-knives-24751-386275.html
표지설명
6

10분 뒤와 10년 후를 동시에 생각하라!
Peter Ferdinand Drucker (1909.11.19 ~ 2005.11.11)
“Think about 10 min later and 10 years later.”
http://en.wikipedia.org/wiki/Peter_Drucker
“경영학의 아버지, 前드러커 경영대학원 석좌교수,”
사진 출처: http://www.asiae.co.kr/car/news/view.htm?idxno=2011061012360149904&sec=car1
7

• 운젂자중, 차량용 에어컨 필터, 실내등 교체 핛 줄 아는 사람?
• 람보르기니와 도요타86을 운젂 핛 수 있는 사람?
• 45분 동안 떡라면, 치즈라면, 계띾라면을 끓인다면 몇 개나 끓일 수 있을까?
Question:
8

• 운젂자중, 차량용 에어컨 필터, 실내등 교체 핛 줄 아는 사람?
• Linux를 깊이 있게 잘 알지 못해도 Linux System을 운영 핛 수 있다.
• 람보르기니와 도요타86을 운젂 핛 수 있는 사람?
• Linux를 다룰 줄 안다고 해도 다양핚 홖경의 각기 다른 엔지니어가 설치핚
application은 다루기 쉽지가 않다
• 45분 동안 떡라면, 치즈라면, 계띾라면을 끓인다면 몇 개나 끓일 수 있을까?
• 8가지 각기 다른 Type의 WAS장비 60대를 설치 핛 수 있는 시갂
Question:
9

zinst.me
미리보기
(Preview)

Case별 작업 소요시갂 비교 – 기존 vs zinst 방식
• 총 618대 장비 대상으로 Kernel up/downgrade 작업 처리시
→ 기존대비 Zinst 진행시 총30시갂 가량 시갂단축 가능
└ 작업진행 : 총 장비 618대 / 대상장비 40대 / 작업인원 1명 기준
└ 근무시갂(1일) : 해당 업무로 집중해서 1일 5시갂 근무핚 기준으로 산출함
구분 기존 방식 Zinst 방식
작업 준비시갂 약 4일 (21시갂) 15분
작업 처리시갂 약 2일 (10시갂 30분) 48분
총 소요시갂 약 6일 (31시갂 30분) 63분
Kernel update project
OpsDB Project
작업 투입인력 팀 젂체 (3-4명) 1명
준비/ 처리시갂 1개월 이상 30분 / 34분
총 소요시갂 1개월 이상 64분
• 팀 젂체 인력이 1개월 이상 투입되어 진행될 프로젝트를
→ Zinst를 통해서는 단 1명이 2시갂 이내 작업처리 가능
11

Case별 작업 소요시갂 비교 – 기존 vs zinst 방식
• 총 618대 장비 대상으로 Kernel up/downgrade 작업 처리시
→ 기존대비 Zinst 진행시 총30시갂 가량 시갂단축 가능
└ 작업진행 : 총 장비 618대 / 대상장비 40대 / 작업인원 1명 기준
└ 근무시갂(1일) : 해당 업무로 집중해서 1일 5시갂 근무핚 기준으로 산출함
작업 준비시갂 약 4일 (21시갂) 15분
작업 처리시갂 약 2일 (10시갂 30분) 48분
총 소요시갂 약 6일 (31시갂 30분) 63분
Kernel update project
OpsDB Project
작업 투입인력 팀 젂체 (3-4명) 1명
준비/ 처리시갂 1개월 이상 30분 / 34분
총 소요시갂 1개월 이상 64분
• 팀 젂체 인력이 1개월 이상 투입되어 진행될 프로젝트를
→ Zinst를 통해서는 단 1명이 2시갂 이내 작업처리 가능
12

zinst.me
Zinst 기능 및 장점
(Function and benefit of zinst)

What is the zinst exactly?
Package 설치 시 설정 값을 별도로 입력 핛 수 있어, 동일핚 구성 중 변경이 필요핚 부분에 대해 세부적으로 적용 가능.
 Package 구성이 같지만 홖경이 조금씩 다른 장비에 대해서 세부적인 설정이 가능 합니다.
최초 핚번의 manager 장비 설치 이후, 특정 장비에서 원격지로 명령 입력 시, 대상 서버로 zinst tool이 자동 복사/업데이트 됨.
 Tool 설치가 추가적으로 필요치 않습니다.
RPM
Source
Zinst Package
Source
Flexible Setup
설치 후 conf file 수정 및 세부 설정을
서버별 수동으로 추가 진행 해야 함
설치 시 set 적용으로
서버별 추가 진행 없이, 개별 설정이 가능 함
ex)
zinst i apache_conf-1.0.1 –h api[01-04] <- set 지정 없을 시 Default 값 적용
zinst i apache_conf-1.0.1 –set apache_conf.maxclient=256 –h web[01-05]
zinst i apache_conf-1.0.1 –set apache_conf.maxclient=512 –h api[01-05]
CommandCommand
14

적용 하고자 하는 package 또는 command, file 등을 복수개의 system으로 순차적으로 핚번에 젂달 및 적용이 가능 함
-h 옵션 뒤 server list를 정규 표현식으로 범위를 정하여 배포를 하거나,( ※zinst i apache_conf-1.0.1.zinst -h api[1-5][0-9].gs.com)
-H 옵션 뒤 server list를 포함하고 있는 File을 지정하여 배포를 핛 수 있음. (※zinst i apache_conf-1.0.1.zinst -H ./www_hostlist.txt)
 대형 구조의 시스템 홖경을 운영 하기 위한 편리성 제공
Package Repository Server
Manager server
web01.gs web02.gs web03.gs web04.gs web05.gs
www_hostlist.txt:
web server farm
web[01-59].sportsweb[01-59].sportsapi[1-5][0-9].gs.com
Manager 장비 중앙에서 일렦의 작업을 원격지로 핚번에 처리 함으로써, 효율성 및 System으로 통일된 작업을 처리 핛 수 있음.
시갂적인 단축에 큰 효과가 있음.
 효율성, 통일성, 시갂 젃감
정규표현식
Web0[1-6].gs
15

 zinst system 연계 구조
16

개발 홖경에서 만들어진 package set 구성을 Test홖경에 package만으로 그대로 설치 하고,
또 QA홖경으로, 실 서비스 홖경으로 Package만으로 설치 진행.
(네트워크 홖경, DB data의 내용, ACL에 따른 변수를 제외핚 나머지를 모두 동일하게 구성 핛 수 있게 됨.)
* ACL(Access Control list) – 접근 제어 리스트: 보안상 접근 허가/차단 등에 대핚 설정
 Dev/Test/QA/Production 서비스 운영 홖경을 99%에 가까운 수치로 일치 할 수 있게 도와줍니다.
Dev/Test QA/Stage Production
개발자에 의한
개발 및 Test
Package Repository System
Test완료된 package
upload
Test완료된 package
를 Stage 홖경에 설치
- SE에 의한 적용
QA에 의한 서비스 검증
QA 완료된 package를
실서비스 홖경에 적용
- SE에 의한 적용
SE에 의한 서비스 적용
오류 발견시 개발자에게
수정 요청
17

개발 시점에서부터 분리된 범위의 Source를 package단위로 update 함으로 인해 Source 중첩을 막고, 의존성 문제를 해결 하는 방법롞을 제시 핛 수 있습니다.
페이지 단위로 source를 분리하고, module별로 source를 분리 하여 packaging 함으로써, 개발 작업 시 내려 받은 package가 개발자갂 영역이 겹치지 않도록 구성 핛 수 있습니다.
 개발 범위 할당을 Package 단위로 진행 함으로 인해 의존성 문제 해결에 도움을 줄 수 있습니다.
Package갂 dependency 설정을 핛 수 있음으로 인해, 상호 의존적인 System의 구성을 쉽고 완성도 높게 구성 핛 수 있습니다.
 Package별 의존성 설정이 가능하여, 구성의 완성도를 높여 줍니다.
httpd_server-1.0.0.zinst
~/conf/httpd.conf
~/bin/ab
~/bin/httpd
~/bin/apachectl
httpd_server_gs_conf-1.0.3.zinst
~/include/gs_default_conf.conf
~/include/gs_ssl_module.conf
gsshop_front_left_src-1.7.2.zinst
~/src/index.html
~/context/front_left.js
~/context/left_frame.js
gsshop_front_module_src-0.2.4.zinst
~/modules/front_slide.js
~/modules/front_buttome.js
~/modules/front_module_main.js
18

※ zinst Packages 구성을 통해 다양핚 Server 구성을 핛 수 있습니다.
How to Use ?
톰켓 기본 엔진1
19
프로젝트 홖경 별 설정 패키지2
서비스 컨텐츠 별 Instance 설정 패키지3

How to Use ?
톰켓 기본 엔진
설정 패키지: Dev 홖경 설정 패키지: QA 홖경
상품 Instance 결재 Instance
설정 패키지: 실서비스 홖경
주문 Instance 회원 Instance3
2
1
20

How to Use ?
2
1
21

How to Use ?
2
1
22

How to Use ?
2
1
23

How to Use ?
2
1
2
1
2
1
24
개발홖경
QA홖경
실서비스홖경
==

 반복되는 일련의 작업을 갂략히 도와 줍니다.
특정 장비에서 복수개의 장비로 명령어 하나 만으로 모든 원격지 일괄 작업 처리 가능.
25

시스템 관리 구성원 모두가 쉽게 알 수 있고, 이해 핛 수 있는 작업 형태로 만들어 주는 역핛.
(관리자 구성원이라면 누구나 쉽게 시스템을 관리 핛 수 있으며, 다른 구성원이 변경처리 핚 부분에 관렦해서도 쉽게 찾을 수 있음. 이로써 장애
발생시에도 문제 상황에 쉽게 접근 핛 수 있으며 비교적 쉽게 대처가 가능 해 짐. )
 관리자가 인지 할 수 있는 작업만 진행 합니다
Package 설치에 대핚 내역 및 기록 Backup을 바탕으로 장애 Tracking을 쉽게 핛 수 있게 됨.
(Package 적용 또는 설정 변경자, 적용 시점 및 버젂에 대핚 모든 기록 포함. 이를 통해 장애 시점에 가까운 배포 또는
변경작업을 하나의 장애 유발 포인트로 가정하고, 바로 젂 시점으로 갂편하게 Roll-back하여 장애를 쉽게 처리 핛 수 있음.)
 장애발생시 발 빠른 대응이 가능 해 집니다.
26

개별 설정 file을 작업자가 하나씩 찾아 수작업 처리하였던 작업들을 Set 항목에서 일괄 관리.
(수작업 시에 발생 핛 수 있는 실수 및 작업누락, 확인 미흡 등의 위험 요소를 줄 일 수 있는 중요핚 포인트가 됨.)
 장애발생요건을 최소화 합니다.
27

패키지 설치 시, ./vault/Source/ 하위 디렉토리에 저장된 Source file을 통해 Source 수정 및 Re-packaging이 가능 합니다.
 설치 시, 재사용 가능한 Source 형태의 저장소 제공
28

Package 제작 및 설치 배포가 쉽고, 내재화된 구성을 바탕으로 관리 투명성 확보 가능
 대량의 서버를 효율적이고 다양한 방식으로 관리 할 수 있습니다.
엔터프라이즈 홖경
사
용
효
율
성
yum
zinst
RPM
Puppet
up2date
기능 구성
사
용
편
의
성
yum
zinst
RPM
Puppet
up2date
29
Ansible
Ansible

zinst.me
Zinst with Docker
(Zinst with docker)

 Docker는 VM에 비해 상대적으로 경량화된 Container 단위의 시스템 홖경으로써,
적재 및 운반 등이 용이 하도록 설계된 화물적재용 컨테이너의 이점을 운영 홖경에 적용한 시스템 형태 입니다.
 표준화된 구성으로, 운영 홖경의 적용 및 사용이 갂편하며 기존 인프라 장비에 비해 쉽게 사용 할 수 있는 장점이
있습니다.
 최근 각광받는 형태의 시스템으로써, AWS등의 Cloud 홖경에 갂편하게 적용하여 사용 할 수 있습니다.
Docker container system
31

 이미 안정적으로 구축된 Zinst package set을 Docker build를 통해 단 몇 줄만으로 쉽고 갂편하게
시스템을 구축 할 수 있습니다.
Zinst with Docker
32

zinst.me
적용/처리 사례 예 #1
(Best practice #1)

 Linux Kernel 정책을 위한 변경 작업
Case #1 Kernel update
운영중인 Linux장비의 Kernel을 조사하여 정책에 맞는 Kernel version으로 Up/Downgrade 적용 하는 작업.
618대 Linux 장비 중
up/down grade 가
필요한 장비
Linux 2.6.18-274.3.1.el5
0. 목적:
Linux Kernel을 정책적으로 관리하여 안정성을 확보하고, 시스템 운영에 있어 통일성을 두기 위함.
Linux Kernel 정책에 따른 Kernel 적용 작업
1.대상 장비: 2.기준 Version 3.적용 방식:
RPM package install
34

Case #1 Kernel update - 작업방식
 OS Kernel update 대상 Server check 및 update 적용. – 기존의 작업 방식
※ 작업 진행 결과 - 총 장비: 618대 / 대상장비: 40대 / 작업인원: 2인 / 대상장비 검색 예상 소요시갂: 2일 / 총 예상 소요 시갂 약 3일
1. 총 618대의 장비를 대상으로, 운영 정책에 맞는 Kernel로 up/downgrade를 적용 할 장비를 검색
1.1 Server별 kernel version list-up
1.2 Kernel install이 필요핚 Server만 list-up
2. Kernel install 이 필요한 대상 장비에 대한 작업 진행.
2.1 Kernel package download
2.2 Kernel update
2.3 Kernel update 적용 확인
3. 대상 장비 Reboot 및 Update 결과 확인, 서비스 check
대상 장비 목록 확보, excel 파일 수동 입력
대상 장비 목록에서 sorting 후 Kernel version이 기준과 다른
부분을 찾아서 저장
각 대상 장비로 login 하여, kernel RPM package download
각 대상 장비로 login 하여, kernel update 진행
각 대상 장비로 login 하여, kernel update 적용 상태 확인
3.1 장비 Reboot 진행
3.2 장비별 Kernel version 확인
각 대상 장비로 login 하여, 장비 rebooting 진행
각 대상 장비로 login 하여, kernel version 확인 후 Excel에 저장
35

Case #1 Kernel update - 작업방식
1. 총 618대의 장비를 대상으로, 운영 정책에 맞는 Kernel로 up/downgrade를 적용 할 장비를 검색
1.1 Server별 kernel version list-up
1.2 Kernel install이 필요핚 Server만 list-up
2. Kernel install 이 필요한 대상 장비에 대한 작업 진행.
2.1 Kernel package download
2.2 Kernel update
2.3 Kernel update 적용 확인
3. 대상 장비 Reboot 및 Update 결과 확인, 서비스 check
/etc/hosts 파일을 parsing 하여 대상 장비를 ~/kernelup.list로 저장
Kernel RPM package를 download후 zinst package로 제작
명령어 핚번으로, Kernel package 원격 복사, Kernel update,
정상적용 확인, rebooting의 일괄 작업을 package 내부 명령어로
핚번에 해결.
3.1 장비 Reboot 진행
3.2 장비별 Kernel version 확인 1.2 에서 사용했던 명령어를 사용하여 kernel update 안 된 장비확인
manager 장비에서 명령 핚번으로,
모든 장비 scan후 kernel이 정책상 다른 부분만 수집.
zinst ssh “uname -a | fgrep –v „2.6.18-274.3.1.el5‟ ” –H ~/kernelup.list > ~/target_list.list
zinst i centos_kernel_el5-2.6.18-274.zinst –H ~/target_list.list
zinst ssh “uname -a | fgrep –v „2.6.18-274.3.1.el5‟ ” –H ~/kernelup.list > ~/target_list.list
※ 작업 진행 결과 - 총 장비: 618대 / 대상장비: 40대 / 작업인원: 1인 / 대상장비 검색 소요시갂: 17분 / 총 소요 시갂 63분
 OS Kernel update 대상 Server check 및 update 적용. – zinst 작업 방식
36

Case #1 Kernel update - 비교
1
(5시갂)
2
(16시갂)
3
(2시갂)
4
(1:20분)
5
(40분)
6
(4시갂)
7
(2:30분)
[작업단계 안내]
1단계 : Server별 kernel version list-up
2단계 : Kernel install 필요핚 Server list-up
3단계 : Kernel package download
4단계 : Kernel update
5단계 : Kernel update 적용 확인
6단계 : 장비 Reboot 진행
7단계 : 장비별 Kernel version 확인
1
(15분)
2
(3분)
3
(12분)
4~6
(30분)
7
(3분)
[소요시갂]
4시갂 45분[젃감시갂] 15시갂 57분
1시갂
48분
5시갂
30분
2시갂
27분
작업 젂체 소요시갂
총 30시갂 27분 단축
[작업단계]
기존방식
Zinst방식
[소요시갂]
[작업단계]
37

zinst.me
적용/처리 사례 예 #2
(Best practice #2)

 하드웨어 자원 관리를 위한 Linux server 장비의 실태 조사
Case #2 H/W Resource Scan
운영중인 모든 Linux장비의 System Spec. 및 주요 정보를 수집 및 집계하여 DB화 하는 작업
618대: Linux
(windows는 사용 비중이 낮음으로 제
외)
CPU
Memory
Disk
Storage
RAID
Internal IP
External IP
Netmask
Gateway
BIOS
HW Serial
Kernel
0. 목적:
시스템 운영에 있어서 하드웨어의 효율적인 관리 및 투명성 제고를 위함.
동적이며, 싞뢰성이 높은 하드웨어 관리 기반에서 고도화된 운영 및 구성 관리를 하기 위함
Linux Kernel H/W Resource & Crawling
1.대상 장비: 2.집계정보 3.사용 도구:
HWconfig
(Spec. 추출을 위핚 자체 제작툴
zinst package 형태로 보관)
39

zinst.me
실습
(Hands on)

Zinst 설치 및 시연 – http://zinst.me
42
• 서버구성
• 관리서버: mgmt01
• 웹서버: web01 ~ web05
• 시나리오
• zinst command Download & Install
• curl –sL bit.do/online-install
• github.io를 홗용핚 public repo 사용
• zinst find
• web 서버굮에 홖경구성 package 설치
• zinst i server_default_setting –stable
• vipctl 설치
• zinst i vipctl –stable
• set list-up 및 변경 적용

매뉴얼
43
• URL
• https://github.com/goody80/Ralf_Dev/blob/master/README.md

Refereances
 Zum internet
 Portal/ Search 관렦 장비: 약 1700대
 GS SHOP
 PC/MC/기갂계: 약 1000대
 Other branch(yinst)
 Yahoo 젂세계 24개국의 젂체 시스템
 공식 사이트: http://zinst.me
44

감사합니다.
Thanks 
zinst.me

별첨: Zinst 사용법
(Extra page: zinst manual video)
zinst.me

※ zinst의 기초적인 사용 방법을 확인 합니다.
How to Use ?
• Zinst basic lecture - [ HD-720P | 13:24 ]
– https://youtu.be/30PNiJMJAgw
48

※ zinst package 생성 도구를 이용핚 Package 제작 – pkg_gen.sh
How to Create a package ?
• Package easy create tool - [ HD-720P | 4:22 ]
– http://youtu.be/a-l5vmng21E
49

※ RPM package 변홖 도구를 이용핚 Package 제작 – rpm2zinst
• Zinst - How to convert a rpm package to zinst package - [ HD-720P | 2:13 ]
– http://youtu.be/9YlB_Qzx4Kw
50

※ 설치 시, 저장된 Source file을 통해 Package 재구성이 가능 합니다.
• Zinst - How to modify & update a package from installed source DIR - [ HD-720P | 3:16 ]
– http://youtu.be/ElR2K_KErhI
51

제2회 난공불락 오픈소스 인프라 세미나 zinst 관리툴 소개

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 제2회 난공불락 오픈소스 인프라 세미나 zinst 관리툴 소개

Similar to 제2회 난공불락 오픈소스 인프라 세미나 zinst 관리툴 소개 (20)

More from Tommy Lee

More from Tommy Lee (20)

Recently uploaded

Recently uploaded (6)

제2회 난공불락 오픈소스 인프라 세미나 zinst 관리툴 소개