분류 전체보기 1292

로그 프레임워크 #3 - JSON 로그에 필드 추가하기

로그 시스템 #3 - JSON 로그에 필드 추가하기 조대협 (http://bcho.tistory.com)JSON 로그에 필드 추가앞에 예제에서 로그를 Json 포맷으로 출력하였다. 그런데, 실제로 출력된 로그 메세지는 log.info(“문자열") 로 출력한 문자열 하나만 json log의 message 필드로 출력된것을 확인 할 수 있다. 그렇지만, 단순한 디버깅 용도의 로그가 아니라 데이터를 수집하는 용도등의 로깅의 message라는 하나의 필드만으로는 부족하다. 여러개의 필드를 추가하고자 할때는 어떻게 할까? Json Object를 log.info(jsonObject) 식으로 데이터 객체를 넘기면 좋겠지만 불행하게도 slf4j에서 logging에 남길 수 있는 인자는 String 타입만을 지원하고, ..

로그 프레임워크 #2 - 기본 로깅 및 JSON 포맷으로 로깅하기

로그 시스템 #2- 자바 로그 & JSON 로그 포맷조대협 (http://bcho.tistory.com) 앞 글에서 간단하게 자바 로깅 프레임워크에 대해서 알아보았다. 그러면 앞에서 추천한 slf4j와 log4j2로 실제 로깅을 구현해보자SLF4J + log4j2메이븐 프로젝트를 열고 dependencies 부분에 아래 의존성을 추가한다. 버전은 최신 버전을 확인하도록 한다. artifactid가 log4j-slf4j-impl 이지만, log4j가 아니라 log4j2가 사용된다. org.apache.logging.log4jlog4j-slf4j-impl2.11.2 다음 log4j2의 설정 정보 파일인 log4j2.properties 파일을 src/main/resources 디렉토리 아래에 다음과 같이 생성..

로그 프레임워크 #1 - 자바 로그 프레임웍 종류

로그 시스템 #1 - 자바 로그 프레임웍 조대협 (http://bcho.tistory.com)로그 시스템 로그 시스템은 소프트웨어의 이벤트를 기록 함으로써, 소프트웨어 동작 상태를 파악하고 문제가 발생했을때 이 동작 파악을 통해서 소프트웨어의 문제를 찾아내고 해결하기 위해서 디자인 되었다. 주로 로그 파일이라는 형태로 하나의 파일에 이벤트들을 기록하였다. 그러나 소프트웨어 스택이 OS, 미들웨어, 사용자 애플리케이션 (자바나 파이썬등으로 구현된 애플리케이션)으로 점점 다중화되고 시스템이 대형화 되면서 한대가 아니라 여러대의 서버에 로그를 기록하고 또한 마이크로 서비스 아키텍처로 인하여 서버 컴포넌트가 분산됨에 따라서 로그를 수집해야할 포인트가 많아지게 되었다. 이로 인해서 로그 시스템이 분산 환경을 지원..

개발자 코딩 노트북 구입기 (DELL Inspiron 7580) 우분투

개발자용 노트북 구입기조대협 (http://bcho.tistory.com) 집에서 개발 공부와, 테스트를 위해서 개인 노트북이 필요했는데, 아무래도 업무와 개인 공부를 분리하는것이 좋을것 같아서, 얼마전 부터 개인 노트북을 사용하기 시작했다. 여러가지 고민을 하다가, 딸에게 주었던 한성 U35S를 돌려받고, 딸에게는 ASUS 라이젠 노트북을 사주었다. I7에 16G 메모리, 128G SSD로 나쁘지 않은 스펙이었지만, 대략 7년정도 된 노트북이라 우분투를 깔고 사용은 했지만, 일반적인 문서 작업이나 코딩들도 가능했지만, 아무래도 서버를 여러개 올리거나 컴파일을 많이 거니, 팬 소리가 너무 귀에 거슬리기 시작했고, 이참에 노트북을 하나 바꿔야 하겠다하고 개발용 노트북을 찾기 시작했다. 아무래도 개발용으로 ..

사는 이야기 2019.03.10

[팁] 쿠버네티스 StatefulSet에서 Headless 서비스를 이용한 Pod discovery

[팁] 쿠버네티스 StatefulSet에서 Headless 서비스를 이용한 Pod discovery 조대협 (http://bcho.tistory.com) statefulset에서 데이타베이스와 같이 master,slave 구조가 있는 서비스들의 경우에는 service를 통해서 로드밸런싱을 하지 않고, service 를 통해서 로드 밸런싱을 하는 것을 잘 사용하지 않고 개별 pod의 주소를 알고 접속해야 한다. 그래서 개별 Pod의 dns 이름이나 주소를 알아야 한다. Pod들은 DNS이름을 가질 수 는 있으나, {pod name}.{service name}.{name space}.svc.cluster.local 식으로 이름을 가지기 때문에, pod 를 DNS를 이용해서 접근하려면 service name이..

도커 컨테이너 보안 취약점 스캔 도구 Anchore

도커 컨테이너 보안 취약점 스캔 도구 Anchore조대협 (http://bcho.tistory.com) 근래에 쿠버네티스를 로컬환경에서 이것저것 테스트하다보니, 클라우드에 있는 기능 보다 오픈 소스 기능을 많이 보게 되는데, 빌드 파이프라인을 보다가 재미있는 오픈소스를 하나 찾아서 정리해놓는다. 컨테이너 이미지에 대한 보안 문제쿠버네티스와 같은 컨테이너 오케스트레이션 솔루션에서 가장 보안 취약이 있는 곳 중의 하나는 컨테이너 이미지 인데, 도커허브와 같이 널리 알려진 컨테이너 리파지토리에 저장되서 배포되는 이미지도 보안적으로 문제가 있는 이미지가 많다. 그래서, 가급적이면 벤더들에서 보안적으로 문제가 없도록 관리하는 베이스 이미지를 사용하는 것이 좋다. (구글에서 제공하는 도커 컨테이너 베이스 이미지 h..

[팁] minikube에서 Loadbalancer type 서비스 테스트 하기

minikube에서 서비스 테스트 하기미니쿠베를 로컬환경에 설치하고 쿠버네티스 서비스를 로드 밸런서 타입으로 배포하면, External IP할당이 되지 않는다. 그래서 아래 그림과 같이 External-IP가 계속 으로 보이게 된다. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 443/TCP 7d2hmy-service LoadBalancer 10.105.173.146 8080:31203/TCP 4m10s 그러면 미니쿠베에서 서비스를 테스트하려면 어떻게 해야 할까? 미니쿠베는 서비스를 테스트하기 위해서 service라는 명령을 제공한다. 아래 그림과 같이 minikube service {쿠버네티스 서비스명} 을 입력하..

[팁] 우분투에서 minikube를 VM 없이 실행하기

요즘 쿠버네티스를 로컬환경에서 이것 저것 테스트하고 있는데, 실행 방법은 다음과 같다. 환경은 minikube를 인스톨하였다. (0.33.1 버전) sudo -E minikube start --vm-driver=none --extra-config=kubelet.resolv-conf=/run/systemd/resolve/resolv.conf 쿠버네티스를 우분투에서 실행할때, 별도의 Virtual Machine 없이 실행이 가능하다. VM 없이 실행하려면 --vm-driver=none 옵션을 줘야 한다. 이때, Local DNS Pod 가 기동될때 문제가 생기는데, 이를 해결하기 위해서 --extra-config=kubelet.resolv-conf=/run/systemd/resolve/resolv.conf ..

쿠버네티스 #22 - StatefulSet을 이용한 상태유지 Pod (데이타베이스) 관리하기 1/2

StatefulSet을 이용하여 상태가 유지되는 Pod 관리하기조대협 (http://bcho.tistory.com)ReplicaSet으로 Stateful Pod 관리하기 앞에서 쿠버네티스의 Pod를 관리하기 위한 여러가지 컨트롤러 (Replica Set, ReplicationController,Job 등)에 대해서 알아보았다.이런 컨트롤러들은 상태가 유지되지 않는 애플리케이션(Stateless application)을 관리하기 위해 사용된다. Pod가 수시로 리스타트되어도 되고, Pod 내의 디스크 내용이 리스타트되어 유실되는 경우라도 문제가 없는 워크로드 형태이다. 웹서버나 웹애플리케이션 서버 (WAS)등이 그에 해당한다. 그러나 RDBMS나 NoSQL과 같은 분산 데이타 베이스등과 같이 디스크에 데이..

쿠버네티스 - PodDisruptionBudget

PodDisruptionBudget조대협 (http://bcho.tistory.com) Pod의 개수는 컨트롤러가 붙어 있을 경우에는 컨트롤러 스펙에 정의된 replica 수 만큼을 항상 유지 하도록 되어 있다. Pod의 수가 replica의 수를 유지 하지 못하고 줄어드는 경우가 있는데, 애플리케이션이 크래쉬 나거나, VM이 다운되는 등의 예상하지 못한 사고로 인한 경우가 있고, 또는 시스템 관리자가 업그레이드등의 이슈로 노드를 인위적으로 다운 시키는 것과 같이 예상 가능한 상황이 있다. 예상 가능한 상황에서 Pod가 없어지는 것을 Voluntary disruptions 라고 하고, 커널 패닉이나 VM 크래쉬같은 예기치 못한 상황에서 Pod가 없어지는 것을 Involuntary disruptions 라..