PPAK

Spring MVC 패턴에서 핸들러 어댑터에 의해 호출되는 Controller 는 클라이언트의 요청에 따른 서버 로직을 수행해야 한다. 대표적으로 수행해야하는 로직으로는 아래 3가지가 존재한다. 1. 요청 값의 유효성 판별 2. 비즈니스(서비스) 로직 수행 3. 결괏값 보존(영속화) 위와 같이 명확하게 역할이 분리된 상황에서 Controller 가 모든 역할을 부담하는 것은 유지 보수 측면에서나, 역할과 책임 그리고 관심사의 분리를 중요시하는 객체지향적 관점에서나 적절하지 않는 전략일 것이다. 따라서 Spring Boot 에서는 Controller(Presentation) - Service(Business) - Repository(Data Access 혹은 Persistence) 의 3 가지 레이어를 두..

이전 포스트 에서 Jenkins 에서 SpringBoot 이미지를 생성하고, 컨테이너를 생성하는 과정을 생략했다. 이번 포스트에서는 직접 Dockerfile 을 작성하고, 이미지 빌드를 하는 과정을 살펴보겠다. Dockerfile #SpringBoot 구동에 필요한 jdk11 FROM openjdk:11 #변수 생성(상대 경로로 작성) ARG JAR_FILE=build/libs/*.jar #(추가할 파일 : 이름) -> Docker 컨테이너 내부에 생성된다. COPY ${JAR_FILE} app.jar #(image 의 container 에서 필요한 저장소 경로) VOLUME /tmp #(도커 컨테이너 내부에서 몇번 포트로 돌 것인가) EXPOSE 8081 #(실행할 명령어, 컨테이너 내부에 생성될 경로..

이전 포스트 에서는 Docker 위에서 Jenkins 개발환경을 셋팅하였다. 본 포스트에서는 실제로 Jenkins project 를 생성하여 빌드 스크립트를 구축하고 Git Webhook 을 이용해 개발자가 빌드 버튼을 매번 누르는 것이 아닌 Github 의 develop 브렌치에 push 되었을 때 빌드가 되도록 자동화를 할 생각이다 프로젝트에서 백엔드의 개략적인 시스템 아키텍쳐가 나왔다. 초기 AWS 를 사용할 예정이였으나 최근 GCP 에서 제공하는 쿠버네티스 엔진을 이리저리 만져보다가 프로젝트 2차 챌린지로 쿠버네티스 환경 구축을 하면 좋을 것 같아서 사전에 플랫폼에 좀 친숙해지기 위해서 GCP 로 배포하기로 마음먹었다. 실제로 이전 포스팅 의 환경 또한 현재 GCP VM 에 구축한 상황이다. 시스..

의미있는 단위로 브랜치를 생성, 관리하고, 가독성이 좋은 형태의 브랜치의 구조를 만들기 위해서 브랜치 관리 전략 중 Git-flow 에 대해서 알아보고, 프로젝트에 적용할 수 있는 방식을 고민해보았다. Git-flow 에서 제시하는 branch 생성 방식은 아래와 같다. master : 실제 배포 버전이 있는 브랜치, 실 서비스에 사용되는 제품을 의미한다. hotfix : 배포 버전에서 발생하는 버그 중 긴급하게 수정이 이루어지는 브랜치 develop : 버전 업그레이드를 위해 기능 추가, 수정 사항이 반영되는 등의 개발이 이루어지는 브랜치 feature : 개발 단계 별 추가, 수정되는 기능 개발이 이루어지는 브랜치 release : 다음 배포 버전에 포함될 기능 개발이 끝난 후 QA 가 이루어지는 브..

이번 팀 프로젝트를 준비하면서 CI/CD 환경 구축을 해봐야겠다고 마음을 먹었다. 우선은 Jenkins 이미지를 생성하고 컨테이너를 생성하는 과정에서 중요한 부분을 정리하고자 본 글을 작성한다. 들어가기에 앞서서, 쓰게될 글을 간단하게 요약을 하면 Local Machine (실제 배포과정에선 EC2 인스턴스?) 의 Docker 를 통해 Jenkins Image 를 생성하고 실행하는 것이 전부인데 그 과정에서 1. Jenkins Image 생성을 위한 Dockerfile 작성 2. DooD (Docker out of Docker) 방식 적용 3. 가상 tty 로 Container 에 접근해 파일 수정 을 수행할 예정이다. Jenkins Image 생성을 위한 Dockerfile, Shell Script 작..