Mason

배포 자동화 파이프라인 배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다. 파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리한다. 각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)들을 수행한다. 파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계가 존재한다. Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생..

AWS Parameter Store의 환경변수 EC2에서 연결하기 위한 포스트이다. 1. Parameter Store에 환경변수를 생성해준다. 2-1. AWS IAM의 Role 사용 위와 같이 AmazonSSmFullAccess와 AmazonSSmReadOnlyAccess 권한들을 설정 한뒤 Role 생성 이후 EC2로 넘어와 해당 인스턴스를 우클릭 한뒤 Security -> Modify IAM role 에서 생성된 role 적용 이후 3번으로 이동 2-2. AWS IAM의 User 사용 1) IAM User 생성 Add users를 클릭한 뒤 User name을 설정해주고 Next를 클릭 이후 밑의 스크린샷과 같이 접근 권한을 추가하여 유저를 생성한다. 이제 생성된 유저의 Access key를 생성해주..

Oauth2 진행 흐름 문제를 파악하기에 앞서 Oauth2의 진행 흐름에 대해 알아보았습니다. 그림에서의 Resource Owner 사용자를 의미하며 Client는 백엔드 서버를, Authorization Server와 Resource Server는 구글과 같은 3rd-party를 의미합니다. 진행 흐름은 다음과 같습니다. 사용자는 백엔드 서버로 소셜로그인을 요청합니다. 요청받은 백엔드 서버는 3rd-party에서 부여해준 Client ID와 함께 사용자의 인증과정을 해당 3rd-party의 Authorization 서버에 요청합니다. 사용자는 3rd-party에서 인증과정을 진행하고 백엔드 서버는 Authorization 서버에서 받은 엑세스 토큰을 이용하여 3rd-party의 Resource 서버에서..

문제 발생 프로젝트 진행 중 프론트엔드 분들을 위한 Mock-up data API를 만들어 EC2를 활용해 배포하여 제공하게 되었는데 이때 Cors 문제가 발생하게 되었다. 스프링 시큐리티를 사용하지 않으므로 간단하게 컨트롤러에 @CrossOrigin 에너테이션으로 해결할 수 있을줄 알았지만 계속해서 http status 415 에러가 난다는 보고를 받았다. 문제 해결 이를 해결하기 위해 Cors filter를 직접 작성해 주기로 했다. package com.stub_data_server.cors; import org.springframework.core.Ordered; import org.springframework.core.annotation.Order; import org.springframewor..

프로젝트 목표 StackOverFlow사이트의 클론코딩 프로젝트 기간 2주 개발 인원 6명(프론트 3명, 백엔드 3명) D+1 팀원간의 개인 역량 체크 짧은 시간인 2주간 주니어 개발자 6명에서 해당 웹사이트의 어떤 기능까지 구현을 할것인가, 그 범위에 대해 논의하게 되었다. 주어진 시간은 2주이지만 그안에 프로젝트의 방향을 논의하고 역할을 분배, 어플리케이션의 기능을 코드로 구현, 테스트 실시, 배포까지 하기 위해선 StackOverFlow의 기능을 최소화하여 꼭 필요한 기능들인 회원과 질문, 답변, 댓글에 관한 기본적인 CRUD 서비스와 소셜 로그인 기능까지만 일단 구현한 후 시간이 남으면 팀원 모두 협의 후 새로운 기능을 추가하기로 결정하게 되었고 이를 바탕으로 사용자 요구사항 정의서를 작성하였다...

아무생각 없이 테스트 코드를 작성하던 도중 Multipart form data 타입의 요청을 테스트 할 차례가 다가 왔다. 일단 Multipart form data 타입의 요청을 테스트하고 해당 테스트를 기반으로 RestDocs를 이용하여 API문서를 만들기 위해서는 두가지 기능을 구현할 방법을 알아야 했다. MockMvc에서 Multipart form data 타입의 요청을 보내는 방법 해당 요청을 테스트한 뒤 RestDocs를 이용하여 API 문서로 만드는 방법 해당 기능을 수행하기에 앞서 request body의 형식이다. "requestBody"라는 key로 json형식의 데이터와 "photoImgs"의 key로 이미지파일이 들어가야 한다. 1. MockMvc에서 Multipart form dat..

드디어 게시판 프로젝트의 마지막 단계만 남았다! 마지막으로 Mock test를 진행하면서 Rest docs를 이용해 API문서를 만드는 도중에 발생한 문제이다. 문제발생 앞서 post 요청에 대한 테스트 코드를 작성한 뒤 통과하고 patch 요청에 대한 코드를 작성한 이후 테스트가 실패하게되었다. 먼저 작성한 테스트 코드이다. @WebMvcTest(value = MemberController.class) @MockBean(JpaMetamodelMappingContext.class) @AutoConfigureRestDocs public class MemberControllerRestDocsTest implements MemberControllerTestHelper { ... ... @Test @WithMo..

이번 포스트는 개인 프로젝트인 게시판 만들기에서 AWS S3와 연동 도중 발생한 작은 문제들에 관한 포스트이다. 1. API platform API 개발중 API platform으로 주로 Insomnia를 사용했었다. 작성한 컨트롤러에서는 @RequestPart 에너테이션을 이용하여 json 타입과 form data 형식의 데이터들을 각각 받아주게 해주었는데 문제는 요청으로 보낼 각각의 데이터들에 어떤 타입의 데이터들인지 명시해주어 보내야 하는데 Insomnia에는 데이터 타입을 각각 지정해주는 기능이 없었다... StackOverFlow에서 조차도 Postman으로 갈아타라는 답변밖에 얻을수 없었고, 결국 반강제적으로 사용이 익숙한 Insomnia를 버리고 Postman으로 갈아타버리게 되었다. 2. ..