CI&CD
AWS EC2에 gh action을 통해 .env가 올라가지 않았던 오류에 대한 고찰
- -
728x90
최근 새로운 프로젝트를 진행하다 보니 오랜만에 글을 작성하는 것 같은데요. 작성하게 된 이유는 완성했다고 생각했던 CI/CD 부분에서 오류를 보았기 때문입니다. 원래 쉽게 찾아 볼 만한 오류들은 굳이 포스팅하지 않았지만 해당 오류를 3일 간 해결하지 못하게 되면서 오랜만에 소위 말해서 멘탈이 나갔었습니다. Stackoverflow 에 질문 글을 등록하기도 하고 개발자 사이트와 개발자 오픈 채팅방에 반복된 질문을 여러 번 했었습니다만 좀 처럼 해결되지 않았습니다. 그러다 늦은 새벽 3시 경 답답한 마음으로 해결 방법을 찾던 와중에 오픈 채팅방에서 한 귀인이 제 Repository를 봐주신다고 하셨습니다. 덕분에 문제를 해결했음은 물론이고 오히려 문제 해결에 대한 사고를 어떻게 했는지 여쭤보았는데 굉장히 친절하게 알려주셨고 처음 받아본 피드백이기에 글로 남겨보고 싶어 작성하게 되었습니다.
현재 제 CD 로직은 Github Actions를 통해 AWS EC2에 도커 이미지를 올린 후 컨테이너를 실행까지 하도록 하고 있는 상황입니다. 이때, Repository에 올라온 소스 코드를 checkout 하여 이미지를 생성하지만 .env 파일은 보안 문제로 업로드 할 수 없었습니다. env 파일이 꼭 필요하기 때문에 gh action 내에서 직접 .env파일을 생성하고, github repository secrets를 이용해 key = value 형태로 값을 넣어주는 방식으로 진행하려 했습니다.
그러나 여기서 문제가 발생합니다. 분명 env 파일을 작성하고 cat 명령어를 통해 해당 env 파일을 읽어보면 제대로 생성이 되었고, 값도 제대로 들어가 있었습니다.
하지만 env 파일이 docker Image 에는 담기지 않았습니다. 이유가 무엇일까요?
저는 처음으로 고민했던 방식이 '아직 yml 스크립트를 짜는 문법에 익숙치가 않았기도 했고 Dockerfile도 익숙치 않았기 때문에 잘못된 구글링으로 인한 코드 문제일 수 있다.' 라고 먼저 의심했었습니다. 그래서 문법에 대해 좀 더 디테일하게 찾아봤지만 해결할 수 없었습니다.
그래서 두번째로 떠오른 것이 '혹시나 dockerfile이 실행되는 OS 환경과 github action이 실행되는 OS가 서로 다르거나 같지만 경로가 맞지 않아 그런게 아닐까?' 라는 생각 이었습니다. 그래서 직접 디렉토리를 생성하고 경로를 맞춰 보았습니다만 역시나 되지 않는군요. 여기서 다른 고민을 하지 않은 채 '디렉토리도 같은데 안되는 것은 아무래도 돌아가는 OS 환경이 다르거나 한 것 같다.' 라는 가정을 하게 됩니다. 결국 근본적인 원인은 찾지 못한 채 '가정'만 하며 같은 곳을 빙빙 돌기 시작... 결국 미궁에 빠지게 되며 끝이 납니다..
는 농담이고, 결국 귀인의 도움을 받아 원인을 찾아냅니다....!!
그림 3을 보시면 101번 줄에서 git source를 새로 로드해오는 것을 알 수 있습니다.
이렇게 된다면 gh actions 에서 작성했던 .env 파일은 OS 상에서만 존재하고 현재 레포지토리에 올라온 소스와 다르기 때문에 당연하게도 .env는 올라가지 않았던 것입니다.
이제 build-push-action의 레포지토리를 찾아가서 Issue 중 관련 내용이 있는지 찾아보면 됩니다.
저를 도와주신 분 께서는 두 가지의 해결 방안을 발견해 주셨는데요.
첫번째는 secrets 라는 옵션을 통해 docker에서 참조가능한 변수를 추가하고, Dockerfile에서 해당 secrets을 run 할 때 옵션으로 주어 환경변수를 적용하는 방법입니다.
두번째는 새로 소스를 받아오지 말고, 기존의 소스를 가지고있는 OS 환경에서 사용하라는 옵션을 찾아보는 것이었습니다.
해당 방법은 옵션으로 context : . 를 주면서 새로 소스를 받아오지 않도록 합니다.
마침내 Dockerfile의 디렉토리 내 파일을 확인해보면 .env를 가지고 있네요! 이대로 배포까지 완료하면 됩니다.
이렇게보니 해결방법은 정말정말 쉬웠습니다. 하지만 저 혼자 했다면 이 원인을 아직까지도 못찾고 있었을 것 같습니다.
필자는 이 문제를 해결함에 있어 사고하신 방식이 너무 궁금해서 안그래도 늦은 시간 도와주셨는데도 불구하고 혹시 어떻게 사고하셨는지에 대해 여쭤봐도 되냐고 했더니 도움주신 분께서 흔쾌히 설명을 해주셨습니다.
(더불어 블로그에 정리하는 것 또한 허락해주셨어요. 너무나 감사합니다.)
도와주신 분의 사고의 순서는 아래와 같았습니다.
1. 내가 넣은 파일들이 잘 들어갔는지 부터 확인
2. 만약 파일이 존재하지만 환경변수가 적용되지 않는다면 도커 내부의 next 설정 문제일 것이라 여겼을 것이고
2-1. 파일이 없다면 도커를 빌드하는 과정에서 파일이 누락됐다 라고 생각
여기서 파일이 없었기 때문에 2-1로 생각하셨고
3. 도커를 빌드하는 과정이 문제가 생겼다면 github actions 스크립트를 따라가기 때문에 일단 github actions에서 (제가 혼자 수정해보느라 이것 저것 건드렸던) 경로들을 전부 기본 경로로 변경하면서 베이스를 다시 맞춘다.
4. 경로를 돌려놨음에도 같은 문제가 생겼으니 경로와 관련없이 다음 스크립트에서 문제가 생긴 것이라 판단하고 그 이후 과정에서는 docker cache, build, deploy 등의 과정이 있었는데 cache와 deploy는 문제가 되지 않으니 스킵하고 build의 로그를 살펴보셨다고 합니다.
5. 로그를 살펴보는 과정에서 위와 같이 소스를 새로 받아오는 것을 확인하신 후, 이 문제일 확률이 높겠다 라고 판단하셔서 해당 uses의 레포지토리를 찾아갑니다.
6. 이후 Issue에서 관련 키워드를 통해 검색을 해서 힌트를 얻으셨다고 합니다.
그리고 여기서 보통 이런 케이스를 추론하는 방법을 두 가지로 이야기 해주셨습니다.
(1). 직접 사용사례를 찾아서 확인
오른쪽 아래의 Used by를 보시면 해당 레포의 내용을 사용하고 있는 유저들이 나오고, 해당 유저들이 어떻게 사용했는지 직접 찾아보면서 확인하는 방법이 있다고 하셨습니다.
( 이 부분은 생각지도 못했어서 꿀팁이라고 느꼈습니다. )
(2). 예상하며 찾는다.
보통 이런 오픈소스는 일반적인 사용사례에 대한 매우 많은 옵션들을 제공하고 있기 때문에 readme 나 docs에서 찾아보고 그럼에도 못 찾았을 땐 분명 비슷한 이유로 올린 Issue가 있을테니 키워드를 통해 관련 Issue를 찾아보는 방법이 있다고 하셨습니다.
( 매우 높은 확률로 내 자신의 오류나 고민은 많은 사람들이 이미 겪었던 문제이기 때문에 없다고 보는게 어렵다는 것을 다시한번 느꼈습니다...! )
이렇게 문제를 해결하고 사고하는 방식에 대한 고찰을 하게 되었습니다. 한 단계 성장한 느낌이라 너무너무 기뻐요.
제 것으로 만들 수 있었으면 좋겠네요 ㅎㅎ.
그리고 이렇게 누군가의 피드백을 들어볼 기회가 없었기 때문에 소중하게 느껴지는 것 같기도 합니다.
각설하고, 혹시나 비슷한 문제로 앓고 계시는 분들이 계시다면 이 포스팅이 도움이 되셨으면 좋겠습니다.
물론 고찰로 쓴 글이기 때문에 크롤링 봇이 과연 제 글을 상단에 올려줄지...
'CI&CD' 카테고리의 다른 글
| [CI/CD] Github Actions -> AWS EC2 -> Docker 자동화 해보기 (0) | 2022.07.24 |
|---|---|
| [GitHub Actions] 254번 오류 해결하기 (with React, Next) (0) | 2022.06.29 |
Contents
소중한 공감 감사합니다