운영하고 있는 홈랩 구조 상 최대한 외부 리소스를 사용하지 않고 운영하고 있다. 그래서 단순히 도메인을 연결하는 것부터 꽤 번거롭지만 학습에 무게를 둔다면 이 방식이 훨씬 좋기에 도메인이 추가될 때 어떤 식으로 하고 있는 메모를 할 예정이다. 구조 현재 구성된 홈랩 구조는 위 사진과 같다. 공유기를 통해 사용하고 있어서 DDNS는 DuckDNS를 가지고 있는 도메인을 통해 CNAME으로 추가했다. 각 도메인은 서브 도메인으로 서비스를 분류하고 있다 예를 들어서 젠킨스는 jenkins.xxx.xxxx.xx이고 깃랩은 gitlab.xxx.xxxx.xx 이런 식으로 설정해 둔다. 서비스 도메인으로 분류하는 이유는 각 서비스마다 IP로 설정하는 경우 공유기 내부에 Port forward 테이블이 너무 복잡해지고..

라고 굉장히 도발적인 제목을 작성해봤다. 사실 몰라도 사용해도 괜찮다. 내가 뭐라고 이러쿵저렁쿵하겠나. 하지만 대부분의 블로그가 획일화된 방법을 제안해 나는 조금 다른 방법을 제안해보고자 한다. JWT 인가 구현 처음은 인가에 대해서 생각해보자. 다른 글처럼 JWT를 설명하는 것은 너무 지루하고 재미없기에 이 글을 읽자. 내가 본 글 중 JWT에 대해서 가장 간단하고 명확하게 정리해서 초보자도 바로 이해할 수 있을 정도로 잘 정리해두었다. 인가 구현에 있어서 가장 첫 번째는 Filter를 추가하는 것이다. Filter는 우리가 Http 요청 시, 해당 요청에 대한 인가 및 인증 처리를 해주고 만약 권한 이상의 요청 시 걸러주는 역할을 하게 된다. // 아래에서 필요한 클래스는 알아보고 마지막에 완성된 코..

Jenkins(이하 젠킨스)를 이용해 CI/CD를 구성하다 보면, 프로젝트 빌드를 위해 호스트에 직접 필요한 도구를 설치하는 경우가 있었다. 하지만 프로젝트가 많아지고, 각기 사용하는 언어 및 빌드 환경이 달라지게 되면 호스트 OS에 무분별하게 도구를 설치하는 상황이 생길 수 있고, 만약 조직 단위로 움직이는 회사인 경우 언어 선택 및 빌드 환경 수정 시 DevOps에게 불필요한 작업 리소스를 줄 수 있다. 젠킨스는 이런 문제를 인식하고 파이프라인에 도커를 사용하도록 지원한다. 플러그인 설치 젠킨스 파이프라인에서 도커를 사용하기 전 필요한 플러그인을 설치한다. Docker plugin Docker pipeline 그리고 호스트 OS에 도커를 사용할 수 있는 환경이 필요하다. 예시 pipeline { ag..

Raw 타입은 사용하지 말라 이번 장에서는 제네릭과 함께 과거 호환성을 위한 남겨진 Raw 타입의 위험성을 설명한다. Raw 타입은 제네릭을 선언하면 함께 정의되는 타입으로, 예를 들어 `List`를 선언하면, `List`로 함께 선언된다. 형태로 알 수 있듯 List는 타입 매개변수(List에서 E)가 포함되지 않은 타입이다. 따라서 Raw 타입을 사용하게 되면 다음과 같은 코드가 컴파일될 수 있다. private final Collection stamps = ...; stamps.add(new Coin(...)); 즉, 제네릭을 통한 타입 일반화를 컴파일 타임이 아닌, 런타임 에러로 받게된다. 이런 사용법은 제네릭의 필요성에도 위반된다. 제네릭은 일반화된 타입을 컴

클래스와 멤버의 접근 권한을 최소화하라 객체지향언어 및 최근에 나온 언어를 접하게 되면 반드시 접하게 되는 개념이 있다. 바로 '가시성'에 대한 개념인데, 흔히 private, protected, public 등과 같은 키워드와 함께 설명된다. 저자는 컴포넌트의 설계 수준에 대한 기준점 중 하나로 객체가 얼마나 외부와 잘 격리되었는지, 즉 캡슐화를 다음과 같은 이유로 제안한다. 여러 컴포넌트는 병렬로 개발할 수 있다. 관리 비용을 낮춘다. 성능 최적화가 쉽다. 재사용성이 높아진다. 개별 컴포넌트에 대한 동작을 검증할 수 있다. 이는 비단 메서드에 국한되지 않는다. 클래스 필드 또한 가시성에 유의해야 한다. 만약 필드가 public으로 외부에서 직접 접근한 경우 해당 필드에 대한 변경 및 제어에 대한 제한..

백수가 주말에 장애대응을 할 수 있다? 여느 날과 같이 구직에 쫓기며 폭풍 개발을 하던 와중에 홈랩 서버가 갑자기 이륙을 하기 시작했다. 무슨 상황인지 싶어 모니터링 도구를 보니 메모리가 매우 화나있었다. 일단 평소 1Gb RAM으로 충분히 동작하고 있어서, 단순히 "팀원이 빌드 실행하셨나 보다.." 정도로 생각하고 신경을 안 쓰다가 시간이 지나도 계속된 엔진 소음으로 문제를 확인하니 이상한 점이 있었다. 첫 번째로 갑자기 높아진 메모리 사용량이다. 처음엔 단순히 빌드 작업 중이시구나 생각했지만, 빌드를 하는거면 메모리보단 CPU가 더 높아야 하는데 CPU는 굉장히 잔잔했다. 왼쪽이 문제 상황에서 CPU 상황이고, 오른쪽은 문제를 해결한 후 테스트로 빌드를 실행할 때 CPU 상황이다. 메모리 사용량이 갑..