Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS충섭 김
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS
Docker Seoul Meetup #2에서 발표한 자료입니다.
CoreOS에서 confd와 sidekick service를 이용한 서비스 배포에 대한 내용입니다.
http://www.youtube.com/watch?v=5ixJCM6pAcg
영상과 함께 보시면 더 좋습니다 :)
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS충섭 김
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS
Docker Seoul Meetup #2에서 발표한 자료입니다.
CoreOS에서 confd와 sidekick service를 이용한 서비스 배포에 대한 내용입니다.
http://www.youtube.com/watch?v=5ixJCM6pAcg
영상과 함께 보시면 더 좋습니다 :)
Docker 기본 및 Docker Swarm을 활용한 분산 서버 관리 A부터 Z까지 [전체모드에서 봐주세요]David Lee
저희 팀에서 Docker Swarm을 처음 도입한 계기는 사실 배포 자동화 프로세스 구축하고 싶었기 때문이었습니다.
처음엔 서버가 하나 뿐이여서 컨테이너 오케스트레이션의 묘미를 느끼지 못했는데 관리자, 푸시, 이벤트, 테스트 등등 여러 서버가 붙으면서 여러개의 서버를 관리해야 했는데
미리 구축해놓은 Docker Swarm이 많은 편의 기능을 제공하고 있어서 여러개의 서버를 관리하는 것도 개발자가 부담없이 할 수 있게 되었습니다.
이 슬라이드는 제가 서버를 구축하는 과정에서 겪었던 어려움들을 여러분은 겪지 않길 바라며 제작하게 되었습니다.
만약 이 슬라이드를 보시는 분이 Docker및 Docker Swarm을 처음 접해보시는 거라면 이 자료가 좋은 가이드가 될 수 있을 것 같습니다.
감사합니다.
이도현 드림
2016 아이펀팩토리 Dev Day 발표 자료
강연 제목 : Docker 로 Linux 없이 Linux 환경에서 개발하기
발표자 : 김진욱 CTO
<2016>
- 일시 : 2016년 9월 28 수요일 12:00~14:20
- 장소 : 넥슨 판교 사옥 지하 1층 교육실
Docker 기본 및 Docker Swarm을 활용한 분산 서버 관리 A부터 Z까지 [전체모드에서 봐주세요]David Lee
저희 팀에서 Docker Swarm을 처음 도입한 계기는 사실 배포 자동화 프로세스 구축하고 싶었기 때문이었습니다.
처음엔 서버가 하나 뿐이여서 컨테이너 오케스트레이션의 묘미를 느끼지 못했는데 관리자, 푸시, 이벤트, 테스트 등등 여러 서버가 붙으면서 여러개의 서버를 관리해야 했는데
미리 구축해놓은 Docker Swarm이 많은 편의 기능을 제공하고 있어서 여러개의 서버를 관리하는 것도 개발자가 부담없이 할 수 있게 되었습니다.
이 슬라이드는 제가 서버를 구축하는 과정에서 겪었던 어려움들을 여러분은 겪지 않길 바라며 제작하게 되었습니다.
만약 이 슬라이드를 보시는 분이 Docker및 Docker Swarm을 처음 접해보시는 거라면 이 자료가 좋은 가이드가 될 수 있을 것 같습니다.
감사합니다.
이도현 드림
2016 아이펀팩토리 Dev Day 발표 자료
강연 제목 : Docker 로 Linux 없이 Linux 환경에서 개발하기
발표자 : 김진욱 CTO
<2016>
- 일시 : 2016년 9월 28 수요일 12:00~14:20
- 장소 : 넥슨 판교 사옥 지하 1층 교육실
인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다.
본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다.
목차
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링 방법론
4. 모니터링 절차
5. NHN 모니터링의 미래
대상
- 인프라를 운영하는 시스템 엔지니어
- 인프라 모니터링 시스템에 관심이 있는 분
5. 운영
서비스 환경 구축
서버에서 어플리케이션 가동
서버 운영
메트릭스 수집
로그 수집
피드백
장애 대응
어플리케이션 개선
스케일 아웃 & 인
6. 모니터링 & 로그 수집
메트릭스 로그
수치 정보
리소스 모니터링
Munin, Diamond, Sensu, …
CPU, Load Avarage,
Memory, …
쿼리수, 접속자수, 부하, …
어플리케이션 모니터링
대개 직접 구현
접속자수, 에러수, …
임의 수치
행으로 구분되는 데이터셋
비정형 데이터
시스템 로그
사용자 정보, 로그인 정보
각종 시스템 서비스 로그
어플리케이션 로그
대개 직접 구현
7. 로그
행으로 구분되는 데이터셋
비정형 데이터
어플리케이션마다 독자적인 포맷 사용
CSV, XML, JSON, …
완전한 독자적 형식
어플리케이션마다 독자적인 출력 사용
파일
표준 출력
아파치 로그 예제
195.140.144.83 - - [16/Aug/2011:00:49:33 +0900] "GET …
195.140.144.83 - - [16/Aug/2011:00:49:37 +0900] "GET …
121.3.24.52 - - [17/Aug/2011:03:23:12 +0900] "GET …
24. 컨테이너 어플리케이션 로그
생각해볼 수 있는 방법
컨테이너 안에서 수집
어플리케이션 컨테이너에서 수집기 운용
컨테이너 외부에서 수집
Docker 로그 파일 직접 사용
25. 서비스(컨테이너)적인 사고법
로그는 서비스의 일부분이 아님
컨테이너에는 데이터가 저장되어서는 안 됨
The Twelve Factor App
http://the-twelve-factor-app.herokuapp.com/
26. The Twelve Factor App - Log (1)
로그는 모든 실행중인 프로세스와 백엔드 서비스의 누적되며
시간순으로 수집되고 정렬되는 이벤트 스트림이다. 일반적으
로 어플리케이션이 직접 생성하는 로그는 한 줄에 하나의 이
벤트를 텍스트 포맷으로 기록한다(예외를 추적하는 로그는
여러줄로 쓰여지기도 한다). 로그는 고정된 시작과 끝이 없으
면 어플리케이션이 실행되는 한 계속된다.
Twelve Factor App은 어플리케이션의 출력 스트림의 목적지
나 어디에 저장되는 지 일체 간섭하지 않는다. 어플리케이션
은 로그를 작성하거나 로그 파일을 관리하려고 해서는 안된
다. 로그 파일을 관리하는 대신 각각의 실행중인 프로세스는
자신의 이벤트 스트림을 버퍼없이 stdout에 출력한다.
27. The Twelve Factor App - Log (2)
로그는 시간순으로 수집되고 정렬되는 이벤트 스트림이다.
-> 표준 출력에 출력!
출력 스트림의 목적지나 어디에 저장되는 지 일체 간섭하지
않는다.
-> 어플리케이션에는 로그에 대한 설정/로직이 없어야함!
28. 도커 로그(로그 파일을 통한 수집)
docker logs 명령어
json으로 저장
docker inspect로 위치 파악
/var/lib/docker/containers 디렉터리의 {containerid}-json.log
접근시 root 권한 필요
31. progrium/logspout 장단점
장점
logspout 컨테이너 하나면 됨
매우 일관적인 로그 수집 시스템(표준 출력)
12 Factor App에서 환경변수로 설정을 관리하는 것과 비슷
단점
컨테이너에 문제가 생기면 로그 수집 정지(?!)
약간의 딜레이
stdout과 stderr만 수집 가능
어플리케이션 설계시 고려가 필요
32. 컨테이너 어플리케이션 메트릭스
기존과 크게 다르지 않음
메트릭스는 대개 실시간 데이터
어플리케이션에서 라이브러리로 직접 보냄
필요한 경우 파일이나 다른 수집기 사용