개발 일기

https://adjh54.tistory.com/77 [Java/Library] Spring Boot Validation 이해하기 : 데이터 유효성 검증해당 글에서는 Spring Validation 라이브러리를 이용하여 클라이언트에서 전송된 '데이터'를 유효성 검증을 처리하는 방법에 대해서 공유합니다. 1) 개발 환경 💡 Spring Validation 구성을 위한 사용된adjh54.tistory.com https://adjh54.tistory.com/77 [Java/Library] Spring Boot Validation 이해하기 : 데이터 유효성 검증해당 글에서는 Spring Validation 라이브러리를 이용하여 클라이언트에서 전송된 '데이터'를 유효성 검증을 처리하는 방법에 대해서 공유합니다...

이전 게시글에서 로그 레벨까지 알아봤고 이제 실제 EC2에서 돌아가고 있는 스프링 컨테이너는 로깅이 어려웠기 때문에 로깅을 할 수 있도록 로깅 프레임워크를 적용 후에 컨테이너를 갈아 끼울 예정이다.Logback에 대해Logback을 사용할때 application.yml을 통해서 설정이 가능하지만 디테일한 설정을 하는데에는 한계가 있다. 그래서 logback-spring.xml을 통해 조금 더세부적인 설정이 가능하다. logback-spring.xml / logback-spring.groovy / logback.xml / logback.groovy의 이름을 한 파일을 스캔하고 이를 바탕으로 로그 설정이 적용된다. 이때 logback-spring.xml이 Spring Boot에 특화된 설정 파일이였다. Ap..

이전 게시글에서 로깅 프레임워크를 쭉 훑어봤고 그래서 어느 수준으로 로깅 레벨을 설정할지 각 레벨을 정리해보고자 한다. 로깅 레벨(Logging Level)TRACE  TRACE: DEBUG보다 상세한 로그로 애플리케이션의 실행 흐름과 디버깅 정보를 상세히 기록해주며 디버깅 시에 사용된다.예로 메서드의 진입과 종료, 변수의 값 변경 등 모든 세부 사항이 기록된다.DEBUG: 이름과 같이 개발단계에서 디버깅을 위해 사용되며 Log.d()로 많이 사용됐을 것이다. "배포 환경에서 보통 사용될 필요가 없다."INFO:  일반적인 정보 로그 수준으로, 시스템의 정상적인 동작을 기록하는데 운영 환경에서 시스템의 상태와 주요 이벤트를 기록하는 데 사용된다. 예로 애플리케이션이 시작되거나 종료될 때, 중요한 설정이 ..

정리하게된 계기이번에 nginx-react(front)-spring(back)을 도커를 통해 각각을 EC2에서 컨테이너로 작동시키고자했다. 그러나 프론트의 랜더링에 대한 이해가 부족했던 탓인지 Nginx의 이해도가 부족했던 탓인지 하면서 계속 80포트로 받아서 백엔드의 요청은 잘 받았지만 프론트로는 요청을 제대로 보내주지 못했다. 사실 이러한 단순한 문제로 2일을 잡아먹었다.그래서 어제 최근 학교에 선배 특강을 오셨던 쿠팡 백엔드 개발자 선배님께 따로 연락을 드렸고 도움을 받았다.선배님의 답변을 통해 다시 시도했고3개의 컨테이너가 각각 하나의 어플리케이션을 가지고 컴포즈를 통해 잘 동작하고 OAuth2.0 또한 아주 잘 작동했다 ㅎ그러나 이때 질문을 하던 과정에서 선배님께서 하나의 미션? 질문?을 던져주..

적용하게된 계기힘겹게 Nginx와 스프링 프로젝트를 git actions로 배포를 하여 실행을 시켜놓고나니까 그제서야 든 생각이 있었다. 그래서 로그는 어떻게 확인할건데? 내가 매번 docker logs를 찍어서 봐야하나..? 근데 이 로그 양이 많아지면 어떻게 될까? 라는 생각이 문득  들었다. Express로 서비스를 했을때는 nohup이라는 모듈을 통해 파일로 저장했던 기억이 있어서 찾아봤더니 역시 Spring Boot에서도 이런 것을 담당해주는 라이브러리가 존재해서 우선 자바 진영 로깅 프레임워크를 쭉 훑어보겠다.로깅(Logging)print(), System.out.println(), console.log() 등으로 개발하는 중간 중간에 로그를 열심히 찍어서 내가 의도한대로 동작하고 있는지 확인..

공부하게된 계기Docker를 사용하다보니 컨테이너 런타임(Container Runtime)이라는 단어를 종종 듣게 됐다. 도커 관련 개발 블로그를 봐면 종종 컨테이너 런타임이라는 용어를 당연하다는 듯이 쓰는 것을 봤다. 처음에 그냥 뭐 컨테이너가 돌아가고 있는 것이나 컨테이너가 돌아가기 위한 소프트웨어? 환경? 이런 것이라고 대강 이해하고 넘어 갔었는데 Kubernetes에 관한 영상을 봤는데도 쓰는데 뭔가 자세히 한번 짚고 넘어가야겠다는 생각이 들어 정리해보게 됐다.도커 아키텍처(Docker Architecture)전에도 한번 다뤘지만 다른 그림으로 도커의 아키텍처를 다시 보자.도커 클라이언트-서버 아키텍처우선은 이게 전에 봤던 것과 유사하다. 기본적으로 도커는 클라이언트-서버 구조로 동작하는데 우선..

쿠버네티스에 대해 공부하기 시작하면서 현업자의 인터뷰를 보면서 대강 뭐하는 애인지 정도 편하게 봤다. 이것을 발판 삼아 앞으로 잘 배워봐야겠다. 직접 써봤듯이 Git Actions와 같은 도구를 통해 CI/CD 배포를 자동화할 수 있었다. 그런데 이때 자동으로 배포한 것에서 감시까지 자동화 했을 때 에러가 난다면 조치는 누가할까? "사람"이 한다. 즉, 자동화는 품질이 사람에 의해 좌지우지가 되는 것이다.이때 배포, 감지에서 더 나아가 조치까지 자동화하겠다는 것이 "오케스트레이션"이란 개념이다.장애가 났어? 그럼 내가 살려줄게, 과부화 났어? 그럼 내가 알아서 Scale Out 해줄게 이러한 것이 추가된 것이다. 소프트웨어를 이미지로 만든 것이 ISO이다. 예를들어 Window OS를 설치하기 위해서는 ..

도입한 계기기존에 나는 Spring Boot로 구현한 백엔드 서버를 배포하는 과정은 처음에는 수작업으로 Dockerfile을 작성하고, 빌드한 이미지를 Docker Hub에 업로드한 후 EC2 서버에서 이를 pull하는 방식으로 진행했다. Nginx 역시 config 파일과 Dockerfile을 작성하고 빌드하여 동일한 방식으로 Docker Hub에 푸시하고 EC2에서 pull해오는 과정을 거쳤다. 이러한 과정을 하나하나 수동으로 처리하다 보니, 소스 코드에 수정이 있을 때마다 수정된 버전을 재배포하기 위해 반복적으로 이미지를 삭제하고, 컨테이너를 지우는 작업을 수행해야만 했다. 이렇게 적으면서만 봐도 너무 번거럽고 귀찮은 작업이다.이러한 반복적인 배포 과정을 자동화하기 위해 Jenkins나 GitHub..