배포를 해볼까-6

저번 포스팅에 이어서 작성해본다.

저번에 도커에 이미지를 띄우고 컨테이너도 만들어서, 거기에 내 프로젝트를 git clone 하고, 환경변수까지 적용을 성공했다.

그래서 docker logs {컨테이너ID} 명령어를 입력하면
내 프로젝트가 정상적으로 실행되고 있는 로그를 확인 할 수 있었다.

그런데, 막상 포스트맨으로 테스트해보려고하는데, 타임아웃이 떠서, 테스트를 할 수 없었다.

그래서 gpt에게 왜 안되는지 할 수 있는 방법을 물었다.
gpt의 답변은 아래와 같다.

1. 도커 호스트 네트워크 모드: EC2 인스턴스에서 Docker 컨테이너를 실행할 때, 도커의 호스트 네트워크 모드를 사용하는지 확인하세요. 호스트 네트워크 모드는 컨테이너를 도커 호스트의 네트워크와 동일하게 실행하므로, 도커 호스트의 포트가 컨테이너의 포트와 바인딩되어야 합니다.
2. SELinux 또는 AppArmor: 일부 리눅스 배포판에서는 SELinux 또는 AppArmor와 같은 보안 모듈이 작동 중일 수 있습니다. 이러한 보안 모듈이 애플리케이션 실행에 영향을 줄 수 있으므로, 해당 모듈을 비활성화하거나 애플리케이션에 필요한 권한을 제공해야 할 수 있습니다.
3. Docker 컨테이너 내부 포트 확인: Docker 컨테이너 내부에서 Spring 애플리케이션을 올바른 포트로 실행하는지 다시 확인하세요. Spring 애플리케이션이 8080 포트로 실행되도록 설정되어 있는지 확인하고, 컨테이너 내부에서 애플리케이션에 접근할 수 있도록 설정되어야 합니다.
4. EC2 인스턴스에 다른 서비스나 프로세스가 8080 포트를 사용 중인지 확인: EC2 인스턴스에서 다른 서비스나 프로세스가 이미 8080 포트를 사용 중이라면, Spring 애플리케이션이 해당 포트를 사용하지 못하고 타임아웃이 발생할 수 있습니다. 다른 프로세스가 8080 포트를 사용 중인지 확인하세요.
5. Spring 애플리케이션 로그 추가: Spring 애플리케이션 로그에 더 많은 정보를 기록하여 문제의 원인을 찾을 수 있습니다. 더 자세한 디버깅 정보를 로그에 기록하고, 애플리케이션 실행 중에 추가 정보를 로깅하도록 설정해 보세요.
6. EC2 인스턴스의 보안 그룹과 서브넷 확인: 보안 그룹 외에도 EC2 인스턴스가 올바른 서브넷에 있는지 확인하세요. 잘못된 서브넷에 인스턴스가 위치하면 네트워크 통신에 문제가 발생할 수 있습니다.

 

2번 해결법으로 docker run -d -p 8080:8080 --env-file app.env --security-opt=apparmor:unconfined knockknock
이렇게 돌려봐도 여전히 ETIMEDOUT이 뜬다.

curl 명령어로 API를 테스트해보면 잘 된다. 하지만 postman에서는 안된다. 뭐가 문제일까?

아!!!!!!!!!!!!!!!!!!진짜 머리가 터질거같다.

도커를 포기하고 그냥 EC2인스턴스 내에다가 클론받고 배포를 끝내고 싶은마음이 든다...
주변에 물어볼 수 있는 사람들에게 모두 물어봤는데 아직 답장이 안왔다.

정말 궁금하다. 포스트맨에서는 안되는데 왜 curl 명령어로는 될까?

 

친구의 조언으로 브릿지 모드가 아닌 호스트모드로 해봤다.

이렇게 해서 api를 호출해보자!

....이렇게 해도 안된다....

진짜 멘탈이 나가도 너무나간다!!