프로찍먹러

docker의 postgres에서 psql로 접속하려했더니 위와같은 권한에러가 발생했다.

docker compose yml에서 docker-compose up 할 때 

    environment:
      # PostgreSQL 계정 및 패스워드 설정 옵션
      PGUSER: my-user

이처럼 키값을 PSUSER로 설정해줘야한다

원래는 POSTGRES_USER였음

https://stackoverflow.com/questions/60193781/postgres-with-docker-compose-gives-fatal-role-root-does-not-exist-error

1. 무슨일이야

Canary branch를 생성하며 기존의 [빈스톡+S3+RDS+Firebase] 세트의 인프라를 똑같이 하나 더 생성하려고했다.

순조롭게 하나씩 뚝딱뚝딱 만들어갔다..

아예 새로운 환경이기에 firebase나 kas api등 모든 키값들을 새로 넣어주어야했다.

따라서 NodeJS의 .env파일과 firebase 설정파일인 firebase.json을 불러오는 script까지 canary버전으로 새로 작성해주었다.

그런데 이게 무슨일인가

빈스톡에 배포를 하고나니 여전히 Dev DB, Dev Firebase, Dev KAS api를 가리키고있는게 아닌가?

데이터는 데브 디비로 저장되고 Firebase JWT는 프로젝트가 다르다며 풀리지 않았다.

왜! 분명 나는 잘 한거같은데!!!(물론 역시 내 실수였다)

2. 어디서 꼬였을까

의심1. 내가 S3에 env를 잘못올려놨겠지

• 아니었다. 다시 다운받아서 열어보니까 잘 올라가 있더라.
• Github Actions에서 env, firebase.json을 가져오는 스크립트에도 문제가 없었다.
• 그 외에 모든 S3와 관련된 부분에서도 문제는 없었다.

의심2. POSTMAN의 환경변수 문제인줄 알았다.

테스트를 포스트맨으로 하는데 엔드포인트를 데브 빈스톡으로 설정한줄 알았다.

• 역시 아니었다. 잘 해놨다.

의심3. 빈스톡 deploy.zip이 생성될 때 뭔가 env가 누락이 되는가 싶었다.

• 로컬에선 잘 포함되어 만들어지는데.. 이것도 아닌것 같았다.

3. 등잔밑이 어두웠다

깃헙액션 스크립트 곳곳에 로그를 찍어가며 어디서부터 잘못된 env로 바뀌는지 찾아갔고..

결국 Generate deployment package와 Deploy to EB 사이 어딘가에서 문제가 생김을 알 수 있었다.

근데 조금 자세히 보면 

[deploy.zip 생성 -> 배포시작 -> 배포완료 -> 애플리케이션 구동] 의 흐름인건데

이 흐름에서 deploy.zip 생성에는 문제가 없었다면,

그 이후의 과정에는 내가 관여할 수 없는것 아닌가? 싶었다.

즉, 배포가 시작되고부터는 내 손을 떠난 상태라고 생각했다.

결국 선임님께 헬프를 쳤는데 30초만에 "혹시 이거 아닌가요?" 라고 답이 왔다.

정답은 빈스톡을 처음 설정할 때 멋모르고 만들어 놓은 .ebextension파일이었다.

4. ebextension이란?

한마디로

"빈스톡이 배포될때 실행되는 커맨드"

라고 할 수 있다.

프로젝트 최상위 경로에 .ebextension 폴더를 생성하고 폴더 안에 .config 파일을 생성하여 커맨드를 지정한다.

commands와 container_commands 이렇게 두가지 종류의 명령이 있다.

이 둘은 실행시점이 다르다.

• commands는 웹서버가 설정되고 애플리케이션 버전이 추출되기 전에 실행되고,
• container_commands는 웹서버가 설정되고 애플리케이션 버전 아카이브의 압축이 풀린 후에 실행된다.

위 이미지에는 없지만 나는 container_commands에 엉뚱한 env를 불러오는 S3 스크립트를 넣어놨었다.

그래서 깃헙액션에서 canary env를 불러와서 deploy.zip에 넣어줘도 빈스톡 배포 직후 엉뚱한 env로 덮어씌워졌던 것이다!!!!

바로 해당 커맨드를 빼주니 정상 동작하더라.

참고:

spring data jpa에서

No serializer found for class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer

에러가 발생했다.

간단하게 해석해보자면 serializer가 없다는 것인데,

serialize, 즉 직렬화란 간단히 말해서 Object를 연속된 String 데이터나 연속된 Bytes 데이터로 바꾸는 것을 의미한다.

역직렬화는 그 반대겠지?

Object는 메모리상에서 존재하고 추상적이다.

String 데이터나 Bytes 데이터는 드라이브에 저장될 수 있고 통신선을 통해 전송될 수 있다.

https://youtu.be/qrQZOPZmt0w

아무튼 다시 나는 스프링부트 + 코틀린을 사용하여 개발을 하고있었고,

JPA로 table을 findAll을 통해서 목록을 뽑아오는 기능을 구현하고있었다.

에러는 이 부분에서 발생했다.

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    var noticeCategory: NoticeCategory,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id")
    var noticeBoard: NoticeBoard

JPA로 조회한 데이터는 메모리 상에 존재하는 Object다

이 Object를 Json 형태로 반환하기위해 직렬화를 해주어야하는데 

NoticeCategory와 NoticeBoard 컬럼이 LAZY로딩으로 설정되어있다.

이렇게 되면 조회한 Object를 serialize하려는 순간 실제 Object가 아닌

프록시로 감싸져있는 hibernateLazyInitializer를 serialize하게되므로 에러가 발생한다

해결

3가지 방법정도가 있다. 난 2번 방법을 사용했다.

1. @JsonIgnore로 반환시키지 않는다

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    @JsonIgnore
    var noticeCategory: NoticeCategory,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id")
    @JsonIgnore
    var noticeBoard: NoticeBoard

2. LAZY로딩 대신 EAGER로딩으로 설정해주면 된다

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "category_id")
    var noticeCategory: NoticeCategory,

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "board_id")
    var noticeBoard: NoticeBoard

3. application 파일에 spring.jackson.serialization.fail-on-empty-beans=false 설정해주면 된다

+

220328 추가사항

프록시 컬럼이 있는 엔티티를 그대로 반환하면 위에 보이듯 hibernateLazyInitializer를 직렬화하려다가 에러가났는데

ObjectMapper로 Entity -> dto로 변환을 시켜주니 LAZY로딩이 정상적으로 동작했다.

참고:

아침에 노트북을 켜서 보니 갑자기 안뜨던 에러가 떴다.

npm install --g eslint

를 해주고 인텔리제이를 재실행했더니 해결됐다.

(권한문제가 발생하면 sudo를 사용하자)