들어가며
응급실 다녀오느라 과제 제출을 제 시간에 못했다. 내 몸뚱아리는 왜 이렇게 나약한지,,
급하게 과제 마무리를 하고 있는데 다행히 과제 제출 기한이 많이 미뤄졌다! 미처 추가하지 못한 부분들을 깔끔하게 추가할 시간이 생겼다. 코드 리팩토링이랑 살짝 내려놓았던 부분들을 다시 매꿔서 제출해야겠다고 다짐하며
오늘의 TIL은 오늘 적용한 여러가지 기능들을 정리해보고자 한다.
application.yml에 있는 민감 정보 .gitignore에 포함시키기
application.yml은 설정파일로 DB의 URL, username, password가 그대로 노출되어있고, S3의 key 역시도 노출되어있다.
이 정보들이 github에 그대로 올라간다면, 해커한테 내 DB랑 S3 해킹해주세요~ 하는 꼴이므로... 이런 민감한 정보들을 .gitIgnore에 추가해보자!
적용할 방식은 application.yml에 있는 민감 정보들을 별도의 yml 파일로 분리해준 다음 해당 파일을 .gitIgnore에 추가해주는 방식이다.
우선 정보를 분리하기 위해 resource폴더에 application-aws.yml 파일을 생성해준다.
타입은 Resource Bundle로 지정해주고 파일 형식을 지정해주지 않으면 .properties로 생성되므로 .yml로 만들고자한다면 파일명에 .yml을 붙여주거나, 생성 후에 바꿔주자.
또, 파일명은 application-[원하는이름] 으로 지정해주어야 나중에 설정에서 해당 파일을 인식할 수 있다.
나는 파일을 생성하고 .gitignore에 등록까지 마친 후에야 application-aws.yml에 DB관련 설정도 들어간다는걸 깨달았고, 다시 바꾸기는 번거로우므로 aws를 붙여주었다.
이제 새롭게 생성한 application-aws.yml에 노출시키고 싶지 않은 설정 정보들을 넣어준다.
하지만 이렇게만 하면 spring이 application-aws.yml을 인식하지 못한다.
따라서 기존 application.yml에 추가된 yml을 인식할 수 있도록 해당 설정을 넣어준다.
spring:
profiles:
include: aws
include에는 application-{이름}.yml 에서 {이름}부분을 넣어주면 된다.
그럼 이제 해당 파일을 .gitIgnore에 등록하는 일만 남았다.
나는 source tree를 사용하고 있어서 간단하게 '파일무시'버튼을 클릭하면 자동으로 gitignore에 추가해주지만, 여러가지 방법이 있으므로 난 직접 .gitignore파일에 해당 파일명을 작성해주는 방법만 소개해본다.
.gitignore에 파일 등록하기
.gitignore는 프로젝트 폴더에 저장되어있다. 따라서 본인이 사용하고 있는 IDE에서도 수정이 가능하고, 직접 파일을 찾아가서 수정도 가능하다.
IDE에서 .gitignore를 찾는건 어렵지 않지만, 폴더에서 찾으려면 '숨김폴더'를 보이게 만들어서 변경해주어야한다!
Mac기준 숨김폴더를 보이게 하는 단축키는 shift
+ cmd
+ .
이고, 만약 .gitignore 파일이 없다면 프로젝트 최상위 폴더(.git이 있는 폴더)에 직접 만들어줘도 된다. 아마 대부분은 자동으로 생성되어있을 것이다.
.gitignore파일을 찾았다면 우리가 추가하고자 하는 application-aws.yml을 적어주고 저장해주자.
그리고나서 .gitignore를 커밋 푸쉬해주면 끝!
AWS S3 적용하기
기존에 클라이언트에서 받아온 파일을 DB에 저장하기 위해서 로컬에 이미지를 저장하는 방식을 사용하고 있었다. 이 방식도 틀린 방식은 아니지만 서버(로컬)에 이미지를 저장하므로 사용자가 많아지게 되면 서버의 용량을 많이 잡아먹게 되는 문제가 있다.
따라서 이번 기회에 가장 많이 사용되고 있는 AWS S3를 적용해보고자한다!
AWS S3의 적용은 대부분 해당 게시글들을 참고하였으므로 자세한 방법은 다음 게시글에서 확인하고, 이 포스팅에서는 어떤 방식으로 적용했는 지만 작성하도록 하겠다.
[SpringBoot] SpringBoot를 이용한 AWS S3에 여러 파일 업로드 및 삭제 구현하기
S3UploadManager.java
@Component
@Slf4j
@RequiredArgsConstructor
public class S3UploadManager {
@Value("${cloud.aws.s3.bucket}")
public String bucket;
private final AmazonS3 amazonS3;
public String uploadFile(MultipartFile file) {
// 파일은 단건만 추가 가능
String fileName = createFileName(file.getOriginalFilename());
ObjectMetadata objectMetadata = new ObjectMetadata();
objectMetadata.setContentLength(file.getSize());
objectMetadata.setContentType(file.getContentType());
try (InputStream inputStream = file.getInputStream()) {
amazonS3.putObject(new PutObjectRequest(bucket, fileName, inputStream, objectMetadata)
.withCannedAcl(CannedAccessControlList.PublicRead));
} catch (IOException e) {
throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR, "파일 업로드에 실패했습니다.");
}
return fileName;
}
public void deleteFile(String fileName) {
amazonS3.deleteObject(new DeleteObjectRequest(bucket, fileName));
}
private String createFileName(String fileName) {
// 파일 업로드 시, 파일명 난수화 -> 다양한 언어 처리가 가능해짐
return UUID.randomUUID().toString().concat(getFileExtension(fileName));
}
private String getFileExtension(String fileName) {
try {
return fileName.substring(fileName.lastIndexOf("."));
} catch (StringIndexOutOfBoundsException e) {
// 파일을 자르지 못할 때 생기는 에러
// 파일이 null로 들어왔을 때 주로 발생한다.
throw new RestApiException(CustomErrorCode.NULL_FILE);
}
}
}
전체적인 코드는 첫번째 게시글과 크게 다르지 않지만 필요한 부분을 약간 수정하였다.
먼저 uploadFile 메서드가 기존에 여러 개의 파일을 받아와서 저장하는 형태를 기획에 따라 단건으로만 받도록 설정하였다. 이 부분은 굳이 바꾸지는 않아도 됐었다는 걸 지금 포스팅 하면서 깨달아서 다시 코드를 살펴보기로 했다.
또다른 변경 사항은 getFileExtension 메서드에서 예외 처리를 직접 하도록 한 부분을 구현해둔 handler가 처리할 수 있도록 변경해주었다.
이제 게시물을 CUD 할 때 이미지를 S3에 저장할 수 있도록 S3UploadManager 를 의존성 주입 후 원하는 대로 사용하면 된다.
마치며
오늘 되게 많이 잤다고 생각했는데 또 잠이 쏟아진다. 이럴거면 고양이로 태어났어야 했는데... 옆에 있는 빵이가 한없이 부러우지는 순간이다.
TIL을 거르지 않고 쓴 것에 대해 스스로를 칭찬하며! 오늘은 여기까지.
출처 및 참고
'Study > TIL' 카테고리의 다른 글
[TIL] 06/17 항해99 40일차 - Github Readme작성을 위한 마크다운 문법 (0) | 2022.06.18 |
---|---|
[TIL] 06/16 항해99 39일차 - 여러가지 정리 (0) | 2022.06.16 |
[TIL] 06/14 항해99 37일차 - 트러블 슈팅 (0) | 2022.06.15 |
[TIL] 06/13 항해99 36일차 - Timestamp format 변경, 트러블 슈팅 (1) | 2022.06.13 |
[TIL] 06/11 항해99 34일차 - Lombok으로 생성자주입, 트러블 슈팅 (0) | 2022.06.11 |