hehe_sim

아가미, 구병모

히히심 — Tue, 8 Apr 2025 14:04:54 +0900

자, 저는 그것이 사람이었든 물고기였든 혹은 네시였어도 상관없어요. 중요한 건 그가 저한테 한 번 더 살 수 있는 기회를 주었고 저는 집에 가서 엄마를 돌보며 필사적으로 돈을 벌고 재계약에 성공해야 한다는 사실뿐이에요. 다음에는 정말 이런 일이 있으려야 있을 수도 없겠지만, 또다시 물에 빠진다면 인어 왕자를 두 번 만나는 행운이란 없을 테니 열심히 두 팔을 휘저어 나갈 거에요. 헤엄쳐야지 별수 있나요. 어쩌면 세상은 그 자체로 바닥없는 물이기도 하고.

가끔은 곤이 무면허 운전으로 사 갖고 오기도 했으나 그걸 먼져 펴보는 일은 없었다. 곤은 자신이 언제부터 시간의 흐름과 무관하게 살아왔는지를 헤아리지 않았다. 비좁은 세상을 포화 상태로 채우는 수많은 일들을 꼭 당일 속보로 알아야 할 필요가 없으며 시대에 뒤떨어진 인간이 되지 않기 위해 애쓸 필요 없고 속도를 내면화하여 자기가 곧 속도 그 자체가 되어야 할 이유도 없는, 아다지오와 같은 삶. 그 어떤 행동도 현재를 투영하거나 미래를 예측하지 않고 어떤 경우라도 과거가 반성의 대상이 되지 않으니 어느 순간에도 속하지 않는 삶이었다.

곤, 그에게 있어서 당신은 어쩌면 일찍이 들어본 적 없던 세계의, 이해할 수 없는 언어로 직조된 존재였어요. 그건 강하가 아니라 상대가 누구였어도 그랬을 거예요. 남과 같지 않은 것은 그 어디서도 환영받지 못하고 증오의 대상이 돼요. 아니면 잘해야 동정의 대상이 되는데, 그것은 타인이 시혜하는 동정과 그에 수반하는 불편한 시선을 기꺼이 받아들이겠다는 수혜자의 합의 아래에서 보통 이루어지곤 해요. 당신에 대한 강하의 ... 글쎄요, 그 불합리는 과연 뭐였을까요, 그 긴장과 불안과 원망은. 강하는 그 혼란을 평범한 일상이 주는 초조 정도 차원으로 수용하려 했어요. 그 과정에서 당신에게 상처 입혔다는 사실을 스스로도 알고 있었어요. 당신이 아무것도 아니라고 생각하면서도 실제론 아무것도 아닌 게 아니라 오히려 모든 것이라는 사실과, 거기에서 비롯되는 괴리감을 견딜 수 없어 했어요.

곤, 보통 사람은 말이지요, 자신에게 결여된 부분을 남이 갖고 있으면 그걸 꼭 빼앗고 싶을 만큼 부럽거나 절실하지 않아도 공연히 질투를 느낄 수 있어요. 그러면서도 그게 자신에게 없다는 이유만으로 도리어 좋아하기도 하는 모순을 보여요. 양쪽의 세계에 걸쳐진 감정은 서로 교환되거나 합의점을 찾지 못하고, 기껏해야 적정 수준에서의 은폐가 가능할 뿐이에요.

"...물론 죽이고 싶지."

작은 불꽃이 그대로 사그라지는 바람에 곤은 그 말을 하는 강하의 표정을 볼 수 없었다. 곤한테 다시 후드를 씌운 뒤 조임줄을 당겨 머리에 단단히 밀착시키고 강하는 이어서 말했다.

"그래도 살아줬으면 좋겠으니까."

살아줬으면 좋겠다니! 곤은 지금껏 자신이 들어본 말 중에 최선이라고 생각했던 '예쁘다'가 지금 이 말에 비하면 얼마나 부질없는 것인지를 폭포처럼 와락 깨달았다. 언제나 강하가 자신을 물고기 아닌 사람으로 봐주기를 바랐지만 지금의 말은 그것을 넘어선, 존재 자체에 대한 존중을 뜻하는 것만 같았다.

다만 당신이 알아야 할 것은 따로 있어요. 강하가 예전에 당신을 어떤 방식으로 싫어했든 간에, 그 싫음이 곧 증오를 가리키지는 않는다는 걸. 그건 차라리 혼돈에 가까운 막연함이라는 걸요. 사람을 바라보는 사람의 마음은 매 순간 흔들리고 기울어지는 물 위의 뗏목 같아요. 그 불안정함과 막막함이야말로 사람이 다른 사람을 받아들이는 유일한 방법 아닐까요. 우리가 누군가를 사랑할 때 확신할 수 있는 단 한가지는, 이 마음과 앞으로의 운명에 확신이라곤 없다는 사실뿐이지 않을가요. 강하와 할아버지만이, 그리고 막판에 이녕 씨만이 둘러싼 세상의 전부였던 당신에게, 이것은 선뜻 이해가 가는 말이 아닐 수도 있겠어요.

[토이프로젝트] 25.03.10 - 카카오로그인 수정

히히심 — Mon, 10 Mar 2025 19:19:12 +0900

1. 카카오 로그인 방법 수정

- 원래 구현한 방법은 프론트에서 인가코드 요청 후 인가코드를 백엔드로 전달하여 백엔드에서 이를 활용해 액세스토큰을 받아쓰는 방법이었는데,

- 프론트에서 백엔드로 전하는 과정에서 "탈취 위험성"이 있기에

- 아예 백엔드에서 인가코드 요청 및 액세스 토큰 발급까지 완료하도록 방법을 수정하였다.

나름대로 보안 대책(HTTPS 적용, POST 방식, 백엔드에서만 액세스 토큰 요청)이 있기는 한데, 아예 백엔드에서 처리하는 방법이 더 간단하기도 하고 편해서 그렇게 하기로 결정했다.

Spring Security OAuth2 Client + JWT 발급 흐름

1) 사용자가 /oauth2/authorization/kakao 등으로 SNS 로그인 시도

2) Spring Security가 인가 코드 - 액세스 토큰 자동 획득

3) OAuth2UserService를 커스텀하여 SNS 사용자 정보를 DB 조회해 기회원/비회원 판별 -> 없으면 회원가입 후 저장 -> JWT 발급

4) JWT를 최종적으로 클라이언트에게 전달

5) 이후 클라이언트는 JWT로 API 호출

이러한 흐름으로 구현 중이다...

운동을 가야하므로 이만...!!!

[우리집에가면] 25.03.09 - 반환형식 정리 & 카카오 로그인 REST API 방식

히히심 — Sun, 9 Mar 2025 21:00:55 +0900

이번주부터 일을 시작해서 적응기간을 가졌다....

일집뻗 일집뻗 반복하여 겨우 정신을 차리니 일요일..^^;;

조금이라도 작업 해보고자 일어남 ㅠㅡㅠ

1. 일관된 반환 형식 정리

ResponseWrapperDto ErrorResponse

https://hehesim.tistory.com/318

ResponseWrapperDto와 ErrorResponse - API 응답

프로젝트 API를 개발하다보니 API 응답에 대한 뭔가 체계적인 방법을 찾고 싶었다. 그래서 열심히 서치하며 정리를 해보았다. 일단 결론만 보자면, ResponseWrapperDto : 전반적인 응답에 대한 공통

hehesim.tistory.com

2. 카카오 로그인 구현

- 프론트에서는 카카오에 로그인 요청을 하고 인가코드를 받아 redirect_uri에 포함하여 GET 요청을 보냄

- 백엔드에서는 해당 redirect_uri에서 인가 코드 추출하여 백엔드에 전달.

ex) 프론트 예시

import { useEffect } from "react";
import { useNavigate } from "react-router-dom";
import axios from "axios";

const KakaoCallback = () => {
    const navigate = useNavigate();

    useEffect(() => {
        // URL에서 인가 코드 추출
        const urlParams = new URLSearchParams(window.location.search);
        const code = urlParams.get("code");

        if (code) {
            console.log("인가 코드:", code);

            // 백엔드에 인가 코드 전송하여 액세스 토큰 요청
            axios.post("http://localhost:8080/auth/kakao", { code })
                .then(response => {
                    console.log("로그인 성공:", response.data);
                    // JWT 저장 후 메인 페이지 이동
                    navigate("/");
                })
                .catch(error => {
                    console.error("카카오 로그인 실패:", error);
                });
        }
    }, []);

    return <div>카카오 로그인 중...</div>;
};

export default KakaoCallback;

- 백엔드에서는 인가 코드 수신 후 이를 활용해 카카오에 액세스 토큰 요청

** 원래는 백엔드에서 인가코드, 액세스토큰 모두 받는 방법으로 했었는데 그래서 이때는 OAuth2를 사용할 수 있었다.

그러나, 현재는 프론트 측에서 인가코드를 받고, 이때 redirect하며 백엔드로 인가코드를 전해주어 백엔드에서는 액세스토큰을 받는 형식으로 하게 되었다. 이때는 OAuth2를 사용할 수 없고, 직접 액세스 토큰 요청을 카카오로 보내어 토큰을 받는 방법이 필요하다. 즉 REST API 방식을 사용해보게 되었다.

-> 일단은 액세스 토큰 요청을 해보았을 때 성공화면을 보았다.

이제는 액세스 토큰 가지고서 사용자 정보 받고, 이 사용자 정보를 우리 프로젝트 회원가입 과정과 jwt Token을 받는 과정을 거쳐 프론트에 JWT 토큰을 전해주는 과정이 필요하다!

내일 마저 해보도록 하겠다..!

돌아오는 주에는 꼭꼭 ! 퇴근 후에 조금이라도 작업 및 공부 시작하기!!!

ResponseWrapperDto와 ErrorResponse - API 응답

히히심 — Sun, 9 Mar 2025 15:40:01 +0900

프로젝트 API를 개발하다보니 API 응답에 대한 뭔가 체계적인 방법을 찾고 싶었다.

그래서 열심히 서치하며 정리를 해보았다.

일단 결론만 보자면,

ResponseWrapperDto : 전반적인 응답에 대한 공통 포맷
ErrorResponse : 에러 상황에 대한 구체적 응답 포맷
ErrorCode : 에러의 종류별로 상태/코드/기본 메시지를 모아둔 Enum
FieldError : 유효성 검증 실패 등에서 발생하는 구체적 필드단위 에러정보를 담기 위한 서브클래스

이 네가지를 구분해서 만들었다.

그 이유는 !?!??

-> API 응답을 체계적으로 분류하고, 일관된 형식으로 제공하려고 !

더 자세히 살펴보겠다.

1. ResponseWrapperDto

: 정상 응답을 감싸는 공통 DTO.

package com.example.refrig.api.common;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.*;

import java.util.List;

@NoArgsConstructor
@AllArgsConstructor
@Builder
@Data
public class ResponseWrapperDto<T> {
    private T data; // 응답 본문 데이터
    private String code; // API 응답 상태코드
    private String message; // 응답 메시지
    private List<ErrorResponse.FieldError> errorList; // 에러 발생 시 해당 에러에 대한 상세 정보 리스트

    // 에러 상황에 대한 DTO를 만들 때 사용하는 정적 메서드
    public static ResponseWrapperDto<ErrorResponse> of(ErrorResponse errorResponse) {
        return ResponseWrapperDto.<ErrorResponse>builder()
                .code(errorResponse.getCode())
                .message(errorResponse.getMessage())
                .errorList(errorResponse.getErrors())
                .build();
    }

    // 일반 성공 응답에 대한 DTO를 만들 때 사용하는 정적 메서드
    public static <T> ResponseWrapperDto<T> of(T body) {
        return ResponseWrapperDto.<T>builder()
                .data(body)
                .build();
    }


    // 객체를 JSON 문자열로 직렬화
    public String toJson() {
        try {
            return new ObjectMapper().writeValueAsString(this);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("Failed to serialize ResponseWrapperDto to JSON", e);
        }
    }
}

2. ErrorResponse

: 에러 상황에서 응답을 전송할 때 동일한 구조를 유지하기 위한 DTO.

package com.example.refrig.api.common;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import org.springframework.validation.BindingResult;

import java.util.Collections;
import java.util.List;
import java.util.stream.Collectors;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class ErrorResponse {
    private String message; //에러 메시지
    private int status; //HTTP 상태 코드
    private String code; //에러 코드 (커스텀 에러코드)
    private List<FieldError> errors; // 구체적인 필드 오류


	/**
    * - errorCode : 에러 코드 및 기본 메시지, HTTP status를 가진 Enum
    * - bindingResult : 스프링 Validation 등을 통해 폼이나 dto 검증이 실패하면 검증오류 정보가 bindingResult에 쌓인다.
    * - errors : 상황에 따라 직접 정의한 필드 에러를 주입할 수 있는 용도.
    * - customMessage : errorCode에 정의된 기본 메시지 대신 상황에 따라 다른 메시지를 사용하고 싶을 때 주입하는 파라미터
    */
    public static ErrorResponse of(
            ErrorCode errorCode,
            BindingResult bindingResult, 
            List<FieldError> errors, 
            String customMessage 
    ) {
        List<FieldError> resolvedErrors;

	// bindingResult가 존재하면 FieldError를 추출.
        // 없으면 파라미터로 받은 errors 사용
        if (bindingResult != null) {
            resolvedErrors = FieldError.of(bindingResult);
        } else if (errors != null) {
            resolvedErrors = errors;
        } else {
            resolvedErrors = Collections.emptyList();
        }

        return ErrorResponse.builder()
        	// customMessage가 있으면 우선 사용, 없으면 errorCode의 기본메시지
                .message(customMessage != null ? customMessage : errorCode.getMessage())
                .status(errorCode.getStatus())
                .code(errorCode.getCode())
                .errors(resolvedErrors)
                .build();
    }


    // 중첩 클래스.
    @Data
    @NoArgsConstructor
    @AllArgsConstructor
    public static class FieldError {
    	// ...
    }
}

3. ErrorCode

: 프로젝트 전역에서 발생할 수 있는 에러 유형을 Enum 형태로 묶어 각 에러별로 HTTP 상태코드(status), 내부 식별 코드(code), 기본 에러 메시지(message)를 정의해둔다.

-> 에러 관리가 체계화되고, 새 에러 유형을 추가하거나 메시지를 변경하는 것도 간편해짐.

package com.example.refrig.api.common;

import lombok.Getter;

@Getter
public enum ErrorCode {
    NO_JWT_TOKEN(401, "AUT000", "JWT 토큰이 존재하지 않습니다.");
    // ...

    private final int status;
    private final String code;
    private final String message;

    ErrorCode(int status, String code, String message) {
        this.status = status;
        this.code = code;
        this.message = message;
    }
}

4. FieldError

: 유효성 검증(Validation) 오류 등에서 구체적으로 어느 필드가, 무슨 이유로 잘못됐는가를 나타낼 수 있는 하위 클래스

- ErrorResponse 내 erros 필드에 리스트 형태로 보관하여 필드 단위 에러 정보를 리스트로 제공할 수 있게 된다.

- 위의 ErrorResponse 클래스 내부에 중첩 클래스로 넣어주었다. FieldError는 Validation 오류 발생 시 어떤 필드가 잘못되었는지를 설명하는 역할인데, 이는 ErrorResponse 내부에서만 사용되는 개념이므로, 별도로 분리하기보다 연관성이 높은 ErrorResponse 내부에서 정의하는 것이 더 자연스럽다.

package com.example.refrig.api.common;


@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class ErrorResponse {
    private String message; //에러 메시지
    private int status; //HTTP 상태 코드
    private String code; //에러 코드 (커스텀 에러코드)
    private List<FieldError> errors; // 구체적인 필드 오류

	// ...


    // 중첩 클래스.
    @Data
    @NoArgsConstructor
    @AllArgsConstructor
    public static class FieldError {
        private String field; //에러 발생한 필드 이름
        private String value; //서버가 받은 잘못된 값
        private String reason; //에러 사유

        public static List<FieldError> of(BindingResult bindingResult) {
            // 스프링의 bindingResult.getFieldErrors 목록을 순회하며 우리 정의의 FieldError 객체로 변환.
            // 일관된 에러 응답 구조
            return bindingResult.getFieldErrors().stream()
                    .map(err -> new FieldError(
                            err.getField(),
                            err.getRejectedValue() == null ? "" : err.getRejectedValue().toString(),
                            err.getDefaultMessage() == null ? "" : err.getDefaultMessage()
                    ))
                    .collect(Collectors.toList());
        }

    }
}

왜 이런 구조를 쓰는가?

1) 일관된 응답 형식
2) 가독성과 유지보수성
3) 표준화된 예외 처리 로직
4) 확장성
서버-클라이언트 간 통신할 때 예측 가능하고 표준화된 형식으로 성공/실패 응답을 주고받도록 설계한 것 !

사담)

이렇게 정리하고 나니 속이 시원한 J....

[우리집에 가면] 25.03.03 - HTTPS 적용 완료

히히심 — Mon, 3 Mar 2025 20:48:21 +0900

1. 빌드 오류 해결

git에서 pull 받아온 소스코드로 빌드하기.

지난 번에 git에서 pull 땡겨와서 빌드를 하는데 계속 이러한 오류가 났다.

Build failed with an exception

* What went wrong:
Execution failed for task ':compileJava'.
> Error while evaluating property 'javaCompiler' of task ':compileJava'.
> Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
> Toolchain installation '/usr/lib/jvm/java-17-amazon-corretto.x86_64' does not provide the required capabilities: [JAVA_COMPILER]

컴파일링이 안되는 문제였다....!!

<문제점/해결책>

java 설치를 했을 때 해당 명령어로 설치했는데, 이때 JDK가 아닌 JRE만 설치된 것이었다.

sudo yum install -y java-17-amazon-corretto

java -version 확인을 하면 잘 나오지만,

javac -version 확인을 해보니 없다고 나온다. 이게 문제였구나

JRE만 설치되고, 컴파일러가 포함된 JDK가 설치되지 않아서 발생한 오류였다!!

설치했던 java를 지우고, 다시 devel 패키지로 설치하였다.

sudo yum remove java-17-amazon-corretto
sudo yum install -y java-17-amazon-corretto-devel

짠 재설치 이후 확인했더니 javac 정보도 나왔다.

이후 도커 컴포즈와 HTTPS 적용은 따로 게시물을 썼다.

https://hehesim.tistory.com/316

[Docker] Docker Container와 Nginx를 활용한 HTTPS 적용기

아주 다양한 오류들을 마주쳤다... = 내가 성장하는 과정잊지 않도록 기록하기 나의 현재 상황은 Nginx로 SSL 인증서는 받았고, 도커 이미지로 업로드하다가 HTTPS 적용이 어려워서 결국 Docker Conta

hehesim.tistory.com

결론 !!! HTTPS 적용 완!!!!~~~~ 이렇게 행복할수가....!?!??!??!?우엉 ㅠ

이제 개발에 빠져 달려보자 내일부터는 <3

[Docker] Docker Container와 Nginx를 활용한 HTTPS 적용기

히히심 — Mon, 3 Mar 2025 20:46:50 +0900

아주 다양한 오류들을 마주쳤다... = 내가 성장하는 과정

잊지 않도록 기록하기

나의 현재 상황은
Nginx로 SSL 인증서는 받았고, 도커 이미지로 업로드하다가 HTTPS 적용이 어려워서 결국 Docker Container로 Nginx 서버와 Backend 서버를 함께 올리기로 함.
그리고 이를 위해 github에 올리고, 해당 소스를 EC2 인스턴스에서 받아 docker compose up 하기로 함.

1. 첫번째 오류

깃에서 pull 받고 빌드 해보는 과정에서 이러한 오류가 났다.

RefrigBackendApplicationTests > contextLoads() FAILED
java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:180
Caused by: org.springframework.beans.factory.BeanCreationException at AbstractBeanFactory.java:325
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException at ConstructorResolver.java:804
Caused by: org.springframework.beans.factory.BeanCreationException at ConstructorResolver.java:657
Caused by: org.springframework.beans.BeanInstantiationException at SimpleInstantiationStrategy.java:199
Caused by: org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$DataSourceBeanCreationException at DataSourceProperties.java:186

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///home/ec2-user/refrig-backend/build/reports/tests/test/index.html

테스트 과정에서 오류가 났는데, 데이터소스를 찾지 못하는 문제였다.

이건 아주 간단한 바보같은 문제였다.

<문제점/해결책>

git에 보안상 문제로 yml 파일을 올리지 않았고, 그러므로 EC2에서는 yml 파일이 없이 실행되어 데이터베이스를 찾을 수 없었던 것.

완전 기본이자너~~~~

그래서 yml 파일을 gitignore에서 빼고, 보안에 문제되는 부분을 환경변수로 마스킹 처리를 했다.

그리고 해당 민감정보를 EC2에서 환경변수로 설정하였다.

나는 ~/.bashrc 내부 내용을 바꿔주었다.

export JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64
export PATH=$JAVA_HOME/bin:$PATH
export DB_URL=jdbc:mysql://refrig-db.xxxx.ap-northeast-2.rds.amazonaws.com:3306/refrig
export DB_USERNAME=root
export DB_PASSWORD=password

요렇게 해두고 꼭 echo를 통해 확인해보시길 바란다.

나는 계속 적용이 안돼서 빌드오류 여러번 겪음.

또한, 적용이 안될때 인스턴스 재접속 및 source ~/.bashrc 명령어로 재적용하기 ~!!!

결국 빌드 성공!

** 여담으로 github에서 environment로 설정하면 되지 않을까? 했는데, 그거는 Github Actions 파이프라인을 사용해야만 가능하다고 한다. 현재 아직 CI/CD 적용을 하지 않았기 때문에 임시로라도 직접 환경변수를 입력해주게 되었다.

2. 두번째 오류

이후 도커 컴포즈 올렸을 때 database 연결에서 문제가 생겼다.

refrig | 2025-03-03T09:32:49.886Z ERROR 1 --- [refrig] [ main] o.s.boot.SpringApplication : Application run failed
refrig | org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: [PersistenceUnit: default] Unable to build Hibernate SessionFactory; nested exception is java.lang.RuntimeException: Driver com.mysql.cj.jdbc.Driver claims to not accept jdbcUrl, ${DB_URL}
refrig | at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1812) ~[spring-beans-6.2.2.jar!/:6.2.2]
...
dependency failed to start: container refrig exited (1)

이제 되야 하는데, 왜 또 디비 문제가 나타난 것이냐~~~~~

Driver com.mysql.cj.jdbc.Driver claims to not accept jdbcUrl, ${DB_URL}

<문제점/해결책>

이번에는 application.yml 파일에서는 적용이 되어 빌드는 되지만,,, 스프링 부트 실행 시 ${DB_URL}이라는 문자열을 그대로 받아, 도커 컨테이너 내부에는 해당 환경변수가 전달되지 않았다.

** 왜 컨테이너에서 환경 변수를 못 읽을까!?

>> 도커 컨테이너는 호스트 OS의 환경변수와 격리되어 있다. 그래서 도커 내부에서 echo $DB_URL 해보아도 나오지 않는다.

>> docker-compose.yml에서 환경 변수를 넘겨주어야 한다! (도커 컴포즈로 컨테이너를 띄울 때 필요한 환경 변수를 컨테이너로 전달해주어야 한다.)

이렇게 docker-compose.yml을 수정해주었다.

환경 변수는 EC2에 설정되어 있는 상태이고, docker-compose에서 환경변수를 참조하는 식으로 설정해주었다.

그랬더니 스프링부트는 정상적으로 시작됨!!

3. 세번째 오류

도커 컴포즈 올렸더니 nginx에서 또 문제가 있는 것 같다.

failed to create shim task
error mounting "...privkey.pem" to rootfsat ".../privkey.pem"
...
not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

<문제점/해결책>

오류 메시지를 보면 마운트 하는 데에서 오류가 생겼다. 호스트의 어떤 경로를 도커 컨테이너 안의 경로와 부적절하게 매핑되어 발생하는 문제이다.

원래의 docker-compose.yml 파일을 보면 이렇게 경로설정을 해두었다.

docker-compose.yml

도커 볼륨 마운트 시 1) 호스트 쪽 경로가 디렉터리인지, 2) 컨테이너 쪽 경로가 디렉터리인지 확인을 해야 한다.

내가 설정한 경로는 호스트 쪽은 디렉터리였고,,, 컨테이너 쪽 경로는 파일이었다.

그래서 이렇게 변경 해주었다.

폴더 대 폴더로 마운트 변경.

그러나 여전히 오류가 났다. 스프링은 정상적으로 올라갔고, nginx측에서 문제가 생김.

cannot load certificate
PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)

흠 이건 또 모야~했는데 호스트 쪽 디렉터리를 확인해보았더니

호스트 쪽 디렉터리에 인증서가 존재한다고 생각했는데, 아니었다. 디렉터리 안이 비어있어서 파일이 존재하지 않는 상황이었다.

그래서 실제 인증서가 존재하는 디렉터리로 설정!!!

+ 또한, 중요한 것은 인증서가 존재하는 letsencrypt/live/ 디렉터리는 심볼릭 링크 구조로, 사실은 archive 디렉터리를 따라가게 된다.

오류

archive까지 포함한 경로로 설정해주어야 함.

그래서 심볼릭 링크의 실제 대상 경로도 컨테이너 내부에서 유효해야 한다. live 디렉터리 내부로만 설정하면 archive로 링크가 연결될 수 없다.

>> 짜잔 결과는

드디어 nginx도 같이 올라갔고, https가 완벽히 적용된 테스트 화면을 볼 수 있게 되었다.

흑 이 배포 문제를 몇일간을 매달리며... 좌절의 순간들을 겪었지만,

영원히 안되라는 법은 없다...!!!

앞으로 조금씩 나아가는 과정이기를

[우리집에 가면] 25.02.25 - 도커 컴포즈 빌드 오류

히히심 — Tue, 25 Feb 2025 20:03:57 +0900

컨디션이 좋지 않아서 늦게 작업 시작했다 ㅠㅠ

1. HTTPS 적용을 위해 Nginx+ ssl 인증서 적용중.

하다보니 docker compose로 설정하는 중인데, 그러다 보니 자연스럽게 ci cd 플로우까지 흘러감...

ㅠ쥬륵 왤케 어렵니~~~~

인스턴스에 자바 설치하고,

git clone 해서 docker compose up으로 하려는데 여기서도 build가 안되는 문제가 생김 ㅠ

고로 내일 다시 도전~~~~!

[우리집에 가면] 25.02.24 - 도메인 오류

히히심 — Tue, 25 Feb 2025 11:04:40 +0900

1. 계속 나던 DNS_PROBE_FINISHED_NXDOMAIN 오류

드디어 해결~~~~

AWS Route53 포기하고, 그냥 가비아 측에서 DNS 레코드 설정을 해주었다.

route 53은 삭제함.

계속 됐다가 또 안되고 그래서 답답했는데 뭔가 이리저리 만지다 보니 계속 충돌이 났나 싶다..

AWS에서 수정했다가, 또 가비아에서 수정했다가 그러다보니 사이트 접속이 가능했다가 안됐다가 했나 싶다.

그거랑, yml 파일에서 ddl-auto 를 create로 했던 걸 update로 고쳤다.

이게 문제였었나 싶기도 함...

무튼 드디어 어디서나 접속 가능하게 되었다~~~야호

2. https 설정을 위해 nginx를 이용해 ssl 인증서 적용

Invalid response from ~/.well-known/acme-challenge/코드 404 에러 발생

>> 이 문제는 해결은 했는데, 아직 docker + nginx + ssl 인증서 적용 중에 있음..

[우리집에 가면] 25.02.21 - 도메인 오류 (사이트 불안정)

히히심 — Fri, 21 Feb 2025 15:04:20 +0900

1. DNS_PROBE_FINISHED_NXDOMAIN

오류 해결 ing...

살려조~

왜 됐다가 안됐다가 하쥬?

[우리집에 가면] 25.02.20 - 도메인 구입 및 DNS 적용

히히심 — Thu, 20 Feb 2025 11:53:22 +0900

1. 가비아에서 도메인 구입

2. AWS Route 53에서 해당 도메인 주소 입력하여 호스팅 영역 생성

3. 값/트래픽 라우팅 대상의 네개 주소를 복사한다 (마지막 .은 제외)

4. 복사한 4개의 값을 가비아 네임서버 설정에 적용 (소유자 인증 필수)

적용되는데에 시간이 좀 걸린다고 합니다,,,,

5. www.myrefrig.site:8080/test 이렇게 매번 포트 번호를 적어줘야 접속이 가능했는데, 리눅스 서버에서 포트포워딩을 해주어 해결했다.

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

이렇게 하면 HTTP 80포트로 접속해도 8080 포트로 리다이렉션 해줌

그러면 이렇게 포트번호를 적지 않아도 연결해줌.

swagger도 잘 뜸!

http://myrefrig.site/swagger-ui/index.html