내가 알고 있는 좋은 명언중 습관에 관한 좋은 글귀가 있다.
내가 꾸준히 들이 내 습관은 언젠가는 그 습관이 나를 지켜준다는 말이있다.
오늘 트러블슈팅이 딱 이런느낌일 것 같다. 이전에 비슷한 경험을 하면서 작성해두었던 트러블슈팅의 경험이 어렵기만 할 것 같은 문제와 디버깅의 과정에 너무나 큰 도움을 준 것을 보고 역시 블로그를 더욱 꾸준히 써야겠다라는 생각이 절실히 들었다.
트러블 슈팅 상황 설명
ECS 를 사용해서 배포중 Docker: exec /usr/local/openjdk-11/bin/java: exec 라는 오류가 나왔다.
로컬환경에서 빌드한 도커 이미지를 ECR 로 성공적으로 푸시하고, 해당 이미지를 사용해 ECS 로 배포를 하던 중, 발생한 오류인데 뭔가 낯선 오류라서
세상에 나말고도 한명은 겪었겠지... 라는 기대감으로 일단 바로 구글링부터 시작을 했다.
이 문제에 대해서 가장 확실하게 해결책을 찾은것은 아래 링크였다
(역시 스택오버플로우 클라쓰 !!)
https://stackoverflow.com/questions/76293575/exec-usr-java-openjdk-20-bin-java-exec-format-error-while-running-docker-image
I encountered the same exception when using JDK 17. Since the image was built on an M1 processor, I updated the ECS task operating system/architecture to Linux/ARM64, and it worked perfectly.
결론부터 말하면 배포를 위해서 만든 로컬환경인 나의 맥북 M1 때문에 발생한 문제였다.
기본적으로 내가 진행하던 플로우는 다음과 같았다.
AWS ECR 관련문서의 푸시명령보기를 참고해서 동일하게 진행하였다.
- 우선 이미지를 먼저 빌드를 해준다.
docker build 나의 이미지 이름 .
- 빌드한 이미지를 환경에서 한번 실행해본다.
docker run -p 8080:8080 이미지 이름 .
- 빌드한 이미지에 태그를 붙히고, 업로드할 장소인 ECR 주소와 이미지를 매핑시키고,
docker tag 이미지 이름 + ECR주소
- ECR 에 푸시하기.
docker push 이미지 이름
이렇게 일련의 과정을 거쳐서 진행했었는데 여기서 함정이 있다.
나는 내가 빌드한 이미지가 잘 되는지를 테스트하기 위해서 docker run 을 해보고
그 이미지가 잘 실행되는지 여부까지 확인하고 배포했다고 생각해서 문제가 없었다고 여겼었지만, 실제로는 스택오버플로우와 같은 문제가 있었던 것이다.
해결
docker build --platform linux/amd64 --no-cache 이미지이름
결론만 말하자면 빌드할때에 다음과 같이 빌드를 하면 위 에러는 더이상 나오지 않는다.
사실 아이러니하게도 디버깅을 하던 중 이걸 해결한 방향이 좀 웃음벨인데,
이전에 내가 블로그에서 나만 따로 보기위해 써놨던 배포과정을 정리하는 내용중에서, 지금과 동일한 상황의 에러를 맞은적이 있었고
그때에는 정말 우연찮게 배포의 안정성을 중요시한다고 linux/amd64 를 추가해놓은것을 이번 배포에서는 깜빡하고 누락한 것이였다. (인간은 늘 역시 같은 실수를 반복한다..ㅠㅠㅠ)
박터지게 찾아보고 다른 원인들이 있나 확인할 시간을 줄여주고, 이전에 시도했던 방법중 하나에서 솔류션이 있었던 것이다.
어찌보면 같은 문제를 또 겪은거라 공부가 부족했을수도 있고, 단순한 휴먼에러라고 볼수도 있지만, 오히려 내가 시도했던것 혹은 아는것을을 간략하게라도 작성해놓는게 얼마나 큰 도움이 되는지를 새삼 한번 더 느끼게 된 것 같다.
의외로 문제의 원인을 외부에서만 찾기보단 어차피 내가 문제니깐(?) 스스로 작성하는 기록이 큰 도움을 준 좋은 사례인것 같다.
