데브원영

최근 github에서 Pull request(이하 pr)에 대해 작성하고 답변하던 도중(kubernetes git-sync pr 주고받은 내용 바로가기) 어떻게 pr을 적는것이 효과적일까에 대해 고민이 많아졌다. 고민과 동시에 구글링을 해봣는데 2015년 github blog에 올라온 좋은 글이 있어 해당 내용을 정리하고자 하여 posting을 하게 되었다. 원글 : How to write the perfect pull request 원글에서는 3가지의 상황에 따라 pr을 작성하는 방법에 대해 소개하였다. Pull request를 시작하는 방법 - pr을 날리는 목적에 대한 내용을 포함하라. ex. ...기능을 화면에 간편하게 표시하기 위함. ex. ...을 작동시키게 하기 위함. - 왜 이 pr을 생성..

개발자가 자신이 개발한 내용을 포스팅할때 이때까지 불편하게 colorscript(링크)나 혹은 github의 gist(링크)를 통해서 개발한내용을 블로그에 embedded 하곤 했다. 그러나 asciinema(링크) 를 쓴다면 더 동적으로 실시간으로 터미널을 녹화하여 포스팅 할 수 있다. 준비물macbook or linux computer with terminalhomebrew터미널에 설치 방법brew install asciinema 녹화 방법시작 : aciinema rec 끝 : exit 영상 파일 블로그에 포스팅 방법녹화 완료.cast 파일 업로드script 다운로드 및 추가 js, css 다운로드 : https://github.com/asciinema/asciinema-player/releasese..

Hazelcast Lock 하젤케스트에서 사용하는 ILock은 java.util.concurrent.locks.Lock 의 상속구현체이다. 즉, 모든 클러스터에서 네트워크상에 이상이 없는한, lock이 잡힌 critical section은 한번에 한 쓰레드만 도는 것이 보증된다. Lock 구현은 매우 신경써서 하지 않으면 문제점이 바로 생겨날 가능성이 있으므로 주의하여 구현해야만 한다. Try-catch구문을 사용하여 Lock 사용하기 lock안쪽 구문은 반드시 try-catch 구문을 사용해야한다. 만약 critical section에서 에러가 났을때 unlock 가능하도록 도와주기 때문이다. 또한 lock구문에서 에러났을때 unlock되는 것을 막기 위해 lock method의 밖에도 try-catc..

IMDG가 필요한 이유?일반적인 1 server, 1 application 구조에서는 memory상에 자신이 쓰고자 하는 자료구조(map, lock, list 등)를 올려두고 쓰면된다. 그림. 일반적인 1 server, 1application 구조 그러나.. 만약 *(many) server, *(many) application 구조에서 특정 자료구조(map, lock, list 등)를 공유해서 사용하고 싶다면 In-Memory Data Grid가 그 해법이다. 그 중에서 추천하는 것은 JVM위에서 돌아가는 Hazelcast를 강추한다. 그림. Hazelcast(IMDG)를 사용하여 자료구조를 공유하여 동시에 사용가능 IMDG란?IMDG : In memory data grid더 빠른 결과를 제공하기 위한 ..

ServerKeyDescriptionDefault valuesonar.host.url소나큐브 서버 urlhttp://localhost:9000Project ConfigurationKeyDescriptionDefault valuesonar.projectKeyThe project key that is unique for each project. Allowed characters are: letters, numbers, '-', '_', '.' and ':', with at least one non-digit. When using Maven, it is automatically set to :. sonar.sourcesComma-separated paths to directories containing sou..

각 솔루션이 하는 역할 위와 같은 솔루션을 선택한 이유 -> [Telegraf + influxDB + Grafana]DevOps를 위한 서버 모니터링 솔루션 선택 보러가기(클릭) 무엇을 할까? 내 컴퓨터를 위한 시스템(cpu, memory 등)을 모니터링하는 이쁘고 귀여운 모니터링 시스템 준비사항 * 10분 * 맥북 * Homebrew 앱 설치, 설정(3min) 1. 텔레그래프 설치 $ brew install telegraf 2. 텔레그래프 설정 $ cd /usr/local/Cellar/telegraf/1.5.1/bin $ telegraf config > telegraf.conf $ vi telegraf.conf ###################################################..

The role of each solution What you'll build Beautiful system metric monitoring system for own computer(localhost). What you'll need * About 10 minutes * Macbook * Homebrew Install & setup apps(3min) 1. install telegraf $ brew install telegraf 2. setup telegraf $ cd /usr/local/Cellar/telegraf/1.5.1/bin $ telegraf config > telegraf.conf $ vi telegraf.conf ##########################################..

DevOps는 개발자가 갖추어야할 기술중 하나인 시대이다. DevOps를 한마디로 표현하자면 아래와 같은 벤다이어그램으로 설명 가능하다.(출처:위키피디아) 개발을 함 뿐만아니라 품질관리, 운영까지 모두 담당하는 것이다. 이 모든것이 가능하게 된 것은 자동화된 솔루션들의 발전때문일 것이다.(특히 오픈소스 솔루션) 그 중 DevOps 밴다이어그램의 한 부분을 차지하는 Operation(운영)에 필수적으로 필요한모니터링 오픈소스 솔루션에 대해서 이야기 하고자 한다. 모니터링의 가장 기본 옵션인 System metrics(CPU, memory, disk 등)을 모니터링하는 솔루션을 구축하는 방법을 찾아보면 아래와 같은 옵션이 있다. 장점 단점 직접 개발 커스터마이징 극대화 가능 개발하는데 시간이 오래 걸림 유료..