2. Preview
개발자가 개발 업무에만 집중 할 수 있도록 신뢰 할 수 있는 인프라 시스템 구축하기
- 주요대상:
개발 빼고 별별거 다 해야 하는 개발자
비협조적인 인프라 엔지니어에게 따지고 싶은 개발자
개발자에게 큰소리 치고 싶은 인프라 엔지니어
일일이 손으로 다 쳐가면서 일하기 싫은 귀차니즘 엔지니어
전화기 끄고 해외여행 다녀오고 싶은 엔지니어(하지만 돈도 없다면? 응?)
3. CONTENTS
1. DevOps 원정대 – Zinst 개발 배경
2. Zinst 와 함께하는 DevOps 여정
3. DevOps 적용 사례
4. 삽질기
5. Zinst 사용 매뉴얼
4. 1. DevOps 원정대 – 절대반지 Zinst 개발 배경
(The Fellowship of the DevOps)
5. 1-1. Zinst ?
Puppet, Chef, Ansible 등과 유사한
DevOps 도구로써 다양한 Server의 구성을
설치 관리 할 수 있도록 만든 도구
Yahoo!의 자체 서버 관리 도구인 Yinst의
Concept을 기반으로 제작
What?
사용편의성
재사용성
낮은 러닝커브직관성
심플한 시스템
구성
Zinst Puppet Ansible
6. 1-2. Why
꼭 만들었어야 했는가?
최근 Ansible이 해당 요구사항을 대체로 충족 하기는 하나, 2010년 당시 구축하고자 하는 환경과 업무 프로세
서에 적합한 도구로 기존의 것들(Cfengine,Chef)은 부족함이 많았음.
예를 들어 Puppet의 경우, 시스템 설치 및 설정 관리용으로는 적합하나 원격지로 커맨드를 날려 시스
템을 운영한다거나 하는 목적으로는 적합하지 않았음.(mcollective가 출시되면서 가능 해 짐)
Learning curve가 적고 사용이 간편해야 했음. 또한 무료여야 했음.
그런건 직접 개발 못하냐고? 직접 만들어 보라고… 누군가가 불사지름! 불타오른다!(오드엠 김창기 CTO님 오셨나요??)
7. 뭣이 중해서!
Yahoo에 있으면서 Yinst만 쓰다보니 Linux command를 다 까먹었다… (script 기록용…)
Yahoo에서는 한번에 서버 수십대씩 셋팅 했는데, 한대씩 하나 하려고 하니 귀찮았다.
Yahoo Korea가 없어지면서 밖으로 나온 Yahoo 개발자들이 엄.청.나.게. 써줄 줄 알았다!
머리속에 그려놓은 아키텍쳐와 개발 업무 프로세스/정책을 실행하기 위해서는,
중앙 집중 관리되는 자동화 시스템이 필수로 있어야 했다.
1-2. Why
(만나면 술만 엄청 먹음)
8. 1-3. Core Strength
다른 Project에 비해 강점은?(1/3)
Yum 또는 Apt-get의 경우 패키지 설치 시, 환경 설정을 별도로 처리해야 하며, 패키지 제
작자에 따라 각기 다른 방식과 디렉토리 정책 등에 의해 제품 사용에 앞서서 learning curve
가 높거나 제각각 임.
Zinst의 경우, 패키지 설치 시, Set값에 의해 하나의 패키지로 다른 서버에 다른 설정을 설치
와 동시에 적용 할 수 있음.
설정 파일의 위치 따위는 몰라도 됨. 설정방법이 대체로 일정 함.
9. 1-3. Core Strength
- Yum 예)
$] yum install apache
vi /usr/local/httpd/conf/httpd.conf
설정 파일 위치를 확인 후, 설정파일을 수동으로 직접 변경하여 처리(설정파일 수정에 대한 history가 남지않음)
- Zinst 예)
$] zinst install apache -set apache.maxclient=32 -set apache.documentRoot=/data/src/html
설치와 동시에 설정값 변경적용 가능
+@ zinst history 명령을 통해 변경내역 확인 및 rollback 명령을 통해 별도로 관리되는 revision으로 복구 처리 가능
10. Set 옵션으로 설정을 변경하는 방법이 핵심이지만 어떻게 적용 할지에 대한 방안이 없었다.
1-3. Core Strength
대상파일은 ”CONF”
변경 가능한 변수들
가수 박상민
아닙니다
수학자 입니다!
답을 먼저 보고 풀이를 만들어 나가다!
해당 변수를 Grep으로
찾아서 sed로 교체 처리
11. 설치가 완료된 장비를 대상으로, 원격에서 직접 관리 가능하며, 한번에 여러대의 장비에 동일
한 명령을 처리 할 수 있게 제작.
다른 Project에 비해 강점은?(2/3)
1-3. Core Strength
Yahoo에서는 engineer 한명이 80만대를 관리한다고!
1. 서버는 Group 단위로 설치/ 관리(패키로 정형화 하여 관리) - zinst로는 요거 끝냄
2. 명령어도 한번에 Group 단위로 적용 – 요거는 껌임
3. 각 Group은 관리자 Web service로 최상위 관리 - zinst의 경우 개발 시도중(돈이 없음..)
4. Group간 연관성 관리 - 3번 만들때 넣을꺼임
5. 도메인을 보면 어떤 서비스의 어떤 역할이며 어느 지역에 있는지 한번에 식별 가능 – 요것도 별거 아님
6. Blah Blah….
하지만 회사에 서버가 80만대가 안된다면!?......
12. 자체 repository를 매우 쉽게 구성 할 수 있게 고안되었으며,
자체적으로 package version관리를 함으로 인해 장기적으로 시스템을 관리 하더라도
외부 환경에 의한 문제를 최소화 해 줌.
다른 Project에 비해 강점은?(3/3)
1-3. Core Strength
외부 Repository의 File version이 update 되니깐
우리쪽 서버 설치가 안된다! 이게 내 잘못인가?
이게 사는건가…?
13. 1-4. How?
특징: Bash로 제작
초기에 Yinst의 도움을 받고자(?) Perl로 제작 하려고 하였으나, Perl version 5.8 과 5.10
에 호환성 문제로 인해 Python으로 방향을 전환해서 개발 하던 중, Stack Overflow의 답변
이 제각각 인 걸 발견.(Python의 Version 호환성 문제가 더 크다는 걸 뒤늦게 알게 됨)
어차피 Linux/UNIX 만 관리할 목적이니 공통적으로 버전 문제가 없는 Bash 채택
참고로 Linux는 C와 Bash로 대부분 만들어짐
딱 필요한 일부 기능만 돌아가는 도구를 만들 목적으로 프로토타입을 만들면, 나머지는 개발
자가 만들어 줄거라 착각했음… ㅠㅠ
14. 2. Zinst와 함께하는 DevOps 여정
(Journey for DevOps with Zinst)
16. DevOps
2-2. Help desk
소스 형상관리, 인프라 작업 요청 프로세스, 작업 Script 제작 및 Test & Package화
개발자가 직접 손대지 않아도 되는 인프라 만들기
Source Repository Project Manager & Helpdesk
17. 2-3. 시스템 운영자동화
개발자가 들여다 보지 않아도 알아서 잘 돌아가는 시스템 만들기
백업 Server 구축 및 백업 Agent 제작
시스템 이중화(Clustering, HA, BCP)적용 및 Test 검증
모니터링 시스템 구축(Nagios, Monit, Vipviewer) 및 모니터링 Agent 제작
Log collector(Logstash, Flume, Cacti)
기타 시스템 자동화 도구 개발 및 스케쥴러 제작
18. 2-4. 시스템 표준화
필요한 설정 및 구성을 한번에 볼 수 있는 직관적인 시스템 환경제공
굳이 들여다 보겠다는 개발자를 위해 인프라 심플하게 구성하기
root@mesos-slave-03:~# zinst ls
2016-05-02 16:29:37 - consul-0.0.2
2016-07-14 08:43:04 - docker-1.10.7
2016-05-02 16:29:35 - docker_compose-1.5.1
2016-05-02 16:29:06 - docker_registry_authorize_client-0.0.1
2016-05-02 16:29:06 - docker_registry_ssl_create_pem-0.0.1
2016-08-04 14:19:26 - gms_ui_container-0.0.3
2016-05-02 16:29:58 - gravity_hosts_file_public-0.0.3
2016-05-02 16:30:20 - account_policy-0.0.1
2016-05-02 16:29:57 - hosts_file_creator-0.0.2
2016-05-02 16:30:33 - logspout_logstash_container-0.0.5
2016-05-18 10:19:19 - mesos-0.0.7
2016-05-02 16:30:17 - mesos_allinone-0.0.8
2016-05-02 16:30:14 - mesos_consul_installer-0.0.5
2016-05-25 11:39:23 - monit-5.6.3
2016-07-15 10:35:06 - monit_consul-0.0.1
2016-05-02 16:30:40 - monit_cron-0.0.1
2016-05-02 16:30:41 - monit_docker-0.0.1
2016-05-02 16:30:34 - monit_logspout_container-0.0.2
2016-05-02 16:42:40 - monit_mesos-0.0.1
2016-05-02 16:42:41 - monit_rootfs-0.0.1
2016-04-26 10:18:31 - server_default_setting-1.3.5
root@mesos-slave-03:~# zinst set
#==========================ZinstSet===========================
consul.rule=server
consul.start_join=10.1.1.31,10.1.1.32,10.1.1.33
docker_registry_authorize_client.REGISTRY_URL=global.registry.gravity.com
docker_registry_authorize_client.USER=gravity-devel
docker_registry_ssl_create_pem.DOMAIN_NAME=global.registry.gravity.com
mesos_consul_installer.Consul="global.consul.gravity.com"
mesos_consul_installer.Service=breeze
mesos_allinone.HVISOR="kvm"
mesos_allinone.bakery_type="mc"
mesos_allinone.Haproxy_master="8081"
mesos_allinone.gravity_mgmt="global.consul.gravity.com"
mesos_allinone.role=slave
mesos_allinone.master_ip=10.1.1.22
mesos_allinone.adv_ip=10.1.1.22
mesos_allinone.nic=bond0
mesos_allinone.logstash_server=10.1.1.23:5000
logspout_logstash_container.docker_registry="global.registry.gravity.com/gravity/logspout-logstash:v24"
logspout_logstash_container.ports="8000:8000"
logspout_logstash_container.logstash_server=10.1.1.23:5000
mesos.port_pool="9090-9090,31000-32000"
mesos.quorum=1
mesos.Port=5051
mesos.advertise_ip=10.1.1.22
.
.
.
19. 2-5. DSL(Domain Specific Language)
굳이 들여다 보겠다는 개발자가 직접 다룰 수 있는 인프라 만들기
정해진 Command 와 내장 Manual,
패키지 단위로 서버 구성 관리
예) $] zinst install httpd -stable
$] zinst set httpd.Maxclient=64 -h 10.1.1.1[0-9]
20. 2-6. Recognizable System
Package & Setup Listing, History & Tracking
이게 뭔지 알 수 있게 만들기(서버 구성 정보/관리문서 없어도 됨)
Local server History
Package Tracking by host
Package Tracking by Package name
굳이 들여다 본 개발자가!
Domain naming convention
- [Endpoint][Digit].[Function(Opt.)]. [Env.].[Service].
[Location].[Company Domain]
ex) www01. api.stage.news.kr3.yahoo.com
21. 2-7. Permission & Recovery
LDAP Server & Client package + 계정권한정책 + 사용자계정 패키지
굳이 들여다본 개발자에 의해 시스템이 망가지지 않게 만들기
LDAP Server
Bastion
Management server
Install
Install
Install
Install package list:
LDAP Client package with Server information
Account Policy package(sudoers)
User Packages(ex. user_ralfyang, user_ariana)
Sudo User Packages(ex. sudo_user_ralfyang)
Admin
22. 2-7. Permission & Recovery
LDAP Server + Client package & 계정권한정책 + 사용자계정 패키지
굳이 들여다본 개발자에 의해 시스템이 망가지지 않게 만들기
LDAP Server
Admin & DeveloperAdmin
23. 2-7. Permission & Recovery
Revision management for Recovery
굳이 들여다본 개발자에 의해 시스템이 망가지지 않게 만들기
Save file for Recovery
2. 멱등성이 적용된 시스템 복구
$ zinst sync -file ./zinst-save.1037
1. 기준 정보로 삭제 후 재설치
$ zinst restore -file ./zinst-save.1037
멱등성: 먹는거 아님
24. 2-8. Well made Packages
자체 Package 제작 및 관리
검증된 몇개의 패키지로 충분히 좋은 시스템 구축 할 수 있게 만들기
YUM
APT-GET
25. 2-9. Server Cluster management
클러스터 관리
분산된 수십대의 서버를 서비스/네트워크 별로 동일하게 구축하기
Well made
package set
A service Test Servers B service Test Servers
A service Stage Servers B service Stage Servers
A service Prod. Servers B service Prod. Servers
Test env.
Packages
Prod. env.
Packages
Stage env.
Packages
A Service
Package set
B Service
Package set
26. 2-10. CI & CD
CI/CD 도구 및 프로세서 만들기(Deploy tool, VIPctl)
Developer
Commit CI Build
Artifact
Repository
PUSH
Source code repository
개발자가 직접 배포 할 수 있는 환경 만들기
27. 2-10. CI & CD
CI/CD 도구 및 프로세서 만들기(Deploy tool, VIPctl)
Developer
Repository
PUSH
Deploy Agent Test/Stage/Prod.
Servers
Deploy
Deploy &
VIP control
Deploy
Management tool
개발자가 직접 배포 할 수 있는 환경 만들기
29. Load-balancer controller
무중단 배포 시스템 구축하기
저는 오전 일찍 출근을 합니다. 보통 9시가 출근 해야 하는 시간이면 8시 정도에 회사에 도착을 합니다.
하루는 출근 시간에 지하철에서 스마트폰으로 홈쇼핑 물건을 구매 하려고 하는데 “페이지를 불러 올 수 없습니다.” 라는 에러와 함께 결
제가 안되는게 아니겠습니까.
세번 정도를 시도 했는데, 계속 실패가 떨어지는거죠..
그래도 우리 회사에서 사는 거고, 내가 이 인프라를 설계하고 있는 사람인데, 장애인건가 싶어서 계속 시도를 했고, 결국엔 결제가 되었습
니다.
배포를 담당하는 담당자를 찾아가서 혹시 오늘 배포가 있었냐? 오전에 결제하려고 하는데 안되던데 장애냐?
라고 물었고. 담당자는 배포를 진행 했다고 했습니다.
배포를 하는데 세션을 확인 안하고 Tomcat을 restart 하냐? 라고 묻자.
배포를 하는데 일일이 다 확인을 못한다고 하는게 아닙니까.
여긴 지금까지 그렇게 했고, 그런 이유에서 아침 일찍 배포를 진행한다고 하더군뇨.
한달에 한,두번 홈쇼핑에서 물건을 구매하는 제가 느낄 정도의 서비스 다운이라면 이건 치명적이라고 생각했고, 그럴거면 배포를 안하는
게 낫다고 생각을 했습니다.
30. 무중단 배포 시스템 구축하기
배포는 무중단으로 진행되어야 합니다. 작은 버그를 patch하기 위해 버그보다 더 치명적인 서비스 중단을 할 수 없습니다.
이때, 기존에 만들었던 VIPCTL이라는 도구를 급하게 수정하기 시작했습니다.
zinst off vipctl 라는 명령을 사용하면, l4-check.html이 Httpd의 DocumentRoot에서 파일이 삭제가 되고,
zinst on vipctl 이라는 명령을 사용하면, “OK” 라는 Text가 들어간 l4-check.html 이라는 파일이 DocumentRoot에 생성
이 되는것이지요.
이 방법은 기존에 야후에서 사용했던 도구를 생각해서 고안해 만든 방식입니다.
zinst stop vipctl 이라고 하면 ifconfig 정보에서 Loop-back이 제거되어 L4의 VIPGROUP에서 해당 서비스가 투입 되지
않게 만들어주며,
zinst start vipctl 라고 하면 loopback이 생성되어서 L4에서 DSR 방식의 Load-balancing이 적용되게 만들어서 쓸 수 있
게 됩니다.
이 vipctl을 아래와 같이 초기 설치 시에, loopback 정보를 미리 설정을 하면, 향후 stop/start시에 자동으로 해당 값으로
적용을 할 수 있습니다.
zinst i vipctl -stable -set vipctl.vips=“1.1.1.2”
이렇게 기능을 추가한 vipctl을 일종의 Network local controller 역할로 각 서버에 배포를 진행하였습니다.
https://github.com/goody80/vipctl
Load-balancer controller
31. Deploy agent는,
1. 배포 대상 서버를 지정하고 CI(Jenkins)를 통해서 해당 배포 에이전트 스크립트를 실행하면,
2. 저장된 서버의 정보를 기반으로 각 대상 서버에 Build된 Artefact가 복사되고,
3. 대상서버를 순차적으로 접속하여 zinst off vipctl을 실행하고,
4. L4로 SNMP request를 보내서 해당 장비가 VIP group에서 빠졌나를 확인하고,
5. 서버상 Tomcat processor를 확인하여 더 이상 남아있는 session이 없는 것을 확인 한 후 Tomcat daemon을 restart 합
니다.
6. Tomcat이 에러 없이 정상으로 restart가 되고 tomcat log에서 start message가 올라오게 되면,
7. 다시 zinst on vipctl 명령을 보내주어서 l4-check.html 파일을 생성 해주고,
8. L4는 상태를 확인하여 VIPGROUP에 해당 서버를 서비스에 투입합니다.
9. 관련해서 진행사항은 *VIPviewer를 통해 VIPGROUP에서 서버가 빠지고 들어오는 것을 확인 할 수 있도록 만들어 두었습
니다.
위의 과정이 한번에 종료가 되면, 언제라도 배포가 가능한 상태가 되며, 서비스별로 더 잘게 Web service나 WAS가 잘게 쪼
게 되면(MSA) 겹치지 않는 시점에서 더욱 빈번히 배포를 자동으로 진행 할 수 있게 됩니다.
서비스 롤백도 빨리 적용 할 수 있게 되고요.
무중단 배포 시스템 구축하기
*VIPviewer: G사 에서 직접 제작한 SNMP를 사용하여 L4의 VIPGROUP 상황을 확인하기 위한 모니터링도구
Load-balancer controller
32. DevOps가 하는 역할은 이런 것
1. 개발자가 서비스 운영에 관련해서 보지 못하는 부분을 보여주고,
2. 운영자가 필요한 도구를 서비스 품질 향상을 위해 지속적으로 개발하며,
3. 문제 및 개선점을 찾아서 지속적으로 확인하고 처리하는 업무를 진행 하는 것
무중단 배포 시스템 구축하기
Load-balancer controller
34. 1. Bash의 특성을 이해
1. 리눅스 환경 자체가 개발환경
2. 메모리 적재보다는 파일에 중간 결과를 저장하는 것이 가공하기 훨씬 쉬움
3. 라이브러리가 없음 -> 명령어 자체가 라이브러리 형태(ex. tsort)
4. 대체 가능한 것은 이미 없는지를 찾아봐야 함
환경구축 및 Zinst 개발 시 기술적으로 어려웠던 점/운영상 문제점
삽질기(?) – (1/3)
Package 의존성 정렬
A -> B
B -> C,D
D -> C
C -> D -> B -> A
순으로 정렬 후 설치 진행
tsort abc.txtA B
B C
B D
D C
abc.txt
35. 2. 검증과정
1. 가볍게 접근: 어차피 어플리케이션이 아니라 사람이 할 작업을 자동화 하는 것뿐
(Zinst는 거들뿐…)
2. Dev/Test/Stage에서 충분히 테스트
3. 작은 기능 구성 -> 복잡하고 다양한 기능구현 -> 멘붕, 포기, 이것 하나만 끝내자..
1. 필요에 따라 덕지적지 개발 (심지어 Zinst의 특성상 파일 하나에 다 해야함)
2. Refactoring -> Parser engine 제작 -> Parser 기반으로 기능을 함수로 추가 확장
환경구축 및 Zinst 개발 시 기술적으로 어려웠던 점/운영상 문제점
삽질기(?) – (2/3)
36. 4. 커뮤니티 활성화
1. 잘 안됨.(다들 Bash에는 관심 없음. 그런 것도 가능 함?). 지금도 안됨
2. Go로 만들어 주세효
5. Team work
1. 완전 운이 좋은 케이스: 기술의 가치를 인정 해주는 팀에서 자유롭게 개발
2. 케미가 맞는 파트너를 만나다!
6. Open-source에 대한 이해 및 가치인정
환경구축 및 Zinst 개발 시 기술적으로 어려웠던 점/운영상 문제점
삽질기(?) – (3/3)
42. • Ralf Yang = DevOps
• Startup company System Engineer
• NHN Services Datacenter Operator
• Yahoo! Korea Service Engineer
• EstSoft, Zum.com System Admin
• Dell international Enterprise Tech. Support Sr. Analyst
• GS SHOP Technical Architect
http://ralfyang.com
별첨: Speaker
43. 별첨: Speaker
• 활동
• Open-source committer:
• Zinst(https://zinst.me), Zinst packages, Cloud-dashboard, Docker-Cli-Dashboard, vipctl, etc.
• Rankedin Ranking
• http://rankedin.kr/user/goody80
• Facebook DevOps Korea Group Admin
• https://www.devopskorea.com
- With Monty: Father of MySQL - - With Joshua: God Father of OpenStack - - With Patrick McGarry: Director of Ceph Community -