유혹하는 개발하기

블로그 이전: hexo로 옮겼또요

Mon, 25 Nov 2019 23:56:00 +0000

노션하고 비슷한 테마의 헥소 블로그로 옮겼습니다. 거기서 봬요 :)

새 블로그로 이동

[오늘의 공부] 19.09.06 | 개발 툴 - 다중 터미널 tmux

Fri, 06 Sep 2019 23:15:00 +0000

tmux

tmux : 다중 터미널로 개발하기

📔 레퍼런스

tmux 관련 용어들

1. 설치

brew install tmux

2. 설정

// config
vim ~/.tmux.conf

// reload
tmux source ~/.tmux.conf

3. 플러그인

설치

// 패키지 매니저 설치 brew install TPM

// 플러그인 목록 작성 vim ~/.tmux.conf

// + I로 설치

Tmuxinator

tmuxinator : 세션 관리

📔레퍼런스

1. ruby 설치 (2.4.6 이상이어야 tmuxinator 설치 가능)

기본 ruby 2.3.7로는 x
이 상태로 gem install tmuxinator 하니까 permission error 남.

2. rbenv 설치 (버전 관리 용도)

ruby-build : version 설치 / rbenv 설치 시 함께 설치 된다. (mac OS 인 경우)

brew update
brew install rbenv
rbenv install -l // 버전 리스트 확인 

3. ruby 2.6.4 설치

rbenv install 2.6.4
rbenv rehash // 새로운 환경을 재설정하는 옵션으로 새로 루비를 설치하거나 루비 젬을 설치한 다음 반드시 실행
rbenv global 2.6.4 // global, local, shell 옵션으로 관리 
ruby -v // ruby 버전 확인

// .zshrc(zsh 사용 경우) 또는 .bash_profiles 에 추가 // 매번 터미널 켤 때마다, 버전 지정해줄 필요 없도록.
eval "$(rbenv init -)"

// vim ~/.zshrc
// source ~/.zshrc

4. tmuxinator 설치

gem install tmuxinator

5. yaml 설정 파일 만들기

tmuxinator new PROJECT_NAME

그럼 두근두근… specup.yml 파일을 만들어보자! -3-… 에러

~/.bash_profiles 나 ~/.zshrc에 에디터, 셸 config 추가

vim ~/.zshrc // export EDITOR='mvim' 추가
source ~/.zshrc

짠!

.yml 파일 작성

tmuxinator start PROJECT_NAME 명령어만 입력하면 tmux 세션을 yml에 설정해둔 옵션으로 자동으로 실행한다.

tmuxinator list // project list 확인
tmuxinator new test

[쿠버 스터디#15] 쿠버네티스란

Thu, 22 Aug 2019 23:43:00 +0000

쿠버네티스

1. 등장배경

도커로 배포한 앱 서버가 3 ~ 5개 있다고 하자. 서비스가 커지면서 대용량 트래픽을 감당하기 위해, 빠른 시간 내 컨테이너를 몇 십 개로 늘려야하는 상황이 왔다. 이때 기존 서버를 다운 시키는 일 없이 컨테이너를 늘리기 위해 어떻게 할 것인가?

컨테이너가 어마어마하게 증가한다면, 도커만으로는 관리가 어려워지기 때문에 이를 운영, 모니터링할 툴이 필요하다.

2. 하는 일

도커와 쿠버네티스의 가장 큰 특징을 말하면, 도커는 애플리케이션을 컨네이너화하고 쿠버네티스는 오케스트레이션을 쉽게 해주는 자동화된 파이프라인에 가깝다.

3. 특징

오케스트레이션에 들어가는 리소스를 줄여준다.

공식문서에서는 쿠버네티스가 오케스트레이션의 필요성을 없애준다고 표현했다. 오케스트레이션이 ‘A를 하고, A를 하면 B를 하고, B를 하면 C를 하는 것’과 같이 정의된 워크플로우를 수행하는 것이라면, 쿠버네티스는 자동화된 프로세스 처리를 통해 운영자가 오케스트레이션에 들이는 리소스를 줄일 수 있도록 한다.

다양한 앱과 기능을 지원한다.

꼭 도커가 아니라도, 여러 컨테이너를 지원한다. 또한, 다음에 소개할 기능들처럼 다양한 기능을 지원하기 때문에 관리자의 선택권이 많아진다.

다양한 앱과 기능을 지원하기 때문에 monolithic(단단하게 하나로 잘 짜여진)하지는 않고, 융통성 있고 유연한 오케스트레이션 툴이다.

쿠버네티스의 기능

1. 서비스 디스커버리

내가 어디에 서비스를 올렸는지 알려준다.

2. 스토리지 오케스트레이션

사용자가 올리는 파일, 개발자가 관리하는 파일 등을 어디에 저장할 것인가. 또한, 그렇게 정한 storage(저장소)를 컨테이너에 마운트할 수도 있다.

3. 자동화된 롤백, 롤아웃

버전만 알려주면 다운타임 없이(서버를 다운시키는 일 없이) 버전 배포가 가능하다.

4. 자동화된 빈 패킹

각 컨테이너에 필요한 CPU, 메모리(RAM) 용량을 지정할 수 있다.

5. 자동화된 복구

문제가 생기면 스스로 어떻게 해결한다. 서버가 언제든지 죽을 수 있고, 늘어날 수 있는 ‘가축’처럼 변하면서 일부 서버가 죽어도 사용자에게 서비스를 할 수 있는 시대가 되었다. 하지만 서버의 대다수가 죽으면 운영이 위험하기 때문에, 서비스하던 노드가 죽으면 다른 노드에 컨테이너를 띄워서 서비스하는 등 셀프 힐링을 한다.

쿠버네티스 구성

1. 마스터 노드

마스터 노드 역시 클러스터의 일부이며, 컨테이너를 배포할 수 있는 다른 서버들을 인지하고 있다.

2. 워커 노드(미니언 노드)

워커 노드에서는 로컬처럼 컨테이너 실행을 위해 도커 엔진이 돌아간다.

3. 컨트롤러

컨트롤러는 서버의 가장 바람직한 상태를 기억하고 있으며, API 서버의 상태를 항상 감시한다. API서버의 상태를 확인하여, 만약 상태가 그 바람직한 상태에 어긋난다면, 바람직한 상태로 만들기 위한 태스크를 API 서버에 할당한다.

4. API 서버

API 서버는 마스터 내에 존재한다. key-value store에 원하는 상태를 저장하고, 저장된 상태를 조회해 모든 요청을 처리한다.

5. kubelet

마스터의 명령을 듣고 워커에게 그 명령을 전달시키는 역할을 한다.

6. Pod 컨테이너의 집합을 말한다. 네트워크의 네임스페이스와 로컬 볼륨을 공유한다.

쿠버네티스의 매니지먼트 유닛이며, 요청이 들어왔을 때 실제 어떤 컨테이너에 요청을 전달할 것인가 정해준다.

[오늘의 공부] 19.08.18 | 파이콘2019 둘째날 후기 - 라이트닝 토크

Sun, 18 Aug 2019 23:15:00 +0000

어머니 생신이라 중간에 나가 못들었던 라이트닝 토크.
솔직히 제일 재밌었다.

라이트닝 토크 오프닝

라이트닝 토크 시작 전, 짤막한 레크리에이션을 했다. 분단을 나눠서 ‘파이콘’으로 화음을 만드는 건데…
그런데….ㅋㅋㅋㅋㅋ
왜 안되는 거지…ㅋㅋㅋㅋㅋ

다함께 못하니 즐거운 불협화음이었다.

본격 라이트닝 토크

라이트닝 토크에서는 10명 이상의 발표자들이 5분 이내에 짤막한 발표를 한다.
라이트닝토크는 일반 발표 세션보다 더 가벼우면서 재밌게 들을 수 있어서 좋았다.

제일 인상 깊었던 건 2명인데 데이터 분석가가 되고 싶어 회사에 지원했다가 코딩을 못해 떨어졌던 이야기(이분 말씀도 잘하시고 재밌었는데 기술적인 문제때문에 발표를 다하지 못해 아쉬웠다), 그리고 카이스트 물리학 석사가 번개가 치는 현상을 파이썬으로 시각화해서 보여줬던 발표가 기억에 남는다. 피뢰침까지 구현해서 보여줬는데, 라이트닝 토크 전 발표 세션에서 신승우 님이 파이썬으로 물리 법칙을 실험해서 시각화해준 것과 비슷해 재밌었다.

그리고 다른 세션!

1. 피플펀드컴퍼니 - 이력서, 자소서 tip

저번 달에 취업성공패키지에서 취업교육훈련 때 들었던 내용과 비슷했다.
그럼에도 불구하고 나도 초반에는 비슷한 실수를 많이 했었다. (심지어 그렇게 하지 말라고 배웠는데도..ㅠㅠ)
어쩔 수 없이 여러 군데 지원하면서 실패해보고 실패 원인을 고쳐가는 수 밖에 없다.

Carol Willing 개발자님

2. 파이썬으로 좀 더 나은 대중교통 만들기

Carol Willing 개발자님

공공기관에서 일하시는 분인데, 좀 더 효율적인 배차 시스템을 위해(?)
python, pandas를 이용해 통계를 내고 버스 시간을 예측했던 사례를 발표하셨다.

데이터 애널리틱스 강의 때 들었던 통계학 용어들을 오랜만에 들으니 정말…
인간은 역시 망각의 동물이구나라는 것을 새삼 다시 느꼈다.

아무튼 거의 아웃사이더 급으로 빠르게 발표하셨다.
이걸 받아 적으신 문자 통역사님은 얼마나 타자가 빠르신 걸까..?

3. 테스트 주도 개발

테스트 케이스 순서 : 성공하는 케이스 -> 실패하는 케이스 -> 버그가 발생하는 케이스

Carol Willing 개발자님

마지막

마지막은 파이콘을 준비한 분들, 파이콘 행사 당시 고생하신 분들, 그리고 참가자 자신에게 박수를 보내며 훈훈한 마무리를 지었다.

조카들이 조금 커서, 코딩을 배울 수 있는 나이가 되면 함께 오고 싶다.

[오늘의 공부] 19.08.17 | 파이콘2019 첫째날 - 행사 참여 후기

Sat, 17 Aug 2019 23:15:00 +0000

키노트

1. 반병현 개발자(코딩하는 공익)

그전에 8퍼센트 인턴을 할 때, 재미있게 봤던 브런치 작가, 반병현님(코딩하는 공익)의 키노트가 있었다.
그로스 해킹을 통해 브런치 글을 퍼뜨리고 자기 자신을 브랜드화하는 데 성공한 이야기를 해주셨다.
이 모든 게 파이썬을 통해 가능했으므로 ‘파이썬은 최고입니다!’라는 결론을 내리셨다 (어째 마지막엔 겸손하게 끝내신 듯). 일반 마케팅 전공(나)보다도 본인 PR을 훨씬 잘하시는 것 같다.

‘엔지니어들은 기술을 통해 내 주변의 불편함을 해결하는 사람들’이라고 하셨다.
반병현님은 그냥 해결하는 게 아니라, ‘창의적으로, 재미있게’ 해결하는 사람 같다.
실물로 봐서 신기했고, 또 직접 발표하시는 걸 보니 글도 재밌는데, 말씀도 재밌게 하신다.
앞으로도 잘되셨으면 좋겠다. :)

2. Carol Willing - Python core developer

Carol Willing 개발자님

스프린트 때 rustpython에 함께 계셨던 Carol Willing 개발자님의 키노트.
파이썬의 코어 개발자인 Carol은 현재의 Python, 그리고 미래의 Python에 대해 말씀해주셨다.

메모한 것을 써보자면,

Python2는 이제 바이바이. 현재 python은 3.8까지 나왔다.
파이썬, 그리고 우리의 코드가 발전하기 위해서는?
좋은 코드는 항상 소통에서 비롯된다.
코드로 소통하기 위해 Carol이 소개하는 Tool들 : Jupyter, nteract, binding.
nteract는 jupyter의 뉴 버전. 그냥 jupyter보다 남들과 공유하기 편하다.
binding의 경우는, 도커 컨테이너를 통해 자신의 주피터 환경을 공유할 수 있게 해준다. 교육 활동에 유용해서 Carol이 자주 쓴다고 한다.
그리고 파이썬의 미래를 Web, Binaries, Mobile 3가지로 설명한다.
이 3가지 분야에서 우리가 해야할 일들은
Web Assembly(WASM) 관련 뉴스를 계속 확인하고
Rust나 WASM 관련 프로젝트를 직접 해보고
겸손해지는 것(배우는 것을 멈추지 않는 것)이다.

첫번째 세션 : 파이썬의 변수, 강한 타입

파이썬을 공부하면서 조금 생소하게 들리는 immutable, mutable 타입에 대해 배웠다.
혹은 배웠는데 기억하지 못하는 것일 수도 있다.
~~연오님께 말하면 ‘어? 현지님 그거 배웠는데. 제 책에 나와있어요.’라고 말하실 수도 있겠다.~~
어쨌든, 어차피 기억하지 못하는 건 모른다는 것이니 재밌게 들었다.

발표자님 질문에 대답을 해서 발표자님이 쓰신 ‘파이썬 프로그래밍’ 책도 받았다.
두꺼워서 거의 무기로 써도 될 것 같다(무기로 쓰라고 주신 건 아니겠지만)

이 날 어머니 생신이라 파이콘 도중에 나와서 가족과 함께 외식하러 갔는데
이제 막 걷기 시작한 조카가 이 책에 많은 관심을 보였다. 에구에구 ^^

[오늘의 공부] 19.08.16 | 파이콘2019 스프린트 2일차 후기 - 테스트 / 백 인써트 자원봉사

Fri, 16 Aug 2019 23:15:00 +0000

피드백

내가 날렸던 PR 에서 이런 식으로 보완할 부분에 대해 코멘트를 남겨주셨다. 처음에는 단순히 체크박스만 추가했는데, 현우님의 피드백에 따라서

링크가 있는 경우에는 체크박스를 해제된 상태로 남기고
링크가 없는 경우에는 체크박스를 체크된 상태로 남겼다.

그리고 기존 코드에서 http://가 하드코딩 되어있던 것을 settings.js 에 기본 값으로 설정해놓았다.

테스트

왼쪽은 링크 생성 시, 오른쪽은 링크가 이미 존재할 때 체크박스의 상태이다.

이렇게 링크 생성 시 체크된 상태로, 링크가 이미 있다면 체크를 해제시킨 상태로 만들었다.
즐거운 마음으로 PR을 날렸고, 현우님은 친절하게도 테스트하는 법까지 알려주셨다.

테스트 케이스를 작성하고 한쪽 cmd로 karma를 실행한 뒤, 한쪽 cmd로 테스트를 실행했다.
기존 테스트를 제외하고 작성했던 4개의 테스트 케이스가 모두 통과했다.

그리고 merge!

스프린트 서울

이렇게 PR을 날리고, 피드백을 받고, 테스트를 추가해 프로젝트의 테스트 커버리지까지 유지하는 방법을 배웠다.
친절한 스프린트장님 덕에 꿀팁도 많이 알아가고, 격월마다 열리는 스프린트 정보까지 얻었다 ㅎㅎ

10월에도 비슷한 주제들로 스프린트가 열린다.
아직 참가 신청을 안받는 것 같은데(?) 이번 스프린트 경험이 너무 좋아서 10월에 열리는 것도 가고 싶다.
서울에 계신 분들, 스프린트에 참여하고 싶은 분들은 함께 해요 ^0^

스프린트 서울 홈페이지 바로가기

백 인서트(Bag Insert)

파이콘 참가자 1800명을 위한 굿즈를 에코백에 담아서 정리하는 이벤트가 있었다.
굿즈를 백에 담아서 Bag Insert라고 이름을 지었나보다. 재밌다는 스프린트장님 말에 혹해서 참여했다.
스프린트가 끝나고, 치킨과 피자를 먹고(취준한다고 끼니 거르는 일이 많았는데 오래만에 치킨, 피자를 먹어서 너무 좋았다.) 봉사활동을 했다.

인간 컨베이어 벨트의 일부가 되어 에코백에 굿즈를 담았다.
계속 돌아가면서 굿즈를 담고, 완성본은 한 곳에 모으는데
흡사 SCV들이 미네랄을 캐서 일렬로 커맨드센터에 공급하는 광경이었다.

커맨드센터에 쌓인 미네랄

이날 우리가 80분? 90분? 만에 1800개를 다 채웠는데, 신기록을 세웠다고 한다.
이게 뭐라고 또 신기록이라고 하니 뿌듯하다 ^^

[오늘의 공부] 19.08.15 | 파이콘2019 스프린트 후기 - Summernote WYSIWYG editor (첫 오픈소스 활동!)

Thu, 15 Aug 2019 23:15:00 +0000

깃허브 블로그도 업데이트 해야하는데.. 편의상 오늘의 공부 카테고리는 네이버 블로그에 올리고 있다.

Summernote

summernote는 WYSIWYG editor 오픈소스 프로젝트이다.
star가 8,718로 WYSIWYG editor 사이에서는 가장 인기가 많다.

summernote의 두번째 commiter 박현우님께서 스프린트장을 맡으셨다.
오자마자, 프로젝트 구조에 대해 친절히 설명해주셨다.

그리고, chrome debugging이랑 git, javascript 프로젝트에 대한 지식, 꿀팁을 알려주셨다.
진짜 오길 너무 잘했다고 생각!

파이콘 스프린트의 묘미

파이콘은 일반 티켓이 7만 원이고, 튜토리얼은 티켓을 보유하면서 추가 티켓 요금(1만 5천 원)을 내야하지만, 스프린트의 경우 파이콘 티켓을 살 필요도 없고, 무료이다!

스프린트에 참여하면 얻게되는 이점들이 있다.

1. 잘하는 분들께 배울 수 있다.
summernote는 javascript 기반이기 때문에 javascript와 관련된 것들, 웹에 관한 정보를 많이 얻을 수 있었다. ~~분명 Pycon이지만, 자바스크립트 스프린트에 참여했다.~~ (파이썬 프로젝트 스프린트에 참여하면 그와 관련된 정보를 얻을 수 있을 것이다.)

2. 프로젝트의 maintainer를 만나서 그 자리에서 바로 PR(pull request)을 날리고 merge가 가능하다!

보통 PR을 날리면 확인하는 데 몇일, 몇달이 걸릴 수 있지만 스프린트에 참여하면 바로 merge 해주신다. ~~이상이 없는 한~~

세계적인 프로젝트인 경우, 영향력이 더 크기 때문에 파이콘 본진에서 스프린트에 참여하는 것도 의미가 크다고 한다.

3. 개발 초보도 참여 가능하다

오픈소스 프로젝트의 규모나 maintainer마다 다르겠지만, 오늘 뵀던 스프린트장님의 경우 오픈소스 활동이 처음인 나를 위해 오탈자를 고치는 issue를 던져주셨다.

그리고 PR을 날리면 스프린트 팀원들이 다같이 박수를 쳐준다(너무 귀엽..♥).
+ 파이콘 스탭들이 풍선을 가져와 스프린트 플래그에 달아준다.

첫 오픈소스 PR!

이슈 해결하기!

3313번째 이슈

아직 Merge는 안됐지만, 오탈자만 고치는 건 아쉬워서, 비교적 쉬운 카테고리로 분류된 이슈 중에서 내가 해결할만한 것을 찾아 고쳤다.

기본적으로 사용자가 입력한 url 주소에서 정규표현식으로 프로토콜(‘http’, ‘https’, ‘ftp’ 등)을 찾고, 없으면 url 앞에 http://을 자동으로 붙여주는 기능이 있었다.

네이버 스마트 에디터의 경우에도, 프로토콜이 없으면 자동으로 http 프로토콜을 추가해주지만, 사용자가 추가된 http 프로토콜을 지울 수 있게끔 되어있다. 반면, summernote는 지워도 지워도, ‘너, 프로토콜 쓰는 거 까먹었구나!’하면서 추가해주는 것이다.

가장 간편한 방법은 ‘정규표현식 검사하지 않기’이다. 프로토콜 여부와 상관없이 그냥 사용자가 입력한 값 그대로 렌더링하는 것이다. 하지만, 위의 이슈 제안자처럼 특수한 경우가 아니라면, 평소에는 프로토콜을 자동적으로 추가하는 게 더 편리할 것이다.

그래서 프로토콜을 사용하는 체크박스를 만들어서, 사용하지 않는 경우는 체크 해제해서 프로토콜을 추가하지 않도록 만들었다.

‘Use protocol when not exists’ 체크박스

http 프로토콜 없는 링크

이렇게 해서 처음보다는 조금 더 나은 PR을 날릴 수 있었다.

두번째 PR

[도커 스터디#14] 도커 네트워크

Fri, 09 Aug 2019 16:43:00 +0000

도커 네트워크(Docker Network)

도커 네트워크에는 Bridge, None, Host 등이 있다. (다른 네트워크는 플러그인을 설치해 사용할 수 있다)

Bridge는 docker run 이미지명
None은 docker run 이미지명 --network=none
Host는 docker run 이미지명 --network=host

각각의 네트워크는 위와 같이 파라미터를 전달하여 사용할 수 있다. Bridge는 default 네트워크이기 때문에 파라미터 전달 없이 사용 가능하다.

저번 시간에 공부했던 ingress, overlay 네트워크에 대해 더 정확히 이해하기 위해 각각의 네트워크를 알아보자.

브릿지 네트워크

호스트에서 생성되는 컨테이너들은 기본적으로 브릿지 네트워크 안에서 연결된다. 이 컨테이너들은 172.17.x.x의 범위 내에서 각각 IP주소를 할당받고, 필요한 경우 이 내부 IP를 통해서 서로 접근할 수 있다. 반대로 동일한 브릿지에 연결되지 않은 컨테이너는 격리시키는 효과가 있다.

브릿지 네트워크는 동일한 호스트에서 여러 컨테이너가 필요한 경우 사용한다. 만약 다른 호스트에서 실행되는 컨테이너 간에 통신이 필요하다면 Overlay Network를 사용한다.

1. docker0

docker를 설치하고 ifconfig로 네트워크 인터페이스를 살펴보면 가상 인터페이스 docker0를 확인할 수 있다.

docker0는 기본 브릿지 네트워크로서, 사용자 정의 브릿지 네트워크와는 달리 -p 또는 --publish 옵션으로 컨테이너를 실행할 때마다 포트를 지정해주어야 한다. (반면 사용자 정의 브릿지 네트워크에서는 내부 포트는 자동으로 서로 공유하고, 외부 포트는 하나로 고정해 일일이 지정할 필요가 없다.)

docker0의 IP주소는 172.17.x.1로 고정되어 있다.

Bridge Network : docker0

2. veth

컨테이너를 실행하면, 브릿지 네트워크에 veth를 통해 연결된다. 현재 실행 중인 3개의 컨테이너 만큼 veth가 생성되어 있다.

※ 리눅스 Namespace와 veth 설명 참고

veth

현재 실행 중인 컨테이너

호스트 네트워크

호스트 네트워크를 사용하는 경우, 브릿지처럼 가상 네트워크 인터페이스로 독립된 네트워크를 사용하는 게 아니라 host 네트워크를 함께 공유한다. 따라서, docker0에 연결되지 않는다.

host의 다른 프로세스나 특정 컨테이너에서 포트 번호를 쓰면, 다른 컨테이너에서는 이미 선점된 포트 번호를 쓸 수 없다.

빈 네트워크(None Network)

sudo docker run 이미지명 --network=none을 통해 실행한 컨테이너는 어떤 네트워크와도 연결(attached)되지 않는다. 그래서 외부 네트워크나 다른 컨테이너에서 접근할 수 없다. 이 네트워크는 스웜 모드에서는 사용할 수 없다.

오버레이 네트워크

1. 오버레이 네트워크

여러 호스트에 각각의 브릿지 네트워크가 있다. 다른 브릿지 네트워크와는 격리된 상태이기 때문에 다른 브릿지 네트워크의 컨테이너와 통신할 방법이 없다. 이때 아래처럼 오버레이 네트워크를 사용해 모든 노드가 스웜을 통해 통신할 수 있다.

sudo docker network create --driver overlay --subnet 10.0.9.0/24 오버레이-네트워크-명

새로 만든 컨테이너가 있다면 아래 명령어로 네트워크에 추가할 수 있다.

sudo docker service create --replica 2 --network 오버레이-네트워크-명 nginx

2. 단일 노드에서의 ingress network

아래 명령어는 하나의 컨테이너만을 운영할 때는 괜찮다.

sudo docker run -p 외부접속포트:내부포트 이미지명

그런데 스웜 모드로 운영한다고 할 때, 하나의 노드에 여러 개의 replica 컨테이너를 만든다고 하자. 이렇게 되면 여러 컨테이너가 같은 포트를 쓸 수 밖에 없는 상황이 된다. 이럴 때는 도커 스웜에서 자동으로 로드밸런서가 내장된 ingress network를 형성하고 외부 포트에서 들어오는 트래픽을 알아서 적당한 컨테이너에 리다이렉트해준다.

3. 여러 노드에서의 ingress network

여러 노드에서 ingress network가 형성된 경우, 마치 overlay 네트워크처럼 작동한다.

사용자가 어떤 노드를 통해 접속해도 로드 밸런서를 통해 다른 노드의 컨테이너에 접근할 수 있다.

만약 사용자가 접속한 노드에 장애가 있거나 컨테이너가 없는 경우 어떻게 될까? ingress network에서는 routing mesh를 통해 여러 노드 내에서 같은 IP 주소와 포트를 공유할 수 있다. 즉, 사용자가 요청하면 호스트 이름과 포트를 조합해 트래픽을 적절한 서비스로 라우팅한다.

참고

[도커 스터디#13] 도커 스웜(Docker Swarm) - 세번째 스터디

Sat, 03 Aug 2019 18:46:00 +0000

배운 것

1. 도커 스웜

여러 컨테이너의 관리를 쉽게 할 수 있게 도와주는 오케스트레이션 도구. 오케스트레이션 툴은 많지만, 스웜은 도커를 이용해 다른 툴보다 훨씬 편하다는 장점이 있다.

2. 멀티 호스트 네트워크 - ingress network & backend overlay

멀티 호스트 네트워크는 분산된 네트워크를 하나의 네트워크처럼 사용하기 위한 방식이다.

ingress는 외부에서 내부 네트워크로 접속할 때 어떻게 처리할 것인지 결정한다. 하나의 서비스 안에 여러 컨테이너 레플리카들이 있는데 이들 중 어떤 컨테이너가 서비스하도록 할 지 로드밸런싱을 한다.

ingress network

반면, backend overlay 방식은 기존 네트워크와 다른 네트워크를 연결하는 방식이다. 도커에서는 기존 네트워크에 다른 서비스를 연결시켜 서비스 간에 통신할 수 있게 해준다.

overlay nerwork

3. 서비스 스케일 업

docker-compose.yml에서 replica의 개수를 변경하는 것과 같다. docker service scale 서비스이름=레플리카수로 서비스 내의 레플리카 수를 변경한다.

4. 컨테이너가 한 개일 때와 여러 개일 때

컨테이너가 한개인 경우 curl로 요청하면 하나만 뜨지만, 여러개를 띄우면 curl로 요청할 때 로드밸런싱이 되서 요청할 때마다 다른 호스트네임이 뜬다.

5. 로깅

WAS와 http에서 찍는 2가지 로깅이 있다. WAS는 프로그램 상에서 생기는 문제를 로그로 남긴다. http에서 찍는 로그는 액세스 로그로서, 응답을 받았을 때 200, 300, 400 등의 로그를 찍는다. 도커는 로깅과 모니터링 기능을 지원하지 않는데, 이때 지원 못하는 로깅은 ‘통신이 잘 되는지 안되는 지’ 확인할 수 있는 트래픽 로깅이라고 한다. 반면, 쿠버네티스에서는 로깅과 모니터링을 할 수 있다.

6. 클러스터링

여러 개의 서버를 하나의 서버처럼 사용할 수 있다. 도커에서는 여러 컨테이너를 하나처럼 묶어서 사용할 수 있는데 이렇게 묶인 것을 클러스터라고 한다.

7. 서비스 디스커버리

OSI 4 또는 7계층으로 주소를 구분하여 서비스를 찾아준다.

8. 스케줄링

태스크를 스케줄에 맞게 일정한 시간 내에 띄우거나 죽이거나 한다. 도커 스웜에서서는 로드 밸런싱을 할 때 라운드로빈 방식을 쓴다. 라운드로빈 방식을 쓰긴 하지만, 다음 서버에 응답이 없으면 건너 뛰고 다음 서버에 요청한다.

9. 도커 공식 문서에서 매니저 노드를 홀수로 하는 게 좋다고 되어있는데 왜일까?

매니저 노드가 짝수 개인 경우, 스웜에서 한 매니저가 죽으면 raft 알고리즘에서 과반을 입증할 수가 없다. (이걸 이해하려면 raft 알고리즘을 먼저 알아야한다.)

4개의 매니저 노드 중 매니저 하나가 죽었다고 하자. 명령 실행을 위해 다른 매니저 노드들에게 합의를 요청한다. 죽은 서버와 자신을 제외하고 2개의 표를 얻는데, 4개 노드 중 2개의 동의로는 과반을 입증할 수 없기 때문에 합의를 볼 수 없는 상황에 이른다.

※도커 리더 다운 실험 참고

10. curl 외에 요청 확인하는 법

httpie를 이용하면 응답이 깔끔하게 정리되어서 나온다. httpie 사이트 참고

11. 순차적 업데이트

도커는 블루그린 방식으로 업데이트 하는 방법을 쓴다. 기존에 만든 서버를 그린이라고 한다. 그리고 기존 서버를 똑같이 복제한 것을 블루라고 한다. 이렇게 굳이 복제를 만드는 이유는 뭘까?

기존 서버를 변경할 때, 서비스를 중단하지 않으려면 업데이트 동안에 대체할 다른 서버가 필요하다. 따라서 복제 서버를 만드는 것이다.

도커 내에 컨테이너를 만들고, 변경이 생기면 기존 컨테이너가 똑같이 복제되어 그린을 업데이트하는 동안 블루로 대체하고, 업데이트가 끝나면 다시 그린으로 대체하는 방식을 쓴다.

12. 매니저노드에서 워커노드가 살아있는지 확인하는 법

1초마다 curl요청을 보내 응답이 없으면 서비스에서 제외시켜버리고 다른 서비스에 요청을 보낸다. 마치 부장님이 급하게 처리할 업무 해결을 위해 사원에게 1초마다 카톡을 보내는데, 1이 사라지지 않으면 해당 직원을 해고하고 다른 사원에게 그 요청을 보내는 것과 같다. ~~무서운 고래 떼~~

13. 스택?

도커 스웜 내에 여러 서비스를 아우르는 것을 스택이라고 한다.

14. ADD나 COPY를 쓰는 이유

이미지를 기반으로 컨테이너를 생성할 때, 컨테이너에 필요한 서비스를 적재해야한다. 따라서 로컬로부터 필요한 서비스들을 ADD나 COPY 명령으로 컨테이너에 담는 것이다.

다음 스터디

이제 쿠버네티스로 넘어간다! 다음주에는 실습 환경을 구축해서 온다. 쿠버네티스와 가장 궁합이 잘 맞는 centOS를 사용한다. 이제까지는 AWS 인스턴스에서 실습했지만, ~~사양이 딸리기 때문에..크흡~~ VMware로 갈아타기로 했다.

[도커 스터디#12] 라운드로빈 스케줄링

Fri, 02 Aug 2019 17:37:00 +0000

스케줄링

1. 스케줄링이란?

CPU의 응답 시간을 최소화하고 처리율을 극대화시키기 위한 프로세스 처리 방식을 말한다. 대기 시간은 최소화하고 최대한 공평하게 처리하는 것을 목적으로 한다.

2. 비선점, 선점 스케줄링

쉬운 이해를 위해 비유를 들어보자. 백장미 학원은 무조건 출석한 순서대로 학생을 봐준다. 다음날 아무리 중요한 시험이 있는 학생이라도 이미 앞의 순서 학생을 봐주기로 한 선생님께 자신을 먼저 봐달라고 우길 수 없다. 이런 것처럼 비선점 스케줄링은 이미 할당된 CPU를 다른 프로세스가 강제로 빼앗아 사용할 수 없는 스케줄링 기법을 말한다.

반면, 들장미 병원에서는 환자들을 순서대로 접수해도, 응급실에 실려온 환자가 가장 먼저 의사의 치료를 받는다. 선점 스케줄링은 우선순위가 높은 프로세스를 빠르게 처리한다. 오늘 공부할 라운드 로빈 스케줄링도 선점 스케줄링에 해당한다.

3. 시분할 시스템

선점 스케줄링은 대화식 시분할 시스템에 사용된다.

시분할은 ~~왜 욕하는 것 같지~~ 같은 시간을 여러 개로 쪼개어 병행 작업을 할 때 사용된다.

예를 들어, 한 사용자가 입력할 때, 컴퓨터는 그 입력을 기다리는 동안 다른 사용자의 요청을 처리한다. 각 사용자는 마치 자신만이 그 컴퓨터를 사용한다고 착각하지만 사실을 여러 사용자가 그 컴퓨터를 사용하고 있다.(예시 출처: 위키백과) ~~영화 her의 사만다가 생각난다.~~

라운드 로빈 스케줄링

1. 라운드 로빈

시분할 시스템(Time Sharing System)을 위해 고안된 방식이다. CPU에게 할당된 총 프로세스들의 작업 시간을 여러 개로 쪼갠다. 이 하나의 시간을 타임 슬라이스 혹은 타임 퀀텀이라고 한다. 각 프로세스는 할당된 시간만 실행한 후 우선 순위가 맨 뒤로 밀려난다.

도커 스웜의 한 서비스 내에서 로드밸런싱을 할 때는 각 태스크들이 라운드로빈 방식으로 스케줄링된다.

2. 어떻게 돌아가는지 확인해보기

아래와 같이 프로세스가 할당되었다고 하자.

프로세스	A	B	C
실행시간	20	6	4

각 타임슬라이스에서 라운드로빈 방식의 프로세스 처리는 아래처럼 이루어진다. 타임 슬라이스는 5초라고 하자.

인덱스 1에서 A는 주어진 시간 내 작업을 처리하지 못해 C 다음으로 우선순위가 밀려난다. C의 타임슬라이스가 끝나고 난 뒤 4번 인덱스에서 다시 시작된다. 5번 인덱스에서 나머지 B 프로세스도 끝나고 나서야, 6번 인덱스부터 남은 타임슬라이스에서는 계속 A가 작업을 실행한다.

인덱스	타임 슬라이스	작업	남은 시간
1	0 ~ 5초	A	15초
2	5 ~ 10초	B	1초
3	10 ~ 14초	C	끝
4	14 ~ 19초	A	10초
5	19 ~ 20초	B	끝
6	20 ~ 25초	A	5초
7	25 ~ 30초	A	끝