Github Secret, 도커를 사용하다 찾은 안된 이유!

음… 이 글을 내일 쓰려고 했는데 금방 해결한 문제이긴한데

아까워서 내일 커밋하는 걸로 미룰까 하다가, 잊을 것 같아 글을 하루에 2개나 쓰게 되었다 ㄱㄱ!

문제 상황

바로 전편에서 ## Future 이라는 문단 제목으로

나중에 할 것을 금방 구현했다.

근데 다 구현했는데, 문제가 발생했다

문제 상황

AWS 컴포넌트들은 기존에 잘 되었던 그대로 엔드포인트랑 이름만 다를 뿐, 구현은 금방 가능해서 바로 만들수 있었는데

사진처럼 엔드포인트를 인증할 수 없다고 떴다.

음..? 분명히

API Gateway도 dev 람다로 바꿨고, 복제한거라 url만 다른건데 뭐지? 싶었다.

디스코드 개발을 안해보신 분들을 위해 약간의 설명을 첨부하자면

webhook을 설정하면, 지정한 webhook에 대해서 형식에 맞는 파라미터와 타입을 디스코드 측에서 미리 검증을 한다.

그러니깐 테스트 케이스로 POST 메서드 몇 개를 보내는 거다.

디스코드에서 POST 메서드 내부에 키를 보내기 때문에 클라이언트 측에서 검증이 가능하다

그런데 발생한 문제를 찾아 CloudWatch 로그를 보니 코드 내부에 로직에 문제가 있던 것이 아니라
(정상적으로 작동하는 main 브랜치의 이미지를 복사 했으니 문제가 생길리 없다)

아예 Unauthorized, 권한 실폐 exception 코드가 실행되었던 것이다.

그래서 가능한 문제들이 Github Action에서 빌드 중에 무언가 잘못된 것으로 파악할 수 있었다.

코드 자체는 같은 레포지토리, 방금 막 분기한 브랜치라 뭐가 잘못되었나 싶지만

저 Unauthorized 문제가 내 디스코드 앱의 Public Key에 대한 문제인 것을 알 수 있었다.

그래서 처음에는

내가 인증키를 github repo secrets를 넣지 않은 것을 알게되었다.

바로 전편에서 설명했듯이

개발용과 배포용 앱이 각각 존재하기 때문에 같은 키를 사용할 수 없어 생긴 문제인줄 알았으나…

아! 아?

위: src/app.py, 아래:Dockerfile 수정 후

문제는 의외로 Dockerfile를 이용해 빌드를 할 때 --build-arg가 앱 소스인 app.py가 퍼블릭 키를 불러오는 변수와 달랐다는 것이다.
(파이썬 스크립트에서 환경 변수를 불러올 때 os.getenv를 사용한다)

고민의 분기점 1

app.py를 수정할까 고민했지만,

개발용 코드나, 베포용 코드에서나 키를 불러올 때 _DEV를 붙이지 않고 퍼블릭 키를 불러오는 것이

코드를 읽는 사람의 입장에서 맥락 상 자연스럽고,

또 하나의 코드에서 브랜치를 확인하거나, 어떤 도커 이미지를 불러오는지 확인하는 코드를 작성하면

안해봐도 오버헤드가 클 것이 눈에 선했기 때문에 바로 이 고민은 접었다.

고민의 분기점 2

이 문제를 베포용 코드(src/)와 개발용 코드(src-dev/)으로 나눠 구현을 할까 고민하다가

Dockerfile을 빌들할 때 넣는 변수 이름을 바꾸는 방법으로 해결했다.

미래의 누군가를 위해 친절하게 주석도 3줄이나 적어줬다

애초에 두개의 브랜치로 나눠 개발을 하는데,

거기서 또 개발용 소스코드를 복제해 개발하는 것은 브랜치를 나눈 의미가 없다고 생각했다.

Github Workflow 파일도 나눠 개발용 workflow를 만드는 과정에

--build-arg를 생각하지 못하고, 모든 변수 이름 뒤에 _DEV를 붙여서 생긴 일이었다.

그래서 발생한 문제의 원인은

애초에 없는 변수를 app.py에서 가져올려고 했고, 그래서 Public Key도 모른채 앱을 실행할려고 했던 것이다.

사실 Public Key도 굳이 repo secrets에 넣을 이유는 없지만

어쩌다보니 이렇게 잘 맞아 떨어져서, 스크립트에 하드 코딩도 줄일 수 있고 브랜치 전략도 잘 실행할 수 있어서 다행이다.

결과물

그렇게 문제를 해결해서 지금은 베포용과 개발용 모두 잘 작동한다!

이제 CI/CD 환경을 구축했으니

실제 기능을 구현할 시간이다